オブザーバビリティ、DevOps、インシデント対応、Splunk On-Callに関連する一般的な質問とその回答を集めました。
ディメンションとプロパティの比較で、どちらかを使うべきかというのはよく議論されます。
大規模な組織で OpenTelemetry を展開する際には、タグ付けのための標準化された命名規則を定義し、規則が遵守されるようにガバナンスプロセスを確立することが重要です。
オブザーバビリティ、DevOps、インシデント対応、Splunk On-Callに関連する一般的な質問とその回答を集めました。
A: アラート、インシデント対応、インシデント管理は関連する機能です。これらは一緒にインシデント対応および解決プロセスを構成します。
モニタリングやオブザーバビリティのツールはインシデント対応プラットフォームにアラートを送信します。これらのプラットフォームはアラートのコレクションを収集し、それらをインシデントとして相関させます。
これらのインシデントは記録のためにインシデント管理（ITSM）プラットフォームに記録されます。アラートは何かが起こったことを示すトリガーであり、インシデントへのコンテキストを提供します。
インシデントには、アラートの内容、インシデントが作成されてから関連するすべての活動、およびフォローされるオンコールポリシーが含まれます。ITSMは、インシデントがアクティブであるときおよび解決された後のインシデントを記録するシステムです。
インシデント対応および管理をより良く実践するために、これらのコンポーネントが必要になります。
On-CallA: モニタリングとオブザーバビリティの主な違いは、「既知の未知」と「未知の未知」の違いです。
モニタリングでは、オペレーターは通常、システムのアーキテクチャと要素に関する事前の知識を持っています。彼らは要素間の関係とそれに関連するメタデータを確実に予測することができます。モニタリングは、頻繁に変更されない状態のインフラストラクチャに適しています。
オブザーバビリティは、オペレーターがシステム内のすべての要素とそれらの関係を予測し、追跡する能力が限定されているシステム向けです。
オブザーバビリティは、従来のメトリクスのモニタリングを含む一連のプラクティスと技術です。
これらのプラクティスと技術を組み合わせることで、オペレーターはシステムのすべての要素に関する事前の知識がなくても、頻繁に変更がある複雑な環境を理解することができます。オブザーバビリティ技術は、環境の変動やメタデータの変化（カーディナリティ）を従来のモニタリングよりもよく考慮できるため、より静的なモニタリングと比較して優れています。
ObservabilityA: トレースとスパンは、メトリクスとログと共に、現代のオブザーバビリティツールにフィードされるコアタイプのデータを構成します。それらは特定の要素と機能を持っていますが、一緒にうまく機能します。
マイクロサービスベースのアーキテクチャは分散しているため、システム内のトランザクションは完了する前に複数のサービスにアクセスします。これにより、問題の場所を正確に特定することが困難になります。トレースは、分散システム内のすべてのサービスを通るリクエストの完全なパスを追跡するための方法です。スパンは、各サービスでの時間のかかる操作です。トレースはスパンの結合したものであり、一緒になると個々のサービスプロセスについてより詳細な情報を提供します。メトリクスはシステムの健康状態の良いスナップショットを提供し、ログは問題を調査する際に深さを提供しますが、トレースとスパンはオペレーターに問題の源泉をより多くのコンテキストでナビゲートするのに役立ちます。これにより、インシデントの調査にかかる時間が節約され、現代のアーキテクチャの複雑さがサポートされます。
APMA: サイドカーパターンは、関連するサービスをインフラストラクチャによって直接接続するためのデザインパターンです。関連するサービスは、接続されているアプリケーションロジックに機能を追加したりサポートしたりすることができます。これは、管理計画に関連するエージェントをアプリケーションサービスと共に展開する方法として広く使用されます。
オブザーバビリティでは、サイドカーサービスはアプリケーションロジックであり、そのサービスからデータを収集するエージェントです。このセットアップには、アプリケーションサービスを含むコンテナと、エージェントを実行するコンテナの2つが必要です。コンテナはポッドを共有し、ディスク、ネットワーク、名前空間などのリソースを共有します。また、一緒にデプロイされ、同じライフサイクルを共有します。
Observabilityディメンションとプロパティの違いや、どちらを使うべきかというのは、よく話題にされます。それぞれの説明から始めるのではなく、私たちがどのように使い、どのように似ているのかを理解してから、それぞれの違いや、なぜどちらかを使うのかの例を見ていくことにしましょう。
最も単純な答えは、ディメンションとプロパティはともに、メトリクスにコンテキスト（状況）を追加するメタデータの key:value ペアであるということです。メトリクス自体は、cpu.utilization のような標準的なインフラストラクチャメトリクスであろうと、API呼び出しの回数のようなカスタムメトリクスであろうと、実際に測定しているものなら全てに当てはまります。
cpu.utilization メトリクスの値が50%であっても、それがどこから来たのかなどのコンテキストを知らなければ、それは単なる数字であり、私たちにとって有用ではありません。少なくとも、どのホストから来たのかを知る必要があります。
現在では、個々のホストのパフォーマンスや利用率よりも、クラスターやデータセンター全体のパフォーマンスや利用率をより気にすることが多く、ホストのクラスター全体の平均 cpu.utilization、あるホストの cpu.utilization が同じサービスを実行する他のホストと比べて外れ値である場合、あるいは環境間での平均 cpu.utilization を比較することに興味を持っています。
このように cpu.utilization メトリクスをスライス、集約、またはグループ化するためには、受け取る cpu.utilization メトリクスのメタデータに、ホストが属するクラスター、ホスト上で実行されているサービス、およびそれが属する環境などの情報が必要です。このメタデータは、ディメンションまたはプロパティの key:value ペアの形で存在することができます。
例えば、ダッシュボードでフィルターを適用したり、分析関数を実行する際にグループ化機能を使用したりするとき、プロパティまたはディメンションを使用することができます。
ディメンションはメトリクスと共に取り込み時に送信されるのに対し、プロパティは取り込み後にメトリクスやディメンションに適用されます。これは、`cpu.utilization`` の値がどのホストから来ているかのような、データポイント（メトリクスの単一の報告値）をユニークにするために必要なメタデータはディメンションでなければならないことを意味します。メトリクス名 + ディメンションは MTS（メトリクスの時間系列）をユニークに定義します。
例：特定のホスト（server1）によって送信される cpu.utilization メトリクスで、ディメンション host:server1 があれば、それはユニークな時間系列と見なされます。もし 10 台のサーバーがそのメトリクスを送信していれば、メトリクス名 cpu.utilization を共有し、ディメンションのキー値ペア（host:server1, host:server2…host:server10）でユニークに識別される 10 の時間系列があります。
しかし、サーバー名がデータセンター内でのみユニークである場合、データセンターの場所を示す 2 番目のディメンション dc を追加する必要があります。これにより、可能な MTS の数は倍になります。受信された cpu.utilization メトリクスは、2 組のディメンションのキー値ペアによってユニークに識別されます。
cpu.utilization に dc:east と host:server1 を加えたものは、cpu.utilization に dc:west と host:server1 を加えたものとは異なる時間系列を作り出します。
上記で述べたように、メトリクス名 + ディメンションの組み合わせで、ユニークな MTS を作ります。したがって、ディメンションの値が変わると、メトリクス名 + ディメンション値の新しいユニークな組み合わせが生まれ、新しい MTS が作成されます。
一方、プロパティはメトリクス（またはディメンション）が取り込まれた後に適用されます。メトリクスにプロパティを適用すると、そのメトリクスが属するすべての MTS に伝播して適用されます。または、ディメンションにプロパティを適用する場合、例えば host:server1 とすると、そのホストからのすべてのメトリクスにそのプロパティが添付されます。プロパティの値を変更すると、そのプロパティが添付されているすべての MTS のプロパティ値が更新されます。これが重要な理由は何でしょうか？ プロパティの歴史的な値にこだわる場合、それをディメンションにする必要があることを意味しています。
例：私たちはアプリケーションに関するカスタムメトリクスを収集しています。1つのメトリクスは latency で、アプリケーションへのリクエストのレイテンシーをカウントします。顧客ごとにレイテンシーを分類して比較できるように customer ディメンションを持っています。私たちは、顧客が使用しているバージョン別にアプリケーションの latency を分類して比較したいと考え、プロパティ version を customer ディメンションに添付しました。最初はすべての顧客がアプリケーションバージョン1を使用しているので、version:1 です。
現在、いくつかの顧客がアプリケーションのバージョン2を使用しているため、それらの顧客に対してプロパティを version:2 に更新します。これらの顧客の version プロパティの値を更新すると、その顧客に関連するすべての MTS に伝播します。これにより、これらの顧客が以前に version:1 を使用していたという歴史が失われるため、歴史的な期間にわたって version:1 と version:2 の latency を比較する場合、正確なデータを得ることはできません。この場合、メトリクスの時間系列をユニークにするためにアプリケーションの version が必要ではないかもしれませんが、歴史的な値にこだわるために version をディメンションにする必要があります。
メトリクスに添付したいメタデータがあるが、取り込み時にはそれを知らない場合が第一の理由です。第二の理由は、ベストプラクティスとして、ディメンションである必要がなければ、それをプロパティにすることです。なぜでしょうか？
一つの理由は、現在、分析ジョブやチャートレンダリングあたりの MTS の上限が 5K であり、ディメンションが多いほど多くの MTS を生成することです。プロパティは完全に自由形式であり、MTS の数を増やすことなく、メトリクスやディメンションに必要な情報を追加することができます。
ディメンションは各データポイントと共に送信されるため、ディメンションが多いほど、より多くのデータを送信することになります。これは、クラウドプロバイダーがデータ転送に料金を請求する場合、コストが高くなる可能性があります。
プロパティを使う良い例としては、ホスト情報の追加などがあります。 machine_type, processor, os などの情報を確認することが重要ですが、これらをディメンションとして設定し、各ホストからのすべてのメトリクスと共に送信するのではなく、プロパティとして設定し、ホストディメンションに添付することができます。
例えば host:server1 では、プロパティ machine_type:ucs, processor:xeon-5560, os:rhel71 を設定します。host:server1 というディメンションを持つメトリクスが入ってくるたびに、上記のすべてのプロパティが自動的に適用されます。
プロパティの使用例としては、各サービスのエスカレーション連絡先や、各顧客の SLA レベルを知りたい場合があります。これらの項目は、メトリクスをユニークに識別するために必要ではなく、歴史的な値にも関心がないため、プロパティにすることができます。プロパティはサービスディメンションや顧客ディメンションに追加され、これらのディメンションを持つすべてのメトリクスや MTS に適用されます。
タグは、メトリクスにコンテキストを与えたり整理するのに使われる、メタデータの 3 番目のタイプです。ディメンションやプロパティとは異なり、タグは key:value ペアではありません。タグはラベルやキーワードとして考えることができます。プロパティと同様に、タグは取り込み後に UI の Catalog や API を通じてプログラム的にデータに適用されます。タグはメトリクス、ディメンション、ディテクターなどの他のオブジェクトに適用することができます。
タグが必要とされるのは、タグとオブジェクトの間に多対一の関係がある場合や、タグとそれに適用されるオブジェクト間に一対多の関係がある場合です。本質的に関連していないメトリクスをまとめるのに役立ちます。
例として、複数のアプリケーションを実行しているホストがある場合です。各アプリケーションに対してタグ（ラベル）を作成し、それぞれのホストに複数のタグを適用して、その上で実行されているアプリケーションをラベル付けします。
例：Server1 は 3 つのアプリケーションを実行しています。タグ app1, app2, app3 を作成し、ディメンション host:server1 にこれら 3 つのタグをすべて適用します。
上記の例を拡張すると、アプリケーションからのメトリクスも収集しているとします。作成したタグを、アプリケーション自体から来るメトリクスに適用することができます。タグに基づいてフィルタリングすることで、アプリケーションに基づいてフィルタリングしながら、アプリケーションと関連するホストメトリクスの全体像を得ることができます。
例：App1 は service:application1 というディメンションでメトリクスを送信します。service:application1 のディメンションにタグ app1 を適用します。その後、チャートやダッシュボードでタグ app1 でフィルタリングすることができます。
タグの他の使用例には、単一の可能な値を持つ二進状態があります。例として、カナリアテストを行い、カナリアデプロイを行った際に新しいコードを受け取ったホストをマークして、新しいコードを受け取らなかったホストとのパフォーマンスを比較しやすくすることがあります。単一の値 canary しかないため、key:value ペアは必要ありません。
ただし、タグでフィルタリングはできますが、groupBy 関数では使用できないことに注意してください。groupBy 関数は key:value ペアのキー部分を指定して実行され、そのキーの値に基づいて結果がグループ化されます。
カスタムメトリクスのディメンションを送信する方法に関する情報については、お使いのライブラリに関するクライアントライブラリのドキュメントをご覧ください。
API を通じてメトリクスやディメンションにプロパティやタグを適用する方法については、 /metric/:name、/dimension/:key/:value に関する API ドキュメントを参照してください。
UI のメタデータカタログでプロパティやタグを追加または編集する方法については、Search the Metric Finder and Metadata catalogで、Add or edit metadata セクションをご覧ください。
大規模な組織で OpenTelemetry を展開する際には、タグ付けのための標準化された命名規則を定義し、その規則が遵守されるようにガバナンスプロセスを設定することが非常に重要です。
これにより、OpenTelemetry を通じて収集される MELT データ（メトリクス、イベント、ログ、トレース）を、アラート、ダッシュボード作成、トラブルシューティングの目的で効率的に活用することが可能になります。また、Splunk Observability Cloud のユーザーが探しているデータを迅速に見つけることができます。
命名規則はまた、データを効果的に集約するためにも重要です。例えば、環境ごとのユニークなホストの数を数えたい場合、ホスト名と環境名を捉えるための標準化された規則を使用する必要があります。
先に進む前に、用語についての注意をしておきましょう。OpenTelemetry の「タグ」は「属性（attribute）」と呼ばれます。属性は、手動または自動の計装を通じて、メトリクス、ログ、トレースに添付することができます。
属性はまた、Resource Detection processorなどのさまざまなプロセッサを使用して、OpenTelemetry コレクターレベルでメトリクス、ログ、トレースに添付することもできます。
Splunk Observability Cloud に属性付きのトレースが取り込まれると、それらは「タグ」として利用可能になります。オプションとして、トレースの一部として収集された属性は、Troubleshooting Metric Setsの作成に使用され、Tag Spotlightなどのさまざまな機能と共に使用することができます。
また、属性はMonitoring Metric Setsの作成に使用され、アラートのトリガーとして使用することもできます。
OpenTelemetry リソースセマンティック規約は、組織が標準化すべき属性を決定する際の出発点として使用できます。以下のセクションでは、よく使用される属性のいくつか見ていきましょう。
監視されるサービスを記述するために多くの属性が使用されます。
service.name はサービスの論理名を定義する必須の属性です。OpenTelemetry SDK によって自動的に追加されますが、カスタマイズすることができます。これはシンプルに保つことが最善です（例えば、inventoryservice は inventoryservice-prod-hostxyz よりも良いでしょう。他の属性を使用してサービスの他の側面を捉えることができます）。
以下のサービス属性が推奨されます：
service.namespace はサービスを所有するチームを識別するために使用されますservice.instance.id はサービスのユニークなインスタンスを識別するために使用されますservice.version はサービスのバージョンを識別するために使用されますこれらの属性はSDKによって自動的に設定され、使用されている計測ライブラリに関する情報を記録します：
telemetry.sdk.name は通常 opentelemetry に設定されます。telemetry.sdk.language は SDK の言語で、例えば java です。telemetry.sdk.version は使用されている SDK のバージョンを識別します。コンテナで実行されるサービスには、container.id、container.name、container.image.name など、コンテナのランタイムを記述するための多くの属性が使用されます。完全なリストはこちらで確認できます。
これらの属性は、サービスが実行されているホストを記述し、host.id、host.name、host.arch などの属性を含みます。完全なリストはこちらで確認できます。
deployment.environment 属性は、サービスがデプロイされている環境（ staging や production など）を識別するために使用されます。
Splunk Observability Cloud は、この属性を使用して関連コンテンツを有効する（詳細はこちら）ため、この属性を含めることが重要です。
AWS などのパブリッククラウド環境で実行されるサービスに関する情報を捉えるための属性もあります。これには、cloud.provider、cloud.account.id、cloud.region が含まれます。
属性の完全なリストはこちらで確認できます。
一部のクラウドプロバイダー、例えば GCP は、独自のセマンティック規則を定義しています。
Kubernetesで実行されるアプリケーションにも、いくつかの標準化された属性があります。これらの多くは、Splunk の OpenTelemetry コレクター配布によって自動的に追加されます（詳細はこちら）。
属性は、例えば k8s.cluster.name、k8s.node.name、k8s.pod.name、k8s.namespace.name、kubernetes.workload.name などがあります。
多くの組織では、OpenTelemetryのリソースセマンティック規約で定義されているもの以上の属性が欲しくなります。
この場合、セマンティック規約にすでに含まれている属性名との命名競合を避けることが重要です。つまり、特定の属性名を命名規則に決定する前に、セマンティック規約をチェックすると良いでしょう。
属性名の命名規則に加えて、属性値も考慮する必要があります。例えば、アプリケーションが属する特定のビジネスユニットをキャプチャしたい場合、簡単にかつ効果的にフィルタリングするために、標準化されたビジネスユニット値のリストも持ちたいでしょう。
OpenTelemetryコミュニティでは、属性の命名に従うべきガイドラインも提供しています。こちらで見つけることができます。
Recommendations for Application Developersは、私たちの議論に最も関連しています。
そこでは、以下を推奨しています：
com.acme.shopname のように、会社のドメイン名で属性名を接頭辞として付けること（属性が社内だけでなく外部で使用される可能性がある場合）otel.* で始まる属性名は避けること。これは OpenTelemetry 仕様の使用に予約されています属性名と値の命名基準を決定する際に考慮すべき最後の点は、メトリクスのカーディナリティに関連しています。
のカーディナリティは、メトリクス名とそれに関連する次元の組み合わせによって生成されるユニークなメトリクス時系列（MTS: Metric Time Series）の数として定義されます。
メトリクスは、ディメンションの数とそれらのディメンションが持つユニークな値の数が多い場合に、高いカーディナリティを持つことになります。
例えば、あなたのアプリケーションが custom.metric という名前のメトリクスのデータを送信するとします。属性がない場合、custom.metric は単一のメトリクス時系列（MTS）を生成します。
一方で、custom.metricが customer.id という属性を含み、数千の顧客ID値がある場合、これは数千のメトリクス時系列を生成し、コストやクエリ性能に影響を与える可能性があります。
Splunk Observability Cloud は、メトリクスの使用量を管理するためのレポートを提供しています。そして、望ましくないディメンションを削除するルールを作成することができます。しかし、最初の防衛線は、属性名と値の組み合わせがどのようにメトリクスのカーディナリティを増加させるかを理解することです。
このドキュメントでは、大規模な OpenTelemetry インストゥルメンテーションの展開を開始する前に、OpenTelemetry タグの命名規則を定義することの重要性を強調しました。
OpenTelemetry のリソースセマンティック規約がいくつかの属性の命名規則を定義し、多くの属性が OpenTelemetry SDKや OpenTelemetry コレクター内で動作するプロセッサーを通じて自動的に収集される方法について説明しました。
最後に、リソースセマンティック規約が組織のニーズに十分でない場合に、属性名を作成するためのベストプラクティスを共有しました。