Elasticsearch

Auto-Detection

Health Check

Built-in Metrics

Elasticsearch is a distributed search and analytics engine built on Apache Lucene.

Auto-Detection

Glouton detects Elasticsearch by its process and listening port (default: 9200).

If auto-detected parameters are incorrect, override them manually:

Linux
Windows

sudo tee /etc/glouton/conf.d/99-elasticsearch.conf > /dev/null << 'EOF'
service:
  # For an Elasticsearch running outside a container
  - type: "elasticsearch"
    address: "127.0.0.1"
    port: 9200

  # For an additional Elasticsearch running outside a container
  - type: "elasticsearch"
    instance: "NAME_ASSOCIATED_WITH_YOUR_ADDITIONAL_SERVICE"
    address: "127.0.0.1"
    port: 9201

  # For an Elasticsearch running in a Docker container
  - type: "elasticsearch"
    instance: "CONTAINER_NAME"
    address: "172.17.0.2"
    port: 9200
EOF

Create or edit C:\ProgramData\glouton\conf.d\99-elasticsearch.conf:

service:
  # For an Elasticsearch running outside a container
  - type: "elasticsearch"
    address: "127.0.0.1"
    port: 9200

  # For an additional Elasticsearch running outside a container
  - type: "elasticsearch"
    instance: "NAME_ASSOCIATED_WITH_YOUR_ADDITIONAL_SERVICE"
    address: "127.0.0.1"
    port: 9201

  # For an Elasticsearch running in a Docker container
  - type: "elasticsearch"
    instance: "CONTAINER_NAME"
    address: "172.17.0.2"
    port: 9200

Glouton automatically detects configuration changes.

Service Check

Glouton opens a TCP connection on the configured port to verify that Elasticsearch is accepting connections. It does not send an HTTP request, so the check says nothing about the cluster’s own health.

Built-in Metrics

Metric	Description
`service_status`	Status of Elasticsearch
`elasticsearch_docs_count`	Number of documents stored in all indices
`elasticsearch_jvm_gc`	Number of garbage collections per second
`elasticsearch_jvm_gc_utilization`	Garbage collection utilization in percent
`elasticsearch_jvm_heap_used`	Heap memory used in bytes
`elasticsearch_jvm_non_heap_used`	Non-heap memory used in bytes
`elasticsearch_size`	Size of all indices in bytes
`elasticsearch_search`	Number of searches per shard per second
`elasticsearch_search_time`	Average time per search in seconds
`elasticsearch_cluster_docs_count`	Number of documents stored across all cluster indices
`elasticsearch_cluster_size`	Size of all cluster indices in bytes

Monitoring Troubleshooting

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 Service Check is not OK

The check only opens the TCP port — it sends no command — so it fails when the port is wrong (Connection refused), when a firewall drops the packets (connection timed out after 10 seconds), or when the configured address cannot be parsed (Invalid TCP address). A green check proves the port is open, and nothing more.

Metrics are Missing

A passing check says nothing about the metrics: they are collected separately.

Glouton queries the node and cluster statistics at http://<address>:<port>. It sends no credentials and no TLS, which is the limitation to know about:

Reproduce what Glouton does, from the machine where the agent runs:

curl -i http://127.0.0.1:9200/_nodes/_local/stats

What you see	Cause	Fix
`401`	Security is enabled — the default since Elasticsearch 8	Glouton cannot authenticate to Elasticsearch; disable security on a local HTTP listener, or scrape the cluster with Prometheus metrics instead
a TLS error	The HTTP layer is HTTPS-only — also the default since Elasticsearch 8	Same: Glouton speaks plain HTTP here
a protocol error	Glouton points at the transport port (9300) instead of the HTTP port (9200)	Set `port: 9200`