Modern applications are distributed, ephemeral and built from a dozen moving parts. To keep them reliable, you need real visibility: not just “is the server up?”, but “how is this request behaving, right now, across every component it touches?”.

The good news is that the observability world has converged on a handful of open standards — Prometheus for metrics, OpenTelemetry for telemetry, plus battle-tested protocols like StatsD and NRPE. Building on these standards is the single best decision you can make for the long-term health of your monitoring stack. This article explains how to use them together to fully monitor an application, and how Bleemeo lets you adopt them without rewriting anything or locking yourself into a proprietary agent.

Why standards matter more than tools

Every monitoring vendor wants you to install their agent, emit their metric format and query with their query language. It works — until the day you want to switch, add a second backend, or simply hire someone who already knows the tooling. Then the cost of that proprietary glue becomes very real.

Open standards flip the equation:

  • Portability — instrument your code once against OpenTelemetry or expose a Prometheus endpoint, and your telemetry is no longer tied to a single backend.
  • Leverage existing skills — PromQL, OTLP and StatsD are everywhere. Your team probably already knows them, and so does your next hire.
  • A rich ecosystem — thousands of Prometheus exporters and OpenTelemetry instrumentation libraries exist today. Standards let you reuse all of them.
  • No lock-in — if a tool stops serving you, you keep your instrumentation and move on.

This is the lens we use at Bleemeo: instead of inventing yet another agent protocol, we speak the standards you already use. Glouton, our open-source agent, is essentially a standards hub — it speaks Prometheus, OpenTelemetry (OTLP), StatsD and NRPE, and forwards everything to the Bleemeo Cloud platform.

OPEN STANDARDS ONE OPEN-SOURCE AGENT BLEEMEO CLOUD Prometheus metrics OpenTelemetry logs (OTLP) StatsD custom metrics NRPE Nagios checks Glouton standards hub Metrics Logs Dashboards & alerts

Four open standards in, one agent in the middle, your platform out — and not a single proprietary format along the way.

The signals you need, mapped to standards

Observability is classically described through three pillars — metrics, logs and traces — to which operations teams add a fourth, very practical signal: status checks (“is this thing healthy right now?”). Here is how each maps to an open standard you can adopt today:

SignalStandardHow Bleemeo ingests it
MetricsPrometheus (exporters + PromQL), StatsDGlouton scrapes Prometheus endpoints and runs an embedded StatsD server
LogsOpenTelemetry (OTLP), structured log filesGlouton exposes OTLP gRPC/HTTP receivers and tails file/container/system logs
TracesOpenTelemetry (OTLP)The same OTLP standard carries traces; pair Bleemeo metrics & logs with any OTLP-compatible tracing backend
Status checksNRPE / Nagios pluginsGlouton acts as an NRPE server and runs your existing checks

Notice there is no “Bleemeo format” in that table — everything is a standard. This article focuses on the two signals you reach for first, metrics and logs, plus the checks that bridge an existing Nagios setup. Traces ride the very same OpenTelemetry protocol as logs, so adopting OTLP now puts that third pillar within easy reach later. Let’s walk through each one.

Metrics: Prometheus, the de-facto standard

Prometheus has become the default language of cloud-native metrics. The model is simple: your application (or an exporter sitting next to it) exposes a /metrics HTTP endpoint, and something scrapes it on an interval.

With Bleemeo, that something is Glouton. You point the agent at any Prometheus exporter and it collects, labels and forwards the metrics — no separate Prometheus server to run and scale:

# /etc/glouton/conf.d/50-prometheus-metrics.conf
metric:
  prometheus:
    targets:
      - url: "http://localhost:8080/metrics"
        name: "my_application"
        allow_metrics:
          - "http_requests_total"
          - "http_request_duration_seconds*"

Because the data is standard Prometheus, you query it with standard PromQL — the same expressions you would write against a self-hosted Prometheus:

# 95th percentile request latency over 5 minutes
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

This is the foundation of the RED method (Rate, Errors, Duration) for services and the USE method (Utilization, Saturation, Errors) for resources — both expressible directly in PromQL. If you’d rather not operate Prometheus yourself, that is exactly the idea behind Prometheus in the Cloud.

📖 Docs: Prometheus concepts · PromQL reference · Ingesting Prometheus metrics

Custom & business metrics: StatsD

Not every metric comes from an exporter. Sometimes you just want your application to fire “this happened” from inside the code — a checkout completed, a job processed, a cache miss. That is exactly what StatsD was built for, and it remains one of the simplest ways to emit custom and business metrics from any language.

Glouton ships with an embedded StatsD server, enabled by default on the standard port:

# Enabled out of the box on UDP 8125
statsd:
  enable: true
  address: "127.0.0.1"
  port: 8125

Sending a metric is then a one-liner from any language — or even straight from the shell, no client library required:

# Increment a counter every time an order is completed
echo "orders.completed:1|c" | nc -u -w0 127.0.0.1 8125

Glouton turns it into a Bleemeo metric (statsd_orders_completed) and it lands on your dashboards next to everything else. It is the quickest path from “I wish I tracked this” to a graph and an alert.

📖 Docs: Using StatsD with Bleemeo

Logs: OpenTelemetry (OTLP) and beyond

Metrics tell you what is wrong; logs tell you why. The modern, vendor-neutral way to ship logs is OpenTelemetry, using the OTLP protocol. OpenTelemetry actually spans metrics, logs and traces under a single standard — with Bleemeo, the OTLP path focuses on logs today, while metrics come in through Prometheus and StatsD. If your application is already instrumented with an OpenTelemetry SDK, you don’t need a new logging library — you just point the OTLP exporter at Glouton, which exposes both a gRPC and an HTTP receiver:

