DigitalBase Docs

監視と利用計測

AI 利用の計測（トークン・リクエスト・金額換算）と、既存の監視基盤（Prometheus / Grafana / Zabbix）への接続、運用アラートの通知を設定します。

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

何が計測されるか

計測の対象は API キー（sk-）経由のゲートウェイ利用です。1 リクエストごとに、キー・モデル・トークン数（実測値）・レイテンシ・成否が記録されます。

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

リクエスト・レスポンスの本文（プロンプト・回答）は保存しません。記録はメタデータのみです。保持期間は USAGE_RETENTION_DAYS（既定 90 日）で調整できます。

利用状況の画面・CSV / API での取得方法は APIアクセスキー を参照してください。

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

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

# .env の例 — default は未定義モデルの既定単価。未設定なら金額表示は出ない
MODEL_PRICES=nvidia/Qwen3.6-35B:0:0,gpt-4o:0.4:1.6,default:0:0
CURRENCY_SYMBOL=¥

単価の入れ方で意味が変わります。

  • クラウド API の単価を入れる → 「この利用をクラウドでやっていたら幾らだったか」の換算（コスト削減の説明用）
  • 社内原価・配賦単価を入れる → 部門課金（チャージバック）の元数字

Prometheus 連携（/metrics）

METRICS_ENABLED=1 で、Prometheus 形式の /metrics エンドポイントが公開されます（既定は無効）。既存の Prometheus / Grafana / Zabbix からそのまま収集できます。

# .env
METRICS_ENABLED=1
# 任意: 設定すると scrape 側に Authorization: Bearer <token> を要求
METRICS_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最も古い実行待ち（queued）の経過秒。増え続ける場合は worker 停止の疑い
digitalbase_pipeline_runs_stale_running上限時間の半分を超えて実行中のまま残っている run 数
digitalbase_event_outbox_pending / digitalbase_event_outbox_oldest_age_seconds未配送イベント数と最古の経過秒
digitalbase_event_outbox_dead再試行を諦めたイベント数（dead letter）。0 でなければ確認が必要
digitalbase_scheduler_upスケジューラの稼働（1=稼働）

運用アラート（Webhook 通知）

ALERT_WEBHOOK_URL を設定すると、運用上の異常を Webhook に通知します（既定は無効。変更は再起動で反映）。ペイロードは {text, type, details} の JSON で、Slack の Incoming Webhook にそのまま接続できます。

# .env
ALERT_WEBHOOK_URL=https://hooks.slack.com/services/XXX/YYY/ZZZ
# 評価間隔（秒、既定 900）
ALERT_CHECK_INTERVAL_SEC=900
通知条件再送抑止
key_budget_warning / key_budget_exceededAPI キーが月次トークン上限の 80% / 100% に到達キーごとに 1 日 1 回
mcp_server_errorカスタム MCP サーバがエラー状態サーバごとに 6 時間
llm_backend_downローカル LLM バックエンドに到達できない1 時間
pipeline_failedパイプライン実行の失敗実行（run）ごとに 1 回
pipeline_consecutive_failures同じパイプラインが連続で失敗（ALERT_PIPELINE_CONSECUTIVE_FAILURES、既定 3 回）連続失敗が続く間は 1 回、成功でリセット
pipeline_queue_backlog実行待ちの滞留（ALERT_PIPELINE_QUEUE_AGE_SEC、既定 900 秒）1 時間
event_outbox_backlog未配送イベントの滞留（ALERT_EVENT_OUTBOX_AGE_SEC、既定 600 秒）1 時間
補足

しきい値ベースの高度なアラート（エラー率・レイテンシ等）は、Prometheus 連携の上で Alertmanager / Grafana Alerting に組むことを推奨します。

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

エンドポイント認証用途
GET /api/health不要生存確認（liveness）。プロセスが応答すれば常に 200。バージョン・バックエンド・ライセンス状態を返します
GET /api/ready不要準備完了確認（readiness）。データベース接続・起動時 migration・推論サーバーの到達がすべて揃ったときだけ 200、欠けていれば 503 と失敗した項目（failed）を返します。ロードバランサやアップデート後の確認に使います
GET /v1/health不要API クライアント向けの事前確認。ライセンスが無効でも応答し、license（有効 / 猶予中 / 残り日数）と推論サーバーの到達性を返します
curl -s http://<host>:8000/api/ready
# 200 {"ready":true,"checks":{"db":true,"migrations":true,"llm":true}}
# 503 {"ready":false,"failed":["llm"],"checks":{...}}

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

関連