Ollama 本番環境の監視：ログ設定から Prometheus アラート実践まで

午前3時17分。枕元のスマートフォンが震え、一度、二度、三度と続きます。まどろみの中で画面をスワイプすると、Slack の赤いアラートメッセージが目に刺さりました：Ollama API timeout - service unavailable。

最初に浮かんだのは：しまった、という思いでした。

当時、Llama 3.1 ベースのカスタマーサービスシステムをリリースして2週間。ユーザー数は多くなく、1日数百回の呼び出し規模でした。デプロイ時は少し不安だったことを覚えています。基本的なログ記録を設定しただけで、監視もアラートもありません。「まず動かしてから考えよう」と。その結果、午前3時に起こされたとき、どこに問題があるのか全くわからなかったのです。GPU メモリが満杯？プロセスが落ちた？ネットワーク問題？全くの手探り状態でした。

その障害対応は朝6時までかかりました。事後振り返りで、私たちのようなチームが少なくないことに気づきました。

監視の欠如が主な理由の一つです。

この記事では、私が経験した失敗を避けるための知見をお伝えします。ログ設定から Prometheus + Grafana 監視、そして AlertManager アラートまで、完全なソリューションを共有します。すべてコピーしてそのまま使える設定ファイル付きです。この構成に従えば、本番レベルの監視システムを約30分で構築できます。正直なところ、当時この仕組みがあれば、あの夜、少なくともあと3時間は眠れたはずです。

本番環境監視のコア課題

Ollama は通常の Web サービスとは異なります。それは「リソースを大量に消費する存在」です。ロードされた各モデルは、メモリだけで4〜16 GBを占有します（データは Markaicode の実測値）。さらに、モデルのコールドスタート（ディスクからメモリへのロード）には10〜30秒かかります。つまり、サービスが落ちて再起動した場合、ユーザーは応答を受け取るまで30秒待つことになります。

私が経験した主な落とし穴は以下の通りです：

メモリリークと GPU 枯渇。長時間稼働後、Ollama は時々 VRAM の解放を「忘れる」ことがあります。24GB VRAM のマシンが2日間稼働した後、残り2GBしかなくなり、新しいリクエストがすべて拒否されたのを見たことがあります。問題は、ユーザーからの苦情があるまで何が起きたのかわからなかったことです。

リクエストキューの滞留。推論自体が遅く、1つのリクエストに5〜20秒かかることがあります。同時に数十のリクエストが来ると、キューはどんどん長くなり、最終的にタイムアウトします。しかし、キューが滞留しているかどうかをどうやって知るのでしょうか？推測するしかありません。

モデルロード遅延。複数のモデルを切り替える際、ロード時間はブラックボックスです。ユーザーはなぜ応答が遅いのかわからず、あなたもわかりません。

したがって、監視の目標は明確になります：サービス可用性（プロセスは生きているか？）、パフォーマンス指標（応答はどれくらい速い？）、リソース利用率（GPU メモリはどれくらい残っている？）、エラー率（何件のリクエストが失敗した？）。この4つの次元を把握すれば、安心できます。

監視ソリューションの選択において、私はいくつかの組み合わせを試しました。小規模チームなら Prometheus + Grafana で十分です；LLM の Prompt とレスポンスを追跡する必要があるなら、Langfuse が便利です；エンタープライズ環境では SigNoz を検討できます。これは OpenTelemetry ベースで、ログ、メトリクス、トレースを統合しています。以下では、最も汎用的な基礎となる Prometheus ソリューションを中心に解説します。

ログ設定と systemd サービス最適化

Ollama を動かすのは簡単ですが、安定して稼働させ続けるには、まずログを正しく設定する必要があります。以前、痛い目を見ました。問題が起きてログを確認しに行ったら、何も記録されていなかったり、ログファイルが数十 GB になってディスクを圧迫していたりしました。

systemd サービス設定

公式スクリプトで Ollama をインストールした場合、systemd サービスはすでに作成されています。しかし、デフォルト設定はシンプルなので、本番環境では追加の設定が必要です：

# /etc/systemd/system/ollama.service

[Unit]
Description=Ollama Service
After=network.target

[Service]
Type=simple
User=ollama
Group=ollama

