Snippets · Sources
Receive StatsD metrics
Plenty of applications still emit StatsD over UDP. The statsd receiver accepts it on the usual port and aggregates it into OpenTelemetry metrics, with the metric type recorded as an attribute.
- Signals
- Metrics
- Category
- CollectionMigration
- Source
- StatsD (UDP)
- Components
- batchmemory_limiterotlphttp
- Destination
- OTLP/HTTP endpoint
OpenTelemetry Collector
receivers:
statsd:
endpoint: 0.0.0.0:8125
aggregation_interval: 60s
enable_metric_type: true
is_monotonic_counter: false
processors:
memory_limiter:
check_interval: 1s
limit_percentage: 80
spike_limit_percentage: 25
batch:
timeout: 5s
exporters:
otlphttp:
endpoint: https://your-backend:4318
service:
pipelines:
metrics:
receivers: [statsd]
processors: [memory_limiter, batch]
exporters: [otlphttp]
LinkMesh
Library › Sources › StatsD
- Listen Address
- 0.0.0.0:8125
- Transport
- udp
- Aggregation Interval
- 60s
- Add StatsD Metric Type Attribute
- true
- Counters Are Cumulative
- false
What LinkMesh then pushes to the collector, under receivers:
statsd/input_src_00000501:
aggregation_interval: 60s
enable_metric_type: true
endpoint: 0.0.0.0:8125
is_monotonic_counter: false
transport: udp
The same, as an API call (see automation recipes):
curl -X POST "$LINKMESH/sources" \
-H "Authorization: Bearer $LMSAT" \
-H "Content-Type: application/json" \
-d '{
"defaultConfig": {
"aggregation_interval": "60s",
"enable_metric_type": true,
"endpoint": "0.0.0.0:8125",
"is_monotonic_counter": false,
"transport": "udp"
},
"name": "StatsD",
"receiverType": "statsd"
}'The rest of the collector config above (memory_limiter, batch, otlphttp) is not part of this template: in LinkMesh those are separate sources, processors and destinations on the route.
Generated from LinkMesh's template catalogue by linkmesh-server snippet-render 1.464.3, not written by hand.
Download config.yamlValidated with otelcol-contrib v0.161.0 on 2026-10-26
Complete config files, each checked with the collector's own validate command (otelcol-contrib v0.161.0). Replace https://your-backend:4318 with your own OTLP endpoint before you run it.
The gotcha
Counters are aggregated, not forwarded one by one. In our test three increments of checkout.orders inside one aggregation_interval arrived as a single delta sum with the value 3. If your backend expects cumulative counters, they need converting before export.
Manage this across a fleet
LinkMesh manages collector configuration across a fleet from one self-hosted control plane, so a change like this is made once rather than host by host. The first 25 Collectors are free after a no-card registration in the OpenSight Customer Portal (5 without one).
Doing this in LinkMesh: Sources
Related snippets
- Receive logs from Fluent Bit and Fluentd (forward)Take logs from existing Fluent Bit or Fluentd agents over the forward protocol, without replacing them first.
- Scrape Prometheus metrics endpointsScrape any Prometheus /metrics endpoint - node_exporter, an application, an exporter - into OpenTelemetry metrics.
- Prometheus counters to a delta-only backend (cumulativetodelta)Scrape Prometheus counters and convert them to the delta temporality Dynatrace requires - gauges untouched.
- Collect host metrics (CPU, memory, disk, network, processes)CPU, memory, disk, filesystem, network, load and per-process metrics from every host, without a separate node agent.