metrics recorder; your application supplies and configures the OpenTelemetry SDK.
This page covers LanceDB Embedded instrumentation. LanceDB Enterprise clusters emit their own metrics from the server side. See Enterprise monitoring below.
Available metrics
Once instrumented, LanceDB registers one observable instrument per metric on yourMeterProvider. The current catalog covers the object store layer:
The recorder is process-global and pull-based: your configured
MetricReader collects on its own schedule, so there is no hot-path overhead beyond the atomic aggregation that LanceDB does anyway.
Histograms are exported Prometheus-style. OpenTelemetry has no asynchronous histogram instrument, so each histogram surfaces as three observable counters:
<name>_bucket (with an le attribute per bucket boundary, including +Inf), <name>_count, and <name>_sum. Only _sum carries the histogram’s unit; _bucket and _count are cumulative sample counts.Python
Install LanceDB with theotel extra to pull in the OpenTelemetry API, plus an OpenTelemetry SDK of your choice. The SDK is intentionally not bundled, so you configure it and its readers and exporters however your platform expects.
instrument_lancedb_metrics() once at startup, before opening any tables. It returns True when the recorder is installed and instruments are registered.
meter_provider, LanceDB uses the global provider returned by opentelemetry.metrics.get_meter_provider().
TypeScript
Install the OpenTelemetry SDK and exporter in your application:instrumentLanceDbMetrics() also accepts no arguments, in which case it uses the global provider from @opentelemetry/api. Calling it more than once is safe: instruments are created only on the first successful call.
Build dashboards and alerts
A few starting points for dashboards and alerts:- Request rate by operation:
rate(lance_object_store_requests_total[1m])broken down byoperationshows read vs. write pressure and helps size ingestion and serving traffic separately. - Tail latency: histogram quantiles over
lance_object_store_request_duration_seconds_bucketcatch object store slowdowns before they surface as query timeouts. - Retryable responses: a rising
lance_object_store_retryable_responses_totaltypically means you are being throttled and should back off or shard writes. - In-flight requests: a growing
lance_object_store_in_flight_requestsgauge without a matching rise in throughput indicates queueing.
Enterprise monitoring
Enterprise A deployment emits its own metrics from the server side, using Prometheus for collection and OpenTelemetry (OTel) to export them with data enrichment. No client-side instrumentation is needed.
Contact support for the comprehensive metric list and
help integrating them with your monitoring dashboard.
Related guides
Performance tips
Tune ingestion, indexing, and query patterns once metrics highlight a hot spot.
Object storage
Configure the object store backends whose requests these metrics measure.