Key Capabilities
Why teams choose DataStream for OpenTelemetry
Six capabilities put a secure pipeline between your OpenTelemetry sources and every backend, with no change to your instrumentation.
Native OTLP ingestion
OTLP/gRPC on port 4317 and OTLP/HTTP on port 4318 run side by side, for logs, metrics and traces. Point your exporters at DataStream and keep the rest of your setup. Exporters work with their default settings.
Secure, multi-tenant endpoint
TLS, mutual TLS, basic and bearer authentication, and source-IP access lists. Tokens can expire and map each sender to a tenant.
Less data before your platform bills it
Start from ready-made rules or write your own. Drop low-severity logs, remove unused metric labels and cap series, and sample traces whole, keeping every trace with an error or a slow span.
Metrics in the shape each backend expects
Cumulative counters become deltas for Dynatrace, and deltas become cumulative for Prometheus remote write, with no extra step in your pipeline. Log counts and sums can go out as metrics too.
Multi-destination routing
Split one stream by signal, tenant or attribute: traces and metrics to your observability platform, logs to your SIEM and data lake, each in the schema it expects.
OTLP out to any backend
Deliver to an OpenTelemetry Collector, Grafana Alloy, a vendor endpoint or another DataStream instance, with ready-made targets for Grafana Cloud, Datadog, Dynatrace, New Relic, Prometheus remote write and more.
ARCHITECTURE
How DataStream works
A staged pipeline sits between your OpenTelemetry sources and your backends. Your SDKs and Collectors stay in place, and their OTLP exporters point at DataStream.
Ingest
OTLP/gRPC and OTLP/HTTP from SDKs, Collectors, Grafana Alloy and edge collectors, next to syslog and your other sources.
Decode & expand
Each export request becomes individual records, one per log record, metric data point and span, with resource and scope kept.
Enrich & tag
Add environment, team or tenant context to every record.
Filter & optimize
Drop low-severity logs and unused metric labels, and sample traces, with ready-made or custom rules.
Route & deliver
Send each signal where it belongs: your observability platform, your SIEM, your data lake or your own storage.
OTLP receiver
- OTLP/gRPC (4317) and OTLP/HTTP (4318), side by side
- Logs, metrics and traces, each switchable
- Protobuf or JSON; gzip, zstd, snappy and lz4
- TLS and mutual TLS
- Basic and bearer authentication
- Source-IP access lists, expiring and per-tenant tokens
OTLP sender
- HTTP or gRPC; protobuf, or JSON over HTTP; gzip
- Grafana Cloud, Datadog, Dynatrace, New Relic, Splunk Observability Cloud and more, each with the signals it accepts
- Prometheus remote write, including Amazon Managed Service for Prometheus and Azure Monitor
- Cumulative-to-delta and delta-to-cumulative conversion
- Custom headers, TLS and mutual TLS
- Batching, retries and queueing
Deployment options
- Linux and Windows, on physical or virtual servers
- Docker and Kubernetes
- Azure Container Instances and Container Apps
- VMware, Hyper-V, KVM, AWS, Azure and GCP
- Clusters for redundancy and load sharing
Built for enterprise challenges
Observability bills that grow with your data
Observability platforms bill by log volume, metric series or data points, and trace volume or host count. DataStream cuts that volume before it reaches the platform, by rules you try on sample data first.
Separate collection for DevOps and security
DevOps and security teams often collect the same sources twice. With DataStream, one OTLP stream feeds both: traces and metrics to your observability platform, logs to your SIEM.
One OTLP gateway for many teams or customers
Each team or customer sends with its own bearer token or from its own IP range. DataStream tags each record with its tenant and can route it to that tenant’s destination.
Changing backends without re-instrumenting
Move between observability platforms and self-hosted Collectors by changing a target. Your SDKs keep sending OTLP to DataStream, and each platform gets metrics in the temporality it expects.
ROI & SAVINGS
Measurable impact on your OpenTelemetry infrastructure
DataStream handles more OpenTelemetry data on the same hardware and sends less of it to your platform. Throughput comes from PipeBench, our open benchmark.
OTLP/HTTP events per second on a 16-vCPU host
Nearly 10 times the throughput on the same host, with no data loss.
OpenTelemetry data sent to your platform
Up to 60% less OpenTelemetry data in our tests, with the ready-made rules on.
COMPARISON
VirtualMetric vs. Alternatives
How does DataStream compare to other pipelines for OpenTelemetry data?
|
Cribl Stream
|
Bindplane
|
VirtualMetric DataStream
|
OTel Collector
|
|
|---|---|---|---|---|
| OTLP in over gRPC and HTTP | One Source per transport |
Both on one source |
gRPC and HTTP together |
Both on one receiver |
| OTLP out encoding | Protobuf | Protobuf (JSON not documented) | Protobuf or JSON | Protobuf or JSON |
| Managed from a web console | No; YAML files, or a third-party OpAMP server | |||
| Tenant per sender at ingest | Per token |
Partial, via config | Per token or source IP |
Partial, via config |
| SIEM targets: Sentinel, Splunk, SecOps, Elastic | Splunk and Elastic | |||
| Ready-made Grafana Cloud, Dynatrace and Prometheus targets | Prometheus only; others via generic OTLP |
Frequently asked questions
Do I need to replace my OpenTelemetry Collector?
No. Keep your SDKs and Collectors and point their OTLP exporters at DataStream. DataStream can also forward to an existing Collector or Grafana Alloy, so it works in front of or behind the tools you run today.
Do you drop data by default?
No. With no rules, OpenTelemetry data reaches an OTLP target unchanged. Some destinations set their own limits: a platform whose intake takes only metrics and traces doesn’t receive logs, Prometheus remote write takes only metrics and drops exponential histograms and series beyond its cap, and some targets drop a record over the platform’s size limit.
Can I keep a full copy of my OpenTelemetry data?
Yes. Storage targets write every log record, metric data point and span to object storage such as Amazon S3, Azure Blob Storage or Google Cloud Storage, as JSON, Avro or Parquet. Your observability platform gets the reduced stream.
What happens if our observability platform goes down?
Data waits in a queue, and delivery resumes on its own when the platform is back. With persistent storage, the queue sits on disk and survives a restart. Queued data is kept for 48 hours by default. The Health tab in DataStream shows delivery errors, queue depth and delivery lag for every route.
Can DataStream turn non-OpenTelemetry data into OTLP?
Yes. Syslog and other sources go out as OTLP logs, with the original message as the body. Metric devices can send their readings as OTLP metrics, one data point per reading.
How do I set up DataStream for OpenTelemetry?
Add an OTLP listener to your DataStream deployment, point your exporters at it, attach a pipeline and a route, then add a target: OTLP, Grafana Cloud, Datadog, Dynatrace, New Relic, Prometheus remote write and more. The OTLP device and OTLP target docs cover every setting.
Talk to our experts
Book a technical session with our engineers to map DataStream onto your OpenTelemetry setup.
Try DataStream
Send your first OTLP stream through DataStream and route each signal where it belongs.
Try now