inference/research
verifiedhigh · 0.93updated 2026-10-04

Ollama: a Prometheus exporter, any metric, or a /metrics endpoint - VERIFIED ABSENT

ollama · unknown

Fields

id
metric-exposures/w3m-ollama-no-ollama-prometheus-any-metric
Metric name
ollama_prometheus_any_metric
Metric type
unknown
Exposure
unknown
Verified negatively
yes
notes
VERIFIED NEGATIVE. Ollama does not emit a Prometheus exporter, any metric, or a /metrics endpoint. ollama_prometheus_any_metric is NOT a metric this engine registers - it is recorded here under the conventional name a reader would go looking for so the absence is queryable rather than implied by a gap in a list. This is the fleet's broadest negative and the one that most needs to be a record rather than a gap. server/routes.go registers no /metrics handler at all, there is no prometheus_client dependency, no histogram, no counter, no gauge - there is nothing to scrape. Every one of the eight LLM metrics is therefore absent, and so is any other metric. Ollama's only timing visibility is per-response JSON (total_duration, load_duration, prompt_eval_count, prompt_eval_duration, eval_count, eval_duration), which for a streaming request arrives only at the end of the stream, so it cannot be aggregated without every client logging every response. The README's Observability & Monitoring section lists five third-party integrations (Opik, OpenLIT, Lunary, Langfuse, HoneyHive) and describes OpenLIT as 'OpenTelemetry-native monitoring for Ollama and GPUs' - that OTel is the THIRD PARTY's, not Ollama's, and the single in-repo hit for 'opentelemetry' is in README.md. What was searched: read the complete route table in server/routes.go (3277 lines): the three 'metrics' matches in the file are api.Metrics{...} Go struct literals on /api/show, /api/ps and /api/tags response bodies, not a Prometheus exposition route. Separately, an in-repo search for prometheus returns 0 hits and for opentelemetry returns 1 hit, in README.md.. Do not read this record's metric_name as something the engine exports; it is the name that is missing.

Notes

VERIFIED NEGATIVE. Ollama does not emit a Prometheus exporter, any metric, or a /metrics endpoint. ollama_prometheus_any_metric is NOT a metric this engine registers - it is recorded here under the conventional name a reader would go looking for so the absence is queryable rather than implied by a gap in a list. This is the fleet's broadest negative and the one that most needs to be a record rather than a gap. server/routes.go registers no /metrics handler at all, there is no prometheus_client dependency, no histogram, no counter, no gauge - there is nothing to scrape. Every one of the eight LLM metrics is therefore absent, and so is any other metric. Ollama's only timing visibility is per-response JSON (total_duration, load_duration, prompt_eval_count, prompt_eval_duration, eval_count, eval_duration), which for a streaming request arrives only at the end of the stream, so it cannot be aggregated without every client logging every response. The README's Observability & Monitoring section lists five third-party integrations (Opik, OpenLIT, Lunary, Langfuse, HoneyHive) and describes OpenLIT as 'OpenTelemetry-native monitoring for Ollama and GPUs' - that OTel is the THIRD PARTY's, not Ollama's, and the single in-repo hit for 'opentelemetry' is in README.md. What was searched: read the complete route table in server/routes.go (3277 lines): the three 'metrics' matches in the file are api.Metrics{...} Go struct literals on /api/show, /api/ps and /api/tags response bodies, not a Prometheus exposition route. Separately, an in-repo search for prometheus returns 0 hits and for opentelemetry returns 1 hit, in README.md.. Do not read this record's metric_name as something the engine exports; it is the name that is missing.

Cross-references