8. ログとモニタリング

アプリケーション内部で何が起こっているかを理解することは、信頼性の維持、問題の診断、スケーリングと最適化に関する情報に基づいた意思決定のために不可欠です。Buildは包括的なオブザーバビリティツールを提供し、複雑さで圧倒されることなく、またサードパーティのサービスを設定することなく、アプリケーションの動作を明確に把握できます。

リアルタイムのログストリーミングからパフォーマンスメトリクスおよびダッシュボードまで、問題を素早く診断し、時間の経過とともにトレンドを追跡し、アプリが正常に動作していることを確認するために必要なすべてのものが揃っています。これらすべてはBuildダッシュボードから直接アクセスできます。エラーレートのスパイクの調査、遅いエンドポイントの追跡、またはトラフィックパターンの確認など、Buildのモニタリングツールは不要なノイズなしに必要な情報を提供するように設計されています。

8.1 ログの表示（UI）

各アプリには、アプリケーションの出力のライブストリームを表示するLogsタブがあります。ログはリアルタイムでストリーミングされ、活動が起きるたびに監視できます。これは問題のデバッグ、デプロイの展開の観察、または最近のコード変更が期待通りに動作しているかの確認に特に有用です。

ログビューアはすべてのダイノからの出力を1つの統一されたストリームに集約するため、何が起こっているかを確認するために個別のインスタンスに接続する必要はありません。各ログエントリにはタイムスタンプが表示され、アプリケーション全体のイベントを容易に関連付けられます。

必要な情報を素早く見つけるために、ログビューアにはいくつかのフィルタリングオプションがあります：

検索フィルタリング — 検索語を入力して、クエリに一致するエントリのみにログをフィルタリングします。特定のリクエストID、ユーザーセッション、またはエラーメッセージからのログを分離するのに便利です。
クイックフィルター — ワンクリックで一般的なHTTPレスポンスコードカテゴリ（2xx、3xx、4xx、5xx）でフィルタリングできます。成功したリクエスト、リダイレクト、クライアントエラー、またはサーバーエラーを1クリックで簡単に分離できます。

ログストリームはタブを最初に開いたときに最近の履歴を表示し、新しいエントリが到着するとリアルタイムで更新され続けます。ストリームを一時停止して特定のエントリをより詳しく調べたい場合は、ログビューアを上にスクロールできます。ストリームはAutoscrollをクリックするまで自動的に更新されてログの末尾を表示し続けます。Autoscrollをクリックするとスクロールが一時停止され、ログ履歴をより詳しく調査できます。

8.2 ログの表示（CLI）

BuildダッシュボードはログをVisualに表示するための便利なインターフェースを提供していますが、コマンドラインから直接作業することを好む場合もあります。Build CLIは、スクリプティング、フィルタリング、その他のコマンドラインツールとの統合のための追加の柔軟性を持って、アプリケーションのログへのフルアクセスを提供します。

CLIを使用してログを表示するには、bld logsコマンドを使用します：

$ bld logs -a my-app

これにより、指定したアプリケーションの最近のログエントリが表示されます。デフォルトでは、コマンドは最近のログのスナップショットを出力してから終了します。継続的なストリームにコミットせずに何が起こったかを素早く確認するのに便利です。

リアルタイムでのログのテーリング

ログを継続的にストリーミングする（ダッシュボードのライブビューと同様）には、--tailフラグを使用します：

$ bld logs -a my-app --tail

ストリームはCtrl+Cで中断するまで継続されます。デプロイの進行状況を監視したり、リアルタイムで問題をデバッグするときに特に便利です。

プロセスタイプによるフィルタリング

アプリケーションがProcfileで複数のプロセスタイプ（web、worker、schedulerなど）を定義している場合、--processフラグを使用して特定のプロセスからの出力にログをフィルタリングできます：

$ bld logs -a my-app -p worker

これは、Webリクエストログのノイズなしにバックグラウンドジョブの問題をデバッグする場合、またはその逆の場合に特に有用です。

