github.com/bleemeo/glouton @26.06.29.135402

A single-binary monitoring agent that just works.

Auto-discovery, an embedded TSDB, and a status-first local panel — out of the box.

Powers the Bleemeo Cloud agent fleet; battle-tested on Linux servers, Docker, and Kubernetes.

What is Glouton?

Glouton is the agent we use at Bleemeo to run our SaaS monitoring product, released as open source. It is one binary that:

• Auto-discovers what's running on your host or in your containers (nginx, postgres, redis, and 30+ apps and protocols) and generates the right metrics and checks.
• Collects host, container, and service metrics out of the box, with sensible defaults.
• Stores them locally on disk in a built-in TSDB (15-day default retention).
• Surfaces everything in a live web panel at http://localhost:8015, and re-exposes the same data through a Prometheus-compatible HTTP API (scrape at /metrics, query via PromQL).
• Optionally forwards to Bleemeo Cloud for long-term storage, alerts and notifications — or to any MQTT broker you control.

Screenshots

Dashboard — KPI cards, discovered services row, system and I/O charts, range-aware history.

Containers — sortable, status-coded, click a row for the full record.	Processes — top consumers, live, click for the full record.	Uptime Monitoring — probe targets, availability and recent failures at a glance.	Informations — facts, services, embedded logs, Prometheus URL and diagnostic exports.

_{Captures generated by ./scripts/take-screenshots.sh against a running Glouton; rerun against any reachable instance to refresh them.}

Quick start

The fastest way to see Glouton in action — no account, no signup:

docker run -d --name=glouton \
  -v /var/lib/glouton:/var/lib/glouton \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /:/hostroot:ro \
  -e GLOUTON_BLEEMEO_ENABLE=false \
  --pid=host --net=host \
  --cap-add SYS_PTRACE --cap-add SYS_ADMIN \
  bleemeo/bleemeo-agent

Then open http://localhost:8015. With Bleemeo disabled the on-disk TSDB starts automatically so the dashboard's longer time ranges (24 h, 7 d, 30 d) work out of the box.

What those Docker flags do

For a hardened setup (no host PID/net sharing, narrower bind mounts) follow the installation documentation.

Highlights

Footprint: ~100 MB RAM and 3-5 % of a single core on a typical host (~700 active metric series, polled every 10 s). The TSDB head accounts for roughly half of the resident memory and stays bounded by metric cardinality, not by retention — keeping more history on disk does not cost RAM.

Collect

• Auto-discovery of running services with curated metric sets — see the full list.
• Container runtimes: Docker (incl. Docker Desktop on macOS, auto-detected), containerd, Kubernetes.
• Application metrics: scrape any Prometheus endpoint (metric.prometheus.targets, filterable per target), JMX for Java apps, StatsD for custom counters and gauges.
• Log-derived metrics: parse journald, syslog, auditd or container logs through an OpenTelemetry pipeline and emit counters (errors per second, slow requests, custom patterns). The lines themselves are not stored or forwarded.
• Probes & checks: HTTP/HTTPS, TCP, custom Nagios-style scripts, NRPE.
• Network & hardware: SNMP, SMART, IPMI, NVIDIA.
• Kubernetes-native: per-pod metrics and checks driven by the cluster's own labels.

Store

