8. ログとモニタリング

アプリケーションを安定して動かし続け、問題の原因を切り分け、スケーリングや最適化を的確に判断するには、その内部で何が起きているかを把握する必要があります。Build.ioは、アプリケーションの挙動を詳細に確認できるツールを一通り備えています。複雑な設定やサードパーティサービスの導入は必要ありません。

リアルタイムのログストリーミング、パフォーマンスメトリクス、ダッシュボードまで、必要な機能はすべてそろっています。問題の診断、傾向の把握、アプリケーションが正常に動作していることの確認は、いずれもBuild.ioのダッシュボードから直接行えます。モニタリングツールは、余計なノイズを挟まずに必要な情報だけを示します。エラーレートの急増を調査するときも、遅いエンドポイントを特定するときも、トラフィックの傾向を見ておきたいだけのときも変わりません。

8.1 ログの表示（UI）

アプリごとにLogsタブがあり、アプリケーションの出力がリアルタイムのストリームとして表示されます。いま起きている動作をその場で追跡できるため、デプロイの進行状況を確認したり、直前のコード変更が期待どおりに動作しているかを検証したりする場面で役立ちます。不具合の原因を切り分けるときも同様です。

ログビューアは、アプリケーションで動作しているすべてのDynoの出力を1本のストリームに集約します。個々のインスタンスに接続する必要はありません。各エントリにはタイムスタンプが表示されるため、アプリケーション全体をまたぐイベントを関連づけられます。

目的のエントリを素早く見つけられるように、ログビューアには次のフィルター機能が用意されています：

検索フィルタリング — 検索語を入力すると、一致するエントリだけが表示されます。特定のリクエストID、ユーザーセッション、エラーメッセージに関連するログを抽出したいときに役立ちます。
クイックフィルター — HTTPステータスコードのカテゴリ（2xx、3xx、4xx、5xx）で絞り込むボタンです。成功したリクエスト、リダイレクト、クライアントエラー、サーバーエラーを、ワンクリックで切り分けられます。

タブを開いた直後は直近の履歴が表示され、その後は新しいエントリが届くたびにリアルタイムで更新されます。特定のエントリを詳しく確認する場合は、ログビューアを上にスクロールしてください。ただし、スクロールしただけでは末尾への自動追従は停止しません。Autoscrollチェックボックスをオフにすると追従が止まり、ログ履歴をさかのぼって調査できます。

8.2 ログの表示（CLI）

ダッシュボードはログを視覚的に確認する手段として便利ですが、コマンドラインから直接操作したい場合もあります。Build CLIからも、アプリケーションのログすべてにアクセスできます。スクリプトへの組み込み、条件による絞り込み、他のコマンドラインツールとの連携は、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リクエストのログを除外できます。逆に、Webリクエストを調査する際に、バックグラウンドジョブのログを除外することもできます。

出力行数の制御

デフォルトでは、直近のログが一定の行数だけ返されます。取得する行数は--countフラグで変更できます：

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

履歴をさらにさかのぼって確認するときや、分析のために出力を他のツールへ渡すときに便利です。

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

Build.ioは、2種類のログソースを区別します：

app — 実行中のアプリケーションが生成するログです（Dynoのstdoutおよびstderr）。
build — ビルドの過程で生成されるログです。依存関係のインストールやアセットのコンパイルなどが該当します。

デプロイの失敗を調査する場合など、ビルドログだけを表示するには、--sourceフラグを指定します：

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

フラグの組み合わせ

フラグを組み合わせると、出力をさらに絞り込めます。たとえば、webプロセスのログだけをテーリングするには次のように実行します：

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

workerプロセスの最後の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.ioの組み込みログビューアは、リアルタイムのデバッグや短時間の調査に適しています。一方で、サードパーティのログ集約サービスを使ったロギングワークフローをすでに運用している場合もあります。BetterStack、Papertrail、Datadogなどを利用しているのであれば、Build.ioのログをそのサービスへ直接転送できます。この転送の仕組みをログドレインと呼びます。

ログドレインは、アプリケーションのログを外部のHTTPSエンドポイントまたはsyslog宛先へ継続的に転送します。設定すると、アプリケーションが生成するログエントリは、Build.ioのログビューアに表示されるとともに、指定したプロバイダーへ自動で転送されます。

設定を検討する理由はいくつかあります：

