ヘルスとモニタリング
何をプローブし、何を監視すべきか、そしてプローブでは分からないことを説明します。
プローブ
| エンドポイント | 応答 | 用途 |
|---|---|---|
GET /health/live | プロセスがリクエストを処理している間は 200 {"status":"ok"} | ライブネス |
GET /health/ready | PostgreSQL が応答する場合は 200 {"status":"ok"}、それ以外は 503 {"status":"unavailable"} | レディネス: 準備完了後にのみトラフィックをルーティングします |
livenessProbe:
httpGet: { path: /health/live, port: 8080 }
readinessProbe:
httpGet: { path: /health/ready, port: 8080 }
timeoutSeconds: 5
レディネスプローブには timeoutSeconds を設定してください。PostgreSQL が接続を受け付けても応答しなくなった場合、チェックはそれよりはるかに長く待機する可能性があります。タイムアウトを設定することで、プローブはハングせずに失敗します。
レディネスが確認しないこと
レディネスが確認するのはデータベースのみです。アクセスキーが有効か、Unico に到達できるかは確認しません。誤ったアクセスキーは、プローブの失敗ではなく、作成時のエラーとして現れます。デプロイ後のチェックには、実際の作成リクエストを含めてください。
ログ
ログは標準出力への JSON 行で、timestamp、severity、service、message を含みます。保存済みプロセスに関わる障害には、その id が含まれます。呼び出し側の誤り(400、404、409、422)はログに記録されません。
正常な起動では、PostgreSQL の接続メッセージの合間に、次の行がこの順序で記録されます(カタログの version と count は、カタログのリリースごとに変わります)。
{"severity":"INFO","timestamp":"2026-11-03T14:02:11.482913407Z","message":"attribute catalog loaded","service":"human-plugin","version":"2026-10-29.1","count":53,"url":"https://human-token-assets.unico.app/attribute-catalog.json"}
{"severity":"INFO","timestamp":"2026-11-03T14:02:11.731050212Z","message":"database schema ready","service":"human-plugin"}
{"severity":"INFO","timestamp":"2026-11-03T14:02:11.733418901Z","message":"human plugin listening","service":"human-plugin","addr":":8080"}
アラート対象
- レディネスの失敗: データベースに到達できません。
- バックエンドの呼び出しに対する
503 DATABASE_UNAVAILABLEまたは502 UPSTREAM_UNAVAILABLEの応答の繰り返し。 - コンテナの再起動: 再起動の繰り返しは、通常、設定の欠落、カタログへの到達不能、またはデータベースの問題を意味します。ログに原因が記載されています。
creating processやretrieving processなどの、エラーレベルのログ行。
Human Plugin はメトリクスをエクスポートしません。リクエストレートとレイテンシには、ゲートウェイまたはサービスメッシュを使用してください。