サービスとユーザーの状況を観測する

問いから始める

Monitoringは、既知の条件を確認します。Observabilityは、予測していなかった障害も含めて、システムの振る舞いを調査するために役立ちます。ダッシュボードを増やすだけで、よりよい答えが得られるわけではありません。

架空のエクスポートサービスでは、ユーザーにとっての問いから始めます。権限を持つユーザーが、合意した時間内に正しいエクスポートを受け取れるでしょうか。その問いに答え、障害を説明するために役立つシグナルを選びます。

OpenTelemetryは、テレメトリの計装機能と標準を提供します。対応するバックエンドにシグナルを送信できます。ただし、保存先、クエリ、アクセス制御、保持期間、証拠に基づいて対応する人は、別途必要です。Observabilityの基本。

異なる種類の証拠を結び付ける

メトリクスは、量の時間的な変化を測定します。ログはイベントを記録します。トレースは、リクエストがシステム内を進むときの関連する処理を結び付けます。Spanは、トレース内の一つの処理を表します。

非同期処理では、投入したジョブとワーカーの実行を、安全に対応付けられるようにします。HTTP 202レスポンスは、処理を受け付けたことを示す場合があります。エクスポートの完了を証明するものではありません。

対応が必要なときにアラートを出す

SLOを設定する前に、SLIとその分母を定義します。この例では、測定対象のエクスポートのうち、合意した時間内に正しく完了したものを数えます。長時間実行中のジョブや、途中で放棄されたジョブをどのように測定に含めるかを定義します。

エラーバジェットは、SLOの評価期間内で許容される失敗を表します。バーンレートは、失敗によってそのバジェットが消費される速さを表します。Googleのガイダンスは、複数の評価期間を使い、迅速な検出と不要なアラートの削減を両立させます。SLOに基づくアラート。

速やかな対応が必要な状態では、担当者を呼び出します。緊急度の低い作業はキューに送ります。すべてのアラートに、担当者、影響の説明、調査先へのリンク、対応手順が必要です。対応につながらないアラートが繰り返される場合は、見直してください。

すべてのサービスに同じ汎用的なしきい値を使わないでください。ユーザーへの影響、トラフィック、営業時間、対応能力によって、判断は変わります。

テレメトリパイプラインを保護する

テレメトリには、個人データ、トークン、リクエストパラメーター、機密文書が含まれる場合があります。収集前に、許可する項目を定義します。アクセスと保持期間を制限します。外部のバックエンドに送信する前に、シークレットを除去します。機密性の高いテレメトリ。

顧客のメールアドレスや一意のジョブIDを、メトリクスのラベルに使わないでください。値の種類に上限がないラベルは時系列データの数を増やし、識別子を露出させるおそれがあります。メトリクスには、値の範囲を管理したディメンションを使います。承認された相関用識別子は、アクセス制御されたログやトレースに記録します。

パイプライン自体も測定します。取り込みの失敗、破棄されたデータ、最新の観測からの経過時間を確認します。エラーのグラフが横ばいでも、エラーがない場合と、テレメトリが届いていない場合があります。その違いが分かるようにします。

具体的な障害を調査する

架空のサービスは、すべてのリクエストにHTTP 202を返しています。キュー内の待機時間は、数秒から15分に増加しています。ワーカーのログには、データベースのタイムアウトが繰り返し記録されています。サンプリングしたトレースでは、ワーカーの処理時間の大半がデータベース呼び出しに使われています。

この証拠は、調査対象を絞るために役立ちます。ただし、原因がクエリの変更、接続の枯渇、データベースの処理能力のどれなのかは、まだ分かりません。デバッグの方法を使って、これらの仮説を比較してください。

Taiga Monitoringは、可用性とブラウザーでの体験を示すシグナルを含む、製品の稼働状況のビューを提供します。インフラとアプリケーションのobservabilityを補完するものであり、それらのシステムに置き換わるものではありません。Monitoring。