出力の長さの制御

デフォルトでは、CLIは適切な数の最近のログ行を返します。より多くまたは少ない行を取得するには、--countフラグを使用します：

$ bld logs -a my-app --count=500

これは履歴をより遡って調べる必要がある場合や、分析のために他のツールに出力をパイプする場合に便利です。

ログソースによるフィルタリング

Buildは2つのログソースを区別します：

app — 実行中のアプリケーションが生成するログ（ダイノからのstdoutとstderr）。
build — ビルドプロセス中に生成されるログ（依存関係のインストール、アセットコンパイルなど）。

デプロイの失敗をトラブルシューティングするときに有用な、ビルドログのみを表示するには、--sourceフラグを使用します：

$ bld logs -a my-app --source=build

フラグの組み合わせ

フラグを組み合わせてより対象を絞った出力を得ることができます。例えば、Webプロセスのログのみをテーリングするには：

$ bld logs -a my-app --tail --process=web

またはワーカープロセスの最後の100行を取得するには：

$ bld logs -a my-app -p worker -c 100

他のツールへのパイプ

CLIはログをstdoutに出力するため、フィルタリング、検索、処理のために他のコマンドラインツールに簡単にパイプできます：

$ bld logs -a my-app -c 1000 | grep "ERROR"
$ bld logs -a my-app --tail | grep --line-buffered "payments"

ヒント： テーリングされたログストリームをgrepでパイプする場合、--line-bufferedフラグを使用してバッファリングされずにすぐに出力が表示されるようにしてください。

コマンドリファレンス

8.3 ログドレイン（外部サービスへの転送）

Buildの組み込みログビューアはリアルタイムのデバッグと迅速な調査に最適ですが、サードパーティのログ集約サービスを使用した確立されたロギングワークフローをすでにお持ちの場合もあります。BetterStack、Papertrail、Datadogなどのサービスを使用している場合、ログドレインを使用してBuildのログをそのサービスに直接転送できます。

ログドレインはアプリケーションのログを外部のHTTPSエンドポイントまたはsyslog宛先への継続的なストリームとして作成します。設定後、アプリが生成するすべてのログエントリはBuildのログビューアに表示されるのに加えて、選択したプロバイダーに自動的に転送されます。

ログドレインを設定したい理由はいくつかあります：

一元化されたロギング — Build以外のインフラを実行している場合、ログドレインにより、すべてのシステムからのログを1か所に集約して統合検索と分析ができます。
カスタムアラート — サードパーティのロギングサービスは多くの場合、高度なアラート機能を提供し、エラーレート、特定のログパターン、または異常検知に基づいて通知をトリガーできます。
拡張された保持期間 — Buildはログを一定期間保持します。コンプライアンス、監査、または履歴分析の目的でログを保持する必要がある場合、外部サービスへの転送により必要な期間だけ保持できます。
高度な分析 — 専用のロギングプラットフォームは、Buildの組み込みビューアを超えた強力なクエリ言語、ビジュアライゼーションツール、機械学習機能を提供します。

ログドレインを設定するには、アプリに移動してSettingsタブをクリックし、このページでLog Drainsセクションを見つけます。ページ右上のLog Drainアイコンをクリックして新しいLog Drainを作成します：

Endpointフィールドの宛先URLとTokenを入力する必要があります。これらの値の取得方法については、ロギングプロバイダーのドキュメントを参照してください。入力して保存すると、Buildはすぐにログの転送を開始します。複数の宛先にログを送信する必要がある場合は、複数のログドレインを設定できます。

8.4 メトリクスとダッシュボード

ログに加えて、Buildは各アプリのMetricsタブを提供しており、アプリケーションの健全性とパフォーマンスの概要を一目で確認できます。ログは何が起こったかを伝えますが、メトリクスは時間の経過とともにパターンとトレンドを理解するのに役立ちます。これはキャパシティプランニング、パフォーマンス最適化、重大な問題になる前に問題を特定するために非常に価値があります。

