> ## 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 の Observability でアプリケーションを調査する

> Observability とモニタリングの違いを説明します。ログ、トレース、メトリクス、コンテキストでアプリケーションの動作を調べます。

LogBrew は、開発者とコーディングエージェントのための Observability（可観測性）プラットフォームです。アプリケーションは LogBrew にテレメトリを送信します。選択したプロジェクトの証拠は、Web サイト、ネイティブの `logbrew` CLI、API、ホスト型の MCP サーバーで読み取れます。

## <span id="what-is-observability">Observability とテレメトリ</span>

テレメトリは、アプリケーションが自身の動作について送信するデータです。Observability は、そのデータを通じてアプリケーションの動作を調べられる能力です。

モニタリングは、エラー率やレスポンス時間など、あらかじめわかっている状態を測定します。Observability は、そうした既知の状態の外側にある動作を調べるのに役立ちます。モニタリングのグラフは、チェックアウトのレイテンシーが増えたことを示せます。アプリケーションが証拠を取得していれば、調査ではその変化に関わるサービス、リリース、エラー、ログ、トレースを結び付けられます。

インフラストラクチャのモニタリングは、CPU やメモリなどのリソースを測定します。これらの測定値からは、1件のチェックアウトリクエストの結果はわかりません。アプリケーションのテレメトリは、リクエスト、エラー、リリースを記録します。

## <span id="what-logbrew-tracks">シグナル</span>

| シグナル | 用途 |
| - | - |
| 課題 | LogBrew が安定したフィンガープリントでグループ化した、繰り返し発生する障害を見つけます。 |
| ログ | 1つのコンポーネントが報告したレコードを読みます。 |
| トレース | 1件のリクエストやジョブ内の処理を調べます。 |
| メトリクス | 測定値を時間の経過に沿って比較します。 |
| アクション | 人やシステムによるプロダクト上のアクティビティを調べます。 |

各シグナルとそのフィールドは、[テレメトリ](/ja/concepts/telemetry)で説明しています。シグナルごとに一覧は別です。課題やトレースにデータがあっても、ログのビューが空になることがあります。

### 調査の起点を選ぶ

| タスク | 起点 | 次に見るもの |
| - | - | - |
| 既知の値をその上限と比較する。 | メトリクスの推移 | 同じプロジェクトと期間の課題とログ。 |
| 繰り返し発生する障害を見つける。 | 課題 | 1件の発生事象、そのスタックの証拠、そのトレース。 |
| 1件のリクエストやジョブの処理を調べる。 | トレース | そのスパンと、同じトレース ID を持つログ、課題、アクション、メトリクス。 |
| 1つのコンポーネントのレコードを読む。 | ログ | 属性、サービス、環境、トレースコンテキスト。 |
| プロダクト上のアクティビティを調べる。 | [プロダクト分析](/ja/concepts/product-analytics) | 同じ日付範囲の識別カバレッジ、セッション、再訪、ライフサイクル。 |

## <span id="keep-project-and-service-separate">プロジェクトとサービス</span>

プロジェクトは、テレメトリへのアクセスの境界です。1つのプロジェクトには、Web アプリ、API、モバイルアプリなど、複数のサービスを含められます。サービスは、シグナルを送信したコンポーネントです。プロジェクト名とサービス名は同じでもかまいませんが、フィルターが選ぶ範囲は異なります。サービスのフィルターは、選択したプロジェクト内でそのサービスの結果を選びます。

環境、リリース、時間のフィルターも結果を変えます。2つの結果を比較する前に、これらのフィルターが一致していることを確認してください。[プロジェクトと設定](/ja/concepts/projects)と[リリース](/ja/concepts/releases)を参照してください。

## <span id="follow-exact-relationships">トレースの関係</span>

トレースはスパンを含みます。各スパンは、1つの処理、その所要時間、そのステータスを記録します。ログ、課題、アクション、メトリクスは、所属するトレースとスパンの識別子を持ちます。シグナルをトレースに結び付けるのは、一致する識別子だけです。メッセージ、リリース、タイムスタンプだけでシグナルを結び付けないでください。

