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. Data Collection → Listener Tasks → 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
SFTP / FTPS / FTP	per task	pulls files from an external file 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 Data Collection → Listener Tasks → Create, 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.

The token is shown once. With token authentication on, the create dialog shows the listener’s token; copy it then. The list and the edit form never show it again, and the curl example names it as <token> for you to fill in. Senders pass it in a TOKEN header. Editing a listener keeps its token. To replace it, use the row’s Rotate token action: it shows the new token once, and the old one stops working immediately.

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.

SFTP / FTPS / FTP collection

The one listener that pulls. The task runs on the platform, connects out to a file server on a schedule, and reads whatever is new in the configured folder — it tracks the last file it saw, so a folder that keeps growing is not re-read from the start.

Create: name, description, server address and port, folder path, username and password, and a Transport:

transport	what it uses	when to pick it
SFTP (over SSH)	file transfer over SSH, usually port 22	the default, and the right answer unless the server cannot do it
FTPS (FTP over TLS)	FTP with explicit TLS (`AUTH TLS`), usually port 21	the server speaks FTP but supports TLS
FTP (unencrypted)	plain FTP	only when the server offers nothing else

Plain FTP sends the username, password and file contents in the clear. It is kept because legacy drops are real — appliance and mainframe exports that cannot be changed — but it is the last choice, and the form says so. FTPS protects both the control channel and the data channel, so the files themselves are encrypted in transit, not just the login.

The transport is fixed when the task is created. Changing it means creating a new task: a collection that silently switched transport under you would be a different thing wearing the same name.

Verify server

Encryption hides the traffic; it does not prove who answered. Verify server is the check that does, and it is on by default for new tasks:

FTPS must present a certificate signed by an authority the platform trusts, and that certificate must match the address you typed. A self-signed certificate is refused.
SFTP records the host key the first time it connects and refuses any later connection whose key has changed. That is what ssh itself does.

Turn it off only for a server you trust that cannot satisfy the check — an internal FTPS host with a self-signed certificate is the usual case. With it off, the connection is still encrypted; what you lose is the guarantee that the encryption goes to the right machine rather than to something in between.

Unlike the transport, this can be changed after the task exists, so a task created before the setting existed can be hardened without recreating it. Those tasks have it off: turning it on for them automatically would have broken every collection pointed at a self-signed server.

When an SFTP server’s key legitimately changes — its administrators rebuilt it or rotated its host key — collection stops, and the server log says the key no longer matches the one recorded. Once you have confirmed the change is theirs, edit the task and tick Forget the pinned host key. The next connection records whatever key the server presents then, so do this only when you are sure; it is the one step that re-trusts the server. (The form shows the address and port read-only; if they are changed through the API, the old key is forgotten automatically, since a different machine has a different key.)

The password is write-only

Sondar stores the password encrypted and never returns it. Opening a task for editing shows an empty password box, which means “a password is stored, leave it alone” — save without touching it and the stored one is kept. Type a new one to rotate it. This is the same rule the notification channels follow, and it is why a read permission on a task does not expose the credential it holds.