# 作業ディレクトリ
WorkingDirectory=/usr/share/ollama

# 環境変数
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/data/ollama/models"
Environment="OLLAMA_DEBUG=1"
Environment="OLLAMA_LOG_FORMAT=json"

# リソース制限（ハードウェアに合わせて調整）
LimitNOFILE=65535
LimitNPROC=4096
MemoryMax=32G

# 自動再起動戦略
Restart=always
RestartSec=10

# 起動コマンド
ExecStart=/usr/local/bin/ollama serve

# 標準出力とエラー出力
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

重要なポイントをいくつか経験からお伝えします：

Restart=always と RestartSec=10：プロセスが異常終了した後、自動的に再起動します。10秒待つことで、システムに少し余裕を与えます。以前、メモリ枯渇による繰り返しクラッシュに遭遇しましたが、この間隔がないと、猛烈な勢いで再起動を繰り返し、ログが爆発的に増殖しました。

MemoryMax=32G：Ollama が使用できる最大メモリを制限します。マシンに他のサービスがある場合、これは重要です。制限なしで試したところ、Ollama が64GB メモリを使い果たし、SSH にもログインできなくなりました。

OLLAMA_DEBUG=1 と OLLAMA_LOG_FORMAT=json：本番環境ではデバッグモードを有効にすることをお勧めします。問題が起きたときに調査しやすくなります。JSON フォーマットのログは、後でツールで解析するのに便利です。

設定を変更した後、再読み込みを忘れないでください：

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo systemctl enable ollama  # 自動起動

Docker デプロイのログ設定

Docker で実行する場合、ログ管理はより注意が必要です。Docker はデフォルトでログを /var/lib/docker/containers/ に書き込みます。制限なしでは無限に増大します。

私の docker-compose 設定はこのようになります：

# docker-compose.yml
version: '3.8'

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: always
    ports:
      - "11434:11434"
    volumes:
      - ./ollama_data:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0:11434
      - OLLAMA_DEBUG=1
    deploy:
      resources:
        limits:
          memory: 32G
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "5"

max-size: "100m" は単一のログファイルの最大サイズが100MB、max-file: "5" は5つのファイルを保持することを意味します。合計で最大500MB のログとなり、十分でありながらディスクを圧迫しません。

ログレベルの説明

Ollama がサポートする環境変数：

変数	説明	本番推奨
OLLAMA_DEBUG	1 に設定で詳細ログ有効	有効推奨
OLLAMA_LOG_LEVEL	ログレベル（INFO/DEBUG/WARN）	INFO または DEBUG
OLLAMA_LOG_FORMAT	ログフォーマット（text/json）	JSON

私は常に DEBUG を有効にしています。ハードディスクに余裕があるなら、問題調査時に多くの時間を節約できます。

journalctl でログを確認する実践

設定後、journalctl でログを確認します：

# リアルタイムでログを確認
sudo journalctl -u ollama -f

# 直近100行を確認
sudo journalctl -u ollama -n 100

# 今日のログを確認
sudo journalctl -u ollama --since today

# 特定のキーワードで検索
sudo journalctl -u ollama | grep -i "error"

# ログをファイルにエクスポート
sudo journalctl -u ollama --since "2026-04-12 00:00:00" > ollama-debug.log

一つのテクニック：JSON フォーマットのログを有効にしている場合、jq で解析できます：

sudo journalctl -u ollama -o json | jq 'select(.level=="error")'

これでエラーレベルのログだけを確認でき、大量の INFO ログから探す必要がありません。

Prometheus + Grafana 監視ソリューション

ログは事後振り返りのツールですが、監視こそが予兆を捉える目です。Prometheus + Grafana の組み合わせを2年以上使っていますが、設定は少し煩雑なものの、安定して信頼性が高く、コミュニティリソースも豊富です。

ollama-exporter デプロイ

Ollama 自体は Prometheus メトリクスを直接公開しないため、exporter で収集する必要があります。frcooper/ollama-exporter を使用しています（Star 数は36と多くありませんが、機能は十分です）。

デプロイ方法は2つ：バイナリを直接実行するか、Docker を使うか。Docker をお勧めします：

