可観測性¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. 可観測性¶
可観測性とは¶
『収集されたデータから、システムと想定内と想定外 (想定できない) の両方の不具合を、どれだけ正確に推測できるか』を表す程度のこと。
システムの想定内の不具合は『監視』や『テスト (ホワイトボックステスト、ブラックボックステスト) 』によって検知できるが、想定外のものを検知できない。
可観測性は、監視やテストも含むスーパーセットであり、想定内の不具合のみでなく、想定外の不具合も表面化する。
想定外の不具合はインシデントの原因になるため、想定外の不具合の表面化はインシデントの予防につながる。
可観測性を高める方法¶
▼ マイクロサービスアーキテクチャの場合¶
テレメトリーを十分に収集し、これらを紐付けて可視化する必要がある。
▼ モノリシックアーキテクチャにおける可観測性¶
可観測性は、基本的にマイクロサービスアーキテクチャの文脈で語られる。
モノリシックでどのようにして可観測性を高めるのかを記入中... (情報が全然見つからない)
02. テレメトリー¶
テレメトリーとは¶
可観測性を実現するために収集する必要のあるデータ要素 (『メトリクス』『ログ』『分散トレース』) のこと。
NewRelicやDatadogはテレメトリーの要素を全て持つ。
また、AWSではCloudWatch (メトリクス+ログ) とX-Ray (分散トレース) を両方利用すると、これらの要素を満たせたことになり、可観測性を実現できる。
計装 (インスツルメント化)¶
システムを、テレメトリーを収集できるような状態にすること。
計装するためには、メトリクス収集用のツール、ロギングパッケージ、分散トレースのためのリクエストIDの付与、などを用意する必要がある。
多くの場合、各テレメトリーの収集ツールは別々に用意する必要があるが、OpenTelemetryではこれらの収集機能をフレームワークとして提供しようとしている。
03. 可観測性を高める方法¶
メトリクスの設計¶
▼ メトリクスの種類¶
どのような種類のメトリクスのデータポイントを収集するかについては、監視の種類ごとに異なる。
ログの設計¶
▼ ログの種類¶
どのような種類のログを収集するかについては、監視の種類ごとに異なる。
▼ ログの持つ情報¶
| 領域 | 内容 | 値 |
|---|---|---|
| フロントエンド | イベントの内容 | タイムスタンプ、 ログメッセージ、リクエストの各ヘッダー値、など |
| ラベル | 実行環境名、など | |
| バックエンド | イベントの内容 | タイムスタンプ、 ログステータス、ログメッセージ、エラーコード、トレースID、スパンID、親スパンID、など |
| ラベル | 実行環境名、リージョン名、Cluster名、Node名、Namespace名、Pod名、マイクロサービス名、コンテナ名、など | |
| インフラ | イベントの内容 | タイムスタンプ、OSイベント、ミドルウェアイベント、セキュリティイベント、など |
| ラベル | 実行環境名、リージョン名、Cluster名、Node名、Namespace名、Pod名、マイクロサービス名、コンテナ名、など |
分散トレースの基になるスパンの設計¶
▼ スパンの持つ情報¶
| 領域 | 内容 | 値 |
|---|---|---|
| バックエンド | イベントの内容 | トレースID、スパンID、親スパンID、処理の開始時間、処理の所要時間、エラーの有無、マイクロサービスの役割名、コールされたエンドポイント、など |
| ラベル | マイクロサービス名、など |
テレメトリー間の紐付け¶
▼ メトリクスと分散トレースの紐付け¶
記入中...
▼ ログと分散トレースの紐付け¶
記入中...
プロファイルの用途¶
分散トレースだけではマイクロサービス間のレスポンスタイムしかわからない。
プロファイルを導入すると、各マイクロサービスのハードウェアリソース消費量もわかるようになる。
これにより、性能劣化のボトルネックを特定しやすくなる。
04. その他のテレメトリー¶
メトリクス/ログ/分散トレース/プロファイルに加えて、新しいテレメトリーがいくつか提唱されている。
- Events (ドメインイベントのようなユーザー定義の処理イベント)
- Exception