# OTLP receivers (enabled by default)
log:
  opentelemetry:
    grpc:
      enable: true
      address: localhost
      port: 4317   # OTLP/gRPC
    http:
      enable: true
      address: localhost
      port: 4318   # OTLP/HTTP

By default these receivers bind to localhost, so nothing is exposed off-host until you deliberately open them up — a safe default for a co-located agent.

You can filter at the edge — for instance, keep only INFO and above — so you don’t pay to ship debug noise:

log:
  opentelemetry:
    global_filters:
      include:
        match_type: strict
        severity_number:
          min: INFO
          match_undefined: true

Not everything emits OTLP yet, and that’s fine: Glouton also tails plain file, container and system logs, and can even turn log patterns into metrics (for example, counting 5xx responses straight from an access log) so you can alert on them. It all feeds Bleemeo’s centralized log management, alongside your metrics.

📖 Docs: Logs overview · OTLP log receivers · Log-based metrics

Bridging the legacy world: NRPE & Nagios checks

Standards aren’t only about the latest protocols — they’re also about not throwing away what already works. Many teams have years of investment in Nagios plugins and NRPE checks. There is no reason to rewrite them.

Glouton can act as an NRPE server: a Nagios server can query it just like any NRPE daemon, and you can expose any Glouton service check to Nagios. It is the perfect bridge for a gradual migration — keep your existing checks running while you layer modern metrics and logs on top:

# Let Glouton answer NRPE requests from your Nagios server
nrpe:
  enable: true
  conf_paths:
    - "/etc/nagios/nrpe.cfg"

This means a single agent covers both worlds at once: standard Prometheus/OTLP/StatsD for new services, and NRPE for the checks you already trust.

📖 Docs: Agent configuration (NRPE settings) · Blog: Using Glouton as a Nagios NRPE daemon

At a glance: which protocol for what?

Four protocols, four jobs. Here is the whole picture in one table — all of it collected by a single Glouton agent, with no proprietary format anywhere:

ProtocolMetricsLogsStatus checksModelBest for
Prometheus✅——Pull (scrape /metrics)Cloud-native metrics, dashboards & PromQL alerting
OpenTelemetry (OTLP)✅✅—PushVendor-neutral instrumented apps; ships logs into Bleemeo today
StatsD✅——Push (UDP)Quick custom & business metrics straight from your code
NRPE——✅Pull (Nagios queries)Reusing existing Nagios plugins & checks

The model column matters operationally: pull protocols (Prometheus, NRPE) let the agent scrape on its own schedule, which keeps long-running services tidy, while push protocols (OTLP, StatsD) let your app emit data the instant something happens — ideal for short-lived jobs and business events. In practice they complement each other: Prometheus and StatsD cover the metric side, OpenTelemetry brings standardized logs (and a future-proof path for the rest of your telemetry), and NRPE bridges everything you already run on Nagios.

Putting it all together

Picture a typical web application. Here is what full, standards-based application monitoring looks like with a single Glouton agent on the host (or as a DaemonSet in Kubernetes):

  1. Metrics — the app exposes a Prometheus /metrics endpoint (request rate, latency histograms, error counters). Glouton scrapes it and you alert with PromQL.
  2. Business events — the checkout path fires a StatsD counter on every completed order, so product and engineering share the same source of truth.
  3. Logs — the app’s OpenTelemetry SDK ships structured logs over OTLP to Glouton, while the reverse proxy’s access log is tailed and converted into a 5xx rate metric.
  4. Legacy checks — an existing NRPE check for a background daemon keeps running, now visible on the same dashboards.

Every one of those four flows is an open standard. Glouton normalises them and forwards to Bleemeo, where you get unified dashboards, alerting and long-term storage — without a single proprietary instrumentation choice along the way. If you ever change your mind about the backend, your instrumentation comes with you.

Bonus: query your observability with AI

Because the data is standards-based and well-labelled, it’s also easy to expose to AI assistants. Bleemeo provides an MCP server, so tools like Claude or your IDE can answer questions like “what changed before the latency spike at 14:00?” against your real metrics and logs.

📖 Docs: Bleemeo MCP server

Getting started

The best part: all four protocols are handled by the same agent, so there is a single thing to install. On a Linux host, register Glouton with your account in one command:

wget -qO- "https://get.bleemeo.com?accountId=<YOUR_ACCOUNT_ID>&registrationKey=<YOUR_REGISTRATION_KEY>" | sh

From there, enable the receivers you need (Prometheus targets, OTLP, StatsD, NRPE) by dropping small files into /etc/glouton/conf.d/ — exactly the snippets shown above. The OTLP and StatsD receivers are on by default, so logs and custom metrics work the moment the agent is up.

📖 Docs: Installing the agent · Agent configuration

Conclusion

You don’t have to choose between “modern observability” and “not getting locked in”. By building on Prometheus, OpenTelemetry, StatsD and NRPE, you get full visibility into your application — metrics and logs — using skills and tooling your team already has, with no proprietary glue. Bleemeo’s role is deliberately humble here: speak the standards, collect everything through one open-source agent, and give you a great place to see it all.

Start monitoring your application today with a 15-day free trial — no credit card required.

Want the details? Browse the Bleemeo documentation or contact our team with your use case.