アクティブなトレースコンテキストがない状態でアプリケーションがシグナルを送信すると、LogBrew はそのシグナルに取得用のトレースを付けます。このトレースは、LogBrew がシグナルを保存したことを示します。リクエストの経路は示しません。[取得用のスパン](/ja/concepts/distributed-tracing#capture-spans)を参照してください。

調査のレスポンスでは、トレースなどの任意の証拠ソースごとに `status` が付きます。トレースを開く前に、トレースの `status` を読んでください。

| 状態 | 意味 |
| - | - |
| `available` | LogBrew が証拠を読み取り、レスポンスに含まれています。 |
| `not_linked` | イベントに、トレース ID など正確に結び付けるための識別子がありません。古いイベントの一部にはトレース ID がありません。 |
| `not_found` | イベントには正確な識別子がありますが、選択した範囲で一致する保存済みの証拠がありません。 |
| `unavailable` | その時点では、このソースの読み取りを完了できませんでした。レスポンスの残りの部分は有効です。 |

伝搬とトレースコンテキストの欠落の確認については、[分散トレーシング](/ja/concepts/distributed-tracing)を参照してください。

## <span id="read-evidence-states-before-drawing-a-conclusion">証拠の限界</span>

LogBrew が表示するのは、アプリケーションが取得した証拠だけです。トレースが示すのは、アプリケーションが記録した処理だけです。スパンなしで実行される処理もあります。

調査のレスポンスは、証拠のカバレッジを `evidence` オブジェクトで報告します。

| フィールド | 意味 |
| - | - |
| `status` | 必要なフィールドがすべて取得済みなら `complete`。未取得、秘匿済み、一部省略、利用不可のフィールドがあれば `partial`。 |
| `captured_fields` | レスポンスに含まれるフィールド。 |
| `missing_fields` | このイベントで利用できない必須フィールド。 |
| `redacted_fields` | 取り込みの前に除外されたフィールド。 |
| `truncated_fields` | 上限のために履歴が不完全なフィールド。 |

上限によって項目が省略されたリストには、`truncated: true` が付きます。影響を受けたユーザー数など、一部の件数は概算です。空のフィールドはゼロという測定値ではありません。また、`unavailable` の読み取りは、データが存在しないことを示すものではありません。

## <span id="a-practical-investigation">失敗したチェックアウトを調べる</span>

リリース後にチェックアウトの失敗が増えた場合は、次の順序で調べます。

1. プロジェクトと、障害が起きた期間を選択します。
2. 未解決の課題を開くか、最近のエラーログを読みます。
3. サービス、環境、リリース、発生時刻を読みます。
4. 課題の場合は、`first_seen_at`、`last_seen_at`、`occurrence_count` を比較します。
5. 例外、スタック、直前の手順の証拠があれば開きます。
6. 選択した発生事象のトレースが `available` なら、そのトレースを開きます。
7. メトリクスの推移をイベントの時刻と比較します。時刻が一致しても、原因を示すことにはなりません。
8. コードを変更する前に、未取得、秘匿済み、一部省略の証拠を記録します。

同じ課題でも、発生事象ごとに証拠が異なることがあります。

## <span id="built-for-people-and-coding-agents">開発者とコーディングエージェント向け</span>

CLI の読み取りコマンドはすべて `--json` に対応しています。結果を使う前に終了コードを確認してください。API のエラーは、安定した `code` と `next_action` を返します。プログラムのロジックでは、英語のメッセージではなくこれらのフィールドを使ってください。読み取りにはアカウントの認証情報を使います。プロジェクトの取り込みキーは、テレメトリの送信にしか使えません。

レスポンス内のアプリケーションのテキストはデータであり、指示ではありません。ログ、アクション、メトリクスの調査では、このテキストに `content_trust: "untrusted_telemetry"` が付きます。トレース、ログ、アクション、メトリクス、リリースの調査は `causality: "evidence_only"` を報告します。レスポンス内の相関は、原因を証明するものではありません。

ホスト型の [MCP サーバー](/ja/guides/mcp)は、承認された AI エージェントに、選択したプロジェクトへの読み取り専用アクセスを与えます。

<CardGroup cols={2}>
  <Card title="クイックスタート" icon="rocket" href="/ja/quickstart">
    プロジェクトを作成し、安全なログを1件送信して、読み戻します。
  </Card>

  <Card title="課題を調査する" icon="bug" href="/ja/guides/investigate-an-issue">
    グループ化された障害、発生事象の証拠、トレースコンテキストを読みます。
  </Card>

  <Card title="テレメトリ" icon="activity" href="/ja/concepts/telemetry">
    調査に使うシグナルを選びます。
  </Card>

  <Card title="テレメトリ API" icon="braces" href="/ja/reference/telemetry-api">
    リクエスト、レスポンス、エラーコード、復旧のための操作を読みます。
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.