【Railway】ログの表示
Railwayでビルド、デプロイ、環境、HTTPのログを表示およびフィルタリングする方法を学びます。
Railwayはこちら （←このリンクから登録すると20ドル分のクレジットがもらえます）
ログの表示
標準出力または標準エラー（例： console.log(...)）に出力されたビルドまたはデプロイのログは、後で表示または検索するためにRailwayによってキャプチャされます。
Railwayでログを表示するには3つの方法があります。
- ビルド/デプロイパネル → ダッシュボードでデプロイメントをクリック
- ログエクスプローラ → 上部ナビゲーションのObservabilityタブをクリック
- CLI →
railway logsコマンドを実行
ビルド/デプロイパネル
特定のデプロイメントのログは、サービスウィンドウでデプロイメントをクリックすることで表示でき、アプリケーションの障害をデバッグするのに役立ちます。
同様に、特定のビルドのログは、デプロイメントを開いた後、Build Logsタブをクリックすることで表示できます。
ログエクスプローラ
環境全体のログは、上部ナビゲーションの「Observability」ボタンをクリックすることでまとめて表示できます。ログエクスプローラは、複数のサービスにまたがる可能性のあるより一般的な問題をデバッグするのに役立ちます。
ログエクスプローラには、日付範囲の選択や特定の列の表示/非表示の切り替えなどの追加機能もあります。
コマンドライン
デプロイメントログは、コマンドラインから表示して、最新のデプロイメントの現在のステータスをすばやく確認することもできます。railway logs を使用して表示します。
ログのフィルタリング
Railwayは、ログのクエリに使用できるカスタムフィルタ構文をサポートしています。
フィルタ構文はすべてのログタイプで利用可能ですが、一部のログタイプには特定の属性があります。
デプロイメントログ
<search term>→ 部分的な部分文字列の一致でフィルタリング"<search term>"→ 完全なログメッセージでフィルタリングreplica:<replica_id>→ 特定のレプリカのUUIDでフィルタリング@attribute:value→ カスタム属性でフィルタリング（以下の構造化ログを参照）
例：
「request」という単語を含むログを検索します。
request「request handled」というメッセージに完全に一致するログを検索します。
"request handled"エラーレベルのログを検索します。
@level:error警告レベルのログを検索します。
@level:warnエラーレベルと特定のテキストを含むログを検索します。
@level:error AND "failed to send batch"特定のカスタム属性を持つログを検索します。
@customAttribute:value特定の配列属性を持つログを検索します。
@arrayAttribute[i]:value環境ログ
環境ログを使用すると、ログが出力された環境からログをクエリできます。
これは、環境内のすべてのサービスから出力されたログを、すべて1つの中央の場所で同時に検索できることを意味します。
デプロイメントログで利用可能なフィルタに加えて、環境ログでは追加のフィルタが利用できます。
@service:<service_id>→ 特定のサービスのUUIDでフィルタリング
例：
Postgresデータベースサービスからのログを除外します。
-@service:<postgres_service_id>PostgresデータベースサービスとRedisキャッシュサービスからのログを除外します。
-@service:<postgres_service_id> AND -@service:<redis_service_id>PostgresデータベースサービスとRedisキャッシュサービスからのログのみを表示します。
@service:<postgres_service_id> OR @service:<redis_service_id>HTTPログ
HTTPログは同じフィルタ構文を使用しますが、HTTP固有のデータには特定の属性セットがあります。
HTTPログで一般的に使用されるフィルタの一部は次のとおりです。
@requestId:<request_id>→ リクエストIDでフィルタリング@timestamp:<timestamp>→ タイムスタンプでフィルタリング（RFC3339形式）@method:<method>→ メソッドでフィルタリング@path:<path>→ パスでフィルタリング@host:<host>→ ホストでフィルタリング@httpStatus:<status_code>→ HTTPステータスコードでフィルタリング@responseDetails:<details>→ 応答の詳細でフィルタリング（アプリケーションが応答に失敗した場合にのみ入力されます）@clientUa:<user_agent>→ 特定のクライアントのユーザーエージェントでフィルタリング@srcIp:<ip>→ 送信元IPでフィルタリング（リクエストを行ったクライアントのIPアドレス）@edgeRegion:<region>→ エッジリージョンでフィルタリング（リクエストを処理したエッジノードのリージョン）
例：
特定のパスのログを検索します。
@path:/api/v1/users500エラーを返した特定のパスのログを検索します。
@path:/api/v1/users AND @httpStatus:500500または501エラーを返した特定のパスのログを検索します。
@path:/api/v1/users AND (@httpStatus:500 OR @httpStatus:501)200以外のすべての応答を検索します。
-@httpStatus:200ヨーロッパ周辺から発信されたすべてのリクエストを検索します。
@edgeRegion:europe-west4-drams3a特定のIPアドレスから発信されたすべてのリクエストを検索します。
@srcIp:66.33.22.11コンテキストで表示
ログを検索するとき、周囲のログを表示すると便利なことがよくあります。これを行うには、「タイムスタンプ」列をクリックするか、ログを展開して「コンテキストで表示」ボタンをクリックします。
構造化ログ
構造化ログは、構造化されたJSON形式で出力されるログであり、カスタムメタデータをログに添付したり、スタックトレースなどの複数行のログを保持したりする場合に役立ちます。
console.log(JSON.stringify({
message: "A minimal structured log", // (必須) ログの内容
level: "info", // ログの重大度 (debug, info, warn, error)
customAttribute: "value", // カスタム属性 (@name:valueでクエリ)
}));構造化ログは、言語のライブラリで生成するのが最適です。たとえば、デフォルトのWinston JSON形式は、デフォルトで正しい構造でログを出力します。
level フィールドを持つログは、ログエクスプローラでそれに応じて色付けされます。
stderr に出力されたログは level.error に変換され、赤色で表示されます。
例
構造化ログの例をいくつか示します。
注： JSONログ全体が正しく解析されるためには、1行で出力する必要があります。
{"level":"info","message":"A minimal structured log"}{"level":"error","message":"Something bad happened"}{"level":"info","message":"New purchase!","productId":123,"userId":456}{"level":"info","message":"User roles updated","roles":["editor","viewer"],"userId":123}正規化戦略
Railwayサービス間で一貫したクエリ形式を確保するために、受信ログは上記の形式に自動的に正規化されます。
- 非構造化ログは
{"message":"...","level":"..."}に変換されます log.msgはlog.messageに変換されますlog.levelはlog.severityに変換されますstderrからのログはlevel.errorに変換されますstdoutからのログはlevel.infoに変換されます- レベルは小文字に変換され、
debug、info、warn、errorのいずれかに最も近いものに一致します
Railwayはこちら （←このリンクから登録すると20ドル分のクレジットがもらえます）
