# テレメトリーの欠落がシグナルであるとき

Site [llms.txt](/ja/llms.txt)

---

空のダッシュボードは、何も起こらなかったことを意味する場合があります。
しかし、システムが起こったことの報告を停止したことを意味する場合もあります。
ダッシュボード上では、どちらも同じように見えます。
一方は何のアクションも必要ありません。
もう一方は、アクションに必要な情報が欠落していることを意味します。

イベントがサービスに入り、処理段階を通過し、ストレージに到達するワークフローを考えてみましょう。
オペレーターはその格納された結果を使用します。
すべてのサービスが利用可能なまま、1つのデータ転送がイベントをサイレントにドロップすることがあります。
エラーレートは低いままですが、オペレーターは不完全なビューで作業していることになります。

これはテレメトリーの完全性の問題です。
アプリケーションは正常でも、テレメトリーの経路が正常でない場合があります。
OpenTelemetry はこれを検知できますが、計装時に計画しておく必要があります。

## 存在すべきものを定義する {#define-what-should-be-present}

欠落したシグナルが有用なのは、そのシグナルが存在すべきだという明確な期待がある場合だけです。
重要なワークフローごとに、少数の期待事項から始めましょう。

- スケジュールされたジョブは、既知の時間枠内に結果を報告すべきである。
- 作業を受け入れる段階は、後で完了または拒否された作業を報告すべきである。
- 継続的にアクティブなサービスは、何らかのテレメトリーを生成し続けるべきである。

これらのチェックでは、計画的に活動がない期間を考慮する必要があります。
リクエストのないサービスはリクエストスパンを生成すべきではありません。
夜間ジョブが毎分報告する必要はありません。

## 段階間でカウントを照合する {#reconcile-counts-across-stages}

明確な境界を持つワークフローでは、その境界でカウンターを記録します。
たとえば、最初の段階で受け入れたイベントと、最後の段階で完了したイベントをカウントします。
通常の処理遅延を考慮した時間枠でカウントを比較します。

カウントは常に一致する必要はありません。
パイプラインは重複をフィルタリングしたり、無効な入力を拒否したり、作業をリトライしたり、バッチで処理したりする場合があります。
これらの予想される変化も計測すべきです。
有用なルールは次のとおりです。

accepted \= completed \+ rejected \+ still processing

数値を照合できない場合、そのギャップがシグナルです。
OpenTelemetry メトリクスはこのチェックに適しています。
すべてのイベントの識別子を保存することなく合計を追跡できるからです。
属性の値は、ワークフローの段階やアウトカムのように、種類が少なく安定したものにしてください。
一意のイベントやユーザーの識別子をメトリクスの属性として使用することは避けてください。

## トレースを使ってギャップの場所を特定する {#use-traces-to-locate-the-gap}

[トレース](/docs/concepts/signals/traces/)は、選択されたリクエストがシステムをどのように通過するかを示します。
トレースにより、作業がある段階に到達したが次の段階には到達しなかったことがわかる場合があります。
そのトレースに関連付けられたログは、局所的な原因を補足できます。

トレースを唯一の完全性チェックにすべきではありません。
[サンプリング](/docs/concepts/sampling/)により、トレースの欠落は予想される収集上の判断である場合があります。
メトリクスを使用してカウントやレートのギャップを検出し、次に利用可能なトレースとログを使ってギャップの始まる場所を特定してください。

非同期の作業では、可能な限りトレースコンテキストを保持してください。
ある作業が直接の親子関係なしに別の作業を開始する場合、スパンリンクでその関係を記録できます。
これにより、単一の同期トレースに強制することなく、ワークフローを追いやすくなります。

## 既知のアクティビティをフルパスで送信する {#send-known-activity-through-the-full-path}

実際のトラフィックは正当な理由で停止する可能性があります。
既知の間隔で送信される小さな合成イベントは、独立したチェックを提供します。
通常の作業と同じ重要な段階を通過させ、最後に結果を検証してください。

合成イベントは識別しやすく、安全に処理できるようにしてください。
個人情報や機密データを含めないでください。
通常のキューイングやバッチ処理を考慮して、成功と見なす時間枠を設定してください。

これにより、ワークフローが既知のイベントを最初から最後まで運べるかどうかがわかります。

## テレメトリー経路を監視する {#monitor-the-telemetry-path}

OpenTelemetry Collector は、自身の動作に関する[内部テレメトリー](/docs/collector/internal-telemetry/)を生成します。
有用なシグナルには以下が含まれます。

- レシーバーが受け入れたまたは拒否したレコード
- エクスポーターが送信したまたは失敗したレコード
- エクスポーターのキューサイズと容量

キューの増大や持続的なエクスポート失敗は、アプリケーションのテレメトリーが到着しなくなった理由を説明できます。
受け入れ数と送信数は、テレメトリーフローがどこで変化したかを示すこともできます。
差異をデータ損失として扱う前に、設定済みのフィルタリング、サンプリング、ルーティング、処理を考慮してください。

稼働中の Collector でもデータの送信に失敗する可能性があるため、プロセスの稼働時間ではなくテレメトリーフローでアラートを設定してください。
可能であれば、この経路を独立して監視し、障害が自身のヘルスシグナルも隠してしまわないようにしてください。

## 複数のポイントからワークフローをチェックする {#check-the-workflow-from-more-than-one-point}

単一のチェックで完全性を証明することはできません。
異なる形で失敗する、対象を絞ったいくつかのチェックを組み合わせてください。

| チェック               | わかること                                               |
| :--------------------- | :------------------------------------------------------- |
| 期待されるシグナル     | 期待された時間枠内にアクティビティが現れた               |
| 段階間のカウント       | 作業が期待どおりに各段階に入り、出ていった               |
| 合成イベント           | フルパスが既知のアクティビティを運べる                   |
| Collector テレメトリー | テレメトリーパイプラインがデータを受け入れ、送信している |

通常のトラフィックが存在しないが合成イベントが成功する場合、システムでは単に活動がないだけかもしれません。
期待されるトラフィックが存在せず、合成イベントも消える場合、観測経路がおそらく壊れています。
アプリケーションのカウントは正常だが Collector の障害が増加する場合、問題はアプリケーションではなくテレメトリーパイプラインにある可能性が高いです。

## チェックをまとめる {#put-the-checks-together}

1つの重要なワークフローから始めましょう。
アクティビティが期待されるタイミングを定義し、境界でカウントを照合し、1つのエンドツーエンドの合成チェックを追加し、Collector のデータフローを監視してください。