# docker-compose.yml に exporter サービスを追加
services:
  ollama-exporter:
    image: frazco/ollama-exporter:latest
    container_name: ollama-exporter
    restart: always
    ports:
      - "9101:9101"
    environment:
      - OLLAMA_HOST=ollama:11434  # ollama コンテナを指す
    depends_on:
      - ollama

次に Prometheus の設定：

# prometheus.yml
global:
  scrape_interval: 30s  # サンプリング間隔、Markaicode は30秒を推奨
  evaluation_interval: 30s

scrape_configs:
  - job_name: 'ollama-exporter'
    static_configs:
      - targets: ['ollama-exporter:9101']
        labels:
          instance: 'ollama-prod'

  # GPU 監視（NVIDIA を使用する場合）
  - job_name: 'nvidia-gpu'
    static_configs:
      - targets: ['localhost:9835']

Prometheus も docker-compose に追加：

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: always
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'

volumes:
  prometheus_data:

主要な監視メトリクス

ollama-exporter は以下のメトリクスを収集します。重要なものをリストアップしました：

メトリクス名	説明	注目点
ollama_requests_total	総リクエスト数	エラー率計算
ollama_requests_failed	失敗リクエスト数	直接監視
ollama_model_load_duration_seconds	モデルロード時間	コールドスタート性能
ollama_request_duration_seconds	リクエスト応答時間	P95/P99 レイテンシ
ollama_tokens_per_second	推論速度	スループット

システムレベルのメトリクスもあります（node-exporter と併用）：

• CPU 使用率：node_cpu_seconds_total
• メモリ使用率：node_memory_MemAvailable_bytes
• ネットワークトラフィック：node_network_receive_bytes_total

GPU 監視設定

GPU は LLM サービスの心臓部であり、監視は必須です。nvidia_gpu_prometheus_exporter を使用しています：

# NVIDIA GPU exporter をインストール
docker run -d \
  --name nvidia-exporter \
  --restart always \
  -p 9835:9835 \
  --gpus all \
  nvidia/gpu-prometheus-exporter:latest

以下の主要なメトリクスを出力します：

• nvidia_gpu_utilization：GPU 利用率
• nvidia_gpu_memory_used_bytes：VRAM 使用量
• nvidia_gpu_memory_free_bytes：空き VRAM
• nvidia_gpu_temperature：GPU 温度

マルチ GPU 環境の場合、メトリクスには gpu_id ラベルが付与され、Grafana で GPU ごとに表示できます。

Grafana Dashboard 設定

Grafana Dashboard の JSON を直接提供します。これをファイルに保存し、Grafana で Import Dashboard をクリックすれば使用できます：

{
  "dashboard": {
    "title": "Ollama Production Monitor",
    "panels": [
      {
        "title": "Request Rate",
        "type": "graph",
        "targets": [
          {
            "expr": "rate(ollama_requests_total[5m])",
            "legendFormat": "Requests/sec"
          }
        ],
        "gridPos": {"x": 0, "y": 0, "w": 12, "h": 6}
      },
      {
        "title": "Error Rate",
        "type": "gauge",
        "targets": [
          {
            "expr": "rate(ollama_requests_failed[5m]) / rate(ollama_requests_total[5m]) * 100",
            "legendFormat": "Error %"
          }
        ],
        "gridPos": {"x": 12, "y": 0, "w": 6, "h": 6}
      },
      {
        "title": "GPU Memory Usage",
        "type": "graph",
        "targets": [
          {
            "expr": "nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes * 100",
            "legendFormat": "GPU {{gpu_id}}"
          }
        ],
        "gridPos": {"x": 0, "y": 6, "w": 12, "h": 6}
      },
      {
        "title": "Response Latency P95",
        "type": "stat",
        "targets": [
          {
            "expr": "histogram_quantile(0.95, rate(ollama_request_duration_seconds_bucket[5m]))",
            "legendFormat": "P95 Latency"
          }
        ],
        "gridPos": {"x": 12, "y": 6, "w": 6, "h": 6}
      }
    ]
  },
  "overwrite": true
}

実際の表示はほぼこのようになります：

• 左上：リクエストレート曲線、ピーク時間がわかります
• 右上：エラー率ゲージ、5% を超えると赤くなります
• 左下：マルチ GPU メモリ使用曲線
• 右下：P95 レイテンシ数値

