FAQ
Last updated on
General
What is the Telemetry Router?
The STACKIT Telemetry Router and its components are used to ingest and distribute telemetry data. A Telemetry Link connects the Telemetry Router with your cloud resources to automatically capture standardized data streams. You have full control to forward this unified data stream to internal STACKIT services or external destinations compatible with OpenTelemetry or S3.
For step-by-step setup instructions, see Create and manage Telemetry Router instances.
Why is it called "Telemetry Router" if it currently only handles Audit Logs?
The name reflects the product’s long-term direction. While the current release handles Audit Logs exclusively, the Telemetry Router is designed to support additional observability signals, such as service logs and metrics, in future releases.
What's the difference between a Telemetry Router and a Telemetry Link?
The Telemetry Router is the component that receives, filters, and forwards telemetry data. It’s self-manageable, and ingesting data at its endpoint requires its own access token.
The Telemetry Link is what connects the Router to your cloud resources at a given hierarchy level (organization, folder, or project) and captures the data stream. A Link requires an existing Router’s ID and access token to be configured.
Telemetry Links are obligatory to redirect logs to your Telemetry Router in any case. A single router does not ensure that STACKIT internal logs are routed to the configured destinations.
Can a Telemetry Router be created at the folder or organization level?
No. Due to technical limitations, a Telemetry Router must always be created within a project. To capture data at the folder or organization level as well, create separate Telemetry Links at those levels, all pointing to the same Router in a project.
What data formats and protocols does the Telemetry Router support?
The Telemetry Router supports two destination types: an OpenTelemetry Protocol (OTLP)-compatible endpoint, or an S3-compatible destination such as STACKIT Object Storage. Make sure your target destination or integration scripts are compatible with one of these.
Where can I send my audit data with the Telemetry Router?
The Telemetry Router offers flexible routing. You can send audit data to STACKIT services (such as Observability, Logs, or Object Storage) or to external destinations (such as your own SIEM tooling or third-party storage), giving you full control over where your data ends up.
What format do Telemetry Router access tokens use?
Access tokens are JSON Web Tokens (JWT), required to interact with a Telemetry Router’s endpoint.
Architecture and Setup
Should I use one central Telemetry Router, or set up a router per project?
We recommend a single, central Telemetry Router in a core project, fed by Telemetry Links from your other projects. You don’t need a router per project. Two things to keep in mind:
- A Telemetry Link can only target a Router in the same region. If you operate across multiple regions, you’ll need one Router per region.
- Links don’t inherit across hierarchy levels: each Link only captures data for its own level (organization, folder, or project). To capture everything across your organization, you’ll need a Link at each relevant level, all pointing to the same central Router.
Can I create more than one Telemetry Link for the same organization, folder, or project?
No. Each hierarchy object can only be connected to one Telemetry Router at a time. This is enforced consistently across the Portal, the API, and Terraform (provider v0.105.0 and later). Creating a duplicate always results in a clear error.
Does the Telemetry Router support traces and metrics, or only logs?
Currently, only logs are supported, specifically internal audit logs. Trace and metric forwarding, including converting traces into metrics through connectors like the OpenTelemetry SpanMetrics connector, isn’t available yet.
Can I add, rename, or transform labels and attributes on audit logs at the Router or Link level?
No. Audit logs are emitted in a fixed OpenTelemetry schema and can’t be relabeled at the Router or Link level. The only configurable processing available is a Filter, which lets you include or exclude records by matching attributes at the resource, scope, or logRecord level. This controls what gets forwarded, not how it’s labeled. Filter expressions use the
=(matches) or!=(excludes) operator against a literal array of string values, not regular expressions. If you need relabeling, apply it downstream at your destination (e.g. Splunk, Elasticsearch).Data Coverage and Privacy
Why don't I see audit events for logins, IAM changes, or other STACKIT services at my destination?
Not all STACKIT services emit audit events to the Telemetry Router yet. Coverage is added per service as each one reaches General Availability (GA); services still in preview won’t appear. See the current list of integrated services in the Audit Log documentation.
Does the Telemetry Router log Object Storage (S3) data access, such as GET/PUT requests?
Not yet. It logs Object Storage Management API operations, for example the creation of S3 credentials, but not data plane requests themselves (GET/PUT on objects). Support for this is planned for a future release. If your security concept requires an audit trail of uploads and downloads, implement that logging in your own application in the meantime.
Why don't Service Account create/delete events show the initiator's email, unlike sign-in events?
This is intentional. Sign-in events include the
stackit.initiator.emailattribute, but Service Account lifecycle events omit direct personal identifiers for privacy and data-obfuscation reasons; you’ll see thestackit.initiatorUUID instead. Email-based correlation for SIEM purposes is tracked as a feature request for a future release.Destinations and Configuration
Can I send data to multiple destinations from a single Telemetry Router?
Yes. You can configure multiple destinations per Router, each set up independently as either OTLP or S3. Data captured by the Router is forwarded to all configured destinations in parallel, not just one.
What authentication methods are supported for OTLP destinations?
The Telemetry Router supports either Basic Auth or Token Auth (bearer token), depending on what your destination endpoint requires.
How do I configure a destination that forwards logs to a STACKIT Observability instance?
You’ll need the Observability instance’s OTLP ingest URL and credentials, both available in the Portal:
- URL: Observability → [select your instance] → API → Information → OTLP Ingest (logs must be enabled on that instance)
- Credentials: Observability → [select your instance] → API → Credentials → Create Credentials
What URL path should I use when configuring a custom OTLP destination?
The destination URI must include the full OTLP-compliant path for logs, ending in
/v1/logs(e.g.https://your-endpoint.example.com/v1/logs). Unlike an OTLP Collector, the Telemetry Router doesn’t automatically append this path, so you need to include it explicitly.Can I use a self-signed TLS certificate for a custom OTLP destination?
No. Destination endpoints must present a TLS certificate signed by a recognized, well-known public Certificate Authority (e.g. Let’s Encrypt). Self-signed certificates aren’t supported. If your endpoint uses one, logs will silently fail to be delivered.
Can I customize the outbound request to a destination, for example by adding custom HTTP headers?
No. Neither of the two supported destination types, OTLP or S3, allows custom headers or request modifications. If your target requires one, for example a vendor-specific API key header, route through an intermediate OpenTelemetry Collector or your destination’s own HTTP source to remap it first.
Networking
How can I find the outbound IP addresses used by the Telemetry Router (for whitelisting or ACLs)?
The outbound IP range can change depending on the clusters we deploy, regardless of your destination type. Instead of hard-coding specific addresses, we recommend retrieving the current STACKIT public IP ranges:
stackit curl https://iaas.api.stackit.cloud/v2/networks/public-ip-rangesIf you’d rather not call the API, our currently active ranges are:
- EU01:
188.34.68.97/32,188.34.92.238/32 - EU02:
45.137.173.48/32,45.137.172.30/32
These ranges can change if new clusters are spawned. If you’re using them directly instead of the API, please update your ACLs accordingly.
- EU01:
Troubleshooting
Why does creating a Telemetry Link or Destination sometimes fail without a clear error?
Before creating the resource, the API validates that your configured values (endpoint, ACL, etc.) actually allow access to the target system. If access isn’t possible (for example, a network or IP restriction is blocking the connection), creation is rejected. Check that your destination’s access controls allow traffic from the Telemetry Router before creating the Link.
I've set up an Object Storage destination, but no logs are arriving in my bucket. What should I check?
Two common causes:
-
Wrong Router reference: your Telemetry Link must reference the correct Telemetry Router ID. Double-check it exists (both EU01 and EU02, if applicable).
-
Incorrect endpoint format: use the generic Object Storage host without the bucket name embedded, for example
https://object.storage.eu01.onstackit.cloud, rather thanhttps://<bucketName>.object.storage.eu01.onstackit.cloud. Specify the bucket name in its own dedicated field instead.
How do I query and filter Telemetry Router audit logs in Grafana Loki?
Make sure your destination uses the full Observability ingestion path rather than a shortened URI. An incomplete path can cause logs to be silently dropped, even if the pipeline shows as “ACTIVE”.
Since attributes are provided at the log level rather than as standard Loki labels, your query needs to fetch all logs and parse them as JSON before filtering. For example:
{service_name=~".+"} | json | service_name_extracted="telemetry-router"or filter by visibility:
{service_name=~".+"} | json | stackit_visibility="PUBLIC"Note that not all STACKIT services are integrated with the Telemetry Router yet, so there won’t be full 1:1 parity with all audit events.
-