MySQL

Collect MySQL/InnoDB server metrics and get curated dashboards and alerts for them with a single import.

MySQL is scraped by an OpenTelemetry Collector running the mysql receiver, which exports over OTLP to your LeanSignal agent gateway (one per cluster or environment) — never to a remote or third-party endpoint. The gateway keeps full fidelity locally and forwards only the demanded subset to your central dataplane. Run one collector that can reach the database; it scrapes InnoDB buffer-pool, threads/connections, row and handler throughput, locks, and more.

Metric names follow the standard OTLP → Prometheus normalization (dots become underscores, unit/_total suffixes are added), so mysql.buffer_pool.usage becomes mysql_buffer_pool_usage_bytes and mysql.row_operations becomes mysql_row_operations_total. The demands below are built against those names.

Prerequisites

• A LeanSignal agent gateway deployed and connected — one per cluster or environment. If you haven’t deployed it yet, follow Install the agent (source: LeanSignal/leansignal-agent). It should show as Connected under Agents in the LeanSignal app.
• Network reachability to the gateway’s OTLP port — 4317 (gRPC) or 4318 (HTTP). See Agent configuration.
• An OpenTelemetry Collector that can reach your MySQL server, plus a monitoring database user — both configured in Setup.
• Editor or admin role in the LeanSignal app (importing a demand creates dashboards and alert rules).

Setup

Run an OpenTelemetry Collector (for example otel/opentelemetry-collector-contrib) with the mysql receiver, exporting OTLP to your LeanSignal agent gateway — not a SaaS endpoint.

Database user and grants (MySQL 8.0+, performance_schema enabled):

CREATE USER 'otel'@'%' IDENTIFIED BY 'REDACTED';
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'otel'@'%';

PROCESS reads global status/variables; performance_schema powers the table/ index I/O-wait metrics; REPLICATION CLIENT is needed for the opt-in replica metrics.

receivers:
  mysql:
    endpoint: mysql:3306
    username: otel
    password: ${env:MYSQL_PASSWORD}
    collection_interval: 30s
    tls:
      insecure: true                 # DB-side TLS off; set false + ca_file to verify
    # Extended demand also needs these opt-in metrics enabled:
    # metrics:
    #   mysql.query.slow.count:            { enabled: true }
    #   mysql.connection.errors:           { enabled: true }
    #   mysql.replica.time_behind_source:  { enabled: true }

processors:
  resourcedetection:
    detectors: [env, system]
    system: { hostname_sources: [os] }
  batch: {}

exporters:
  otlp:
    endpoint: leansignal-agent:4317   # per-cluster gateway (use :4318 for HTTP)
    tls:
      insecure: true                  # in-cluster plaintext; provide ca_file for TLS

service:
  pipelines:
    metrics:
      receivers: [mysql]
      processors: [resourcedetection, batch]
      exporters: [otlp]

Default vs opt-in metrics

The Essential and Standard variants use only default-enabled metrics. The Extended variant’s slow-query, connection-error, and replica-lag panels/alerts are opt-in — enable them under receivers.mysql.metrics as shown above, or those series will be absent. The mysql_instance_endpoint resource label is used to group by instance.

Where to run this

You have two options:

• On the LeanSignal agent gateway. It is an OpenTelemetry Collector distribution and bundles the mysql receiver, so you can add the receivers: block above straight to its own config.
• On a separate OpenTelemetry Collector, in agent mode. Run a standalone collector close to the target with just this receiver plus an otlp exporter pointed at the gateway (leansignal-agent:4317); it forwards everything on.

Both are supported — pick whichever suits your topology. A separate collector tends to fit when the gateway has no route to the database (a different network or cluster), or when you’d simply rather keep collection close to the source; running it on the gateway means one less process to operate.

Multiple instances

The receiver tags each series with mysql_instance_endpoint (the server it scraped), so multiple servers are distinguished automatically — add one receivers entry per server. The imported dashboard has an Instance filter — view all instances at once or focus on one.

Logs and traces

A database server produces logs, and its traces come from the clients:

• Server logs — point a collector filelog receiver at the error log and slow query log and forward OTLP to the gateway; the receiver can run on the gateway itself if it can read the files. Already shipping them with a Promtail/Alloy-style agent? Repoint it at the gateway’s Loki push endpoint (:3500) instead.
• Query traces — instrument the applications that call MySQL (see the runtime integrations); their database client spans carry db.* attributes, so slow statements show up inside request traces.

Demand-driven, like metrics

