Dapr の可観測性メトリックとログ

この記事では、インジケーターとログのサポートについて紹介します。

索引

メトリクスにより、アプリのパフォーマンスとリソース消費量を把握できます。舞台裏では、Dapr はさまざまなシステムおよびランタイム メトリックのコレクションを出力します。 Dapr はメトリクス標準として Prometheus を使用し、Dapr とシステム サービスはポート 9090 でメトリクス データを公開します。Prometheus スクレーパーは、定義済みの時間間隔でこのインターフェイスを呼び出して、インジケーター データを収集します。スクレーパーは、以下に示すように、インジケーターの値を監視バックエンドに送信します。

Prometheus メトリックをスクレイピングする

メトリック スクレーパーがメトリックを収集する場所をどのように認識するのか疑問に思うかもしれません。 Prometheus は、ターゲットのデプロイメント環境に組み込まれた検出メカニズムと統合できます。たとえば、Kubernetes で実行する場合、Prometheus は Kubernetes API と統合して、環境内で実行されている利用可能なすべての Kubernetes リソースを見つけることができます。

Dapr は、次の表に示すように、Dapr システム サービスとそのランタイムに関するさまざまなメトリックを生成します。

Dapr インジケーター

実行時に、Dapr コマンドに --enable-metrics=false 引数を含めることでメトリックの収集を無効にするか、--metrics-port 9090 引数を使用してメトリック エンドポイントの既定のポートを変更できます。

また、アプリケーションのデプロイメントに dapr.io/enable-metrics: "false" アノテーションを設定することで、特定のアプリケーションのメトリック エクスポーターを無効にすることもできます。メトリック エクスポーターを無効にすると、daprd はメトリック リスニング ポートを開きません。次の例では、ポートを 9090 として指定してメトリックを明示的に有効にしています。

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: ノードアプリ
仕様:
 セレクター:
 マッチラベル:
 アプリ: ノード
テンプレート：
 メタデータ:
 ラベル:
 アプリ: ノード
注釈:
 ダップル。 io / 有効: "true"
 dapr .io / アプリ- ID : "nodeapp"
 dapr .io / アプリ- ポート: "3000"
 dapr .io / 有効化- メトリック: "true"
 dapr .io / メトリック- ポート: "9090"
 仕様:
 コンテナ:
 - 名前: ノード
画像: dapriosamples / hello - k8s - node : 最新
ポート:
 - コンテナポート: 3000
 imagePullPolicy : 常に

Dapr 構成ファイルを使用して、ランタイム メトリックの収集を有効または無効にすることもできます。

 apiバージョン: dapr .io / v1alpha1
 種類: 構成
メタデータ:
 名前: dapr - config
 仕様:
 トレース:
 サンプリングレート: "1"
 メトリック:
 有効: false

Prometheus スクレーパーがメトリックを収集し、監視バックエンドに公開した後、Grafana を使用して、Dapr システム サービスとサイドカーの監視を含むダッシュボードを作成できます。 Dapr を監視するために、Dapr が提供するダッシュボード テンプレートを直接インポートできます。アドレスは https://github.com/dapr/dapr/tree/master/grafana で、3 つのダッシュボードが含まれています。

• Dapr システム サービス ステータス - dapr-operator、dapr-sidecar-injector、dapr-sentry、および dapr-placement
• Dapr サイドカー ダッシュボード - サイドカーの健全性/リソース、HTTP および gRPC のスループット/レイテンシ、アクター、mTLS などを含む Dapr サイドカーのステータスを表示します。
• Dapr アクター ダッシュボード - アクター呼び出しのスループット/レイテンシ、タイマー/リマインダー トリガー、ラウンドベースの同時実行性など、Dapr サイドカーのステータスを表示します。

したがって、まず Prometheus と Grafana をインストールし、Kubernetes に基づいて Prometheus の自動検出を構成し (エンドポイントとポッドの両方を構成する必要があります)、Prometheus を Grafana のデータ ソースとして構成する必要があります。ここでは、次の 2 つのアプリケーションをすでに導入しています。

 $ kubectl get svc - n kube - mon
 名前タイプクラスタ- IP 外部- IP ポート( S ) 年齢
グラファナノードポート10.99 .209 .245 < なし> 3000 : 30403 / TCP 39 d
 プロメテウスNodePort 10.100 .236 .253 < なし> 9090 : 31561 / TCP 81 d
 $ kubectl ポッドの取得- n kube - mon
 名前準備完了ステータス再起動年齢
