Server monitoring with OpenTelemetry:
the Collector is the agent.

If you used to run a Zabbix agent, a Nagios NRPE client, or a Datadog Agent on every server, the same workload runs today as an OpenTelemetry Collector with the contrib distribution. CPU, memory, disk, network, Nginx status, Postgres internals, and synthetic HTTP checks all become OTLP signals. Point the exporter at any compatible backend: Telemtra, Grafana Cloud, self-hosted Prometheus, whatever fits. We've run this in production. Below is the config we'd actually deploy.

The model shift

Traditional server monitoring assumed a vendor agent and a vendor backend. The agent collected; the backend stored. Both pieces were proprietary. Replacing one meant replacing both.

OpenTelemetry breaks the pair. The OTel Collector is the agent. It ships from github.com/open-telemetry/opentelemetry-collector-contrib as a single binary (otelcol-contrib) and runs anywhere the vendor agents used to run. The wire format is OTLP, an open standard. The backend is replaceable. Whatever sysadmin habits you already have (config files, systemd units, log rotation, package updates) transfer directly.

The five-minute starter: hostmetrics

The hostmetrics receiver collects CPU, memory, load, disk, filesystem, network, paging, and process metrics from the host it runs on. One block in the Collector config replaces what a node_exporter or Datadog Agent does for system-level metrics.

receivers:
  hostmetrics:
    collection_interval: 30s
    scrapers:
      cpu:
      memory:
      load:
      disk:
      filesystem:
      network:
      paging:
      processes:

processors:
  resource:
    attributes:
      - { key: host.name, value: ${env:HOSTNAME}, action: insert }
      - { key: deployment.environment, value: production, action: insert }
  batch:
    timeout: 30s

exporters:
  otlphttp/telemtra:
    endpoint: https://ingest.telemtra.io
    headers:
      x-api-key: ${env:TELEMTRA_API_KEY}

service:
  pipelines:
    metrics:
      receivers: [hostmetrics]
      processors: [resource, batch]
      exporters: [otlphttp/telemtra]

That's the whole agent. Drop it into /etc/otelcol/config.yaml, restart the Collector, and CPU per core, memory pressure, disk I/O, and process counts land in the backend. Our host metrics reference lists every metric each scraper emits — including the useful ones that are off by default — and the Linux host observability guide walks through it for a Linux VM end-to-end.

Three more receivers most ops stacks need

Host metrics are the floor. Beyond them, the contrib distribution ships receivers that cover most of the things a traditional monitoring tool would have. Four picks that cover roughly 80% of common needs:

nginx: webserver metrics

Reads from Nginx's stub_status endpoint and produces metrics for active connections, connections per state, requests per second. Pairs naturally with the filelog receiver tailing access.log for request-level detail — our Nginx monitoring reference covers which statuses, error messages, and metrics deserve alerts.

receivers:
  nginx:
    endpoint: http://localhost:80/status
    collection_interval: 10s

Apache equivalent is the apache receiver against mod_status. IIS users have iis (and windowsperfcounters for the OS layer).

postgresql: database metrics

Connects to Postgres via the standard libpq protocol and scrapes pg_stat counters: backends per database, transactions committed/rolled-back, buffer hit ratio, block reads. The metrics map to standard Postgres operational dashboards.

receivers:
  postgresql:
    endpoint: localhost:5432
    transport: tcp
    username: otel_monitor
    password: ${env:PG_MONITOR_PASSWORD}
    databases:
      - production
      - reports
    collection_interval: 30s
    tls:
      insecure_skip_verify: false

Create a Postgres role with pg_monitor grants. The receiver doesn't need superuser. The mysql and mongodb receivers follow the same shape. redis uses the Redis protocol against a connection string.

httpcheck: synthetic uptime checks

HTTP-level uptime monitoring without a separate synthetic vendor. The Collector itself periodically requests URLs and records latency, status code, and TLS expiration. Run it on a separate host from the service being checked so you measure something approximating user experience.