Tokens/s のパネルも追加して、異なるモデルの推論速度を横比較できるようにしています。

Grafana データソース設定

Grafana コンテナ起動後、Prometheus データソースを手動で設定する必要があります：

1. Grafana にログイン（デフォルト admin/admin）
2. Configuration -> Data Sources -> Add data source
3. Prometheus を選択、URL に http://prometheus:9090 を入力
4. Save & Test

docker-compose でまとめてデプロイする場合、ネットワークが共通なのでコンテナ名で直接アクセスできます。

アラートルールと AlertManager 設定

監視で問題を可視化できますが、アラートがあって初めて「今すぐ対応が必要」だとわかります。以前、私は間違いを犯しました。すべてのアラートを critical に設定したのです。その結果、スマートフォンは1日に何十回も振動し、最終的に感覚が麻痺し、本当に問題が起きても反応できなくなりました。

アラート段階分け戦略

アラートを3段階に分けています。このロジックは数回のインシデントを経て改良されました：

レベル	トリガー条件	応答要件
Critical	サービス停止、GPU メモリ95%超過、エラー率20%超過	即座に対応（Slack + スマートフォンプッシュ）
Warning	応答時間60秒超過、GPU メモリ80%超過、エラー率5%超過	1時間以内に確認（Slack のみ）
Info	モデル切り替え、新バージョンデプロイ	記録のみ（メールサマリー）

重要な原則：Critical アラートは少なく、見たら緊張するようにする。

Prometheus アラートルール

prometheus.yml にアラートルールを追加：

rule_files:
  - 'ollama_alerts.yml'

そして別途 ollama_alerts.yml を作成：