メトリクスダッシュボードの右上隅にある時間範囲セレクターを使用して、3つのビューを切り替えます：

2時間 — 最近のインシデントの調査やデプロイの即時影響の監視に最適。
2日間 — 1日のトラフィックパターンを確認し、現在のパフォーマンスを昨日と比較するのに便利。
7日間 — 週次トレンド、緩やかなパフォーマンス劣化、または長期的な成長パターンを特定するためのより広い視野を提供。

メトリクスダッシュボードはアプリケーションの動作を異なる視点で提供する3つのグラフで構成されています：

リクエスト

リクエストグラフはHTTPステータスコードカテゴリ別に分類された時間経過に伴う受信リクエスト数を表示します。このビジュアライゼーションにより、異常を簡単に発見できます。例えば、壊れたリンクやAPI統合の問題を示す可能性がある4xxクライアントエラーの急増、またはバグやリソース制約を示す可能性がある5xxサーバーエラーの増加などです。

このグラフはダイノの再起動もタイムラインのマーカーとして表示します。再起動イベントをトラフィックパターンやエラーレートの変化と関連付けることで、安定性の問題を診断する際に非常に役立ちます。例えば、トラフィックのスパイクと再起動のパターンが一致している場合、負荷時にダイノのメモリが不足している可能性があります。

もう一つの便利な機能は、「インタラクティブセッション」イベントもタイムラインに表示されることです。これは、誰かがBuild CLIツールを使用してアプリに接続し、パフォーマンスに影響を与える操作を実行したかどうかを特定するのに役立ちます。これらのインタラクティブセッションのフルスクリーン録画は、アプリのOverviewタブから利用可能で、Latest ActivityボックスのView ephemeral logオプションを参照してください。

パフォーマンス

パフォーマンスグラフはレスポンスタイムメトリクスを追跡し、アプリケーションがどれだけ速くリクエストを処理しているかを確認できます。一部のユーザーに影響する問題を隠す可能性がある単純な平均を表示する代わりに、Buildはパーセンタイルベースのメトリクスを表示します：

p50（中央値） — リクエストの50%が完了するレスポンスタイム。ほとんどのユーザーの典型的なエクスペリエンスを表します。
p95 — リクエストの95%が完了するレスポンスタイム。スペクトルの遅い側のユーザーのエクスペリエンスを理解するのに役立ちます。
p99 — リクエストの99%が完了するレスポンスタイム。外れ値と最悪のシナリオを特定するのに便利です。
最大値 — 各時間帯に記録された最も遅いレスポンスタイム。ノイズが多い場合がありますが、最大レスポンスタイムの大幅なスパイクは調査する価値がある特定の問題のあるリクエストを示している可能性があります。

パフォーマンスデータを分析する際は、p50とp99のギャップに特に注意してください。大きなギャップは一貫性のないパフォーマンスを示します。一部のリクエストは素早く完了しているが、他のリクエストは大幅に遅い。このパターンは多くの場合、場合によって速かったり遅かったりするデータベースクエリ、変動するレイテンシを持つ外部API呼び出し、または特定の条件下でのリソースの競合などの問題を示しています。

帯域幅

帯域幅グラフは時間経過に伴うデータ転送レートを追跡し、以下を表示します：

TX（送信） — アプリケーションからクライアントに送信されたデータ。高いTX値は通常、大きなレスポンス、ファイルダウンロード、またはメディアコンテンツの提供と相関しています。
RX（受信） — クライアントからアプリケーションが受信したデータ。RXのスパイクはファイルアップロードや大きなペイロードを持つリクエストに対応することが多いです。

帯域幅の監視はアプリケーションのデータ転送パターンを理解するのに役立ち、予期しない変化を特定するのに有用です。例えば、非効率なAPIレスポンスやクライアントが大きなリソースを繰り返しリクエストしていることを示す可能性がある、アウトバウンドトラフィックの急増などです。