grafana - d877667d6 - 4 vgnd 1 / 1 実行中25 ( 60 分前) 39 日
ノード- エクスポーター- 49l 4f 1 / 1 実行中48 ( 60 分前) 81 日
ノード- エクスポーター- khqls 1 / 1 実行中46 ( 60 分前) 81 日
ノード- エクスポーター- wjwtb 1 / 1 実行中47 ( 60 分前) 81 日
プロメテウス- 649968556 c - szb9c 1 / 1 実行中11 ( 60 分前) 14 日

Prometheus は自動検出用に構成されているため、Dapr アプリケーションのメトリックはデフォルトで自動的にキャプチャされます。これらは Prometheus のターゲット リストで見つけることができます。

プロメテウスのターゲット

次に、https://github.com/dapr/dapr/tree/master/grafana で提供されている 3 つのダッシュボードをそれぞれ Grafana にインポートできます。

インポートダッシュボード

ただし、インポート後すぐにダッシュボードが表示されない場合があります。データ ソースを実際に構成されたデータ ソースに変更するには、いくつかの変更が必要です。

テンプレートを変更する

システムを構成すると、ダッシュボードのデータを正常に表示できるようになります。以下は、Dapr システム サービスのメトリックを表示するダッシュボードの例です。

ダッシュボード

ログ

ログにより、実行時にサービスで何が起こっているかを把握できます。アプリケーションを実行すると、Dapr は Dapr サイドカーおよび Dapr システム サービスからログ データを自動的に出力します。ただし、アプリケーション コードに記録されたログは自動的には含まれません。アプリケーション コードからログを出力するには、OpenTelemetry SDK などの特定の SDK をインポートできます。

Dapr は構造化されたログを出力し、各ログ エントリは次の形式になります。

dapr ログ形式

時間とレベルのフィールドは、トラブルシューティングの際に非常に役立ちます。時間フィールドではログ エントリが並べ替えられるため、特定の期間を正確に見つけることができます。トラブルシューティングを行う際、デバッグレベルのログ エントリによって、コードの動作に関する詳細な情報が提供されます。

また、デフォルトでは、Dapr は構造化されたログ データをプレーン テキスト形式で出力します。各ログエントリは、キーと値のペアを含む文字列としてフォーマットされます。以下はプレーンテキスト形式のログレコードの例です。

 time = "2020-03-11T17:08:48.303776-07:00" level = info msg = "Dapr ランタイムを開始しています -- バージョン 0.5.0-rc.3 -- コミット v0.3.0-rc.0-155-g5dfcf2e" instance = dapr - pod - xxxx scope = dapr . ランタイムタイプ= ログバージョン= 0.5 .0 -rc.3
 time = "2020-03-11T17:08:48.303913-07:00" level = info msg = "ログ レベルが info に設定されました" instance = dapr - pod - xxxx scope = dapr . ランタイムタイプ= ログバージョン= 0.5 .0 - rc .3

この形式は単純ですが、解析するのは困難です。ログ収集ツールを使用する場合、JSON 形式のログの方が解析しやすくなります。 JSON エントリを使用する場合、ログ ツールは個々のフィールドにインデックスを付けてクエリを実行できます。以下は JSON 形式の同じログ エントリです。

 { "instance" : "dapr-pod-xxxx" 、 "level" : "info" 、 "msg" : "Dapr Runtime を開始しています -- バージョン 0.5.0-rc.3 -- コミット v0.3.0-rc.0-155-g5dfcf2e" 、 "scope" : "dapr.runtime" 、 "time" : "2020-03-11T17:09:45.788005Z" 、 "type" : "log" 、 "ver" : "0.5.0-rc.3" }
 { "instance" : "dapr-pod-xxxx" 、 "level" : "info" 、 "msg" : "ログ レベルが info に設定されました" 、 "scope" : "dapr.runtime" 、 "time" : "2020-03-11T17:09:45.788075Z" 、 "type" : "log" 、 "ver" : "0.5.0-rc.3" }

JSON フォーマットを有効にするには、各 Dapr サイドカーを構成する必要があります。セルフホスト モードでは、コマンド ラインでフラグ --log-as-json を指定できます。

 dapr run --app - id nodeapp --log - level info --log - as - json node app 。 ​ ​ js

Kubernetes では、次のようにアプリケーションの各デプロイメントに dapr.io/log-as-json アノテーションを追加できます。

 注釈:
 ダップル。 io / 有効: "true"
 dapr .io / アプリ- id : "calculator-front-end"
 dapr.io/app - ポート: " 80 "
 dapr .io / config : "dapr-config"
 dapr .io / ログ- as - json : "true"

Helm を使用して Kubernetes クラスターに Dapr をインストールする場合、すべての Dapr システム サービスに対して JSON 形式でのログ記録を有効にすることができます。

 helm リポジトリにdapr を追加しますhttps://dapr.github.io/helm-charts/
 helm リポジトリの更新
