APIの可観測性:信号を判断につなげる

要点

稼働状況の画面だけでは、遅い処理や誤った結果の理由を説明できません。利用者の経路を起点に、診断に必要な測定、イベント、依存先を結び付けます。

無人の機器室にある通信ラックとネットワーク配線
この記事の内容

問いに合う信号を選ぶ

OpenTelemetryはメトリクス、ログ、トレースなどを区別します。相互に補完しますが、完全な可視性を保証しません。測定期間、計測箇所、対象外を明示し、平均値だけで遅いリクエストを見落とさないようにします。

問い役立つ信号限界
失敗した件数は?集約メトリクス失敗の定義、範囲、期間が必要。
どこに時間がかかった?トレースと各段階の時間サンプリングや未計測の依存先がある。
何が起きた?構造化ログ秘密情報や過剰な記録を避ける。
利用経路は動く?機能監視一つのシナリオですべては覆えない。

行動につながる診断を整える

  • 正規化した操作ごとに流量、エラー、処理時間の分布を測ります。メトリクスのラベルに利用者IDや可変URLを使わないようにします。
  • イベントに相関IDとサービス版を関連付けます。見つからないトレースを調べる前に、文脈の伝播とサンプリング方針を確認します。
  • アラートには影響、担当者、最初の対応を設定します。監視用の専用アカウントを使い、取り消せない操作を避けます。

データを守り結果を検証する

ログにパスワード、トークン、機密の本文を残さず、閲覧権限と保存期間を制限します。HTTP上の成功でも業務上の結果が誤る場合があります。管理された環境で、満たすべき条件や権限も確認します。

一次資料

テレメトリをユーザータスクに接続する

メトリクス、ログ、トレースはそれぞれ異なる疑問に答えます。高い稼働率は、チェックアウトやサインインの失敗を隠蔽する可能性があります。ユーザーが期待する結果を定義し、それを実現する呼び出しを計測します。

  • 成功、遅延、ユーザーに表示される障害を示すジャーニーインジケーターを選択します。
  • トレース内の機密データを制限しながら、サービス間で相関関係を伝播します。
  • 依存関係の障害をリハーサルし、アラートが適切なアクションと理解しやすい劣化モードにつながるかどうかを確認します。

一次資料:OpenTelemetry — Observability primer. 関連する方法:実践ガイドを読む.

収集停止:ログと欠けたイベントを照合する

生成、受信、利用可能なイベントを分け、記録の静けさを障害がない証拠としません。

  • アプリ、収集器、保存先と担当者を整理します。秘密や顧客データを含まない、安定した識別子の有限な架空イベント列を準備します。イベント時刻と観測時刻を残します。収集の遅延は自動的に喪失を意味しません。
  • テストで宛先を止めて復旧します。キュー、再試行、拒否、再起動を観測します。永続キューは一部の喪失を抑えますが、容量が有限で保存先に依存します。満杯時の動作を定め、収集がサービスを黙って停止させないか確認します。
  • 同じ観測締切で参照集合と実際に読めるイベントを照合します。重複、遅延、欠落を別々に数えます。通信の確認は最終的な利用可能性を証明しません。信頼できる参照なしでは範囲は不明であり、喪失ゼロや障害ゼロとしません。

再現できる受け入れ事例

架空の例です。顧客や実際の観測結果を示すデータではありません。

事例の入力を見る
{
    "expected_ids": [
        "E1",
        "E2",
        "E3"
    ],
    "received_ids": [
        "E1",
        "E1",
        "E3"
    ],
    "received_rows": 3,
    "unique_received": 2,
    "missing_ids": [
        "E2"
    ],
    "observation_cutoff": "same_for_both_sets"
}

期待される判断

架空例:E1、E2、E3を期待し、E1、E1、E3を受信します。三行は完全性を示しません。E1が重複し、締切時にE2が欠けています。

OpenTelemetry — Collector resiliency

三行受信したら三イベントを保持した証拠ですか?

いいえ。同じ識別子の二行が欠落を隠すことがあります。識別子、観測期間、各段階を比較します。