Logs and traces land in the gateway’s edge stores (a roughly one-hour full-fidelity window) and are queryable immediately in the LeanSignal app under Logs and Traces with the source set to Available. Nothing is stored centrally until a dashboard demands it — the ready-made demands on this page stay metrics-only. See Logs and Traces.

Demands

MySQL ships as a ready-made demand in three variants. You don’t copy any JSON — in the LeanSignal app go to Demands, press the ˅ arrow on the Add Demand button (the arrow opens the import menu), choose Import from catalog…, and pick the variant. Each variant below lists the slug that identifies its published bundle. See Integrations for the full import flow.

The variants are nested — Standard is a superset of Essential, Extended a superset of Standard. Pick whichever is closest to what you need and treat it as a starting point: after import everything is a normal, editable copy, so retune thresholds, add or drop panels, and adjust queries for your environment — your edits reshape the demand automatically. Start small and re-import a larger variant later if you outgrow it.

Essential

The golden signals. 1 dashboard · 4 panels · 3 alerts — connections, throughput, and buffer-pool efficiency at a glance.

Import this variant from the catalog. Its demand slug:

Demand slug

mysql-otel-demand-essential

Dashboard — Connected threads, Row operations, InnoDB buffer pool hit ratio, and Buffer pool utilization.

Alerts (3)

Alert	Severity	Fires when
MySQL instance restarted	warning	uptime < 5m
MySQL high connection count	warning	> 100 connected threads for 5m
MySQL low buffer pool hit ratio	warning	hit ratio < 95% for 10m

Review the bundle JSON →

Standard

Well-rounded coverage. 1 dashboard · 8 panels · 6 alerts — adds running threads, handler throughput, locks, and disk I/O. The recommended default.

Import this variant from the catalog. Its demand slug:

Demand slug

mysql-otel-demand-standard

Dashboard — everything in Essential, plus Threads running, Handler operations, InnoDB row lock waits, and InnoDB disk operations.

Alerts (6)

Alert	Severity	Fires when
MySQL instance restarted	warning	uptime < 5m
MySQL high connection count	warning	> 100 connected threads for 5m
MySQL low buffer pool hit ratio	warning	hit ratio < 95% for 10m
MySQL high threads running	warning	avg > 40 threads running for 10m
MySQL high row lock waits	warning	> 10 row-lock waits/s for 5m
MySQL high on-disk temp tables	warning	> 5 on-disk temp tables/s for 10m

Review the bundle JSON →

Extended

Deep server visibility. 1 dashboard · 14 panels · 10 alerts — sorts, slow queries, buffer-pool pages, temporary objects, and replication for servers you need to diagnose, not just watch.

Import this variant from the catalog. Its demand slug:

Demand slug

mysql-otel-demand-extended

Dashboard — everything in Standard, plus Sorts, Slow queries, Buffer pool pages, Dirty data pages, Temporary tables & files, and Replica lag behind source.

Alerts (10)

Alert	Severity	Fires when
MySQL instance restarted	warning	uptime < 5m
MySQL high connection count	warning	> 100 connected threads for 5m
MySQL low buffer pool hit ratio	warning	hit ratio < 95% for 10m
MySQL high threads running	warning	avg > 40 threads running for 10m
MySQL high row lock waits	warning	> 10 row-lock waits/s for 5m
MySQL high on-disk temp tables	warning	> 5 on-disk temp tables/s for 10m
MySQL high InnoDB disk reads	warning	> 100 physical reads/s for 10m
MySQL high slow query rate	warning	> 1 slow query/s for 5m (opt-in)
MySQL high connection errors	critical	> 1 conn error/s for 5m (opt-in)
MySQL replica lag high	critical	replica > 30s behind for 5m (opt-in)

Review the bundle JSON →

Dashboards

Each variant imports one MySQL dashboard, its panels grouped into collapsible sections. Every dashboard carries an Instance filter (on the mysql_instance_endpoint label), so one import covers the whole fleet — view every instance at once, or focus on one. Legends are sortable tables showing last/mean/max per series, so the outlier instance stands out. Dashboards are demand-driven: importing one tells your agents to forward exactly the timeseries its panels query, and nothing else. Panels are ordinary Perses panels — edit queries, add panels, or retune them after import, and your changes reshape the demand automatically.

Alerts

Thresholds are conservative starting points — tune them to your workload.

Caution

Imported alert rules arrive without a notification channel and start out paused — with nowhere to deliver, they do not evaluate. After importing, 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.

Next steps

• Demand-driven observability — why importing a demand also shapes what your agents collect.
• Agent configuration — the full agent config surface.