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

午前3時17分。Slack に赤いアラート：Ollama API timeout - service unavailable。カスタマーサポートのシステムを稼働させて2週間、毎日数百回の呼び出しがありました。デプロイ時には基本的なログ記録しか設定せず、監視もアラートも一切なし。GPU メモリが満杯になった？プロセスが落ちた？ネットワークの問題？まったく見当もつきません。結局、朝6時まで格闘してようやく復旧しました。

監視の欠如は、その主な原因の一つです。

この記事では、ログ設定から Prometheus + Grafana による監視、さらに AlertManager によるアラートまで、完全なソリューションを共有します。どれもそのままコピーして使える設定ファイルです。この方法に沿えば、おおよそ30分で本番レベルの監視体制を立ち上げられます。

本番環境の監視における核心的な課題

Ollama は普通の Web サービスとは少し違います。いわば「リソースを大量に食う存在」です。モデルを1つ読み込むだけで、メモリだけでも 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：本番環境では debug モードを有効にしておくのがおすすめです。問題が起きたとき調査しやすくなります。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	推論速度	throughput

さらにシステムレベルの指標もあります（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_id ラベルが付くので、Grafana でカードごとに分けて表示できます。

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	レスポンス時間60s超過、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: '[email protected]'
        send_resolved: true

Slack Webhook の設定手順

1. Slack で App を作成する（または Incoming Webhooks を使う）
2. Webhook URL を api_url フィールドに追加する
3. channel は分けるのがおすすめ：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 のトレース機能はとても実用的です。1つのリクエストが 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 パフォーマンス最適化の実践 — 次回予告