Listening collection

Sending data into the platform without an agent — the server listens on a port (HTTP, TCP, UDP, FTP/SFTP) and anything that can push to that port gets indexed. This is the server-side counterpart to agent collection, and it is the answer for devices and systems that cannot run the agent: network gear that can only send syslog, applications that can only POST, FTP drops from external processes.

The server-side surface

Listening Collection lists the server-side tasks. Configure → Data Collection → Global Settings (the server-side global settings) turns each listener on and off and sets its port:

listener	where the port is set	what it does
HTTP	one global port, shared by every HTTP task	receives data POSTed to a URL
TCP	per task	receives a TCP stream on a port
UDP	per task	receives UDP datagrams on a port
FTP / SFTP	per task	pulls files from an FTP/SFTP server

HTTP is the one protocol with a global port: every HTTP listener task shares it, and the tasks are told apart by their request path. TCP and UDP tasks each bind their own port, so the port is part of the task, not a global setting.

There is no default port. The global HTTP setting ships with the port empty, and the listener will not start until you set one. (8091 appears in the API examples, so it is a common choice, but nothing defaults to it.)

Every listener is off by default — a collection task cannot use a listener until its global setting is enabled. Create a task under Configure → Data Collection → + New, and pick the server-side data source for the protocol.

HTTP collection

An HTTP listener is a URL on the platform. Anything that can send an HTTP request can index data through it, which is what makes it the lowest-friction ingest path — no agent, no SDK.

Create (server-side HTTP): name (also the request path), description, whether to use token authentication, the source type, the repo, and the data-source origin (default http:<token>). On completion the task gives a URL and a curl command example to test with.

Send data:

curl -XPOST http://<host>:<port>/<task-name>?sourcetype=nginx  -d '<lines>'

<port> is the global HTTP port you configured; <task-name> is the request path (the task name).
Query params can carry the built-in fields origin, host, sourcetype, repo per request. Each one overrides the task’s own setting for that request, and the task’s setting in turn overrides the global one — so a single listener can route to several indexes.
Any other query parameter becomes a tag on the events from that request, which is a cheap way to label a batch at the point of sending.
The body is the data — line-separated text.
The response reports what was accepted: {"total":2,"success":2,"failure":0,"details":[]}.

The task management list filters by HTTP to show all HTTP listeners with their basic info, running status, and traffic statistics; disable, edit, authorize.

TCP / UDP collection

A port listener for streams that cannot speak HTTP — the usual use is syslog forwarding and other network-gear output.

Create: port number, protocol (TCP or UDP), source type, repo, data-source origin (default tcp:<port> / udp:<port>), optional hostname, and an optional domain-name limit restricting which hosts may connect (blank = any host on the port).

TCP is the default recommendation over UDP: UDP provides no grouping, ordering or delivery guarantee, so logs pushed over UDP can be lost without any indication. Use TCP where the source supports it.

The task list filters by TCP/UDP; each task shows basic info, status, and traffic statistics.

FTP / SFTP collection

Pulls files from an external server on a schedule — the FTP task runs on the platform, connects to the server, and reads the files at the configured folder path.

Create: name, description, server address and port, folder path, username/password, and an SSH toggle — off by default, enabling it switches the task to SFTP on port 22.