• Built-in TSDB (Prometheus' on-disk engine, embedded). 15-day default retention, configurable, no extra process. Auto-enabled when running without Bleemeo so the panel's history works straight after docker run.
• Prometheus endpoint at /metrics for any external scraper.
• PromQL-compatible HTTP API at /api/v1/query and /api/v1/query_range — same shape as a Prometheus server, so Grafana and friends connect with no glue.

Surface

• Local panel at localhost:8015 with KPI cards, discovered services row, status-coded charts (system metrics, network & I/O), filesystem and disk utilisation filterable per device or mount, drag-to-zoom on every chart, theme-aware (system, light, dark).
• Per-container detail page with its own historical charts.
• Live agent logs embedded in the panel, with search and severity colouring (inferred from message keywords).
• Diagnostic bundle downloadable from the UI for support cases.

Forward

• Bleemeo Cloud — SaaS with long-term retention, alerts, notifications, account-wide dashboards. Free trial.
• MQTT broker of your choice — pair with SquirrelDB Ingestor for a self-hosted Prometheus alternative, or write your own consumer (messages are JSON, zlib-compressed).

What Glouton is not

Setting expectations honestly:

• Not a log shipper. Glouton can derive metrics from application logs (see the "Log-derived metrics" bullet above), and it surfaces its own runtime logs in the panel for debugging, but it does not store, index, or forward log lines themselves. Use Vector, Fluent Bit, or the OpenTelemetry collector if that's what you need.
• Not a tracing / APM agent. No spans, no transaction tracking. Pair with an OpenTelemetry SDK on your application side if you need that.
• Not a Prometheus replacement on its own. Glouton serves a Prometheus-compatible endpoint and ships an embedded TSDB suitable for a single host, but for a cluster-wide setup you still want a real Prometheus, a Mimir/Thanos backend, or Bleemeo Cloud.

Install

• Docker — see Quick start. A Docker Compose layout with jmxtrans alongside Glouton lives in docker-compose.yml.
• Native Linux package — officially built .deb (Debian, Ubuntu) and .rpm (RHEL, CentOS, Fedora) packages. Follow the installation documentation; it targets Bleemeo users but works just as well without an account once you set bleemeo.enable: false.
• Windows installer — MSI built from packaging/windows/, see the same installation documentation.
• Kubernetes — kubectl apply -f k8s.yaml from the repo root for a default DaemonSet + RBAC manifest, or follow the installation documentation for the Helm chart and per-cluster options.
• macOS — no packaged installer yet; use the published Docker image for the runtime case, or build from source with go run . from a clone (see CONTRIBUTING.md) for development. Docker Desktop and Colima sockets are auto-detected, so your containers show up without any extra config.

Updating

Release notes are on the GitHub Releases page.

• Linux package — glouton-auto-upgrade.timer is enabled by default and pulls fresh packages from the configured repository. To disable, mask the timer: systemctl disable --now glouton-auto-upgrade.timer.
• Docker — docker pull bleemeo/bleemeo-agent && docker restart glouton. Tag a specific version (e.g. bleemeo/bleemeo-agent:25.10.07.142359) if you prefer to pin and bump manually.
• Kubernetes — bump the image in your k8s.yaml / Helm values and re-apply.

Configuration

Out-of-the-box defaults work for most cases. To opt out of the Bleemeo connector and run fully standalone, this is enough:

bleemeo:
  enable: false

Drop that into /etc/glouton/conf.d/30-install.conf on a packaged install, or pass it as -e GLOUTON_BLEEMEO_ENABLE=false with the Docker image.

A few knobs people often touch:

agent:
  local_store:
    # enable: null      # tri-state: null = auto (on iff bleemeo.enable is false)
    retention: 15d      # how far back the on-disk TSDB keeps points

thresholds:             # per-metric thresholds, drive the service_status / agent_status
  cpu_used:
    high_warning: 80
    high_critical: 95
  mem_used_perc:
    high_warning: 80
    high_critical: 95

metric:                 # scrape arbitrary Prometheus endpoints
  prometheus:
    targets:
      - name: my-app
        url: http://my-app.internal:8080/metrics
        # allow_metrics: [http_requests_total, http_request_duration_seconds]
        # deny_metrics:  [go_gc_*]

The full reference, with every available key, lives in the agent configuration documentation.

Telemetry

By default Glouton posts a single anonymous payload to https://telemetry.bleemeo.com/v1/telemetry/ once per agent start. It contains:

• A random per-install ID (not your hostname, not the Bleemeo agent UUID).
• Whether the Bleemeo connector is active (true / false).
• Glouton version, installation format (package / Docker / manual).
• OS name and version, kernel version, system architecture.
• CPU cores and model, total memory.
• Timezone (used as a coarse country signal).

No metric values, no service names, no IP addresses or hostnames are sent. It helps us understand the deployment surface we're shipping for. To opt out, add this to the config (or set GLOUTON_AGENT_TELEMETRY_ENABLE=false):

agent:
  telemetry:
    enable: false

Examples

The examples/ folder contains ready-to-run docker-compose stacks that plug Glouton into a wider pipeline.

Local Grafana + Prometheus

(cd examples/prometheus && docker-compose up -d)   # Linux
(cd examples/prometheus_mac && docker-compose up -d)  # macOS

Then open http://localhost:3000/d/83ceCuenk/ (admin / password).

Push to MQTT + SquirrelDB

(cd examples/mqtt && docker-compose up -d)

Same Grafana URL. The example uses NATS as the broker and SquirrelDB Ingestor to write to SquirrelDB. See the SquirrelDB Ingestor README for authentication and HA notes.

Glouton's MQTT messages are published on v1/agent/<fqdn>/data (with . in the FQDN replaced by , because NATS doesn't allow dots in topics) and look like:

[
  {
    "labels_text": "__name__=cpu_used",
    "time_ms": 1665479613948,
    "value": 46.8
  }
]

Documentation

• Agent installation
• Configuration reference
• [Discovered services & metrics](https