ログの一元化 — Build.io以外にもインフラを運用している場合、すべてのシステムのログを1か所に集約し、まとめて検索・分析できます。
カスタムアラート — サードパーティのロギングサービスには、高度なアラート機能が用意されていることが多くあります。エラーレート、特定のログパターン、異常検知を条件に通知を送信できます。
保持期間の延長 — Build.ioがログを保持する期間には上限があります。コンプライアンス、監査、履歴分析のためにログを残すのであれば、外部サービスへ転送すれば必要な期間にわたって保持できます。
高度な分析 — 専用のロギングプラットフォームには、強力なクエリ言語、可視化ツール、機械学習機能があります。いずれもBuild.ioの組み込みビューアにはありません。

ログドレインを設定するには、アプリのSettingsタブを開き、Log Drainsセクションを表示します。ページ右上のLog Drainアイコンをクリックすると、新しいログドレインを作成できます：

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

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

ログとは別に、アプリごとにMetricsタブが用意されています。アプリケーションの健全性とパフォーマンスの概要を一目で確認できます。ログが「何が起きたか」を示すのに対して、メトリクスは時間の経過に伴うパターンとトレンドを示します。キャパシティプランニングやパフォーマンスの最適化、問題が深刻化する前の検知に役立ちます。

メトリクスダッシュボード右上の時間範囲セレクターで、3つのビューを切り替えます：

2時間 — 直近のインシデントの調査や、デプロイ直後の影響の確認に適しています。
2日間 — 1日単位のトラフィックの変動を把握し、現在のパフォーマンスを前日と比較したいときに向いています。
7日間 — 週単位のトレンド、緩やかなパフォーマンス劣化、長期的な成長パターンを確認できます。

メトリクスダッシュボードは3つのグラフで構成され、それぞれ異なる観点からアプリケーションの動作を示します：

リクエスト

リクエストグラフは、受信したリクエスト数をHTTPステータスコードのカテゴリ別に、時間の経過に沿って表示します。このグラフを使うと、異常を見つけやすくなります。たとえば、4xxクライアントエラーの急増は、リンク切れやAPI連携の不具合を示している可能性があります。5xxサーバーエラーの増加であれば、バグやリソース不足が考えられます。

同じグラフには、Dynoの再起動もタイムライン上のマーカーとして表示されます。再起動イベントをトラフィックパターンやエラーレートの変化と重ねて確認すると、安定性の問題を診断する手がかりが得られます。たとえば、再起動がトラフィックのスパイクと繰り返し重なっている場合は、負荷時にDynoのメモリが不足している可能性があります。

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

パフォーマンス

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

p50（中央値） — リクエストの50%がこの時間内に完了します。大多数のユーザーが体感している水準です。
p95 — リクエストの95%がこの時間内に完了します。応答が遅い部類に入るユーザーが、どの程度待たされているかが分かります。
p99 — リクエストの99%がこの時間内に完了します。外れ値や最悪のケースの把握に役立ちます。
最大値（Max） — 各期間で最も遅かったレスポンスタイムです。変動の大きい指標ですが、大幅なスパイクは特定のリクエストに問題があることを示している場合があるため、調査する価値があります。

パフォーマンスデータを分析する際は、p50とp99の差に注目してください。大きく開いている場合は、パフォーマンスが一貫していないと考えられます。短時間で完了するリクエストと、大幅に遅いリクエストが混在している状態です。この傾向の原因としては、実行状況によって速度が変わるデータベースクエリ、レイテンシが安定しない外部API呼び出し、特定の条件下でのリソース競合が挙げられます。

帯域幅

データ転送レートは、帯域幅グラフで時間の経過に沿って追跡できます。表示されるのは次の2つです：

TX（送信） — アプリケーションからクライアントへ送信されたデータです。TXの値が高い場合は、サイズの大きなレスポンス、ファイルダウンロード、メディアコンテンツの配信が多い状態を示します。
RX（受信） — クライアントからアプリケーションが受信したデータです。RXのスパイクは、ファイルアップロードやペイロードの大きいリクエストと重なることが多くあります。

帯域幅を監視すると、アプリケーションのデータ転送のパターンを把握でき、予期しない変化にも気づけます。たとえば、アウトバウンドトラフィックが急増した場合は、APIレスポンスが非効率になっているか、クライアントが大きなリソースを繰り返し要求している可能性があります。