receivers:
  httpcheck:
    targets:
      - endpoint: https://app.example.com/healthz
        method: GET
      - endpoint: https://app.example.com/api/v1/orders
        method: GET
        headers:
          Authorization: Bearer ${env:HEALTHCHECK_TOKEN}
    collection_interval: 60s

Each target produces httpcheck.duration, httpcheck.status_code, and httpcheck.tls.cert_remaining metrics. Alert on cert expiry under 14 days, latency above SLO, or non-2xx status. The same alerts you'd configure in a synthetic monitoring product.

Windows: windowsperfcounters

For Windows servers, windowsperfcounters exposes any Windows performance counter the OS knows about, the same data that Perfmon shows. Pair it with the windowseventlog receiver for Event Viewer logs — our Windows Event IDs reference covers which events are worth alerting on once they flow.

receivers:
  windowsperfcounters:
    collection_interval: 30s
    metrics:
      system.cpu.utilization:
        description: CPU utilisation
        unit: '%'
        gauge:
    perfcounters:
      - object: Processor
        instances: ['*']
        counters:
          - name: '% Processor Time'
            metric: system.cpu.utilization

Pair with the windowseventlog receiver for Event Log forwarding. Our Windows Event Logs doc covers that end of it.

What this approach doesn't give you (yet)

Three honest gaps versus a mature traditional monitoring suite:

• No auto-discovery wizard. Datadog's agent or SolarWinds will scan a host and turn on the relevant integrations automatically. The Collector requires you to enable receivers in config. For large heterogeneous fleets this is real friction; for a uniform server population it's a one-time setup.
• Fewer prebuilt dashboards out of the box. Datadog ships hundreds of vendor-curated dashboards. The OTel/Telemtra/Grafana approach gives you the data; you (or community templates) build the dashboard.
• You operate the Collector. Package updates, config drift, log rotation, restart on OOM. The same operational hygiene you would have applied to a Zabbix agent. Not new work, just not removed by adopting OTel.

Backend choice is open

The Collector config above exports OTLP. Substitute any compatible backend:

• Telemtra: flat-rate OTel-native SaaS (this site)
• Grafana Cloud Mimir: managed Prometheus-compatible store, also speaks OTLP — see OpenTelemetry-native backends vs Grafana Cloud for the trade-offs
• Self-hosted Prometheus: via the Collector's prometheusremotewrite exporter
• SigNoz, OpenObserve, Honeycomb, New Relic: each accepts OTLP, some with quirks

The choice doesn't change the Collector side. Just the exporter block.

A migration sketch

If you're moving off a traditional server monitoring tool, the lowest-risk path:

1. Run the Collector alongside the existing agent for a billing cycle. Both ship data; you compare. Spike the bill on the new side for a month to learn the cost shape.
2. Replicate the dashboards you actually look at in the new backend. Most teams discover they used 20% of the vendor dashboards and the rest were noise.
3. Cut over alerts one at a time, starting with the lowest-stakes ones. Cardinality and unit differences sometimes catch teams here. Better to discover with a non-paging alert than the on-call rotation alert.
4. Decommission the old agent when the new pipeline has been alerting cleanly for two weeks.

Frequently asked questions

Can the Collector replace the Datadog Agent?

For the workloads covered above — system metrics, nginx, Postgres, HTTP checks — yes. The honest gaps are auto-discovery, prebuilt dashboards, and the fact that you operate the Collector yourself; see the "what this approach doesn't give you" section.

How do I monitor CPU and memory?

The hostmetrics receiver, covered in the five-minute starter above. One config block replaces node_exporter or a vendor agent for system-level metrics.

Can OpenTelemetry do uptime checks?

Yes — the httpcheck receiver, covered above, records latency, status codes, and TLS expiry per target. Alert on cert expiry under 14 days and non-2xx statuses.

Further reading

See Linux host observability with OpenTelemetry for the end-to-end VM walkthrough, Windows Event Logs with OpenTelemetry for the Windows side, and OpenTelemetry Collector receivers: a practical guide for the broader receiver catalogue. Start a Telemtra workspace to point a Collector at a hosted OTLP backend in 60 seconds.