Connect Everything You Monitor

How Auto-Discovery Works

When you install the Glouton agent on a server, it immediately begins scanning for running services using TCP socket checks executed every 60 seconds. There is nothing to configure: Glouton probes well-known ports and identifies the technology behind each open socket, whether it is MySQL on port 3306, Nginx on port 80, or Redis on port 6379. Each detected service receives a service_status metric that reports one of four values: 0 (OK), 1 (Warning), 2 (Error), or 3 (Unknown/timeout). This gives you an at-a-glance health indicator for every service running on the host.

Between polling intervals, Glouton maintains keep-alive connections to critical services. This means that if a service crashes or becomes unreachable, failure detection is immediate rather than waiting for the next 60-second cycle. Detected services are automatically tagged with metadata such as the service name, port, and host, so they appear in your Bleemeo dashboards and alert rules without any manual configuration. You get full visibility from the moment the agent starts running.

When you need more control, you can customize discovery behavior using YAML configuration files placed in /etc/glouton/conf.d/. For containerized environments, Docker labels such as glouton.SETTING_NAME let you tune monitoring on a per-container basis. Kubernetes users can rely on pod annotations to configure scraping and service detection at the orchestration layer. Environment variable overrides are also supported with the GLOUTON_ prefix (for example, GLOUTON_LOGGING_LEVEL), making it straightforward to adjust settings in cloud deployments where file-based configuration is not practical. On the free plan, you get availability checks for all discovered services; upgrading to the professional plan unlocks service-specific metrics like query rates, cache hit ratios, and connection pool utilization.