TCP and UDP Sources in Cribl Stream

Cribl Stream has three socket-based Push sources for data that clients push in directly: TCP (Raw), TCP JSON, and UDP (Raw). The TCP (Raw) Source page and the TCP JSON Source page each describe a Source that ships in the default configuration on a preconfigured port, and the UDP (Raw) Source page describes a connectionless intake aimed at high-velocity telemetry. They share Persistent Queue and Processing settings but differ in framing, security, and positioning.

TCP (Raw)

The TCP (Raw) page is explicit up front: Push type, TLS support yes, Event Breaker support yes, preconfigured on port 10060. Clone it or directly modify it, then enable it. Delete it and Stream re-creates it when defaults are applied again, so disable instead. General Settings: Input ID, Description, Address, Port. Enable header lets each new connection carry a header record with an authToken and a fields object added to every event. Authentication method is Manual (enter or Generate a token) or Secret (a text secret, Create link); with the token empty, unauthorized access is permitted.

Every new connection may start with that header line, then data. The TCP (Raw) page shows this sample payload (on-prem), with the token redacted:

{"authToken":"<your-token>", "fields": {"region": "us-east-1", "AZ":"az1"}}

this is event number 1
this is event number 2

Processing is where the Event Breaker support lands: rulesets default to the System Default Rule, and a buffer timeout (10 ms minimum, 10000 ms default, 43200000 ms maximum) sets how long the breaker waits before flushing a channel to the Routes as-is. Custom Command (off by default), Fields, Auto parse, and a Pipeline or Pack sit alongside.

Advanced Settings: Enable proxy protocol (when on, __srcIpPort shows the original sender), IP allowlist regex (default .*), Active connection limit (1000 per Worker Process, 0 for unlimited), socket idle and max lifespan timeouts (0, disabled), forced socket termination (30 seconds). All three pages share a Persistent Queue section: off by default, Always On mode, a 1MB bytes-based buffer limit (replacing the event-based one as of version 4.18.0), a 5 GB queue size limit, and queue-full behavior that blocks or drops events. The two TCP pages share a server-side TLS section (off by default, with mutual auth options and version bounds); Cribl.Cloud offers Cribl-provided certificates.

TCP JSON

The TCP JSON page describes a Source for newline-delimited JSON over TCP: Push type, TLS support yes, no Event Breaker support. It sits in the default configuration like the Raw Source, preconfigured on port 10070, its Input ID prefilled with in_tcp_json, not changeable via the UI.

Framing is where the two TCP Sources differ. Cribl Stream expects newline-delimited JSON: a header line first, optional when no auth token is set; with a token enabled, the header carries it as authToken. Common fields under fields in the header are added to all events automatically; each following line is one JSON event. The TCP JSON page shows this sample, token redacted:

{"authToken":"<your-token>", "fields": {"region": "us-east-1", "AZ":"az1"}}

{"_raw":"this is a sample event ", "host":"myHost", "source":"mySource", "fieldA":"valueA", "fieldB":"valueB"}
{"host":"myOtherHost", "source":"myOtherSource", "_raw": "{\"message\":\"Something informative happened\", \"severity\":\"INFO\"}"}

Authentication here is its own section: the method dropdown offers Manual (default), the shared secret clients send in the authToken header field, with a Generate link, or Secret, a stored secret from the internal secrets manager or, when enabled, an external KMS; a blank value again permits unauthorized access. Test: cat test.json | nc <myCriblHost> 10001 against a Source on port 10001.

Advanced Settings overlap the Raw Source, then add Enable load balancing (Cribl Stream only): an extra Worker Process (wLB) spreads connection data across multiple Worker Processes, and the page warns that with it enabled, common fields in the JSON header are no longer supported. Routed to a Splunk Destination, _time, host, and source map to their Splunk fields, _raw becomes the event body, and other fields become index-time fields. The page also notes per-minute metrics logging to metrics.log (Worker Process X Metrics on the Logs tab).

UDP (Raw)

The UDP (Raw) page lists its constraints in one line: Push type, TLS support no, Event Breaker support no. It ingests unparsed, asynchronous data streams over a connectionless protocol, positioned for high-velocity telemetry where low latency is prioritized over guaranteed delivery, or where TCP handshake overhead would hurt performance. The page says to treat the Source as a fallback for non-standard data: for common network telemetry, the Syslog, NetFlow and IPFIX, or SNMP Trap Sources come first.