kubectl 名前空間dapr を作成- システム
helm install dapr dapr / dapr --namespace dapr - system --set global を実行します。 logAsJson = true

Dapr によって出力されたログは、分析のために監視バックエンドに送ることができます。ログ コレクターは、システムからログを収集し、監視バックエンドに送信するコンポーネントです。よく使われるログコレクターは Fluentd です。前回のコースでは、Kubernetes で Fluentd、Elastic search、Kibana を設定してログを収集する方法を紹介しました。詳細については、公式ドキュメント https://docs.dapr.io/operations/monitoring/logging/fluentd/ を直接参照することもできます。

運用状況

サービスの健全性ステータスは、サービスの可用性に関する洞察を提供します。各 Dapr サイドカーは、ホスト環境がサイドカーの健全性を判断するために使用できる健全性 API を公開します。

 GET http : //localhost:3501/ v1.0/healthz

この操作は、2 つの HTTP ステータス コードを返します。

• 204: サイドカーが正常に走行する場合。
• 500: サイドカーが正常に機能していません。

自己管理モードで実行している場合、ヘルス API は自動的には呼び出されませんが、アプリケーション コードまたはヘルス監視ツールによって呼び出すことができます。

Kubernetes で実行する場合、Dapr サイドカー インジェクターは、ヘルス API を使用してライブネス プローブと準備プローブを実行するように Kubernetes を自動的に構成します。

Kubernetes は、コンテナが起動して実行されているかどうかを判断するためにライブネス プローブを使用します。ライブネスプローブが失敗コードを返す場合、Kubernetes はコンテナが停止していると想定し、コンテナを自動的に再起動します。この機能により、アプリケーションの全体的な可用性が向上します。

Kubernetes は、準備プローブを使用して、コンテナがトラフィックの受け入れを開始する準備ができているかどうかを判断します。 Pod のすべてのコンテナの準備が整うと、準備完了とみなされます。準備状況によって、Kubernetes サービスが負荷分散シナリオでトラフィックを Pod にルーティングできるかどうかが決まります。準備ができていないポッドはロードバランサーから自動的に削除されます。

活性プローブと準備プローブにはいくつかの構成可能なパラメーターがあり、どちらも Pod マニフェスト ファイルのコンテナー仕様セクションで構成されます。 Dapr は、サイドカー コンテナーごとに、デフォルトで次の構成を使用します。

 ライブネスプローブ:
 httpGet : 取得:
 パス: v1.0 / healthz
 ポート: 3501
 初期遅延秒数: 5
 期間秒数: 10
 タイムアウト秒数: 5
 失敗しきい値: 3
 準備状況プローブ:
 httpGet : 取得:
 パス: v1.0 / healthz
 ポート: 3501
 初期遅延秒数: 5
 期間秒数: 10
 タイムアウト秒数: 5
 失敗しきい値: 3

プローブには次のパラメータを使用できます。

• パスは Dapr ヘルス API エンドポイントを指定します。
• port Dapr ヘルス API ポートを指定します。
• initialDelaySeconds は、Kubernetes がプローブ コンテナを初めて起動する前に待機する秒数を指定します。
• periodSeconds は、Kubernetes がプローブ間で待機する秒数を指定します。
• timeoutSeconds は、Kubernetes がタイムアウトする前に API 応答を待機する秒数を指定します。タイムアウトは失敗として解釈されます。
• failureThreshold は、コンテナが非アクティブまたは準備ができていないと判断する前に Kubernetes が受け入れる失敗ステータス コードの数を指定します。

詳細な観測可能性は、本番環境で分散システムを実行する上で非常に重要です。 Dapr は、分散トレース、ログ、メトリック、ヘルスなど、さまざまな種類のテレメトリを提供します。

Dapr は Dapr システム サービスとサイドカーのテレメトリ データのみを生成し、アプリケーション コード内のテレメトリは自動的には含まれないことに注意してください。ただし、特定の SDK を使用して、アプリケーション コードからテレメトリ データを出力することは可能です。

Dapr テレメトリはオープン スタンダード ベースの形式で生成されるため、さまざまな監視ツールで取り込むことができます。 Zipkin、Azure Application Insights、ELK Stack、New Relic、Grafana などが含まれます。さらに、Dapr は構造化されたログ レコードを出力するように構成できます。バックエンド監視ツールがインデックスを作成できるため、JSON 形式の構造化ログ データを使用することをお勧めします。ユーザーは、ログをインデックス化することで、ログ レコードを検索するときに豊富なクエリを実行できます。 Dapr は、Dapr サービスと構成に関する情報を表示するダッシュボードも提供します。