OpenTelemetry is emerging as the common framework for collecting observability data, and for good reason. It’s vendor-neutral, open source, and designed to collect traces, metrics, and logs in a consistent way. But while most of the buzz is around tracing and metrics, let’s not forget: logs are still the backbone of investigation and response.
That’s why Graylog now supports native collection of OpenTelemetry data over gRPC. If you’re already using OpenTelemetry in your stack—or you’re just curious how to consolidate structured telemetry logs with the rest of your event data—this new input makes things easier.
Let’s walk through what this feature does, why it matters, and how to get it working in your environment.
Why OpenTelemetry and Graylog Makes Sense
OpenTelemetry isn’t a single protocol—it’s a toolkit. The OpenTelemetry Protocol (OTLP) supports multiple transport formats, but gRPC is the go-to for real-time, high-throughput use cases.
By adding a gRPC input for OTLP logs, Graylog becomes a central observability engine, capable of handling not just syslog and Beats traffic, but also telemetry streams from cloud-native apps, Kubernetes clusters, and distributed services.
This unlocks:
- Structured, correlated log data enriched with trace context
- Faster detection and root cause analysis using familiar Graylog tools
- One less hop between your services and your SIEM or logging platform
What the gRPC Input Actually Does
The new input type allows Graylog to ingest OTLP-formatted logs over gRPC, a lightweight and efficient transport layer ideal for distributed systems.
Specifically, the input:
- Listens for incoming telemetry using the OTLP log signal
- Accepts data in protobuf format over gRPC (not HTTP)
- Maps and parses log fields into Graylog’s First-Level Field Mapping
- Supports TLS encryption, authentication, and service-level tagging
At this time, the input is optimized for log data, but future iterations could support metrics or trace signals as well.
First Level Field Mapping
| OpenTelemetry Field | Graylog Field |
| trace_id | otel_trace_id |
| span_id | otel_span_id |
| flags | otel_trace_flags |
| severity_text | otel_severity_text |
| severity_number | otel_severity_number |
| time_unix_nano | otel_time_unix_nano |
| observed_time_unix_nano | otel_observed_time_unix_nano |
At this time, the input is optimized for log data, but future iterations could support metrics or trace signals as well.
Resource and Attributes Mapping
- Resource Attributes: Prefixed with otel_resource_attributes_ and converted to Graylog fields.
- Resource Schema URL: Mapped to otel_resource_schema_url.
- Log Attributes: Prefixed with otel_attributes_.
- Log Schema URL: Mapped to otel_schema_url.
- Instrumentation Scope:
- otel_scope_name
- otel_scope_version
- otel_scope_attributes_*
Who Supports OTLP/gRPC?
If you’re working in the cloud (and let’s be honest, who isn’t?), it’s helpful to know which providers offer support for OpenTelemetry—especially if you’re planning to send logs over gRPC. The good news: all major clouds support OpenTelemetry in some form, and most offer native or collector-based support for OTLP over gRPC.
Here’s a quick common list of cloud support:
| Cloud | OTEL Support | OTLP/gRPC Support | Common Integration |
|---|---|---|---|
| AWS | ✅ | ✅ | CloudWatch, X-Ray |
| Azure | ✅ | ✅ | Azure Monitor |
| GCP | ✅ | ✅ | Cloud Logging, Trace |
| IBM | ✅ | ✅ | Instana |
| Oracle | ✅ | ⚠️ (via Collector) | OCI Logging |
How To Set It Up in Graylog
Getting started is pretty straightforward.
- Go to System > Inputs, and choose OpenTelemetry (gRPC).
- Configure the Title, IP Bind Address, port (default is 4317), TLS certs (if needed), and optional service name.
- Start the input.
On the collector side, configure your OpenTelemetry Collector to send logs via gRPC. Make sure your pipeline includes a logs exporter using the OTLP target, and you’re good to go. You can find full setup instructions in the Graylog documentation.
What You Can Do Once It’s Flowing
Once OpenTelemetry logs are hitting your Graylog instance, you can:
- Create dashboards that combine infrastructure and app-level data
- Use streams to isolate logs by service or environment
- Enrich logs with Graylog Information Model Schema
- Automate responses using alerts and pipelines
You can even correlate log events with traces—bringing observability and threat detection closer together. (Because let’s be honest: context is everything when you’re chasing down an incident.)
Common Pitfalls to Watch For
Getting gRPC right takes a little finesse. Here are a few gotchas:
- Port issues: gRPC often uses 4317, but firewall rules or existing services can interfere.
- TLS misconfigs: Certificates must match your endpoint and client trust setup.
- Collector mismatches: The OpenTelemetry Collector config must match Graylog’s gRPC endpoint and expected signal type.
If you’re stuck, the input diagnostics tool in Graylog’s web UI can usually point you in the right direction.
From Buzzword to Better Logs
OpenTelemetry is no longer just a forward-looking framework, it’s fast becoming table stakes. And now, with native gRPC support in Graylog, it’s easier than ever to collect telemetry logs without duct-taping another tool into your stack.
If you’re ready to see how structured telemetry logs can strengthen your visibility, give the new OpenTelemetry (gRPC) input a try. It just might become your new favorite way to get logs into Graylog.
