Place memory_limiter as the first processor in every pipeline so that backpressure can propagate to receivers (and ultimately to senders) before the Collector runs out of memory
Set limit_mib to roughly 80% of the container/pod memory limit; set spike_limit_mib to about 25% of limit_mib to absorb bursts without hitting the hard limit
Set check_interval to 1s (default) in production; reduce to 100ms only in memory-sensitive environments since a shorter interval adds CPU overhead
Place batch last (or near last) in the processor list so only telemetry that has passed all filters and samplers is batched—this avoids buffering data that will ultimately be dropped
In the batch processor set timeout to 200ms–1s and send_batch_size to 512–8192 depending on payload size; set send_batch_max_size slightly above send_batch_size to allow a single oversized batch to flush rather than block
Monitor otelcol_processor_batch_batch_size_trigger_send and otelcol_processor_batch_timeout_trigger_send counters to understand whether your pipeline is size-bound or time-bound, and adjust accordingly
Known gotchas
If batch is placed before memory_limiter, the batch buffer grows unbounded during a backend outage and the Collector OOMs before memory_limiter can refuse new data
The memory_limiter enforces a soft limit (limit_mib) and a hard limit (limit_mib + spike_limit_mib); when the soft limit is exceeded, the receiver is told to apply backpressure but data already in the pipeline is not dropped until the hard limit is reached
send_batch_max_size must be greater than or equal to send_batch_size; setting it lower causes a config validation error
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp