持ち込みgRPC:分散リンク追跡gRPC-Opentracing-Zipkin

原文アドレス:gRPC持ち込み:分散リンク追跡gRPC+Opentracing+Zipkinプロジェクトアドレス:https://github.com/EDDYCJY/go...
前言
実際の応用の中で、あなたはそんなに多くのServer端をして、N個のRPC方法を書きました.方法の指標を見たいのに、手がつけられないのか.
本文はgRPC+Opentracing+Zipkinを通じて分布式リンク追跡システムを構築し、システム全体のリンク、性能などの指標を表示することを実現する.
Opentracing
何だ?
OpenTracingは,プラットフォームに関係なく,メーカーに関係のないAPIを提供することで,開発者が追跡システムの追加(または交換)を容易に行うことができる.
しかしOpenTracingは標準ではありません.CNCFは公式の標準機関ではないため、分散追跡のためにより標準的なAPIとツールを作成することを目標としています.
名詞の解釈
Trace
1つのtraceは、(分散)システムにおけるトランザクションまたはプロセスの実行プロセスを表します.
Span
1つのspanは、分散システムで完了した単一の作業ユニットを表す.他のspanの「参照」も含まれており、複数のspansを完全なトレースに組み合わせることができます.
各spanはOpenTracing仕様に従って以下の内容をカプセル化する.

操作名

開始時間および終了時間

key:value span Tags

key:value span Logs

SpanContext

Tags
Span tags(スパンラベル)は、ユーザがカスタマイズしたSpanコメントとして理解できる.トレース・データのクエリー、フィルタリング、理解が容易
Logs
Span logs(スパンログ)は、Span内の特定の時間またはイベントのログ情報を記録することができる.主に特定のSpanのログ情報とアプリケーション自体の他のデバッグまたは情報出力を取得するために使用されます.
SpanContext
SpanContextはプロセス境界を越えてサブレベルSpanに渡される状態を表す.トレースイメージにコンテキストを作成するときによく使用されます
Baggage Items
Baggage Itemsは、traceグローバル実行において追加的に伝送されるデータのセットとして理解できる
1つのケース
図には、次の内容が表示されます.

実行時間のコンテキスト

サービス間の階層関係

サービス間シリアルまたはパラレルコールチェーン

以上の情報を組み合わせると,実際のシーンではシステム全体の呼び出しチェーンのコンテキスト,性能などの指標情報を通じて,システムの痛み点がどこにあるかを一気に発見することができる.
Zipkin
何だ?
Zipkinは分散型追跡システムである.その役割は、マイクロサービスアーキテクチャにおける遅延問題を解決するために必要なタイミングデータを収集することである.これらのデータの収集と検索を管理します.
ZipkinのデザインはGoogle Dapper論文に基づいている.
うんてん

docker run -d -p 9411:9411 openzipkin/zipkin

その他の方法のインストールについては、次を参照してください.https://github.com/openzipkin...
検証＃ケンショウ＃
アクセスhttp://127.0.0.1:9411/zipkin/ Zipkinが正常に動作しているかどうかを確認
gRPC + Opentracing + Zipkin
前のセクションでは、次の準備をしました.

Opentracingとは何かを知る

Zipkinは分布式追跡システムの機能を提供する

を構築する.
次に、gRPCがOpentracing標準APIを介してZipkinとドッキングし、Zipkinを介してデータを表示することを実現する.
ディレクトリ構造
新しいsimple_zipkin_client、simple_zipkin_サーバディレクトリ、ディレクトリ構造は次のとおりです.

go-grpc-example
├── LICENSE
├── README.md
├── client
│   ├── ...
│   ├── simple_zipkin_client
├── conf
├── pkg
├── proto
├── server
│   ├── ...
│   ├── simple_zipkin_server
└── vendor

インストール

$ go get -u github.com/openzipkin/zipkin-go-opentracing
$ go get -u github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc

gRPC
Server

package main

import (
    "context"
    "log"
    "net"

    "github.com/grpc-ecosystem/go-grpc-middleware"
    "github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc"
    zipkin "github.com/openzipkin/zipkin-go-opentracing"
    "google.golang.org/grpc"

    "github.com/EDDYCJY/go-grpc-example/pkg/gtls"
    pb "github.com/EDDYCJY/go-grpc-example/proto"
)

type SearchService struct{}

func (s *SearchService) Search(ctx context.Context, r *pb.SearchRequest) (*pb.SearchResponse, error) {
    return &pb.SearchResponse{Response: r.GetRequest() + " Server"}, nil
}

