Skip to content
BleemeoBleemeo

InfluxDB

Auto-Detection
Health Check
Built-in Metrics

InfluxDB is a specialized time series database designed to store and analyze high-volume, timestamped data with high writing and querying speeds.

Bleemeo monitors InfluxDB through automatic service detection by its process, an HTTP service check, and built-in metrics. All three lines — 1.x, 2.x and 3.x — are supported and publish one shared set of influxdb_* metrics.

We detect the InfluxDB line by process (influxd or influxdb3) and probing /ping to find the correct port and endpoint for the detected line to check the service and gather metrics:

InfluxDB line Port Metrics Endpoint
1.x 8086 /debug/vars
2.x 8086 /metrics
3.x 8181 /metrics
Terminal window
sudo tee /etc/glouton/conf.d/99-influxdb.conf > /dev/null << 'EOF'
service:
# InfluxDB 1.x or 2.x
- type: "influxdb"
address: "127.0.0.1"
port: 8086
username: "admin"
password: "REPLACE_WITH_YOUR_PASSWORD"
# InfluxDB 3.x, whose password holds the access token
- type: "influxdb"
instance: "CONTAINER_NAME"
port: 8181
password: "REPLACE_WITH_YOUR_TOKEN"
EOF

Glouton automatically detects configuration changes.

What each line requires differs, and getting it wrong is silent — the service stays detected and checked while no metric arrives:

  • 1.x — no credentials are needed for the metrics. A 1.x server leaves /debug/vars open even with auth-enabled = true, so it answers whether or not Glouton is given a username and password.
  • 2.x — none. /metrics answers unauthenticated.
  • 3.x — a token is required. The server answers 401 on /metrics, /health and /ping alike without one. It goes in the password setting.

In a container, Glouton reads INFLUXDB_ADMIN_USER / INFLUXDB_ADMIN_PASSWORD (1.x) and INFLUXDB3_AUTH_TOKEN (3.x) from the container environment, so a containerized server usually needs no configuration at all.

Glouton performs an HTTP service check on the InfluxDB port, on the /ping endpoint. A 3.x server authenticates every route and so answers 401 there, the check carrying no token; that 401 still counts as OK, because it is the server saying it is up and asking who is calling.

MetricDescription
service_statusStatus of InfluxDB

The three lines share no metric name of their own, so each fills in the part it publishes and the rest is simply absent. The version each metric exists on is given below.

MetricDescription
influxdb_requestsNumber of InfluxDB HTTP requests, per second (1.x, 2.x, 3.x)
influxdb_request_duration_secondsAverage InfluxDB HTTP request duration (1.x, 2.x, 3.x)
influxdb_client_errorsNumber of InfluxDB requests answered with a client error, per second (1.x, 2.x, 3.x)
influxdb_server_errorsNumber of InfluxDB requests answered with a server error, per second (1.x, 2.x, 3.x)
influxdb_auth_failuresNumber of InfluxDB requests refused for lack of credentials, per second (1.x)
influxdb_uptimeInfluxDB uptime (2.x, 3.x)
influxdb_points_writtenNumber of points written to InfluxDB, per second (1.x, 2.x)
influxdb_points_write_failedNumber of points InfluxDB failed to persist, per second (1.x, 2.x)
influxdb_points_write_droppedNumber of points InfluxDB dropped, per second (1.x, 2.x)
influxdb_write_timeoutsNumber of InfluxDB writes that timed out, per second (1.x, 2.x)
influxdb_queriesNumber of InfluxDB queries, per second (1.x, 3.x)
influxdb_query_duration_secondsAverage InfluxDB query duration (1.x, 3.x)
influxdb_queries_activeNumber of InfluxDB queries being executed (1.x)
influxdb_queries_failedNumber of InfluxDB queries that failed, per second (3.x)
influxdb_query_oomsNumber of InfluxDB queries that ran out of memory, per second (3.x)
influxdb_seriesInfluxDB series cardinality (1.x)
influxdb_memory_bytesInfluxDB memory usage (3.x)
influxdb_mem_pool_bytesInfluxDB query memory pool (3.x)
influxdb_parquet_cache_size_bytesSize of the InfluxDB parquet cache (3.x)
influxdb_parquet_cache_filesNumber of files in the InfluxDB parquet cache (3.x)
influxdb_parquet_cache_accessNumber of InfluxDB parquet cache accesses, per second (3.x)
influxdb_object_store_transfer_bytesInfluxDB object store transfer rate (3.x)
influxdb_thread_panicsNumber of InfluxDB thread panics, per second (3.x)

See Troubleshoot a Service Check or Missing Metrics for what applies to every service: finding the address and port Glouton really uses, what each check message means, and how to read the collection error — which does not appear in the agent logs at the default level.

The check is an HTTP request, so beyond the usual Connection refused and connection timed out after 10 seconds it also fails on an unexpected status code.

Reproduce what Glouton does, from the machine where the agent runs — first the version probe, then the endpoint it selects:

Terminal window
curl -s http://127.0.0.1:8086/ping -i | head -3
curl -s http://127.0.0.1:8086/debug/vars | head -5 # 1.x
curl -s http://127.0.0.1:8086/metrics | head -5 # 2.x
curl -s http://127.0.0.1:8181/metrics | head -5 # 3.x
What you see Cause Fix
401 Unauthorized on a 3.x server No token is configured Set password to the access token
404 Not Found on /debug/vars The server is 2.x, which has no such endpoint None — Glouton reads /metrics there; check the version probe
401 on /ping from a 1.x server ping-auth-enabled is on, so the version probe fails and the server is taken for a 3.x one Set ping-auth-enabled = false
/metrics answers on a 1.x server, but no metric arrives 1.x’s /metrics is the Go client library’s default registry and carries nothing about InfluxDB None — Glouton reads /debug/vars on 1.x by design
a connection error The server listens on another port Set port, or stats_url for the server’s base URL — Glouton appends /ping, /metrics and /debug/vars itself
only write or only query metrics missing Expected for 3.x and 2.x respectively See the version column above