Monitoring & metrics

Every Solr node exposes /admin/metrics, scoped to that node’s JVM plus every core it hosts. Metrics are organized into registries — solr.node (node/CoreContainer-level, solr_node_* when rendered), solr.core.<name> (per-core, solr_core_*), solr.jvm (heap, GC, threads — on by default), and, in SolrCloud, solr.cluster (Overseer). The endpoint defaults to Prometheus exposition format; add wt=openmetrics for OpenMetrics (which also carries trace exemplars when distributed tracing is enabled).

Alongside the pull-based API, Solr can push the same metrics via OTLP (gRPC or HTTP) to any OpenTelemetry-compatible backend, so a cluster can be wired into an existing observability stack without a separate scraper. JMX reporting is still available for tools that expect it. See Metrics Reporting and JMX with Solr.

For a self-hosted Prometheus/Grafana stack, Solr ships a standalone exporter process — prometheus-exporter/ in the full distribution, run separately from any Solr node — rather than having each node serve Prometheus text format directly for this purpose. It polls the Ping, Metrics, Collections, and search/facet APIs on a schedule and republishes the results as Prometheus metrics, driven by a solr-exporter-config.xml file whose <ping>, <metrics>, <collections>, and <search> rules use JQ expressions to turn each API response into named, labeled metric values.

See Monitoring Solr with Prometheus and Grafana, which also links a starter Grafana dashboard.

/admin/ping is a per-core (or, with distrib=true, cluster-wide) request handler purpose-built for load balancers: a cheap, uniform "is this core/collection reachable" check independent of query content. Its behavior — which query it runs internally, and any healthcheck-file gating — is configured through the Request Parameters API paramset bound to the /admin/ping handler rather than directly in solrconfig.xml.

A healthy core answers <str name="status">OK</str> with a QTime; point the load balancer’s health-check probe at this URL (per node, per core) rather than at a search endpoint, so a slow query never gets misread as node failure. See Ping.

The admin UI’s Plugins / Stats screen is the point-and-click counterpart to the metrics and performance-statistics APIs: pick a category (caches, request handlers, search components, the searcher) from the sidebar and drill into live counters for a specific core, without writing a query. Two refresh modes help while watching a change happen: Watch Changes highlights values that moved since the last poll, and Refresh Values just reloads the snapshot. The same request-handler and cache counters it displays are documented, field by field, at Performance Statistics Reference — useful when deriving a rate (QPS, avg latency) from the cumulative counts the UI shows.

Beyond the main Solr log, a slow-query log is opt-in per request handler: set <slowQueryThresholdMillis> inside the handler’s <query> block in solrconfig.xml, and any request the handler serves past that threshold is logged at WARN to a dedicated solr_slow_requests.log in SOLR_LOGS_DIR, alongside the normal request log. In SolrCloud, every distributed request also carries a request id (rid) through every shard it touches, so a slow or failed query can be correlated across nodes in the logs; add disableRequestId=true to turn it off for a request. logParamsList narrows what gets logged to a specific set of request parameters, useful when query bodies are large or sensitive.

See Configuring Logging.

For request-scoped visibility that spans multiple shards and nodes — where a single search actually spent its time — Solr integrates with OpenTelemetry to propagate a trace context across the distributed request and export spans to a tracing backend (Jaeger, Zipkin, or anything OTLP-capable). This complements the aggregate counters from the Metrics API with per-request timelines, and pairs with the OpenMetrics exemplars mentioned above, which link a metric bucket back to a sample trace. See Distributed Tracing.

Long-running search requests (today; more task types are expected later) can opt into being tracked and cancellable by adding canCancel=true (and, optionally, a caller-supplied queryUUID) to the request. Once tracked, the task shows up for listing and can be cancelled by id — useful for killing a runaway query, or an expensive relevance experiment left running by mistake, without restarting the node.

The same operations exist under /v2/collections/<collection>/tasks/…​. See Task Management.

Metrics and stats are read-only views into settings tuned elsewhere: cache sizing and autowarming live in Configuration: solrconfig.xml, the Config API & caches, and indexing-side counters (merge and flush metrics, transaction-log stats) are covered alongside the write path in Indexing internals & performance. For running the exporter and admin UI behind authentication, see Security; for where each process runs in production, see Deployment & upgrades.