> ## Documentation Index > Fetch the complete documentation index at: https://docs.logbrew.co/llms.txt > Use this file to discover all available pages before exploring further. # アプリケーションのテレメトリ：ログ、トレース、メトリクス > ログ、トレース、メトリクス、課題、プロダクトのアクションを比較し、調査に使う LogBrew のシグナルを選びます。 テレメトリは、アプリケーションが自身の動作について送信する構造化された証拠です。ログは報告されたイベントを記録します。トレースは処理どうしを結び付けます。メトリクスは値を測定します。課題は障害をまとめます。アクションはプロダクト上のアクティビティを記録します。 プロジェクト、サービス、環境、リリース、時刻のフィールドが、各結果の範囲を決めます。SDK が取得するシグナルについては、[SDK 連携](/ja/guides/sdk-ingestion)を読んでください。 ## シグナルを選ぶ | シグナル | 用途 | | - | - | | 課題 | 18件の発生事象があるチェックアウトの例外など、繰り返し発生する障害。 | | ログ | 決済の失敗など、アプリが報告した1件のイベント。 | | トレース | 計測済みのサービスをまたぐ1件のリクエストの処理と所要時間。 | | メトリクス | リクエストの所要時間や完了したジョブ数など、時間の経過に沿った測定値。 | | アクション | ページビュー、スクリーンビュー、インタラクションなど、プロダクト上のアクティビティ。 | 障害の調査は、課題かログから始めます。1回の実行を調べるには、利用できるトレースを使います。より長い期間を調べるには、メトリクスの推移を使います。アクティビティと再訪については、[プロダクト分析](/ja/concepts/product-analytics)を読んでください。 調査に必要なフィールドだけを取得します。サービス名、処理名、メトリクス名は変わらないものを使います。認証情報、決済データ、リクエストの生のボディは送信しないでください。そのための設定は[取得するデータを管理する](/ja/guides/safe-capture)にあります。 ## ログ ログは、ある時点でアプリケーションが残したレコードです。役に立つログには、次の情報があります。 * イベントが発生した時刻。 * 正規の重大度。 * プロジェクトとサービスの範囲。 * 環境とリリース。 * ログにアクティブなトレースコンテキストがある場合は、トレースとスパンの識別子。 * イベントのコンテキストを表す、小さく名前の付いた属性。 ログのレスポンスでは、これらの値は `occurred_at`、`severity`、`project_id`、`service_name`、`environment`、`release`、`trace_id`、`span_id`、`attributes` に入ります。コンテキストは、メッセージのテキストではなく名前付きの属性に入れてください。 複数のサービスのログが1つのビューに並んでいても、トレース上の関係はありません。その関係を作るのはトレースコンテキストだけです。 ## トレース トレースは、1件のリクエストや処理のスパンを含みます。ルートスパンには親がありません。子スパンは自身の親を示します。トレース内のスパンはすべて同じトレース ID を持ち、スパン ID はそれぞれ異なります。[分散トレーシング](/ja/concepts/distributed-tracing)を参照してください。 アクティブなトレースコンテキストなしで送信されたログ、課題、アクション、メトリクスには、取得用のトレースが付きます。このトレースには取得用のスパンしか含まれません。リクエストの経路は示しません。[取得用のスパン](/ja/concepts/distributed-tracing#capture-spans)を参照してください。 ## メトリクス メトリクスは、時間の経過に沿った測定値を記録します。各メトリクスは、名前、単位、ディメンション、プロジェクト、期間、間隔と合わせて読んでください。LogBrew は、メトリクスの `kind` と `temporality` に応じて、各ポイントの `value` を決めます。 | メトリクスの種類 | `aggregation.code` | ポイントの `value` | | - | - | - | | `instant` の `gauge` | `gauge_last` | キューの深さなど、間隔内の最後の状態。 | | `delta` の `counter` | `delta_sum` | 完了したジョブ数など、間隔内の変化の合計。 | | `delta` の `histogram` | `distribution_p95` | リクエストの所要時間など、95パーセンタイルの概算。 | | `cumulative` のストリーム | `raw_cumulative_last` | 最後の生の累計値。レートではありません。 | | その他の組み合わせ | `raw_last` | 最後の生のサンプル。 | たとえば、1つの間隔に値が `2`、`3`、`5` のデルタカウンターのサンプルが3件あれば、ポイントの `value` は `10`、`sample_count` は `3` になります。同じ値の gauge のサンプルが同じ順序で3件あれば、ポイントの `value` は `5` になります。p95 の値は平均ではありません。記録された観測値の約95%が、その値以下です。 `status: "ready"` の場合は、導出された集計を利用できます。`status: "limited"` の場合は、`aggregation.limitation` を読み、生の値だけを使ってください。gauge や cumulative のストリームを合計しないでください。ポイントのない間隔は、測定されたゼロではありません。クエリのフィールドについては、[クエリフィルター](/ja/reference/telemetry-api-filters)を読んでください。 `GET /api/telemetry/metrics/series` はこれらのポイントを返します。`project_id`、`name`、`since` が必須です。各系列には、`kind`、`unit`、`temporality` を持つ `identity` が1つあります。`identity` が異なる系列は別々のままです。各ポイントには、次のフィールドが含まれることもあります。 | フィールド | 意味 | | - | - | | `min`、`max`、`average` | 間隔内のサンプルの範囲と平均。 | | `p50`、`p95`、`p99` | ヒストグラムのパーセンタイルの概算。 | | `rate_per_second` | デルタカウンターの合計を間隔の幅で割った値。 | | `trace_exemplars` | 間隔内からサンプリングしたトレース ID。1つを開くと、その間隔のリクエストを調べられます。 | `series_limit` によって量の少ない系列が省略された場合、`coverage.truncated` は `true` になります。メトリクスの期間を、同じ長さの直前の期間と比較するには、次を実行します。 ```bash theme={null} logbrew explain metric '' --project '' --since 24h --json ``` ## 課題 課題は、繰り返し発生する障害を安定したフィンガープリントでまとめます。課題には、重大度、ステータス、発生事象の件数、初回確認の時刻、最終確認の時刻があります。課題の詳細には、例外チェーン、スタックフレーム、直前の手順、関連するログ、トレースとの関係が加わることがあります。 `last_seen_at` は、グループ内で最も新しい発生事象です。選択した発生事象は、それより古い場合があります。両方の時刻を読んでください。 課題の `status` は `unresolved`、`resolved`、`archived` のいずれかです。API のレスポンスのバージョン1では、`archived` は `ignored` と表示されます。レスポンスのバージョン2と3では、`priority`（`high`、`medium`、`low`）と `priority_source` が加わります。バージョン3では `assignee` も加わります。[ステータスの値](/ja/guides/issue-workflow#status-values)と[優先度](/ja/guides/issue-workflow#priority)を参照してください。 ## アクション アクションは、プロダクト上のアクティビティを記録します。対応している分類により、アクションはページビュー、スクリーンビュー、インタラクションのいずれかになります。イベント名だけでは分類は決まりません。このコンテキストを追加するには、[プロダクトイベントの取得](/ja/guides/product-events)を使います。 セッションはユーザーではありません。匿名サブジェクトは識別済みユーザーではありません。 ## 共通のフィールド | フィールド | 用途 | | - | - | | `project_id` | テレメトリを所有し、読み取りの境界を決めます。 | | `service_name` | シグナルを送信したアプリやサービスを識別します。 | | `environment` | 本番環境、ステージング環境、プレビュー、ローカルのデータを分けます。 | | `release` | デプロイされたコードのバージョンを識別します。 | | `occurred_at` | 1件のログやアクションが発生した時刻です。スパンは `started_at` を使います。 | | `trace_id` | 同じトレースコンテキストで取得したシグナルを結び付けます。 | | `span_id` | トレース内で、シグナルが属するスパンを識別します。 | ## 重大度の値 | 正規の値 | 入力で受け付ける別名 | | - | - | | `info` | `trace`、`debug`、`info` | | `warning` | `warn`、`warning` | | `error` | `error` | | `critical` | `fatal`、`critical` | LogBrew は、入力の別名を大文字と小文字を区別せずに受け付けます。API、CLI、ライブイベントは正規の値を使います。不明な重大度の値は拒否されます。重大度は記録された緊急度です。ビジネスへの影響や根本原因を示すものではありません。 ユーザーは、課題やログに表示される重大度を変更できます。その場合、レスポンスには `effective_severity` を含む `triage` オブジェクトが入ります。`severity` フィールドは、取得したときの値のままです。 ## ライブの読み取りとスナップショットの読み取り `logbrew read` は、選択したプロジェクト、期間、フィルターのスナップショットを返します。新しいイベントを読むには、もう一度実行します。`logbrew watch` は、接続している間、新しいログ、課題、アクションをストリーミングします。トレースやメトリクスはストリーミングしません。接続に失敗しても、プロジェクトが空であることにはなりません。 ## 証拠の状態 レスポンスでは、取得済み、未取得、秘匿済み、一部省略、利用不可の状態を区別します。トレースの証拠には、`available`、`not_linked`、`not_found`、`unavailable` の4つの状態があります。それぞれの意味は[概要](/ja/introduction#follow-exact-relationships)を、カバレッジのフィールドは[証拠の限界](/ja/introduction#read-evidence-states-before-drawing-a-conclusion)を参照してください。新しい SDK は、以前に送信したイベントにフィールドを追加しません。 ## 1つのプロジェクトを調査する ```bash theme={null} logbrew read issues --project '' --status unresolved --since 24h --json ``` 保持されている課題の履歴を読みます。一覧で使った `--since` フィルターは適用されません。 ```bash theme={null} logbrew investigate issue '' --json ``` トレース ID は、選択した発生事象がそれを返す場合にだけ使います。 ```bash theme={null} logbrew read trace '' --project '' --json ``` ログ、アクション、メトリクスを、同じプロジェクト、サービス、環境、リリースで絞り込みます。時刻だけでシグナルを結び付けないでください。 レスポンスのフィールドについては、[テレメトリ API](/ja/reference/telemetry-api) と[レスポンス形式](/ja/reference/telemetry-response-shapes)を読んでください。 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.