🛠 This page is for engineering teams self-hosting their own Lightdash instance. If you want to monitor usage and analytics, go to the Usage analytics guide.
Enabling Prometheus metrics
By default, Prometheus metrics are disabled in Lightdash. To enable them, set the following environment variable:Configuration options
You can customize the Prometheus metrics endpoint using the following environment variables:Available metrics
Lightdash exposes the following metrics:Process metrics
These metrics provide information about the Node.js process running Lightdash:Node.js metrics
These metrics provide information about the Node.js runtime:PostgreSQL metrics
These metrics provide information about the PostgreSQL connection pool:Queue metrics
Query metrics
These metrics track query execution performance. Thecontext label is either scheduled or interactive based on the execution context.
Pre-aggregate metrics
These metrics track the pre-aggregate system, including materialization, DuckDB resolution, and file management:AI agent metrics
These metrics track the performance of the AI agent:S3 metrics
HTTP server metrics
WhenLIGHTDASH_PROMETHEUS_HTTP_METRICS_ENABLED is set to true, Lightdash exposes a standardized OpenTelemetry HTTP server semantic convention histogram. Buckets are in seconds and labels use route templates (not raw URLs) to keep cardinality bounded.
Custom event metrics
Lightdash supports operator-configurable Prometheus counter metrics that are driven by application events. These are defined via a JSON configuration file specified by theLIGHTDASH_CUSTOM_METRICS_CONFIG_PATH environment variable.
Each entry in the config file creates a counter metric that increments when a matching application event fires. This allows you to track custom business-level metrics such as user logins or query executions without modifying the application code.
Using metrics for monitoring and alerting
You can use these metrics to create dashboards and alerts in your monitoring system. Some common use cases include:- Monitoring memory usage and setting alerts for potential memory leaks
- Tracking PostgreSQL connection pool utilization
- Monitoring event loop lag to detect performance issues
- Setting up alerts for high CPU usage
- High memory usage:
process_resident_memory_bytes > threshold - Event loop lag:
nodejs_eventloop_lag_p99_seconds > threshold - Database connection pool saturation:
pg_active_connections / pg_pool_max_size > 0.8
OpenTelemetry support
Lightdash metrics are also compatible with OpenTelemetry. You can use the OpenTelemetry Collector with the Prometheus receiver to scrape Lightdash’s Prometheus metrics endpoint and export them to any OpenTelemetry-compatible backend. Example OpenTelemetry Collector configuration:Setting up a Prometheus server
If you don’t already have a Prometheus server set up, here are some resources to help you get started:General Prometheus setup
- Prometheus Getting Started Guide - Official documentation on how to install and configure Prometheus
- Prometheus Installation - Different ways to install Prometheus
- Prometheus Configuration - Detailed configuration options for Prometheus
Setting up Prometheus in Google Cloud Platform (GCP)
- Google Cloud Managed Service for Prometheus - Google Cloud’s managed Prometheus service
- Installing Prometheus on GKE - Setting up Prometheus on Google Kubernetes Engine
- Google Cloud Operations Suite Integration - Integrating Prometheus with Google Cloud Operations Suite
Setting up Prometheus in Amazon Web Services (AWS)
- Amazon Managed Service for Prometheus - AWS managed Prometheus service
- Getting Started with Amazon Managed Service for Prometheus - Official AWS documentation
- Setting up Prometheus on Amazon EKS - Deploying Prometheus on Amazon Elastic Kubernetes Service