Skip to content
All flows

Replace vendor agents on your VM fleet

Scrapes CPU, memory, load, disk, filesystem, and network metrics plus system and application logs on every VM.

Scrapes CPU, memory, load, disk, filesystem, and network metrics plus system and application logs on every VM. Cloud metadata (EC2, GCP, Azure) and your fleet tags are stamped on every point for per-team cost attribution downstream. Ships OTLP to any backend through a disk-backed queue that rides out outages and reboots.

How the data moves
receiverprocessorexporterextension
metrics
hostmetricsmemory_limiterresourcedetectionresourcebatchotlp_grpc
logs
filelogjournaldmemory_limiterresourcedetectionresourcebatchotlp_grpc

Use this flow

Open the config in Telflo and it becomes a working pipeline on the canvas: adapt what's specific to you, test it against recorded traffic, and push it to your fleet over OpAMP. Free account, no card.

Components

What's in it, and why

hostmetrics

Scrapes CPU, memory, load, disk, filesystem, and network metrics from each VM, the same host telemetry the vendor agent collected.

filelog

Tails application log files with offsets checkpointed to file_storage so restarts neither re-read nor silently skip lines.

journald

Reads systemd unit logs (sshd, docker, containerd) on Linux hosts so system logs arrive without tailing files; app logs stay on filelog to avoid duplicates.

memory_limiter

Caps the collector heap on each host and pushes backpressure to receivers before the process OOMs; first in both pipelines per its README.

resourcedetection

Stamps host.name plus EC2, GCP, or Azure instance metadata on every metric and log so fleet data is attributable per host and region.

resource

Applies the fleet-wide tags (deployment.environment, team, cost center) that Telflo fleet variables templatize per host group.

batch

Batches after all enrichment to cut export request volume; its README says to place it after memory_limiter and any sampling processors.

otlp_grpc

Ships metrics and logs to any OTLP backend or gateway collector with retry and a file-backed persistent queue.

health_check

Serves the HTTP liveness endpoint that systemd units or fleet automation probe on each host.

file_storage

Persists filelog and journald read positions and backs the exporter sending queue so nothing is lost across restarts.

Notes

Gotchas

  • 1

    The process scraper emits a full metric set per PID and logs permission errors constantly when the collector is not root; if you enable it, add include filters and the mute_process_* flags rather than turning it on fleet-wide.

  • 2

    resourcedetection ordering matters: the first detector to set an attribute wins, so keep env first if you want per-host OTEL_RESOURCE_ATTRIBUTES to take precedence, and leave override: false so detected values never clobber attributes already on the data.

  • 3

    filelog with start_at: end reads nothing from a file until it is written to again, and without the storage extension every collector restart re-tails from the end, silently dropping whatever was written during the downtime.

  • 4

    The journald receiver shells out to journalctl, so the binary must exist in the collector's environment (minimal container images often omit it), the collector user needs journal read access (systemd-journal group), and the receiver does not run on Windows or macOS.

  • 5

    Without the filesystem scraper's mount point and fs type excludes, overlay and tmpfs mounts get scraped too, double-counting disk usage on any host running containers; health_check's check_collector_pipeline sub-feature is documented as not working, so probe the plain endpoint only.

Test it before your fleet runs it

Free account, no card. Open this flow in the editor, adapt it, and see what it does to real data before anything ships.