シグナルを選ぶ
障害の調査は、課題かログから始めます。1回の実行を調べるには、利用できるトレースを使います。より長い期間を調べるには、メトリクスの推移を使います。アクティビティと再訪については、プロダクト分析を読んでください。
調査に必要なフィールドだけを取得します。サービス名、処理名、メトリクス名は変わらないものを使います。認証情報、決済データ、リクエストの生のボディは送信しないでください。そのための設定は取得するデータを管理するにあります。
ログ
ログは、ある時点でアプリケーションが残したレコードです。役に立つログには、次の情報があります。- イベントが発生した時刻。
- 正規の重大度。
- プロジェクトとサービスの範囲。
- 環境とリリース。
- ログにアクティブなトレースコンテキストがある場合は、トレースとスパンの識別子。
- イベントのコンテキストを表す、小さく名前の付いた属性。
occurred_at、severity、project_id、service_name、environment、release、trace_id、span_id、attributes に入ります。コンテキストは、メッセージのテキストではなく名前付きの属性に入れてください。
複数のサービスのログが1つのビューに並んでいても、トレース上の関係はありません。その関係を作るのはトレースコンテキストだけです。
トレース
トレースは、1件のリクエストや処理のスパンを含みます。ルートスパンには親がありません。子スパンは自身の親を示します。トレース内のスパンはすべて同じトレース ID を持ち、スパン ID はそれぞれ異なります。分散トレーシングを参照してください。 アクティブなトレースコンテキストなしで送信されたログ、課題、アクション、メトリクスには、取得用のトレースが付きます。このトレースには取得用のスパンしか含まれません。リクエストの経路は示しません。取得用のスパンを参照してください。メトリクス
メトリクスは、時間の経過に沿った測定値を記録します。各メトリクスは、名前、単位、ディメンション、プロジェクト、期間、間隔と合わせて読んでください。LogBrew は、メトリクスのkind と temporality に応じて、各ポイントの value を決めます。
たとえば、1つの間隔に値が
2、3、5 のデルタカウンターのサンプルが3件あれば、ポイントの value は 10、sample_count は 3 になります。同じ値の gauge のサンプルが同じ順序で3件あれば、ポイントの value は 5 になります。p95 の値は平均ではありません。記録された観測値の約95%が、その値以下です。
status: "ready" の場合は、導出された集計を利用できます。status: "limited" の場合は、aggregation.limitation を読み、生の値だけを使ってください。gauge や cumulative のストリームを合計しないでください。ポイントのない間隔は、測定されたゼロではありません。クエリのフィールドについては、クエリフィルターを読んでください。
GET /api/telemetry/metrics/series はこれらのポイントを返します。project_id、name、since が必須です。各系列には、kind、unit、temporality を持つ identity が1つあります。identity が異なる系列は別々のままです。各ポイントには、次のフィールドが含まれることもあります。
series_limit によって量の少ない系列が省略された場合、coverage.truncated は true になります。メトリクスの期間を、同じ長さの直前の期間と比較するには、次を実行します。
課題
課題は、繰り返し発生する障害を安定したフィンガープリントでまとめます。課題には、重大度、ステータス、発生事象の件数、初回確認の時刻、最終確認の時刻があります。課題の詳細には、例外チェーン、スタックフレーム、直前の手順、関連するログ、トレースとの関係が加わることがあります。last_seen_at は、グループ内で最も新しい発生事象です。選択した発生事象は、それより古い場合があります。両方の時刻を読んでください。
課題の status は unresolved、resolved、archived のいずれかです。API のレスポンスのバージョン1では、archived は ignored と表示されます。レスポンスのバージョン2と3では、priority（high、medium、low）と priority_source が加わります。バージョン3では assignee も加わります。ステータスの値と優先度を参照してください。
アクション
アクションは、プロダクト上のアクティビティを記録します。対応している分類により、アクションはページビュー、スクリーンビュー、インタラクションのいずれかになります。イベント名だけでは分類は決まりません。このコンテキストを追加するには、プロダクトイベントの取得を使います。 セッションはユーザーではありません。匿名サブジェクトは識別済みユーザーではありません。重大度の値
LogBrew は、入力の別名を大文字と小文字を区別せずに受け付けます。API、CLI、ライブイベントは正規の値を使います。不明な重大度の値は拒否されます。重大度は記録された緊急度です。ビジネスへの影響や根本原因を示すものではありません。
ユーザーは、課題やログに表示される重大度を変更できます。その場合、レスポンスには
effective_severity を含む triage オブジェクトが入ります。severity フィールドは、取得したときの値のままです。
ライブの読み取りとスナップショットの読み取り
logbrew read は、選択したプロジェクト、期間、フィルターのスナップショットを返します。新しいイベントを読むには、もう一度実行します。logbrew watch は、接続している間、新しいログ、課題、アクションをストリーミングします。トレースやメトリクスはストリーミングしません。接続に失敗しても、プロジェクトが空であることにはなりません。
証拠の状態
レスポンスでは、取得済み、未取得、秘匿済み、一部省略、利用不可の状態を区別します。トレースの証拠には、available、not_linked、not_found、unavailable の4つの状態があります。それぞれの意味は概要を、カバレッジのフィールドは証拠の限界を参照してください。新しい SDK は、以前に送信したイベントにフィールドを追加しません。
1つのプロジェクトを調査する
1
未解決の課題を見つける
2
1件の課題を読む
保持されている課題の履歴を読みます。一覧で使った
--since フィルターは適用されません。3
利用できるトレースを開く
トレース ID は、選択した発生事象がそれを返す場合にだけ使います。
4
関連する証拠を読む
ログ、アクション、メトリクスを、同じプロジェクト、サービス、環境、リリースで絞り込みます。時刻だけでシグナルを結び付けないでください。