# ollama_alerts.yml
groups:
  - name: ollama_critical
    rules:
      # サービス停止アラート
      - alert: OllamaServiceDown
        expr: up{job="ollama-exporter"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Ollama サービス停止"
          description: "Ollama exporter に接続できません。サービスが停止している可能性があります"

      # GPU メモリアラート（>95%）
      - alert: GPUMemoryCritical
        expr: nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes > 0.95
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "GPU メモリが枯渇寸前"
          description: "GPU {{ gpu_id }} メモリ使用率が95%を超えています。現在 {{ $value | humanizePercentage }}"

      # 高エラー率アラート
      - alert: HighErrorRate
        expr: rate(ollama_requests_failed[5m]) / rate(ollama_requests_total[5m]) > 0.20
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "リクエストエラー率が高すぎます"
          description: "過去5分間のエラー率が20%を超えています。ログを確認してください"

  - name: ollama_warning
    rules:
      # 応答時間アラート
      - alert: SlowResponseTime
        expr: histogram_quantile(0.95, rate(ollama_request_duration_seconds_bucket[5m])) > 60
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "P95 応答時間が遅すぎます"
          description: "95% のリクエストの応答時間が60秒を超えています"

      # GPU メモリ警告
      - alert: GPUMemoryWarning
        expr: nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes > 0.80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "GPU メモリ使用率が高い"
          description: "GPU {{ gpu_id }} メモリ使用率が80%を超えています"

      # エラー率警告
      - alert: ErrorRateWarning
        expr: rate(ollama_requests_failed[5m]) / rate(ollama_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "リクエストエラー率が上昇"
          description: "過去5分間のエラー率が5%を超えています"

いくつかの注意点：

• for: Xm：X分間持続してからトリガー。瞬時の変動による誤検知を回避
• GPU アラート閾値95%：実測では、95%を超えるとすぐに問題が発生します
• エラー率アラートは rate() を使用：絶対数ではなく、トレンドを見るため

AlertManager 設定

AlertManager はアラートを外部に送信する役割を担います。設定ファイル alertmanager.yml：

global:
  resolve_timeout: 5m

# ルーティング設定
route:
  group_by: ['severity', 'alertname']
  group_wait: 30s      # 同じグループのアラートを収集するため30秒待機
  group_interval: 5m   # 同じグループのアラート間隔
  repeat_interval: 3h  # 未解決アラートの再送間隔
  routes:
    - match:
        severity: critical
      receiver: 'critical-alerts'
      continue: false
    - match:
        severity: warning
      receiver: 'warning-alerts'
      continue: false
    - match:
        severity: info
      receiver: 'info-alerts'

# レシーバー設定
receivers:
  - name: 'critical-alerts'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
        channel: '#ollama-critical'
        send_resolved: true
        title: '{{ .Status | toUpper }}: {{ .CommonAnnotations.summary }}'
        text: '{{ .CommonAnnotations.description }}'

  - name: 'warning-alerts'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
        channel: '#ollama-monitor'
        send_resolved: true

  - name: 'info-alerts'
    email_configs:
      - to: 'your-email@example.com'
        send_resolved: true

Slack Webhook 設定手順

1. Slack で App を作成（または Incoming Webhooks を使用）
2. Webhook URL を api_url フィールドに追加
3. チャンネルを分けることを推奨：critical は専用チャンネル、warning は通常チャンネル

スマートフォンプッシュも追加しています。PagerDuty や OpsGenie を使用している場合、AlertManager は統合をサポートしています。費用をかけたくない場合は、Telegram Bot も利用可能で、設定も複雑ではありません。

サイレンスと抑制ルール

メンテナンス中など、一時的にアラートをサイレンスする必要がある場合、AlertManager UI で直接操作できます：

# AlertManager UI にアクセス
http://your-server:9093

# Silences -> New Silence をクリック
# 継続時間、マッチングラベルを設定

API でも可能です：

curl -X POST http://localhost:9093/api/v1/silences \
  -d '{
    "matchers": [{"name": "alertname", "value": "OllamaServiceDown", "isRegex": false}],
    "startsAt": "2026-04-12T10:00:00Z",
    "endsAt": "2026-04-12T12:00:00Z",
    "createdBy": "admin",
    "comment": "Scheduled maintenance"
  }'

LLM 専用監視ツール応用

Prometheus + Grafana は汎用的なソリューションですが、LLM には特有の監視ニーズがあります：Prompt トレース、Token コスト、レスポンス品質評価。これらのメトリクスは従来の監視ツールでは扱いにくいです。

Langfuse：LLM トレースと Prompt 管理

Langfuse は LLM アプリケーション専用に設計された監視プラットフォームで、MIT ライセンスのオープンソース、セルフホスト対応です。できること：

• 各会話のトレース：入力 Prompt、出力内容、Token 数、所要時間を記録
• Prompt バージョン管理：Prompt を変更した後、新旧バージョンの効果を比較可能
• 品質評価：ユーザーフィードバック、人力アノテーションを記録し、モデル出力品質を追跡

統合方法は簡単で、Langfuse 公式が Ollama アダプタを提供しています：

# Python 統合例
from langfuse import Langfuse
import requests

langfuse = Langfuse(
    public_key="pk-xxx",
    secret_key="sk-xxx",
    host="https://cloud.langfuse.com"  # またはセルフホストアドレス
)

# 各呼び出しを記録
trace = langfuse.trace(
    name="ollama-chat",
    input={"prompt": user_prompt},
    metadata={"model": "llama3.1"}
)

response = requests.post(
    "http://localhost:11434/api/generate",
    json={"model": "llama3.1", "prompt": user_prompt}
)

trace.update(
    output=response.json()["response"],
    metadata={"tokens": response.json().get("eval_count", 0)}
)

Langfuse セルフホスト版は Docker でデプロイ可能：

services:
  langfuse-server:
    image: langfuse/langfuse:latest
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/langfuse
      - NEXTAUTH_SECRET=your-secret

LangChain を使用している場合、統合はさらに簡単で、Langfuse に公式の callback handler があります。

SigNoz：OpenTelemetry 統合監視

SigNoz は OpenTelemetry ベースの可観測性プラットフォームで、ログ、メトリクス、トレースを統合しています。Prometheus、Jaeger、ELK の3つのシステムを別々に保守する必要がない利点があります。

LLM アプリケーションの場合、SigNoz のトレース機能が非常に実用的です。リクエストが API エントリポイントからモデル推論、データベースクエリまでの完全なチェーンを確認できます。

SigNoz のデプロイには比較的多くのリソースが必要で、最低4GB メモリを推奨します。公式の Docker Compose でワンクリックデプロイ：

git clone https://github.com/SigNoz/signoz.git
cd signoz/deploy/docker
docker compose up -d

ツール選択の推奨

異なるシナリオでの推奨をまとめました：

シナリオ	推奨ソリューション	理由
小規模チーム（5人未満）	Prometheus + Grafana	シンプルで十分、コミュニティリソースが豊富
Prompt トレースが必要	Prometheus + Langfuse	Langfuse は LLM に特化、補完的
エンタープライズマルチサービス	SigNoz + OpenTelemetry	統一プラットフォーム、運用コストが低い
純粋なクラウドネイティブ	マネージドサービスを直接使用	運用工数を削減

私自身は現在、Prometheus + Grafana + Langfuse の組み合わせを使用しています。Prometheus はインフラメトリクスを、Langfuse は LLM アプリケーション層を管理し、役割を分けて明確にしています。

最後に

長々と語りましたが、結局一言に尽きます：問題が起きてから監視を考えるのではなく、事前に準備する。

あの午前3時の教訓から、この完全な監視ソリューションが生まれました。現在、私の Ollama サービスは1年以上稼働しており、その間に数回 GPU メモリアラートに遭遇しましたが、すべて Warning レベルで処理され、夜中に起こされることはなくなりました。

このソリューションの構築コストは実際には高くありません。すべての設定ファイルを整理しましたので、直接ダウンロードして使用できます：

• systemd サービス設定
• Docker Compose 完全デプロイ（Ollama + Exporter + Prometheus + Grafana）
• Prometheus アラートルール
• AlertManager 設定テンプレート
• Grafana Dashboard JSON

対応する GitHub リポジトリを記事の最後に記載しています。この設定に従えば、慣れている人は20分、初心者でも30分程度で稼働させられます。

次のステップとして推奨：

1. まず最も基本的な Prometheus + Grafana でメトリクスを稼働させる
2. 3〜5日観察し、正常状態のデータ範囲に慣れる
3. 実際の状況に基づいてアラート閾値を調整
4. Prompt トレースが必要な場合は、Langfuse を追加

監視は一度の投資で、継続的な利益をもたらします。午前3時の教訓から学ぶ必要がないことを願っています。

---

設定ファイルリポジトリ：github.com/yourname/ollama-monitoring-config（サンプルリンク、実際のデプロイ時は置き換えてください）

シリーズ記事：

• Ollama ローカルデプロイ完全ガイド — シリーズ第1弾
• Ollama パフォーマンスチューニング実践 — 次回予告

FAQ

Ollama 本番環境の監視に必要なコアメトリクスは？

4つの次元：サービス可用性（プロセス生存状態）、パフォーマンス指標（P95/P99 レスポンスレイテンシ）、GPU メモリ利用率（枯渇防止）、リクエストエラー率（異常トレンド追跡）。

Prometheus + Grafana と Langfuse の違いは？

Prometheus + Grafana はインフラメトリクス（CPU、GPU、メモリ、リクエスト数）を監視、Langfuse は LLM アプリケーション層（Prompt トレース、Token コスト、レスポンス品質評価）に特化。両者は補完的で、組み合わせ使用を推奨。

アラート閾値はどう設定すべき？

3段階を推奨：Critical（GPU メモリ95%超過、エラー率20%超過、サービス停止）は即座に対応；Warning（GPU メモリ80%超過、エラー率5%超過）は1時間以内に確認。重要なのは Critical を少なく、見たら緊張するようにすること。

Docker デプロイでログファイルが無限増大する場合は？

docker-compose.yml の logging 設定で max-size: "100m" と max-file: "5" を追加。単一ログファイルを100MB、最大5ファイル保持で、合計500MB を超えないように制限。

GPU マルチカード環境で各 GPU を個別監視するには？

nvidia_gpu_prometheus_exporter のメトリクスには gpu_id ラベルが付与されます。Grafana の PromQL で {{gpu_id}} を legendFormat として使用すると、GPU ごとに表示できます。

午前3時にアラートを受信した後、どう迅速に問題を特定する？

まず GPU メモリ曲線を確認（使い尽くされていないか）、次にエラー率トレンドを確認（急激な上昇か徐々に悪化か）、最後に journalctl ログで具体的なエラー情報を検索。この順序で10分以内に根本原因を特定できます。

7 min read · 公開日: 2026年4月12日 · 更新日: 2026年4月12日