OpenTelemetryによるベンダーニュートラルな監視設定

OpenTelemetryについての社内勉強会で使用した資料になります。
OpenTelemetryを使って複数のバックエンドにデータを送ったり、
OCI上でOpenTelemetryを活用する構成について記載しています。
よろしくお願いいたします。

1. OpenTelemetryによる ベンダーニュートラルな監視設定 2023/11 李俊起
2. 内容 ▪OpenTelemetryとは ▪OpenTelemetry Collectorとは ▪デモ① Otel Collectorでバックエンド切替 ▪デモ② Otelを活用したOCI上の監視設定 ▪分散トレーシングとは ▪まとめ
3. OpenTelemetryとは
4. OpenTelemetryとは ▪ テレメトリーデータ(Trace, Metric, Log)収集/連携のために以下を提供 ➢ SDK/API ➢ Opentelemetry Collector ➢ OTLP ➢ etc. ▪ OpenTelemetry自体はバックエンドを持たない ➢ データ収集と連携の部分のみを担当 ▪ ベンダーに依存しない ▪ CNCFの中でKubernetesに次ぐ２番目に活発に開発が行われている(※) ➢ 様々なベンダーが開発に関わっていて、OpenTelemetryに対応している ※https://www.cncf.io/blog/2023/05/03/opentelemetry-demystified-a-deep-dive-into-distributed-tracing/
5. OTLP （OpenTelemetry Protocol） ▪ 各データ(Trace, Metric, Log)をやりとりするための 標準化されたOpentelemetry独自のProtocol ▪ ベースのプロトコルはHTTPとgRPCから選択可能 ▪ OTLPをネイティブにサポートするベンダーも増えている ➢ New Relic、OCI APMなど
6. OpenTelemetry Collectorについて
7. OpenTelemetry Collectorとは ▪ データ(Trace,Metric,Log)を①受け付けて②処理して③バックエンドに 流すエージェント ▪ 以下3つのコンポーネントから構成されている(※) ① Receivers ▪ 様々なフォーマットでデータを受け付ける ② Processors ▪ Exporterに流す前に処理をする（e.g. batch処理、Ａｔｔｒｉｂｕｔeの追加） ③ Exporters ▪ データを様々なフォーマットでバックエンドに送る ※Connectorについては割愛
8. フォーマット変換 ▪ 様々なフォーマットのデータ変換/送受信できる Receiver Processor Exporter New Relic X-Ray Cloud Watch Cloud Watch Logs OpenTelemetry Collector ・ ・ ・ ※利用可能なReceiver/Processor/Exporter一覧 Registry | OpenTelemetry otlp datadog awsxray awsemf fluentforward otlp prometheus Fluent Bit OpenTelemetry exporter ・ ・ ・ Fluentd
9. デモ① OpenTelemetry Collectorでバックエンド切替
10. やること ▪ デモ用アプリ(※)を使ってTrace,Metric,Logを OpenTelemetry Collectorで以下のバックエンドに連携 1. New Relic 2. AWS X-Ray、CloudWatch、CloudWatch Logs 3. OSS(Jaeger、Cortex、Loki) spring-projects/spring-petclinic: A sample Spring-based application (github.com)
11. 構成図 EC2 Instance EC2 Instance Fluent Bit OpenTelemetry OpenTelemetry Collector New Relic EC2 Instance Jaeger Loki Cortex exporter X-Ray Cloud Watch Cloud Watch Logs Metrics Logs Traces otlp fluentforward otlp prometheus awsxray awsemf otlp loki awscloudwatchlogs prometheusremotewrite
12. デモ② Otelを活用した OCI上の監視設定
13. やること 1. OCIマネージドサービスをフル活用した監視設定パターン １－１． 以下のOCIマネージドサービスにデータを連携 ▪ Trace： OCI APM ▪ Metric： OCI Monitoring ➢ management agentで各exporterのメトリクスをＯＣＩ Ｍｏｎｉｔｏｒｉｎｇに変換(連携) ▪ ログ： OCI Logging ➢ unified monitoring agentを使ってサーバ上のログをOCI Loggingに連携 １－２． Connector Hubを使ってLoggingのログをメトリクスに変換し、 アラームを設定してアラートを発火させる 2. New Relic利用パターン ➢ New Relicにデフォルトでは連携できないOCI Monitoringのメトリクスは OCI Monitoring SDKを用いた自作のExporterでNew Relicに連携する
14. OCIマネージドサービスフル活用シナリオ ▪ OCI Managed Serviceをフル活用し、OCI上で完結 OCI Monitoring Alarms OCI Logging Connector Hub OCI APM OCI VM OpenTelemetry Notifications Unified Monitoring Agent (Fluentdベース) Management Agent Functions Metrics Logs Traces exporter E-mail HTTP （Webhook）
15. OCIマネージドサービスの感想 ▪ 料金が安い OCI AWS Datadog ログ 0.05$/GB ※収集や検索など区分なし 収集 0.76$/GB 保存 0.033$/GB 検索 0.0076$/GB 分析(Live Tail) 0.01$/分 収集 0.13$/GB 保存/検索 3.13$/100万ログ ※30日保存基準 メトリクス 収集 0.0025$/100万 DataPoint 検索 0.0015$/100万 DataPoint 収集 0.30～0.02$/メトリクス ※メトリクス数が多くなるほど安くなる 検索 0.01$/1,000件メトリクス 28.75$/ホスト トレース 0.65$/時間 ※100,000 events per hour(？) 収集 5$/100万件 検索 0.5$/100万件 50$/ホスト https://www.oracle.com/cloud/price-list/#pricing-observability ※無料枠は考慮しない
16. OCIマネージドサービスの感想 ▪ ログが500件までしか表示されない(※) ▪ ログに対するアラートと1対1で Connector Hubのメトリクスへの変換設定が必要 ▪ ログがLoggingに連携されるまで3分程遅延がある ➢ Connector Hubにメトリクスが連携される時間も影響される ▪ ログの検索に正規表現を使えない（ワイルドカードは使用可） ➢ 柔軟なアラート設定が困難 ▪ アラートの回復通知がない ➢ 再通知で回避? ※Grafana OCI Logsプラグインでは2万件まで(?)
17. SaaS＆OSSツール導入シナリオ ▪ OCI Monitoringでしか確認できないManaged Serviceのメトリクスを OCI SDKを使って自作のExporter(※)を作成し、Otel Collectorで収集 OCI VM exporter Fluent Bit OpenTelemetry OpenTelemetry Collector New Relic OCI Monitoring exporter (※) OCI Monitoring OCI VM Metrics Logs Traces OCI SDK
18. OCI Loggingの3rd partyツールへの連携 ▪ Connector HubでStreamingに連携し、 そこから更に別のバックエンドに連携することもできる ・Service Connector Hub 概要 - Speaker Deck ・OCI Streaming 概要 - Speaker Deck OCI Logging Connector Hub Streaming Kafka互換API Fluent Bit New Relic Loki OR OR OR etc.
19. 分散トレーシングとは
20. 分散トレーシングとは ▪ ユーザからのリクエストによる様々な処理をEnd-to－Endで追跡する技術 ▪ Span ➢ 1つのリクエストの中で実行される処理単位 ▪ Trace ➢ 同じTrace IDを持つSpanの集合体。 リクエストごとに一意のTrace IDが割り当てられ、 １つのリクエストの中のSpan(処理)は同じTrace IDを共有する。
21. 分散トレーシングのイメージ スマホ購入アプリ （マイクロサービス） 在庫 確認 注文 決済 Span1 Span2 Span3 Span4 1つのリクエスト(処理)のTrace Trace ID = aaaa Span ID = bbb Trace ID = aaaa Span ID = ccc Parent Span ID = bbb Trace ID = aaaa Span ID = ddd Parent Span ID = ccc Trace ID = aaaa Span ID = eee Parent Span ID = ddd Trace IDとSpan ID (+Trace flag) を後続処理に伝搬 認証
22. Traceデータ生成/バックエンド送信 ① ③ ①～④を繰り返し Java Application H T T P H T T P OpenTelemetry SDK/ Auto Instrumentation Header ------------- Trace ID: xxx Span ID : xxx ・ ・ Header ------------- Trace ID: xxx Span ID : xxx ・ ・ ② ④ Backend MicroService X Contextが含まれている ヘッダーが連携される ヘッダーにある Contextを抽出する SDK等によって生成された処理に関するデータと、 Trace ID/Span ID等が含まれる TraceデータをBackendに送る 新たに生成されたContextを ヘッダーに格納する ※OpenTelemetry java Auto Instrumentationの仕組みについて https://valinux.hatenablog.com/entry/20211209
23. 分散トレーシングのビュー ▪ Service Map ➢ 各Span間の相関図 ▪ タイムラインビュー ➢ 各Spanを時間軸で表示 ※図の出典 https://hackernoon.com/ja/%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%E3%81%AE%E9%81%8E%E5%8E%BB%E7%8F%BE%E5%9C%A8%E3%81%A 8%E6%9C%AA%E6%9D%A5
24. まとめ
25. OpenTelemetryに揃える！ ▪ 最初からOpenTelemetryを組み合わせた構成にして、 バックエンドを柔軟に選択/切り替えできるようにする ▪ 今後Profileも追加される予定で、 よりアプリケーションに近い部分の観測もできるようになるかも