General Settings: Input ID, Description, Address (for example localhost, 0.0.0.0, ::), Port. The UDP-specific knobs sit in Advanced Settings: Single msg per UDP (on: the message is one event; off, the default: break on newlines), Ingest raw bytes (adds a __rawBytes field with the message bytes), IP allowlist regex (default .*), Buffer size limit (events) (in-memory buffering when downstream blocks, 1000 events default), and UDP socket buffer size (bytes), which sets the SO_RCVBUF kernel buffer (blank: OS default) and affects OS memory.

Reliability is where the docs are bluntest. Nothing in UDP guarantees delivery: the page's cloud note says large event rates can make Cribl.Cloud drop data, a UDP protocol restriction, and recommends a customer-managed hybrid Worker Group close to the sender plus OS UDP buffer tuning. Better practices: adding Worker Processes to a Worker Node does not linearly improve UDP performance, and excessive counts under high stress cause kernel-level socket contention (elevated ksoftirqd CPU). The page calls 2-3 Worker Nodes with fewer than 10 Worker Processes per Node a stable balance for many environments, and says to isolate high-volume UDP in a dedicated Worker Group.

Each received message becomes an event with _raw (UTF-8 of the message), _time (Unix seconds), source in the form udp|<remote IP address>|<remote port>, and host. The tuning section points at the kernel buffer: check sysctl net.core.rmem_max (a typical value around 200 KB is too small for a moderately busy Syslog server) and netstat -su, where any nonzero packet receive errors count means lost events. The UDP (Raw) page fixes it by raising both buffer settings to 26214400, its notation for 25 MB:

$ sysctl -w net.core.rmem_max=26214400
net.core.rmem_max = 26214400
$ sysctl -w net.core.rmem_default=26214400
net.core.rmem_default = 26214400

The same two lines belong in /etc/sysctl.conf for reboots; also watch the Status tab for dropped messages and Worker process memory.

Choosing a source

All three document the same base: Push intake, General Settings, Tags, Persistent Queue, Processing, Connected Destinations via Routes or QuickConnect. The stated differences:

• Delivery. The TCP Sources carry connection limits (1000 default), socket timeouts, and backpressure; the UDP page states the other trade: low latency over guaranteed delivery.
• Framing. Raw TCP input is broken by the Event Breaker, the only one of the three with that support, with an optional per-connection header record; TCP JSON is line-delimited JSON with an optional header for auth and common fields; UDP frames by message or by newline.
• Security. Both TCP pages document server-side TLS, Manual or Secret authentication, and mutual auth; the UDP page documents no TLS and no authentication setting.
• Defaults. TCP (Raw) and TCP JSON ship preconfigured on ports 10060 and 10070; the UDP page states none.

What the docs flag

• Both TCP Sources sit in the default configuration; delete one and Stream re-creates it, so disable rather than delete.
• A blank auth token or secret permits unauthorized access, on both TCP pages.
• Selecting TLSv1 or TLSv1.1 as the minimum TLS version shows a deprecation warning.
• Smart persistent queue mode is deprecated for hybrid and on-prem, migrating to Always On in January 2027; on Cribl-managed Cloud Workers (with an Enterprise plan) only the toggle is exposed, at a fixed 1 GB.
• The bytes-based buffer size limit replaced the event-based one as of version 4.18.0.
• TCP JSON: enabling load balancing stops common fields in the JSON header from working.
• UDP: high event rates can make Cribl.Cloud drop data (a UDP protocol limit), and the typical 200 KB kernel buffer is too small for a moderately busy Syslog server.

Frequently asked questions

What port does the default TCP (Raw) Source in Cribl Stream listen on?

The default TCP (Raw) Source in Cribl Stream is preconfigured to listen on port 10060, and you can clone it or modify it directly and then enable it. The TCP JSON Source ships preconfigured on port 10070 the same way.

Does the UDP (Raw) Source in Cribl Stream support TLS?

No. The UDP (Raw) Source page lists TLS support as NO, while the TCP (Raw) and TCP JSON pages list TLS support as YES. The UDP page also documents no authentication setting.

How is data framed on the TCP JSON Source in Cribl Stream?

It is newline-delimited JSON: a header line first, optional when no auth token is set, then one JSON event per line. The header carries the authToken when a token is enabled, and common fields under the fields object are added to every event.

When does the Cribl docs recommend the UDP (Raw) Source in Cribl Stream?

The docs position it for high-velocity telemetry where low latency is prioritized over guaranteed delivery, or where TCP handshake overhead would hurt performance, and say to treat it as a fallback. For common network telemetry, the Syslog, NetFlow and IPFIX, or SNMP Trap Sources come first.