メインコンテンツまでスキップ

ディメンション

このサイトでは、オブザーバビリティの領域を 6 つのディメンションで考えます。 各ディメンションを独立して見ることは、分析的な観点から有益です。 つまり、特定のワークロードに対して具体的なオブザーバビリティソリューションを構築する際に、使用するプログラミング言語などの開発者関連の側面や、コンテナや Lambda 関数などのランタイム環境といった運用上のトピックを網羅することができます。

o11y space

注記

「シグナルとは何か？」 ここでいうシグナルとは、ログエントリ、メトリクス、トレースを含む、あらゆる種類のオブザーバビリティデータとメタデータポイントを意味します。 より具体的である必要がある場合を除き、「シグナル」という用語を使用し、文脈から適用される制限を理解できるようにしています。

それでは、6 つのディメンションを 1 つずつ見ていきましょう：

出力先​

この次元では、長期ストレージやシグナルを利用するためのグラフィカルインターフェースなど、あらゆる種類のシグナルの出力先を考慮します。

開発者として、サービスのトラブルシューティングのためにシグナルを発見、検索、相関付けできる UI や API へのアクセスが必要です。

インフラストラクチャやプラットフォームの役割では、インフラストラクチャの状態を理解するためにシグナルを管理、発見、検索、相関付けできる UI や API へのアクセスが必要です。

Grafana screen shot

最終的に、これは人間の観点から見て最も興味深い次元です。 しかし、その恩恵を受けるためには、まず少し作業が必要です。 ソフトウェアと外部依存関係を計装し、シグナルを出力先に取り込む必要があります。

では、シグナルはどのように出力先に到達するのでしょうか？ 良い質問ですね。それは...

エージェント​

シグナルの収集と分析への経路について説明します。シグナルは 2 つのソースから取得できます。1 つはアプリケーションのソースコード (言語セクションを参照) から、もう 1 つはアプリケーションが依存するもの、つまりデータストアで管理される状態や VPC などのインフラストラクチャ (インフラとデータのセクションを参照) からです。

エージェントは、シグナルを収集して取り込むために使用するテレメトリの一部です。テレメトリのもう一部は、計装されたアプリケーションやデータベースなどのインフラ要素です。

プログラミング言語​

この観点は、サービスやアプリケーションを作成するために使用するプログラミング言語に関するものです。 ここでは、X-Ray SDK や OpenTelemetry が 計装 のコンテキストで提供するような SDK やライブラリを扱います。 ログやメトリクスなどの特定のシグナルタイプに対して、選択したプログラミング言語をオブザーバビリティソリューションがサポートしていることを確認する必要があります。

インフラストラクチャとデータベース​

この次元では、サービスが実行されている VPC のようなインフラストラクチャ、RDS や DynamoDB のようなデータストア、SQS のようなキューなど、アプリケーションの外部依存関係を指します。

ヒント

"共通点" この次元のすべてのソースに共通する点は、アプリケーション（およびアプリケーションが実行されるコンピューティング環境）の外部に位置しており、不透明なボックスとして扱う必要があるということです。

この次元には以下のものが含まれますが、これらに限定されません：

コンピュートユニット​

コードをパッケージ化し、スケジュールし、実行する方法です。例えば、Lambda では関数であり、ECS と EKS では、それぞれタスク (ECS) または Pod (EKS) で実行されるコンテナがそのユニットとなります。 Kubernetes のようなコンテナ化された環境では、テレメトリーのデプロイに関して、サイドカーまたはノード (インスタンス) ごとのデーモンプロセスという 2 つのオプションが提供されています。

コンピュートエンジン​

このディメンションは、基本的なランタイム環境を指します。これは、(例えば EC2 インスタンスの場合のように) プロビジョニングとパッチ適用が必要な場合もあれば、(Fargate や Lambda などのサーバーレスサービスのように) 必要ない場合もあります。 使用するコンピュートエンジンによっては、テレメトリ部分がすでにサービスの一部として提供されている場合があります。例えば、EKS on Fargate には Fluent Bit による統合されたログルーティングが含まれています。