オブザーバビリティの Primary Signals

2024-04-10 OpenTelemetry Observability運用の実例 Lunch LT
https://findy.connpass.com/event/313260/

Transcript

1. オブザーバビリティの Primary Signals id:onk 2024-04-10 OpenTelemetry Observability運用の実例 Lunch LT 1
2. 自己紹介 • 大仲 能史 a.k.a. id:onk • 株式会社はてな ◦ チーフエンジニア ◦ Mackerel開発チーム 2
5. 5 今日の話
6. 6 オブザーバビリティの Primary Signals
7. オブザーバビリティのPrimary Signals 7 https://github.com/cncf/tag-observability/blob/whitepaper-v1.0.0/whitepaper.md
8. オブザーバビリティのPrimary Signals • Metrics: システムの健康状態を高レベルで示す • Logs: イベントの詳細を提供する • Traces: リクエストの流れを追跡する • … 8
9. 9 Primary Signalsは、大局 から詳細までシステムを多 角的に理解するために必要
10. メトリックの良いところ • パフォーマンス、効率性 ◦ ログやトレースを大量に収集・分析するのは重い ◦ お金がかかる 10 https://dev.henry.jp/entry/observability-and-cost
11. メトリックの良いところ • 監視やトレンド分析の容易性 ◦ 数値なので異常値の検出やアラート設定が容易で、 監視しやすい、可視化しやすい ◦ ダッシュボードを構築して、システムの健康状態を 一目で把握できる ◦ 長期的なパフォーマンス変化を追跡できる 11
12. 最近目にするオブザーバビリティ • トレース・ログに重心が寄っている ◦ メトリックは既存の監視で既にカバーされている領域 ◦ オブザーバビリティを高めるには、現状のメトリックだ と詳細度が足りないことも多い • とはいえPrimary Signalsなので大事 ◦ コストが安いし、キャパシティプランニングや ふりかえりに必要 12
13. Primary Signals • メトリック ◦ システム全体の健康とパフォーマンスの概要 システムが期待通りに機能しているかを把握する • ログ ◦ 何が起きているか、どのように発生しているのかの詳細 • トレース ◦ システムの内部動作とリクエストの流れを理解するビュー 複雑な問題の診断に有効 13
14. 14 OpenTelemetryで メトリックを収集する
15. OpenTelemetryでメトリックを収集 • 既存の監視が既に構築されている ◦ メトリックを収集できていて、直ちに困ってはいない • OpenTelemetryになるとここが嬉しい ◦ メトリックがAttributeを持つのでO11yを高めやすい ◦ 将来的にOTelがメトリック収集方法の標準になる見込み ◦ 他のテレメトリーデータとの相互操作性 ▪ 例えばメトリックの異常値からトレースに簡単に遷移するとか 15
16. 16 どうやって始めれば？
17. 17 OpenTelemetry Collectorを使え
18. OpenTelemetry Collector 18 https://opentelemetry.io/docs/collector/ https://opentelemetry.io/docs/
19. OpenTelemetry Collector • Receiver ◦ Collectorがデータを受信する方法を提供する ◦ LISTENするだけじゃなく、ポーリングも可能 19
20. ホストメトリックの計装 • ホストメトリック ◦ CPU使用率 ◦ メモリ使用率 ◦ ディスク使用率 ◦ ネットワーク I/O ◦ … 20
21. ホストメトリックの計装 • Host Metrics Receiverを使う • OpenTelemetry Collectorのreceiversに設定 すると、自身のホストメトリックを収集できる 21
22. ホストメトリックの計装 22 https://mackerel.io/ja/blog/entry/tech/sending-host-metrics-to-mackerel-with-opentelemetry-collector
23. ミドルウェアのメトリックの計装 • ミドルウェアのメトリック ◦ nginx ◦ MySQL ◦ Redis ◦ Elasticsearch ◦ … 23
24. ミドルウェアのメトリックの計装 • OpenTelemetry Collector Contribにある 24
25. ミドルウェアのメトリックの計装 • OpenTelemetry Collector Contribにある 25 https://kmuto.hatenablog.com/entry/2024/03/24/215200
26. ミドルウェアのメトリックの計装 • ポーリングするReceiverの作り ◦ 既にあるエンドポイントからメトリックを収集 ▪ nginxならhttp_stub_status moduleで出力している ◦ 収集したメトリックをOpenTelemetry形式に変換 ◦ 収集する頻度はカスタマイズ可能 26
27. アプリケーションのメトリックの計装 • アプリケーションのメトリック ◦ アクティブユーザー数 ◦ データベースの応答時間 ◦ キャッシュヒット率 ◦ … 27
28. アプリケーションのメトリックの計装 • 自動計装はまだまだ足りない ◦ 例えばOpenTelemetry Ruby Contribにメトリックの 自動計装は存在していない 28
29. アプリケーションのメトリックの計装 29
30. 30 それでも自動計装に なるべく乗りつつ メトリックが欲しい！
31. 31 Span Metrics Connector
32. Connectorとは • ReceiverとExporterの2つの役割を持つ • 異なるテレメトリーパイプラインを繋ぎ合わ せる 32 https://opentelemetry.io/docs/collector/building/connector/
33. Connectorとは • OpenTelemetry Casual Talkも見てね 33 https://speakerdeck.com/rnakamine/building-a-servicemap-with-service-graph-connector
34. Span Metrics Connectorとは • トレースからメトリックを生成する ◦ R.E.D メソッドのメトリックを収集できる ◦ Request, Error, Duration 34
35. Span Metrics Connectorとは • トレースは自動計装されている ◦ 主にシステム境界でspanが切られている ▪ HTTPリクエスト ▪ SQLの実行 • トレースを集計するとメトリックになる ◦ Request数、Error数、Duration(histogram) 35
36. メトリックを収集したら • メトリックを集計するとダッシュボードになる ◦ どこに時間が掛かっているのか可視化したい ▪ HTTPリクエストやSQLの実行に掛かった時間を積み上げグラ フに ◦ 特定のクエリにかかった時間のパーセンタイル表示 ▪ 各Durationをhistogramで保存しているので、計算可能 36
37. 37 OpenTelemetryで メトリックを収集する その他の方法
38. その他の方法 • 既存のプラグインを利用する ◦ 各バックエンド向けに実装されたプラグインを活用して 今まで通りにメトリックを収集する ◦ 各バックエンド向けに実装されたReceiverに送信する と、メトリックをOpenTelemetryに加工し、ラベル付 きメトリックとしてバックエンドに送信する 38
39. その他の方法 39 https://sfujiwara.hatenablog.com/entry/maprobe-otel-metrics • 既存のバックエンド向けのエージェントから OTLPで送信する
40. 40 まとめ
41. まとめ • 各Primary Signalの立ち位置 ◦ メトリックは引き続き大事 • OpenTelemetryでのメトリック収集の始め方 ◦ CollectorにReceiverを入れると収集できるよ ◦ SpanMetricsConnectorで始めることもできる 41