const (
    PORT = "9005"

    SERVICE_NAME              = "simple_zipkin_server"
    ZIPKIN_HTTP_ENDPOINT      = "http://127.0.0.1:9411/api/v1/spans"
    ZIPKIN_RECORDER_HOST_PORT = "127.0.0.1:9000"
)

func main() {
    collector, err := zipkin.NewHTTPCollector(ZIPKIN_HTTP_ENDPOINT)
    if err != nil {
        log.Fatalf("zipkin.NewHTTPCollector err: %v", err)
    }

    recorder := zipkin.NewRecorder(collector, true, ZIPKIN_RECORDER_HOST_PORT, SERVICE_NAME)

    tracer, err := zipkin.NewTracer(
        recorder, zipkin.ClientServerSameSpan(false),
    )
    if err != nil {
        log.Fatalf("zipkin.NewTracer err: %v", err)
    }

    tlsServer := gtls.Server{
        CaFile:   "../../conf/ca.pem",
        CertFile: "../../conf/server/server.pem",
        KeyFile:  "../../conf/server/server.key",
    }
    c, err := tlsServer.GetCredentialsByCA()
    if err != nil {
        log.Fatalf("GetTLSCredentialsByCA err: %v", err)
    }

    opts := []grpc.ServerOption{
        grpc.Creds(c),
        grpc_middleware.WithUnaryServerChain(
            otgrpc.OpenTracingServerInterceptor(tracer, otgrpc.LogPayloads()),
        ),
    }
    ...
}

zipkin.NewHTTPCollector:Zipkin HTTPバックエンドコレクタ

を作成する

zipkin.NewRecorder:Zipkinコレクタベースのレコーダ

を作成する

zipkin.NewTracer:OpenTracingトラッカー(Zipkin Tracer対応)を作成する

otgrpc.OpenTracingClientInterceptor:grpcを返す.UnaryServerInterceptorでは、ブロッキングがgRPC MetadataでOpenTracing SpanContextを検索する点が異なります.サービスのためのSpan Contextのサブノード

が見つかった場合

otgrpc.LogPayloads:設定してOptionに戻ります.アプリケーションのペイロード

をOpenTracingに双方向に記録させる役割を果たす.
総じて、コレクタ、レコーダ、トラッカーを含むZipkinを初期化する.ブロッキングを再利用してサーバ側でSpanContext、Payloadの双方向読み取りと管理を実現
Client

func main() {
    // the same as zipkin server
    // ...
    conn, err := grpc.Dial(":"+PORT, grpc.WithTransportCredentials(c),
        grpc.WithUnaryInterceptor(
            otgrpc.OpenTracingClientInterceptor(tracer, otgrpc.LogPayloads()),
        ))
    ...
}

otgrpc.OpenTracingClientInterceptor:grpcを返す.UnaryClientInterceptor.このブロッキングの核心機能は、

である.
(1)OpenTracing SpanContext注入gRPC Metadata
(2)contextを表示する.Contextのコンテキスト関係は、親Spanが存在する場合はChildOf参照を作成し、サブSpanを得る
その他、サーバ側と一致し、Zipkinを初期化してからClient側特需のブロッキングを追加します.基礎的な仕事ができるようになりました
検証＃ケンショウ＃
サーバーを起動します.go,Client.go.http://127.0.0.1:9411/zipkin/の概略図を表示します.
複雑な点
さあ、自分で実践してみよう
まとめ
マルチサービス下のアーキテクチャでは、シリアル、パラレル、サービス・スイート・サービスは非常に一般的な状況であり、従来のシナリオでは問題がどこにあるか(コストが大きすぎる)を発見するのは難しいことが多い.このような状況は分布式追跡システムが拳を伸ばす機会だ.
この章の紹介と学習を通じて、その概念を理解し、追跡システムを構築し、応用することを望んでいます.
リファレンス
このシリーズのサンプルコード

go-grpc-example

シリーズディレクトリ

gRPC持ち込み:gRPC及び関連紹介

は、gRPC:gRPC Client and Server

に持ち込む.

は、gRPC:gRPC Streaming、Client and Server

を導入します.

はgRPC:TLS証明書認証

を持ち込む.

gRPC持ち込み:CAベースTLS証明書認証

gRPC:Unary and Stream interceptor

に持ち込む

はgRPCを持ち込みます:あなたのサービスにHTTPインタフェース

を同時に提供させます.

gRPC持ち込み:RPCメソッドのカスタム認証

gRPC:gRPC Deadlines

に持ち込む

gRPC持ち込み:分散リンク追跡gRPC+Opentracing+Zipkin

資料

opentracing

zipkin