Notifications
Clear all
Topic starter
19/08/2026 3:56 pm
TL;DR: Log pipelines are hitting throughput, reliability, and parsing limits as security teams move terabytes of telemetry each day, and Axoflow argues that OTLP/gRPC reduces overhead versus syslog and HTTP by using protobuf, streaming, flow control, and application-level acknowledgments. The broader shift is that transport choice is becoming a governance issue for log integrity, not just an infrastructure preference.
NHIMG editorial — based on content published by Axoflow: Why Use OpenTelemetry gRPC for Log Data Transport
Questions worth separating out
Q: How should security teams choose a log transport for identity and security telemetry?
A: Choose the transport based on delivery semantics, not just throughput.
Q: Why does gRPC reduce risk in large security data pipelines?
A: gRPC reduces risk because it lowers the chance that overloaded collectors, network churn, or parsing failures will silently drop records.
Q: What breaks when syslog is used for high-volume telemetry without extra controls?
A: What breaks is not just performance, but assurance.
Practitioner guidance
- Map telemetry by control dependency Identify which log streams support IAM, PAM, workload identity, and audit evidence, then classify them by loss tolerance before changing transport.
- Standardise OTLP schemas before widening ingestion Define the fields that every collector and backend must preserve, including sender, workload, environment, and correlation identifiers.
- Test backpressure and reconnect behaviour under load Simulate collector saturation, network jitter, and backend restarts to verify that the transport layer slows cleanly and resumes without silent loss.
What's in the full article
Axoflow's full article covers the operational detail this post intentionally leaves for the source:
- Protocol-level examples showing why HTTP/2 multiplexing changes throughput under telemetry load
- The transport comparison table for OTLP/gRPC versus OTLP/HTTP and syslog
- Implementation considerations for Google Cloud Pub/Sub and OpenTelemetry pipelines
- Operational notes on where self-hosted support is still required for OTLP/gRPC
👉 Read Axoflow's analysis of why gRPC improves log transport reliability →
gRPC for log pipelines: what it means for security teams?
Explore further
19/08/2026 4:34 pm
Protocol reliability is now a control issue, not an engineering preference. When logs support identity assurance, privileged access review, and incident reconstruction, transport loss becomes a governance failure as much as a performance defect. gRPC's stronger delivery semantics matter because security programmes depend on complete evidence chains, especially when service accounts, API activity, or authentication events must be correlated across systems. Practitioners should treat telemetry transport as part of control design, not infrastructure plumbing.
A question worth separating out:
Q: How do teams know whether a log transport is actually reliable?
A: Measure end-to-end delivery, not just connectivity. A reliable transport should preserve records through overload, reconnect cleanly after interruption, and expose retry or acknowledgment behaviour that can be tested. If you cannot prove that the application processed the event, the transport is not yet reliable enough for critical security telemetry.
👉 Read our full editorial: Why gRPC is replacing syslog for secure log transport