一次資料:OpenTelemetry — Collector resiliency. 関連する方法:実践ガイドを読む.

放置されたサブドメイン:CNAMEを管理下で廃止する

DNS名を管理中のリソースに結び付け、サービス解放前に依存先を閉じます。

  • 公開名、CNAME連鎖、事業者リソース、担当者を記録し、DNSを権限のあるアカウントの台帳と照合します。HTTPエラー、NXDOMAIN、リソース不在だけでは乗っ取り可能とは判断できません。事業者の保護を確認します。
  • 解放前に参照を削除するか管理中の宛先へ変更します。以前のTTLとキャッシュを考慮し、権威DNSと複数のリゾルバーを確認します。必要な所有権確認は残し、TXTを一括削除しません。
  • リンク、転送、OAuthコールバック、Webhook、Cookieドメインを調べます。既に解放済みならDNSを修正し、インシデント手順で露出を調査します。削除後にDNSとリソースを照合します。

再現できる受け入れ事例

架空の例です。顧客や実際の観測結果を示すデータではありません。

事例の入力を見る
{
    "name": "portal.example",
    "cname_present": true,
    "resource_deleted": true,
    "provider_claimability": "not_verified",
    "takeover_observed": false,
    "expected": "remove_or_replace_mapping_and_review_exposure"
}

期待される判断

架空例:portal.exampleが削除済みリソースを指しています。CNAMEを削除するか管理中の宛先へ変更します。不在だけで第三者の乗っ取りとは判断しません。

Microsoft — Prevent dangling DNS entries

一次資料:Microsoft — Prevent dangling DNS entries. 関連する方法:実践ガイドを読む.

API再試行:経路全体の時間を数える

呼出し、待機、全経路を分けます。

架空の学習用事例です。数値はCIEや顧客の実績ではありません。

架空の4呼出しは各250ミリ秒以内、待機は100、200、400。ジッター、接続、待ち行列、ローカル検証は除きます。

総試行数
41 + 3
待機合計(ms)
700100 + 200 + 400
モデルの予算(ms)
17004 × 250 + 700
試行列を分ける
段階呼出し上限(ms)次の待機(ms)
試行1250100
試行2250200
試行3250400
試行42500
合計1000700
モデルの時間(ms)
  • 呼出し時間1,000
  • 待機の合計700
  • 全体の期限(ms)1,500

結論を出す前の確認

  1. 1,000 + 700 = 1,700は期限1,500ミリ秒を超えます。
  2. 全体期限を伝え、効果の重複を防ぎます。タイムアウトは遠隔処理の取消しを証明しません。

再試行の時間予算を試す

n × T + W × (2^(n−1) − 1)

関連する方法:実践ガイドを読む.

参照資料:データ・用途・限界

資料確認日 .

この言語版の詳しい参照メモは英語で提供しています。

参照資料:データ・用途・限界
出典と目的確認済みのデータ・指標利用方法留意する限界
NIST · SP 800-61 Rev. 3

Prepare incident response within cybersecurity risk management.

Revision 3 was published in April 2025 and supersedes Revision 2. It is a CSF 2.0 Community Profile. Rehearse containment decisions, evidence preservation, communication and recovery. Compare planned actions with evidence produced during the exercise.

手法を詳しく読む →

Reading the guide does not validate a local plan. Contacts, emergency access and dependencies need local testing.
Google · Core Web Vitals

Distinguish loading, responsiveness and visual stability.

Good thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile, segmented by mobile and desktop. Separate field measurement from laboratory tests. Record period, URL, device, population and sample size before comparing changes.

手法を詳しく読む →

These thresholds are not measured results for this site. A good lab score alone does not establish visitor experience.

APIの非推奨化と廃止

この言語版の詳しい参照メモは英語で提供しています。

Announced retirement and continuity to verify

A Sunset field signals intent; it establishes neither actual shutdown nor guaranteed continuity until then. Prepare dependencies, data and access to move.

  • Identify the announcement’s exact scope and owner.
  • Keep dates and updates with receipt evidence.
  • Test exit, in-flight operations and removal of obsolete access.

Compare deprecation and retirement announcements →

IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23

IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23