Ollama observability: logs / /api/ps / metrics / tracing
Parent: Ollama deployment, cloud, security and operations · Published reference · snapshot 2026-10-14 · skill ollama-expert/references/ollama-ops-platform.md
Also known as: Ollama observability: logs, /api/ps, metrics, tracing
↓ Facts as markdownall context files
Everything the scanned sources say about Ollama observability: logs, /api/ps, metrics, tracing: 46 source-anchored units across 9 sources, grouped by facet.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- What is the OpenTelemetry Collector? [source]
- The ollama_build_info metric is a simple gauge that tells you the version of Ollama currently running. This is incredibly useful for debugging, as you can quickly correlate performance issues or unexpected behavior with a specific Ollama version. Always ensure your Prometheus configuration is set to scrape the /metrics endpoint with an appropriate interval, typically between 15 and 60 seconds, to capture meaningful data without overwhelming your Prometheus instance or Ollama. [source]
Parameters and configuration
- livenessProbe.enabled bool true Enable livenessProbe [source]
- livenessProbe.failureThreshold int 6 Failure threshold for livenessProbe [source]
- livenessProbe.initialDelaySeconds int 60 Initial delay seconds for livenessProbe [source]
- livenessProbe.path string "/" Request path for livenessProbe [source]
- readinessProbe.enabled bool true Enable readinessProbe [source]
- readinessProbe.failureThreshold int 6 Failure threshold for readinessProbe [source]
- readinessProbe.initialDelaySeconds int 30 Initial delay seconds for readinessProbe [source]
- readinessProbe.path string "/" Request path for readinessProbe [source]
How-to and procedures
- Use the `ollama ps` command to see what models are currently loaded into memory. [source]
Examples and snippets
- - name: OLLAMA_NUM_PARALLEL value: "4" resources: requests: cpu: "4" memory: 8Gi limits: cpu: "8" memory: 16Gi readinessProbe: httpGet: path: / port: 11434 initialDelaySeconds: 10 periodSeconds: 5 livenessProbe: httpGet: path: / port: 11434 initialDelaySeconds: 30 periodSeconds: 30 volumeMounts: - name: ollama-data mountPath: /root/.ollama volumes: - name: ollama-data persistentVolumeClaim: claimName: ollama-data --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ollama-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 100Gi storageClassName: gp3 --- apiVersion: [source]
- ```powershell theme={"system"} — `$env:OLLAMA_DEBUG="1"` … [source]
Problems, failure modes and limitations
- Two constraints are worth noting up front. First, ollama-metrics is proxy-only: there is no standalone polling mode. The process must sit between your applications and Ollama to capture per-request metrics. If you run it without routing traffic through it, you’ll still get model state and RAM from /api/ps, but you’ll lose token counts and latency histograms entirely. Second, routing through an extra hop adds a small amount of latency and a single point of failure. You should assess whether this is acceptable for your deployment before putting it on a critical inference path. [source]
- To check whether a containerised model is on the GPU, run `docker exec <ctr> ollama ps` and read the Processor column (100% GPU, 100% CPU, or a split such as 48%/52% CPU/GPU). A split means VRAM spillover, not a detection failure. [source]
- * `AMD_LOG_LEVEL=3` Enable info log levels in the AMD HIP/ROCm libraries. This can help show more detailed error codes that can help troubleshoot problems * `OLLAMA_DEBUG=1` During GPU discovery additional information will be reported * Check dmesg for any errors from amdgpu or kfd drivers `sudo dmesg | grep -i amdgpu` and `sudo dmesg | grep -i kfd` [source]
Facts and statements
- docker run -d \ --name ollama-metrics \ --restart unless-stopped \ -e OLLAMA_HOST=http://localhost:11434 \ -e PORT=8080 \ --network host \ ghcr.io/norskhelsenett/ollama-metrics:latest [source]
- The troubleshooting docs show OLLAMA_DEBUG=1 only for Windows (quit the tray app, set it in PowerShell, launch `ollama app.exe`). The AMD section says OLLAMA_DEBUG=1 adds GPU discovery detail. CUDA_ERROR_LEVEL=50 and AMD_LOG_LEVEL=3 add driver-level diagnostics. [source]
- The ollama-metrics sidecar runs as a transparent proxy (example PORT=8080 in front of Ollama on 11434). It counts tokens and request duration from proxied responses and polls /api/ps on each /metrics scrape. Metrics shown: ollama_generated_tokens_total, ollama_prompt_tokens_total, ollama_loaded_models, ollama_model_loaded, ollama_model_ram_mb, ollama_request_duration_seconds. [source]
- The official docs fetched (troubleshooting, FAQ, API ps) describe no native Prometheus /metrics endpoint. Third-party exporters exist to fill the gap, which supports the view that Ollama does not ship one. [source]
- A blog says OLLAMA_ENABLE_METRICS=true enables a native /metrics endpoint. The post cites no Ollama source or release, and the official docs fetched do not mention the variable. [source]
- Ollama server logs live in: macOS ~/.ollama/logs/server.log; Linux systemd via `journalctl -u ollama --no-pager --follow --pager-end`; containers on stdout/stderr (`docker logs <container>`); a manual `ollama serve` on its terminal; Windows %LOCALAPPDATA%\Ollama\server.log with older logs in server-#.log. [source]
- ollama-metrics runs as a transparent HTTP proxy in front of Ollama. It forwards every request upstream and instruments the response stream: token counts, request duration, time-per-token. It also polls the Ollama API at /api/ps on every /metrics scrape to collect loaded model state and RAM allocation. [source]
- ollama-metrics requires proxy mode to capture token counts and latency: Model state and RAM come from /api/ps polling and are available even without proxied traffic, but routing your applications through port 8080 is the only way to get the full picture [source]
- GET /api/ps returns a `models` array of running models. Each entry has name, model, size, digest, details, expires_at (unload time), size_vram and context_length. The CLI equivalent is `ollama ps`. [source]
- Token and latency metrics come only from traffic passing through the proxy and only from inference endpoints (/api/generate, /api/chat), not /api/tags. Without proxied traffic a sidecar reports just model state and RAM from /api/ps. Clients must be repointed at the proxy port. [source]
- Ollama is traced from the client side. SigNoz's guide uses opentelemetry-instrumentation-ollama (OllamaInstrumentor), plus httpx and system-metrics instrumentation, exporting over OTLP. It does not say Ollama emits OpenTelemetry itself. [source]
- A note on Prometheus: NetEye uses InfluxDB as its native metrics backend, not Prometheus. To use check_prometheus, you’ll need a separate Prometheus instance that scrapes ollama-metrics. The simplest option is a lightweight container running on the same host as Ollama or on a dedicated monitoring host. NetEye’s Grafana can then be pointed at this Prometheus instance as an additional data source if you want dashboards alongside the Icinga checks. [source]
- docker run --rm -p 9497:9497 \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ ollama-prometheus-exporter [source]
- Yes, Ollama is free: the software is MIT licensed, and running models on your own hardware is unmetered. What costs money is Ollama Cloud, the hosted service that runs models on Ollama's GPUs, and the machine you run Ollama on yourself. [source]
- Ollama running and reachable from the host where ollama-metrics will run [source]
- Optional: The ollama-metrics repository already includes a Grafana dashboard you can import directly: dashboard.json. [source]
- Step 1: Deploy ollama-metrics [source]
- export OLLAMA_BASE_URL=http://localhost:11434 uv run ollama-prometheus-exporter [source]
- ollama-prometheus-exporter: build: context: . environment: OLLAMA_BASE_URL: http://host.docker.internal:11434 [source]
- curl http://localhost:11434/api/ps [source]
- Ollama Monitoring & Observability with OpenTelemetry [source]
- What is Ollama Monitoring? [source]
- Ollama monitoring with OpenTelemetry lets you collect traces, logs, and metrics from your local LLM workloads and export them to SigNoz. This guide walks you through setting up full Ollama observability using OpenTelemetry, covering automatic and manual instrumentation for Python applications. [source]
- With full Ollama monitoring in SigNoz, you can correlate traces, logs, and metrics in unified dashboards, configure alerts for latency and errors, and gain actionable insights to improve the reliability and responsiveness of your LLM workloads. [source]
- View Ollama Traces, Logs, and Metrics in SigNoz [source]
- /openapi.yaml get /api/version Retrieve the version of the Ollama [source]
- { "models": [ { "name": "gemma4", "model": "gemma4", "size": 6591830464, "digest": "c6eb396dbd5992bbe3f5cdb947e8bbc0ee413d7c17e2beaae69f5d569cf982eb", "details": { "parent_model": "", "format": "gguf", "family": "gemma4", "families": [ "gemma4" ], "parameter_size": "8.0B", "quantization_level": "Q4_K_M" }, "expires_at": "2025-10-17T16:47:07.93355-07:00", "size_vram": 5333539264, "context_length": 4096 } ] } [source]
- Pro, Max, and Team plans include a set dollar amount of usage credits each month. Free accounts include a starter amount of usage for a smaller set of starter models. Buying usage credits unlocks all models. Running models on your own hardware is always unlimited. [source]
- /openapi.yaml get /api/ps Retrieve a list of models that are currently running [source]
Related concepts
- ollama — is a related of Ollama observability: logs, /api/ps, metrics, tracing
- ollama-metrics — is a instance of Ollama observability: logs, /api/ps, metrics, tracing
- healthcheck — is a part of Ollama observability: logs, /api/ps, metrics, tracing
- 11434 — is a related of Ollama observability: logs, /api/ps, metrics, tracing
- journalctl — is a part of Ollama observability: logs, /api/ps, metrics, tracing
- ollama:rocm — is a hyponym of Ollama observability: logs, /api/ps, metrics, tracing
- persistent volume — is a part of Ollama observability: logs, /api/ps, metrics, tracing
- neteye — is a instance of Ollama observability: logs, /api/ps, metrics, tracing
Children
- No children recorded.