メインコンテンツへスキップ
ヘルスとモニタリング

何をプローブし、何を監視すべきか、そしてプローブでは分からないことを説明します。

Markdown

プローブ​

エンドポイント応答用途
GET /health/liveプロセスがリクエストを処理している間は 200 {"status":"ok"}ライブネス
GET /health/readyPostgreSQL が応答する場合は 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 はメトリクスをエクスポートしません。リクエストレートとレイテンシには、ゲートウェイまたはサービスメッシュを使用してください。