ログ

サービスの Logs タイルを開くか、サービスの Deployments の一覧でデプロイをクリックします。ログには専用のページがあります。

• デプロイ。 上部のドロップダウンで、どのデプロイのログを見るかを選びます。現在のデプロイが先頭にあり、それより前のものは History の下にあります（Removed または Failed）。隣にはデプロイの状態、ID（コピーボタン付き）、デプロイしたブランチとコミット（イメージを使うサービスではイメージ）が表示されます。
• Build logs はそのデプロイの出力です：クローン、ビルド、push、展開。デプロイ中はリアルタイムで更新され、終了後もデプロイとともに残ります。イメージをデプロイしただけのデプロイにはビルドがないので、このタブは使えません（ただしデプロイが失敗した場合は、その手順から原因がわかるので使えます）。
• Runtime logs はサービスのコンテナの出力で、その間に Zenavo のプラットフォームイベントが入ります。

表の読み方

1 行のログが表の 1 行になり、列は 3 つです。

列	表示内容
Severity	ERROR、WARN、INFO、DEBUG と色付きの点。
Time	ブラウザのタイムゾーンでの日時。例：10/22 18:25:06。
Summary	1 行に収めたログ。行（または左の矢印）をクリックすると全体が表示されます。JSON は整形され、Copy で行をコピーできます。展開した行には正確な時刻、インスタンス、デプロイも表示されます。

Zenavo は重要度を行そのものから読み取ります。JSON のロガー（"level"、"severity"、pino の数値レベル）、level= フィールド、行頭付近の INFO:、[WARN]、ERROR - などの語（uvicorn、Python logging、Java、Rails、Go）、Kubernetes 形式の E1022 … 行、nginx の [error]、クラッシュ（Traceback、panic:、…Error:）を理解します。レベルのないアクセスログは、4xx の応答が WARN、5xx が ERROR です。スタックフレームのようにインデントされた行は、直前の行の重要度を引き継ぎます。それ以外は INFO です。Kubernetes は stderr への出力を stdout と区別しないので、stderr に書いただけではエラーになりません。

検索ボックスと ERROR / WARN / INFO / DEBUG ボタンで表を絞り込めます。表は最新の行を追いかけます。上にスクロールすると止まり、Jump to latest で再び追いかけます。Export は表示中の内容を .log ファイルとして保存します（保存されたログでは期間内のすべての行）。

プラットフォームイベント

アプリ自身の出力の間に、インスタンスに起きたことが紫色の [Zenavo] Pod/<インスタンス> の接頭辞付きで表示されます。

イベント	意味
Scheduled	インスタンスがサーバーに配置されました。
Pulling、Pulled	イメージをダウンロード中、または準備完了。
Failed、ErrImagePull、ImagePullBackOff（ERROR）	イメージを取得できません。名前、タグ、レジストリへのアクセスを確認してください。
Created、Started	コンテナが作成され、起動しました。
Unhealthy（WARN）	ヘルスチェックが失敗しました。
BackOff（WARN）	コンテナが終了を繰り返し、間隔を延ばしながら再起動されています。
OOMKilled（ERROR）	メモリが足りなくなり、コンテナが停止されました。メモリ上限を上げるか使用量を減らしてください。
Exited（WARN）	コンテナがエラーコードで終了しました。
Killing、Stopped	インスタンスが置き換えられ（新しいデプロイ、再起動、スケールダウン）、指示どおり停止しました。
FailedMount、Evicted、FailedScheduling（ERROR）	ボリュームを接続できない、サーバーのリソースが足りない、またはインスタンスを動かす余地がありません。

ヘルスチェックの失敗のように繰り返すイベントは、1 分に 1 回まで回数付き（例：(x7)）で表示されます。

インスタンスとデプロイ

Runtime logs は既定で Newest instance（最新のインスタンス）を追いかけます。All instances を選ぶとすべてのレプリカが表示され（展開中は新旧のインスタンスが並びます）、各行にインスタンス名が付きます。

各行と各イベントには、そのインスタンスを起動したデプロイが記録されるので、展開中に新旧のインスタンスが同時に動いていても、デプロイのログはそのデプロイのものだけになります。Zenavo がこれを記録し始める前に保存された行は、代わりに時間でデプロイに割り当てます（デプロイの開始から次のデプロイの完了まで）。そのような行を表示するときは、ページにその旨が表示されます。

期間と保存されたログ

現在のデプロイでは、All time でログをリアルタイムに追いかけます。各インスタンスの最後の 200 行と、その後の新しい行です。期間（過去 1 時間から過去 30 日、または任意の範囲）を選ぶと、保存されたログが表示されます。削除されたデプロイでは常に保存されたログが表示されます。行はたいてい書き出されてから 2 分以内に保存されます。

ログの保持期間はチームのプランで決まります。

プラン	保持期間
Free	48 時間
Dev	7 日
Pro	30 日
Team	90 日

ログの保存は、機能が有効でサービスが動いているときに始まります。Viewer もライブログと同様に読んだりダウンロードしたりできます。

保存の仕組み

• コントロールプレーンが収集します。 Zenavo はサーバーの管理にすでに使っている接続を通じて、プロジェクト自身の名前空間だけからログとイベントを読みます。サーバーにはストレージの認証情報が渡らないので、サーバーが侵害されても誰かの保存ログを読んだり消したりはできません。
• 伏せ字にしてから暗号化します。 まず変数の値を取り除きます。コンテナの出力もイベントのメッセージも同じです（ヘルスチェック失敗のメッセージには受け取った応答が含まれることがあります）。続いて各チャンクを圧縮し、アップロード前にコントロールプレーンのマスターキーから導出した鍵で暗号化（AES-256-GCM）します。バケットやそのアクセスキーを手に入れた人にも暗号文しか見えません。
• 期限どおりに削除します。 プランの保持期間を過ぎたログは 1 時間ごとに削除され、削除したプロジェクトやチームのログも消えます。
• 上限があります。 各サービスが保存するログは 1 時間あたり 200 MB までです。それを超えるとお知らせの行を保存し、その時間の残りはスキップします。ライブログには全行が表示されます。64 KB を超える行は切り詰められます。

ログを Datadog、Loki、自分のエンドポイントにも転送するには、ログドレインを追加してください。プラットフォームイベントも [Zenavo] Pod/<インスタンス> — <理由>: <メッセージ> の行として転送されます。