How OpenTelemetry logs reach Graylog over OTLP gRPC
A platform or security team that wants application logs from OpenTelemetry services in Graylog should plan around the Graylog OpenTelemetry (gRPC) input, which receives log data over OTLP using gRPC and maps it into Graylog's internal schema. The input is fed by an OpenTelemetry Collector configured with Graylog as a logs backend, and the input is the method Graylog documents for this path. OpenTelemetry itself does not store or display logs. It is a framework and toolkit for generating, exporting and collecting telemetry such as traces, metrics and logs, so Graylog fills the storage and search role that OpenTelemetry leaves to separate tools. The Graylog documentation for this input is the starting point for the input settings.
The Collector is the component your team will configure and operate. It is vendor-agnostic and licensed under Apache-2.0, and it can run as an agent beside each service or as a gateway that accepts data from many sources. Choosing between those two layouts decides where batching, retries and credentials live, so settle it before writing the exporter block. Confirm which Collector distribution and version your environment uses, because core components carry mixed stability levels documented in each component's README. Confirm that your Collector build includes the exporter Graylog expects, and record the version in your change records so later upgrades can be tested against the same pipeline. Treat the Graylog endpoint, the exporter and the authentication settings as one unit to be tested together.
What you need before connecting OTel logs to Graylog
Most OTLP log ingestion problems trace back to a missing prerequisite rather than the input itself. The items below cover the Graylog version, the Graylog node, the Collector build, the network paths and the certificates and tokens that connect them. Check each one before you configure the exporter.
Graylog version and docs
Confirm which Graylog release your cluster runs before you read any input documentation. The current Graylog documentation covers version 7.2, and input options can change between releases, so the settings in this guide should be checked against the docs for your exact version. If you run an older release, use the matching documentation set rather than the current one. Record the version in your change ticket so the Collector configuration and the server line up during upgrades.
A running node with the OTel input
The Graylog OpenTelemetry (gRPC) input must be available on the node that receives logs. Start the input from the System menu, confirm it is in the running state, and check the port it listens on against your firewall rules. In a multi-node cluster, decide which node or load balancer address the Collector targets, and confirm that every node you expose can accept the input. Test the listener with a non-production source before you point production services at it.
Collector build with the exporter
Graylog is fed by an OpenTelemetry Collector configured with Graylog as a logs backend, so the Collector must include the exporter you plan to use. The Collector project ships a contrib distribution that carries community exporters, and the release line in use at the time of writing was v0.163.0. Confirm the exporter name and its configuration keys against the release you deploy, because exporter names and options change between Collector versions. Use the signed artifacts and SHA256 checksums that the releases publish to verify the binary before deployment.
Network paths in both directions
Two network paths must be open. Services send OTLP data to the Collector, usually as an agent beside the workload or as a gateway that many sources share, and the Collector sends logs to Graylog over gRPC. Map each hop, including any proxy, load balancer or Kubernetes network policy, and confirm the ports on both sides. A correct Graylog configuration does nothing if a firewall silently drops the gRPC traffic between the Collector and the input.
TLS certificates for production
Graylog documents an insecure, unauthenticated configuration for testing only, so production traffic needs TLS. Decide which certificate authority issues the server certificate for the input, how the Collector trusts that authority, and who renews the certificate before it expires. Record the hostname the Collector uses to connect, because the certificate must match it. Ask your security team whether internal certificate issuance follows your existing PKI policy.
Bearer token issuance and storage
The production configuration pairs TLS with bearer token authentication, so every Collector needs a token that Graylog accepts. Decide who generates tokens, how they are scoped per environment or service, and where the Collector reads them from at runtime. Store tokens in your secrets manager and inject them through environment variables or files, not inline in the Collector configuration. Plan a rotation procedure before go-live, because changing a token requires updating every Collector that uses it.
Configuring the Collector exporter and the Graylog input
This sequence connects an OpenTelemetry Collector to a Graylog OTLP gRPC input, moving from an insecure test setup to TLS with bearer token authentication, and ends with a confirmed test log in Graylog.
Create the OpenTelemetry gRPC input in Graylog
A Graylog administrator opens the input configuration in the Graylog web interface and adds an OpenTelemetry (gRPC) input on the Graylog nodes that will receive data. Record the bind address and port the input listens on, because the Collector exporter must reach exactly that endpoint. Confirm the input is running and shows a healthy state before moving on. The check is that the input appears as running in the input list with no startup errors in the server log. Confirm the exact configuration fields against the input documentation for your Graylog version, since names and defaults can change between releases.
Start with the insecure test configuration
In a non-production network segment, configure a test Collector with the OTLP gRPC exporter pointed at the input and no authentication or TLS. The Graylog documentation shows this unauthenticated setup for testing only, so do not reuse it on a network that other hosts can reach. Set the exporter endpoint to the input's host and port, and keep the Collector configuration in version control so the later production change is a reviewed diff. The check is that the Collector starts without configuration errors and its logs report the exporter as active.
Enable the logs pipeline in the Collector
Confirm the Collector configuration includes a logs pipeline that connects a receiver, such as the OTLP receiver your services send to, to the Graylog exporter. A logs pipeline that lists the exporter but not the receiver, or the reverse, will load without sending data. Validate the file with the Collector's configuration check before restarting the service. The check is that the Collector validates the file and the pipeline appears in its startup output with the logs signal enabled. Verify component names and stability levels in each component's README, because some Collector components are at different maturity levels.
Send a test log and confirm receipt
Emit a single log record from a test service or a sample application instrumented with an OpenTelemetry log SDK, routed through the Collector. Then check the Graylog input's received message counter and search for the test message in Graylog using a distinctive string. Also check the Collector output for successful export messages. If the counter does not move, look first at the endpoint, the port reachability from the Collector host and any firewall rules between them. The check is that the test message is searchable in Graylog and the Collector reports successful exports.
Move to TLS with bearer token authentication
Before any production traffic, switch the input to the TLS with bearer token configuration that the Graylog documentation describes for production. Issue the server certificate from your internal certificate authority, configure the input to present it, and set the token the input will accept. Store the token in your secrets manager rather than in the Collector file. Then update the Collector exporter to trust the certificate authority and send the bearer token in the request metadata. The check is that the Collector reports successful exports over TLS and that a request with a missing or wrong token is rejected by the input.
Confirm routing into the intended stream
Send a test record with the service and environment attributes your routing rules depend on, then confirm it lands in the stream you planned for OpenTelemetry logs rather than the default stream. Open the message in Graylog and check that the mapped fields, such as the message text, severity and resource attributes, appear under the names you expect. Adjust the stream rules or processing pipeline and resend if they do not. The check is that the test message appears in the target stream with its mapped fields visible. Ask your Graylog administrator to confirm the stream rules before production traffic starts.
Record the configuration and retire the test setup
Remove the insecure test exporter from every environment that can reach the input, and record the endpoint, TLS settings, token storage location and the pipeline configuration in your runbook. Confirm the test endpoint is no longer reachable from outside the test segment. Ask whoever owns Graylog operations to add the input's health and received-message metrics to monitoring. The check is that a rejected unauthenticated request is logged, the production exporter shows successful exports, and the runbook names the owner of the token and certificate.
Insecure test setup versus TLS with bearer token in production
The Graylog OpenTelemetry input documentation includes a configuration in which the Collector sends logs to Graylog without TLS and without credentials. Its purpose is to confirm that a service, a Collector pipeline and a Graylog input can connect and that fields arrive in the expected shape. The documentation presents it for testing only, and teams should treat it as scaffolding that is removed later, not as a template to copy forward.
- Traffic is readable on the wire: Without TLS, log bodies, attributes and resource fields cross the network as plain text, including any personal data or secrets a service writes into messages.
- Anyone who can reach the port can write: Without a bearer token, nothing stops another host on the network from sending events that appear to come from a trusted service.
- Test data needs its own destination: Send test logs to a separate index set so they do not mix with production search results or retention settings.
- Test configuration tends to persist: Record the test endpoint, then remove the insecure exporter from every Collector configuration before go-live.
Before acceptance, check that the test Collector file is not the one deployed to production and that the test input is disabled or deleted in Graylog.
For production, the Graylog documentation describes TLS combined with bearer token authentication. TLS protects the channel from eavesdropping and tampering, and the bearer token identifies which senders are allowed to write. Both settings must be configured on the Graylog input and matched in the Collector exporter. Certificates should be issued by the internal certificate authority your organization already trusts, with subject names that match the address the Collector dials.
- Server certificate: Install a certificate on the Graylog OTLP gRPC endpoint and confirm that every Collector host, including gateway Collectors, trusts the issuing chain.
- Client trust settings: Point the exporter's TLS configuration at the correct CA bundle. Disabling certificate verification to make a connection work hides the problem and should be treated as a failed step.
- Token in the exporter: Send the token as an authorization header from the exporter, and load it from a secret store or environment variable so it does not appear in a file kept in version control.
- Scope per sender group: Use a separate token for each environment or group of Collectors, so a leaked token can be revoked without affecting every service.
Verify with a test event that a request with a missing or wrong token is refused and that a Collector on a separate host validates the certificate.
Tokens need a rotation procedure before go-live, because an expired credential can stop log flow without an obvious error in the application. The OpenTelemetry Collector supports authenticator extensions in two directions. They can authenticate incoming connections on receivers, for example with OIDC, and they can add credentials to outgoing exporter requests, for example with the oauth2client extension. Which approach fits depends on how the Graylog input accepts credentials, so confirm that against the current input settings and the Collector configuration documentation.
- Rotation sequence: Create the new token, deploy it to Collectors, confirm that logs still arrive, then revoke the old token. Only use overlapping validity if the Graylog input supports it.
- Inbound checks on gateways: Authenticator extensions on a gateway Collector can validate upstream clients before data reaches the exporter, which helps when many services send through one gateway.
- Automatic credentials: Use oauth2client when the credential is issued by an identity provider and must be refreshed without manual edits.
- Ownership and failure alerts: Assign a named owner to each token and watch Collector and Graylog logs for authentication failures, so an expired token does not silently drop data.
Rehearse a full rotation in a non-production environment and confirm the exact steps your Collector versions need before you run it in production.
How OTel log fields map into Graylog's schema
This table lists the main OpenTelemetry log record fields, what each one carries, and what to confirm in Graylog's OpenTelemetry input before relying on it. Use it as a checklist, since the exact Graylog field names come from the input's documented mapping and your SDK version. The main takeaway is that severity, timestamp and resource attributes drive search, alerting and stream routing, so verify them first with real records.
| OTel log field | What it carries | What to confirm in Graylog |
|---|---|---|
| Body | The log message text or structured value the application emitted | Which Graylog message field holds the body, and whether structured bodies are stored as a single string |
| Severity | Severity text and numeric level set by the logging API | How levels map to Graylog's level field, and what happens to unrecognized values |
| Timestamp | Event time, plus observed time when the SDK or Collector records it | Which timestamp Graylog uses as message time, since collector queuing can shift arrival times |
| Trace and span identifiers | IDs that link a log record to a distributed trace | Whether both IDs are stored as searchable fields and in what format they arrive |
| Resource attributes such as service.name | The emitting service, host, namespace and environment | How resource attributes are named in Graylog, and whether they work in stream rules |
| Log record attributes | Application-defined key-value pairs attached to each record | Whether names are kept, prefixed or nested, since this affects field types and index mapping |
Routing OTel logs into streams with pipelines
Route OTel logs into dedicated streams by matching on fields that the OpenTelemetry input has already mapped into Graylog's schema, such as the service name or selected resource attributes. A stream rule on a field like service_name or a mapped resource attribute sends matching messages to a stream, and each stream points at an index set. Before you build rules, confirm the exact field names the input produces in your Graylog version by sending a test log from a Collector and inspecting the message in search. Do not assume attribute names carry over unchanged from your OpenTelemetry resource definitions.
Processing pipelines sit between ingest and storage. Graylog Open routes data through streams and pipelines, so a pipeline rule can normalize values, drop noisy severities, or add a tag before the message lands in its stream. Use a stream rule when the decision is a simple field match, and use a pipeline when you need to change or enrich the message first. Keep rules that depend on each other in one place so the team can see the order of evaluation and test changes against sample messages from each service.
Stream design also sets storage. Graylog's index model rotates indices by message count, size or time and deletes the oldest indices under retention, so every stream and index set you create carries its own retention window and storage footprint. Give high-volume services such as debug-heavy workloads their own index set with a deliberate retention period, and keep low-volume audit-relevant services on a longer one. Before go-live, confirm the retention settings for each index set, estimate daily ingest per stream from a representative sample, and review whether any stream duplicates data into another stream, since that multiplies storage.
Hardening the OTLP path end to end
An OTLP log path crosses the application, the Collector, the network and the Graylog input, and a weak point in any one of them exposes the whole stream. The cards below cover the controls that connect those hops, from transport encryption and credentials to what the telemetry is allowed to contain. Confirm each option against your Graylog and Collector versions before you rely on it.
Encrypt the gRPC listener with TLS
Production should use the TLS and bearer token configuration that the Graylog OpenTelemetry input documentation describes, not the insecure, unauthenticated setup meant for testing. Decide where certificates come from, who renews them, and whether the Collector verifies the Graylog certificate chain. Check the exact TLS keys the input accepts in your Graylog version, because log data would otherwise cross the network in clear text.
Rotate and store bearer tokens
The bearer token is the only credential that proves a sender is allowed to write logs, so treat it like a service secret. Store it in your secrets manager or a restricted environment variable rather than in a Collector file that others can read, and give each environment or service its own token where the input allows it. Plan a rotation procedure that updates the Collector and Graylog together, and test that the old token stops working.
Restrict source networks
Limit which hosts can reach the gRPC port with firewall rules, security groups or load balancer allow lists, so that only known Collector gateways and agents connect. Keep the Graylog input off public networks where the sources are internal. Document each permitted source, and review the list when services move or new clusters are added, since an open port turns a token leak into a wider exposure.
Keep sensitive data out of log bodies
Logs from applications often carry tokens, email addresses, account numbers or request payloads that should never reach a shared log platform. Remove or redact these fields in the application or in Collector processors before export, and set attribute allow lists where your Collector distribution supports them. Agree with the application owners which fields are permitted, because Graylog stores whatever arrives until retention deletes it.
Apply Collector configuration best practices
The OpenTelemetry security guidance covers Collector settings such as limiting exposed endpoints, avoiding unnecessary receivers, and keeping configuration under version control with review. Run the Collector with the minimum extensions and receivers it needs, and check each component's stability level in its README before you enable it in production. Pin Collector versions and review release notes, since authentication extensions and their options can change between releases.
Use authenticator extensions where needed
Collector authenticator extensions can check incoming connections on receivers and add credentials to outgoing requests, which helps when a gateway forwards logs for several services. Confirm which authenticator your Collector build includes and whether it works with the Graylog input's own token check, because layering both needs a clear owner for each credential. Test rejected and accepted requests in staging before you change production senders.
Common failures when OTel logs stop arriving in Graylog
This table pairs each common symptom of missing OpenTelemetry logs with its likely cause and the first fix to try. Work down the rows in order, since the early checks (endpoint, TLS, token) block everything after them. Confirm each fix against the OpenTelemetry (gRPC) input documentation for your Graylog version before changing production settings.
| Symptom | Likely cause | First fix to try |
|---|---|---|
| No connection errors, no messages | Wrong endpoint or port in the Collector exporter | Match the exporter endpoint to the host and port of the OTel gRPC input, then confirm the port is open between the Collector and Graylog |
| Exporter reports TLS handshake failure | Certificate does not match the hostname the Collector dials | Issue the Graylog certificate for the name in the exporter endpoint, or change the endpoint to a name the certificate covers |
| Exporter reports unauthorized or 401-style errors | Bearer token missing, misspelled or expired | Check the token value and header configuration on both sides, and replace any token that has passed its validity period |
| Exporter reports unknown or unsupported exporter | Collector build lacks the Graylog-compatible exporter | Confirm the build includes the exporter you configured, for example by using a distribution that bundles it, and rebuild if it does not |
| Collector runs but nothing leaves it | Logs pipeline not wired to the exporter | Verify the service section lists the exporter under the logs pipeline, not only the traces or metrics pipelines |
| Messages arrive but searches return nothing | Stream rule routes messages away from the default search view | Check which stream received the messages and review its rules, and confirm the search covers that stream |
| Messages arrive with unfamiliar field names | OTel attribute names differ from the fields your searches expect | Inspect a raw message, map the OTel attributes to your search fields, and update saved searches and dashboards to match |
| Logs appear only after a restart or in bursts | Collector batching or retry settings hide a failing export | Review the Collector logs for retry messages and check the batch and queue settings against the Graylog input documentation |
Questions teams ask before connecting OpenTelemetry to Graylog
How much effort does an OpenTelemetry to Graylog integration take for one service?
For one service, the effort is mostly configuration: an OpenTelemetry Collector pipeline with Graylog as the logs backend, an OTLP gRPC input in Graylog, and a test that confirms records arrive with mapped fields. The Graylog docs show an insecure, unauthenticated setup for testing only, so a single service still needs the TLS and bearer token configuration before it handles real data. Plan one review pass to check field mapping in search results, then confirm that the service's logs land in the intended stream. Most of the time goes to the application's logging setup, which varies by language. Log SDK maturity differs across languages, so check your language on the OpenTelemetry status page before scoping the work.
How much effort does it take to roll this out across a whole fleet?
Across a fleet, the work shifts from configuration to standardization. The first decision is where Collectors run: as an agent beside each service, or as a gateway that accepts data from many sources, as the OpenTelemetry Collector documentation describes. Each choice changes network paths, token handling and the number of places you update when Graylog endpoints or credentials change. Expect to define shared Collector configuration, a token issuance and rotation process, a stream routing scheme and an owner for each application's log fields. Effort grows with the number of teams, languages and environments as well as services. Ask a partner to scope the work from an inventory of your services so the estimate reflects your actual landscape.
What drives the cost of sending OpenTelemetry logs to Graylog?
Cost has four parts: Collector hosting, network, Graylog storage and the Graylog edition. Collector hosting is compute you run, sized by the telemetry each agent or gateway handles. Network cost depends on how much log data crosses your links. Storage is the largest variable: the Graylog system architecture page advises sizing it as daily ingest times retention days times 120 percent. Graylog Open is free with no volume limits and community support. The Graylog pricing page lists Graylog Enterprise from 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units. Ask for quotes that separate one-time setup from recurring licensing, hosting and storage, and confirm the daily ingest figure you are sizing against.
Can our own team connect OpenTelemetry to Graylog without outside help?
A team with Collector experience and Graylog administration skills can build this in-house, since the Graylog docs and OpenTelemetry documentation cover the components. The risk sits in decisions that are easy to get wrong: TLS for OTLP, token lifecycle, field mapping across services and stream routing that controls who can see which logs. Operations also need attention, including Collector upgrades, because the OpenTelemetry Collector releases ship regularly (for example v0.163.0 on October 16, 2026). Check whether you have someone who will own the Collector configuration, the Graylog inputs and the security review after go-live. DeployOpen can plan, implement and document the integration under a fixed scope agreed in writing, or support it afterward through a retainer.
What does the integration need from our side?
Your side needs to provide four things. First, network paths from application hosts or gateways to the Graylog input port or the load balancer in front of Graylog nodes. Second, certificates for TLS, issued from your internal CA or a public CA, with a named renewal owner. Third, a token owner who can rotate bearer tokens and update Collector configuration without an outage. Fourth, application owners who review the mapped fields and agree on which services belong in each stream and how long their logs are kept. Confirm the exact input settings against the Graylog documentation for your version, and review the Collector configuration best practices with your security team before production.
How long does an OpenTelemetry pilot for Graylog usually take?
No researched figure is available for pilot length, so ask any partner for a timeline written from your agreed scope. A pilot is complete when three things are proven: records arrive with the expected fields, access to the stream is controlled, and the service's log volume fits your storage plan. Most of the duration is set outside the integration: change approvals for production paths, certificate issuance lead time, the availability of application owners for review and whether Graylog already runs in production with spare capacity. Set exit criteria before the pilot starts, such as an approved field mapping and a tested token rotation. Measure daily ingest during the pilot, because the storage formula depends on that number.
Do OpenTelemetry logs require a Graylog Enterprise license?
The supplied facts do not state that the OpenTelemetry input requires an Enterprise license, so confirm this with Graylog for the version you plan to run before you commit. Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license, and it ships with inputs such as syslog, GELF and Beats. Graylog Enterprise adds a data lake, a correlation engine and 24/7 support, and the pricing page lists it from 15,000 US dollars per year. Ask Graylog which edition includes the OpenTelemetry input, and check the input list in your installed version. Because SSPL terms govern how Graylog Open can be offered, have your legal team review them if you plan to provide logging as a service to others.
Is the unauthenticated OpenTelemetry configuration acceptable for production?
No. The Graylog docs show an insecure, unauthenticated Collector configuration for testing only, and a TLS with bearer token authentication configuration for production. Use the production pattern from the start so test habits do not carry into live data. The OpenTelemetry Collector can authenticate incoming connections on receivers, for example with OIDC, and add credentials to outgoing exporter requests, for example with the oauth2client extension. Confirm which authentication methods the Graylog input accepts in your version before choosing a design. Keep bearer tokens in a secrets store, scope them to one environment, and record who can rotate them. Review network exposure of the input port as part of the same change.
How DeployOpen scopes and delivers this integration
DeployOpen plans and implements the OpenTelemetry log path inside your own infrastructure, under a fixed scope agreed in writing before work starts. The scope names each piece of the path: the OpenTelemetry Collector configuration on the sending side, the Graylog OpenTelemetry (gRPC) input and its listener, the TLS certificates and bearer token setup, the field mapping into Graylog's schema, and the streams that route OTel logs to the right index sets. Work happens in your cloud accounts, data centers or restricted networks, so the team defines which hosts run the Collector, which network paths open to the Graylog nodes, and who holds the token and certificate material before any configuration is written.
Delivery follows the scope in order. The insecure, unauthenticated configuration in the Graylog docs is used only in a test environment, and the production build moves to TLS with bearer token authentication before real service logs flow. Testing covers sample log records from each instrumented service, confirmation that expected fields land in Graylog's schema, checks that streams capture only the intended sources, and a failure test such as an expired token or a stopped Collector. The handover includes the working configuration files, a short runbook for rotating the token and certificates, and a list of the Collector and Graylog versions the build was tested against, so your team can repeat the steps on its own.
Ongoing support, including Collector upgrades, changes to field mapping as services add new attributes, and periodic review of stream rules, is available as a retainer after handover. Your quote follows from the written scope, so before asking for one, confirm which services and environments are in scope, which Graylog edition and version you run, and who on your side will approve the token and certificate design.
