DigitalBase Docs

監視と利用計測

AI 利用の計測、Prometheus 連携、運用アラート通知、死活監視。

対象:管理者 / 情シス必要権限:管理者ロール（環境変数の変更）

何が計測されるか

API キー（sk-）経由のゲートウェイ利用を 1 リクエストごとに記録する（キー・モデル・トークン数・レイテンシ・成否）。

経路計測
/v1/chat/completions（外部クライアント）リクエスト・実測トークン・レイテンシ・成否
/v1/embeddingsリクエスト・トークン（概算）・レイテンシ
/mcp のツール呼び出しリクエスト・呼び出したツール名
カスタム MCP のツール実行監査ログに全経路の呼び出し・成否
アプリ内のチャット画面記録なし（API キーを使わないため）
補足

本文（プロンプト・回答）は保存しない。保持期間は USAGE_RETENTION_DAYS（既定は無期限）。

利用状況の画面と CSV / API での取得はAPIアクセスキーを参照。

金額表示（モデル別単価）

利用状況画面に金額を表示する。.env に、1,000 トークンあたりの モデル名:入力単価:出力単価 をカンマ区切りで指定する。

MODEL_PRICES=nvidia/Qwen3.6-35B:0:0,gpt-4o:0.4:1.6,default:0:0
CURRENCY_SYMBOL=¥
  • default は未定義モデルの既定単価。未設定なら金額表示は出ない
  • クラウド単価を入れれば換算額、社内単価を入れれば部門課金の元数字になる

Prometheus 連携（/metrics）

.env の METRICS_ENABLED=1 で Prometheus 形式の /metrics を公開する（既定は無効）。

METRICS_ENABLED=1
METRICS_TOKEN=<任意の文字列>

METRICS_TOKEN は任意。設定すると scrape 側に Authorization: Bearer <token> を要求する。

prometheus.yml の例。

scrape_configs:
  - job_name: digitalbase
    metrics_path: /metrics
    static_configs:
      - targets: ["<DigitalBase ホスト>:8000"]
    # METRICS_TOKEN を設定した場合
    # authorization: { credentials: "<token>" }

公開されるメトリクス

メトリクス内容
digitalbase_gateway_requests_24h{channel}直近 24 時間のゲートウェイリクエスト数
digitalbase_gateway_errors_24h{channel} / digitalbase_gateway_rate_limited_24h{channel}エラー数・レート制限（429）数
digitalbase_gateway_input_tokens_24h{channel} / digitalbase_gateway_output_tokens_24h{channel}入出力トークン
digitalbase_gateway_latency_ms_24h{quantile}レイテンシ分位（p50 / p95 / p99）
digitalbase_llm_backend_upローカル LLM バックエンドの到達性（1=正常）
digitalbase_api_keys{state}発行済み API キー数（active / inactive）
digitalbase_connections{kind} / digitalbase_mcp_servers{status}外部接続数・カスタム MCP の状態別台数
digitalbase_pipeline_runs_24h{status}直近 24 時間のパイプライン実行（状態別）
digitalbase_pipeline_queue_oldest_age_seconds最も古い実行待ちの経過秒
digitalbase_pipeline_runs_stale_running上限時間の半分を超えて実行中のまま残っている run 数
digitalbase_event_outbox_pending / digitalbase_event_outbox_oldest_age_seconds未配送イベント数と最古の経過秒
digitalbase_event_outbox_dead配送を諦めたイベント数（0 以外は要確認）
digitalbase_scheduler_upスケジューラの稼働（1=稼働）

運用アラート（Webhook 通知）

.env に ALERT_WEBHOOK_URL を設定すると、運用上の異常を Webhook に通知する（既定は無効）。Slack の Incoming Webhook に直接接続できる。

ALERT_WEBHOOK_URL=https://hooks.slack.com/services/XXX/YYY/ZZZ
ALERT_CHECK_INTERVAL_SEC=900
  • ALERT_CHECK_INTERVAL_SEC は評価間隔（秒、既定 900）
  • 同じ通知の再送間隔（秒）は通知ごとに ALERT_*_REPEAT_SEC で決める（0 = 評価のたびに送る）
通知条件
key_budget_warning / key_budget_exceededAPI キーが月次トークン上限の 80% / 100% に到達
mcp_server_errorカスタム MCP サーバがエラー状態
llm_backend_downローカル LLM バックエンドに到達できない
pipeline_failedパイプライン実行の失敗
pipeline_consecutive_failures同じパイプラインが連続で失敗（ALERT_PIPELINE_CONSECUTIVE_FAILURES、既定 3 回）
pipeline_queue_backlog実行待ちの滞留（ALERT_PIPELINE_QUEUE_AGE_SEC、既定 900 秒）
event_outbox_backlog未配送イベントの滞留（ALERT_EVENT_OUTBOX_AGE_SEC、既定 600 秒）
service_exitサービスが異常終了した（Linux の systemd。止まった時だけ送り、落ち続ける間の再送は ALERT_SERVICE_EXIT_REPEAT_SEC、既定 4 時間）
補足

エラー率・レイテンシ等のしきい値アラートはPrometheus 連携の上で Alertmanager / Grafana に構成する。

死活監視（ヘルスチェック）

死活監視には次のエンドポイントを使う。

エンドポイント認証用途
GET /api/health不要生存確認（liveness）
GET /api/ready不要準備完了確認（readiness）。DB・migration・推論サーバーが揃えば 200、欠ければ 503
GET /v1/health不要API クライアント向け。ライセンス状態と推論サーバーの到達性

準備完了を確認する。

curl -s http://<host>:8000/api/ready

揃っていれば 200 を返す。

{"ready":true,"checks":{"db":true,"migrations":true,"llm":true}}

欠けていれば 503 を返す。

{"ready":false,"failed":["llm"],"checks":{...}}

推論サーバーの自動再起動と状態表示はモデル管理を参照。

関連