Praxis Gateway collector
Use a Praxis Gateway collector when you want a single point in your network to aggregate telemetry, apply org-wide policy once, and simplify outbound paths and export credentials to your data destinations (for example Google SecOps (Chronicle), GCS, or any destination in your pipeline).
You define pipelines in the Praxis management plane: that is where you control configuration and use insights for operations. The management plane is not a destination for pipeline export—telemetry is sent to the destinations you attach in the graph (for example SecOps, object storage, or another OTLP export).
What you are deploying
A Praxis Gateway collector is not a different product. It is a standard Praxis collector (praxis-collector) with a Praxis Gateway pipeline you define in the Praxis management plane:
- Praxis collectors that send to the Praxis Gateway use an OTLP destination aimed at the Praxis Gateway collector.
- The Praxis Gateway collector exposes an OTLP source, runs processors, and exports to the data destinations you attach in that pipeline (for example SecOps, GCS, or object storage—not the Praxis management plane, which is for configuration and insights).
OTLP (OpenTelemetry Protocol) is the gRPC/HTTP path Praxis uses for collector-to-collector transfer. A Praxis Gateway design gives you a single trusted egress tier for telemetry, a practical place to keep export-related credentials, and one layer of shared processors (for example masking, routing, or sampling) before data leaves your network.
On the same host you can add more Praxis sources—syslog, TCP, or UDP—so appliances and legacy senders can use the same Praxis Gateway collector as your Praxis fleet without all running a collector.
:::tip Same collector everywhere
A Praxis Gateway collector runs the same praxis-collector build you install on other systems. Praxis Gateway describes network role and how you connect sources and destinations, not a separate installer or SKU.
:::
When a Praxis Gateway helps
| If you need… | A Praxis Gateway collector is useful because… |
|---|---|
| Tighter control of outbound access | One (or a small HA pool) of Praxis Gateway collector hosts can forward telemetry to your export destinations (for example SecOps, GCS) instead of every node doing so |
| To concentrate secrets and export configuration | API keys, mTLS material, and SecOps configuration can sit on the Praxis Gateway tier instead of every node |
| One place for org-wide policy (PII, routing, sampling) | Processors on the Praxis Gateway collector can run after all ingress paths you attached to that pipeline |
| Ingest from appliances and syslog | Non-OTLP listeners (syslog, TCP, UDP) can share the same Praxis Gateway collector with OTLP |
| To keep existing Fluent Bit, Fluentd, or other OTLP forwarders | Their OTLP output can use the same OTLP source you use for Praxis-to-Praxis forwarding |
Without a Praxis Gateway deployment, every host that sends telemetry directly to your export destinations often needs its own outbound paths, TLS configuration, and destination credentials. Collectors also connect to the Praxis management plane to receive pipeline configuration and to use insights—that control path is separate from the destinations (SecOps, storage, and so on) you choose in the pipeline for where telemetry is exported.
With a Praxis Gateway, you usually concentrate outbound telemetry through one (or a small HA pool) of Praxis Gateway collector hosts to your export destinations. Praxis collectors that send to the Praxis Gateway use a well-known internal address and OTLP (TLS recommended on those hops). Local collection still runs on each collector; each exports to the Praxis Gateway collector’s OTLP source, and the Praxis Gateway collector exports to the data destinations you configured in the Praxis management plane (the UI where you define the graph—not a destination for bulk telemetry in that graph).
Reference architecture
Telemetry path: several Praxis collectors (and optionally other OTLP senders) → one Praxis Gateway collector → your export destinations (for example SecOps, GCS, object storage). You define that graph in the Praxis management plane; the management plane is not itself a place where bulk telemetry is exported as a pipeline destination.
Configuration and insights (separate from export): the Praxis management plane is where you author pipelines, view health, and use operational insights for collectors and destinations—it does not appear as a bulk telemetry export in the diagram above.
Inside the Praxis Gateway collector, the data path matches any other Praxis pipeline that has an OTLP source to accept data from other collectors:
- Collectors in your environment run the sources and processors you need for each host or cluster.
- They use an OTLP destination aimed at the Praxis Gateway collector (gRPC or HTTP), instead of every node opening outbound to public or shared targets directly—if that matches your network and security design.
- The Praxis Gateway pipeline runs shared processors and exports to the destinations you set on that pipeline.
You can add more sources and destinations to the same Praxis Gateway collector over time. It remains a normal Praxis pipeline on a normal praxis-collector.
More than OTLP: syslog, TCP, and UDP
In production a Praxis Gateway collector often accepts more than Praxis-to-Praxis OTLP:
- OTLP — Praxis collectors (primary) and, if you use them, OpenTelemetry-style or Fluent Bit OpenTelemetry senders
- Syslog — infrastructure and network devices, or services that only speak syslog
- TCP and UDP — line-based or framed payloads your integration supports
Typical pattern (several kinds of ingress, one place you control export):
This is a common way to get one listener tier for parsing, redaction, and export in a VPC or on a DMZ edge.
Use cases (summary)
| Use case | What your team gets | Notes (high level) |
|---|---|---|
| Egress and compliance | Fewer hosts with direct telemetry outbound to the internet or SaaS | OTLP into the Praxis Gateway collector; then export to SecOps, GCS, and other targets (you define those destinations in the Praxis management plane) |
| Secret handling | Fewer long-lived keys for export on end nodes | Store destination secrets in your vault or as your process allows; the Praxis management plane is where you control pipeline and destination configuration and see insights—it is not a telemetry export target |
| Appliances and syslog | No need for a collector on every device | Syslog, UDP, TCP on the Praxis Gateway collector; normalize in processors |
| Fluent Bit / Fluentd | Keep your current forwarders | OTLP to the Praxis Gateway collector, or syslog/TCP to Praxis sources per your integration |
| DMZ or hybrid | Clear boundary between untrusted and trusted sides | Place the Praxis Gateway collector in the DMZ; run export to destinations your org approves (for example SecOps or private links to storage) |
| Org-wide policy | One place for PII, sampling, and routing | Processors on the Praxis Gateway collector apply across all sources on that pipeline |
| Kubernetes | In-cluster collectors to a Service; only Praxis Gateway hosts need full egress | LoadBalancer or ClusterIP; mTLS or bearer on OTLP as you design |
| Migration | Phased move into Praxis | Steer traffic to the Praxis Gateway collector, dual export, then cut over |
This does not require a different collector build—only network placement and pipeline configuration in the Praxis management plane.
When to install a Praxis Gateway collector—and when to skip it
Consider a Praxis Gateway collector if you have many Praxis collectors and need one controlled telemetry egress path; you need syslog, TCP, or UDP from systems that will not run Praxis; you use Fluent Bit, Fluentd, or an OTLP-capable tool and you want the Praxis Gateway—not every node—to hold export and cloud credentials; you want central TLS to a well-known internal endpoint; or you want shared processors before data leaves the VPC. You still use the Praxis management plane to define pipelines and see insights; that is separate from which hosts send data to SecOps and your other destinations.
You may not need a dedicated Praxis Gateway if you do not need a shared aggregation tier for telemetry, you accept per-node export to your destinations with your security model, and management-plane connectivity to collectors for configuration is sufficient. The Praxis management plane remains where you configure pipelines; it is not an export destination for bulk telemetry in the data path.
Interoperability
Everything a Praxis Gateway pipeline can receive—OTLP (logs, metrics, traces), syslog, TCP, UDP, and so on—uses the same processor and destination model as any other Praxis pipeline. Praxis-to-Praxis forwarding is the first-class path via the OTLP destination and OTLP source you configure. Other products that send OTLP to the same listener are optional; they do not change what Praxis Gateway means for your own collectors.
Next steps
- Configuration — Connect sending collectors to the Praxis Gateway collector, TLS, mTLS, and bearer token patterns
- TLS and certificates — Create lab-style CAs and certificates with OpenSSL if you have no org PKI guide yet
- OTLP source and OTLP destination — Full field reference
- Syslog, TCP, UDP — When the Praxis Gateway collector is not only OTLP