Integrations

Integrations are ready-made demands: curated bundles of dashboards and alert rules for a specific technology, published by LeanSignal and importable into your tenant in one step. Instead of building a demand from scratch, you pick an integration, choose how much depth you want, and import.

Because a demand is the set of metrics its dashboards and alerts consume, importing an integration does two things at once:

1. It gives you dashboards and alerts that work out of the box.
2. It tells your agents exactly which timeseries to forward — nothing more. See Demand-driven observability.

How importing works

You never copy or paste JSON. In the LeanSignal app:

1. Go to Demands and press the ˅ down arrow on the right edge of the Add Demand button — the arrow opens the import menu (the button itself starts an empty demand instead).
2. Choose Import from catalog… and browse by category to the integration and variant you want — each variant shows its panel and alert counts before you commit.
3. Confirm with Import demand. LeanSignal fetches the bundle from this docs site and creates the demand, its dashboards, and its alert rules in your tenant with fresh IDs, owned by you.

Every published variant also has a stable slug (for example host-metrics-otel-demand-standard), listed on its integration page. If the catalog is unreachable you can enter the slug directly, and Import from file… lets you import a downloaded bundle instead — that path shows a dry-run preview of what will be created before you confirm.

Note

The bundle behind each slug is served as JSON at https://docs.leansignal.io/demands/<slug>.json — the same document the app imports. Open it in a browser to review a demand before importing, or diff two variants. The full catalog is listed at /demands/index.json.

After import

• LeanSignal recomputes the demand’s consumed metrics and cost estimate, then pushes the updated demand set to every connected agent — see Architecture. Within seconds your agents start forwarding the timeseries the new dashboards and alerts need.
• Imported alert rules arrive without a notification channel and start out paused — with nowhere to deliver, they do not evaluate. Create or pick a channel under Alerts → Manage Channels, attach it to each rule, and resume. Rules without a channel are marked with a warning icon in the alerts list.
• Everything is a normal, editable copy. Rename panels, retune thresholds, or delete what you don’t need — you own it now.

Instances and labels

Every dashboard has an Instance filter, so one import covers your whole fleet: view every instance at once, or narrow to a single one. Each integration’s Setup section explains how to populate that instance identity:

• Application SDKs use the instance label. Set service.instance.id to a stable per-replica name (a hostname or pod name) — it is exported as instance in the OTLP → Prometheus mapping.
• Prometheus-scraped apps (Ruby, PHP, VictoriaMetrics, and Host Metrics (node_exporter)) use the scrape target’s native instance label — populated automatically.
• Host Metrics filters on host_name, LeanSignal Agent on leansignal_agent_name, and MySQL on mysql_instance_endpoint — resource labels the collectors attach to every series. PostgreSQL uses the instance label, set on the scraping collector.

Data-point labels used for breakdowns (status, state, operation, …) are always present regardless.

Variants

Most integrations ship in three variants so you can trade coverage against cost:

Variant	For	Footprint
Essential	The golden signals and page-worthy alerts only.	Smallest
Standard	A well-rounded overview with warning/critical alerting. Recommended default.	Medium
Extended	Deep, per-subsystem visibility and the full alert set.	Largest

The variants are nested — Standard is a superset of Essential, Extended a superset of Standard — so you can start small and re-import a larger variant as a new demand when you need more depth.

Available integrations

Every integration follows the same shape — Overview → Prerequisites → Setup → Logs and traces → Demands. The ready-made demands are built on OpenTelemetry metrics; each page’s Logs and traces section covers sending those signals to the gateway too (they become demanded through the dashboards you build — see Logs and Traces). The chips on each card show panel · alert counts per variant.

Infrastructure

AC AWS CloudWatch

AWS CloudWatch metrics for EC2, Application Load Balancer, RDS, Lambda, and SQS via YACE — CPU, status checks, 5xx rates, storage headroom, error ratios, throttles, and queue backlogs

Essential 8·5 Standard 16·9 Extended 22·11

Host Metrics (node_exporter)

Host metrics from Prometheus node_exporter — CPU, memory, disk, and network, plus the hardware sensors — temperatures, fan speeds, power draw, and ECC memory errors

Essential 4·4 Standard 7·6 Extended 18·14

Host Metrics

Host-level metrics from the OpenTelemetry hostmetrics receiver

Essential 4·3 Standard 7·5 Extended 15·9

LA LeanSignal Agent

The LeanSignal Agent's own telemetry — control-stream health, pipeline throughput, export failures, queue depth, and process memory

Essential 4·3 Standard 13·6 Extended 22·10

LA LeanSignal API

The LeanSignal API's own telemetry — per-filter collection/storage accounting, demand-set size and cost, connected agents, and process health

Essential 12·0 Standard 16·0 Extended 21·0

VictoriaMetrics

VictoriaMetrics single-node metrics — ingestion rate, active series, disk usage, churn, query errors, and process health

Essential 4·3 Standard 7·6 Extended 14·10

Application runtimes

.NET

.NET CLR runtime health (GC, JIT, thread pool, memory, exceptions) plus ASP.NET Core HTTP server and HttpClient request metrics

Essential 3·3 Standard 7·5 Extended 14·9

Go

Go runtime metrics (memory, goroutines, GC goal, scheduler latency, GOMAXPROCS/GOGC) plus HTTP server request metrics

Essential 4·3 Standard 8·6 Extended 14·10

Java (JVM)

JVM runtime health (heap/non-heap memory, GC duration, threads, classes, CPU) plus HTTP server request metrics

Essential 4·3 Standard 7·5 Extended 14·9

Node.js

Node.js/V8 runtime metrics (event-loop utilization & delay, V8 heap, GC pauses) plus HTTP server request metrics

Essential 4·3 Standard 8·6 Extended 14·10

PHP

PHP HTTP request metrics (rate, errors by status class, latency) from Prometheus instrumentation scraped into LeanSignal

Essential 4·3 Standard 8·5 Extended 12·7

Python

HTTP server request metrics (Flask/Django/FastAPI/WSGI/ASGI) plus CPython process/runtime metrics (memory, CPU, threads, GC)

Essential 4·3 Standard 7·5 Extended 14·9

Ruby on Rails

Rails HTTP request metrics (rate, errors, latency) plus view and database time, from Prometheus (Yabeda) instrumentation scraped into LeanSignal

Essential 4·3 Standard 8·6 Extended 14·10

Databases

MySQL

MySQL/InnoDB server metrics from the OpenTelemetry mysqlreceiver — buffer pool, threads, row/handler throughput, locks, and (opt-in) slow queries and replication

Essential 4·3 Standard 8·6 Extended 14·10

PostgreSQL

PostgreSQL metrics from the OpenTelemetry postgresqlreceiver — backends, commits/rollbacks, cache hits, tuple ops, sizes, replication, and (opt-in) deadlocks and temp files

Essential 4·3 Standard 8·6 Extended 14·10

More integrations are on the way.