ログの表示

Railwayはこちら

ログの表示

標準出力または標準エラー（例： 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/users

500エラーを返した特定のパスのログを検索します。

@path:/api/v1/users AND @httpStatus:500

500または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はこちら