Syslog

Firewalls, routers, hypervisors, and Linux and Windows hosts push their logs as syslog to a listener Fluency runs: the cloud syslog endpoint, or a collector appliance on your own network. There is no credential. The device and the platform are joined by an address, a port, and — when the transport is TLS — a certificate authority the device has to trust.

Syslog also differs from every other transport in how records reach a parser. An API or HEC template creates its own data source, so its records can only go one way. Syslog templates do not: every syslog record, from every device and every listener, arrives at one shared router, and the installed syslog templates compete for each record by recognising its format. That design explains most of what follows.

Every template that receives syslog has a guide in Integrations — most under On-Prem / Syslog, plus Windows Server, ManageEngine and Symantec Endpoint Protection Manager. The Integration Matrix lists them all. Cisco ASA is the most complete worked example of everything on this page.

How It Works

1. The device sends to a listener — the cloud endpoint or a collector.
2. The listener splits each message's syslog header into fields: the time, the sender's address, the host name and program name from the header, and the message text. A collector compresses and forwards what it receives to the platform over HTTPS.
3. Every record enters the shared syslog router, which runs a series of pipes in a fixed priority order:
   1. A timestamp adjustment runs first on everything (see Time).
   2. Each installed syslog template contributes a pipe with its own parser. A parser looks at the record — usually at the program name in its header — and either claims it, extracts its fields and writes it to the template's index, or passes it on to the next.
   3. A catch-all pipe at the end keeps every record no parser claimed. These are stored unparsed in the default index (managed-default in search), with only the header fields below.

Three consequences follow:

• A syslog template takes no device-specific settings. Most take no parameters at all. A template recognises a format, not a device, so one install serves every device of that kind on every listener — the cloud endpoint and all of your collectors alike.
• Install the template before pointing the device at the listener. Records that arrive before a parser is installed are kept, but in the default index, unparsed.
• The device's format matters more than its address. A device sending a format its template does not recognise lands in the default index — and there is no error anywhere, because nothing failed. Each guide names the exact format its parser expects.

The listener application itself, Fluency Syslog Endpoint, is installed once per instance from the System Components category and takes no parameters. Its Actions list shows the shared router, the timestamp and catch-all pipes, and the endpoint data source it creates.

The Fields Every Record Carries

Field	Comes from
@timestamp	The timestamp in the syslog header.
@sender	The IP address the message arrived from — the device itself, or the last NAT or relay in front of it.
@source	The host name in the syslog header. Where the header has none, the sending address.
@tags	The program name from the header — the value most parsers use to claim a record.
@facility, @level	The header's facility and severity.
@message	The message, with the header removed.
@collector	The name of the collector that received it, or fluency-server for the cloud endpoint.

Template parsers then add their own fields and may rewrite these. For an unclaimed record these are the only fields there are, which makes @sender the quickest way to ask is this device's traffic arriving at all? — search for the device's address across indexes, regardless of whether anything parsed it.

Where to Send: the Two Destinations

A device sends to one of two listeners, and they do not use the same ports. Pointing a device at the wrong one produces no error anywhere — the records simply never arrive.

The Cloud Syslog Endpoint

The cloud endpoint has a per-tenant domain and a block of ports allocated to your account. There is no standard port number to copy: the domain and the port for each protocol are shown on Platform → Administration → Syslog Ports, and both are specific to your tenant.

Read the destination off that page:

• Domain — the host name the device sends to, such as rockville.syslog.ingext.io.
• The protocol row you intend to use — Syslog TLS, TLS RFC 6587, Syslog UDP or Syslog TCP — shows the port it listens on. A protocol that is switched off shows a dash instead of a port.

Use the name, not an address, wherever the device accepts one. The domain is an alias for a cloud load balancer that answers on several addresses, and those addresses are not guaranteed to stay the same. A device whose destination field takes only an IP address has to be given one of them, and then needs re-checking whenever the endpoint stops receiving from it.

See Syslog Ports for the page in full.

A Collector Appliance

A collector on your own network listens on fixed default ports:

Protocol	Default port
udp	514
tcp	514
tls	6514
tls (RFC6587)	7514

These are the numbers most devices default to — 514 for traditional syslog, 6514 for syslog over TLS — and they apply only to a collector, not to the cloud endpoint. Each collector listener can carry a Customer Tag, which is how records arriving on a given port are attributed to a site or a customer; the cloud endpoint has no equivalent per-port field. A collector is addressed by its own IP address on your network, so there is nothing to resolve.

The collector is the right destination for a device that can only send UDP or unencrypted TCP, a device with no route to the internet, or a site with many senders. It forwards to the platform over HTTPS, so cleartext syslog never leaves your network. See Why Use a Collector, and Managing Collectors → Collector configuration for the listener settings.

Choosing a Protocol

Protocol	Encrypted	Framing	Delivery	Use it for
UDP	No	One message per datagram	Best effort. A lost datagram is gone, and nothing reports it.	A collector on the same trusted network, from a device that can do nothing better.
TCP	No	One message per line	Reliable while connected	A collector on a trusted network. Not across the internet.
Syslog TLS	Yes	One message per line	Reliable while connected	The default for any device that can do TLS. What most devices call "syslog over TLS".
TLS RFC 6587	Yes	Octet-counted: each message prefixed with its length	Reliable while connected	Devices whose reliable mode sends length-prefixed messages — FortiGate's reliable syslog is the common case.

The two TLS listeners are different framings, not alternatives. Find out which one the device emits before choosing a port, because the wrong one fails quietly:

• A line-framed sender on the TLS RFC 6587 port is dropped without an error on either side.
• A length-prefixed sender on the Syslog TLS port connects and is accepted, but the length prefix lands where the program name belongs, messages can run together, and no parser claims the result.

There is no length-prefixed listener without TLS, so a device whose TCP mode is octet-counted has to use TLS RFC 6587.

Reliable is not free on every device. Some devices treat a reliable log destination as a security control and fail closed: when the TCP or TLS destination is unreachable, they stop passing traffic until it comes back. A Cisco ASA does exactly this unless logging permit-hostdown is set. Check the device's guide for this before choosing TCP or TLS, and see Changing the Platform Side Safely.

TLS Trust

Both TLS listeners use one-way TLS: the device verifies the listener's certificate, and the listener never asks the device for one. A device that can only do mutual TLS cannot use either listener.

What the device has to trust depends on the destination:

• The cloud endpoint presents a certificate issued by a public certificate authority. Download CA (ca.crt) on the Syslog Ports page supplies the roots it chains to — a single file holding five public root certificates, Amazon Root CA 1 to 4 and Starfield Services Root Certificate Authority – G2. A host with an ordinary operating-system trust store usually trusts them already. Network appliances generally keep a short trust store of their own, and on those the file has to be imported before the handshake will succeed. Some appliances import one certificate per entry; split the file and import each, or at least the root the endpoint's chain ends at.
• A collector presents a certificate signed by a certificate authority the appliance generates for itself when it is installed. The downloaded file cannot validate it. The collector's own CA certificate is /etc/certs/ca.crt on the appliance — copy it from there (see Collector Login). The collector's server certificate does not name the collector's address, so a sender that checks the server's name against the address it dialled will refuse the connection; configure such senders to verify the certificate chain only.

A device that does not trust the certificate fails the handshake, and the failure is visible only on the device: nothing reaches the platform, so nothing is logged there.

Header, Format and Time

The Header

On the UDP, TCP and Syslog TLS listeners the header is read as traditional BSD syslog (RFC 3164): priority, timestamp, host name, then a program name ending in a colon. An IETF syslog (RFC 5424) header is not decoded on those listeners — its version number, 1, is read as the program name, and the real timestamp and host name stay inside @message. Several devices send that way by default, and their parsers are written to expect exactly that, so this is not something to fix on the device. It is the reason not to switch a device to RFC 5424 output on your own initiative when its guide does not say to.

Give every device a distinct host name in its header. @source comes from the header, and without one it falls back to the sending address — so every device behind one NAT, or one relay, collapses into a single source.

Format

Where the device has a template, use exactly the format its guide names. Each parser recognises one format and claims nothing else, and the right answer differs by vendor: SonicWall stops parsing if switched to CEF, UniFi requires CEF, FortiGate needs its default format, and a Cisco ASA in EMBLEM format is never claimed. The guide is the authority.

Only for a source with no template is the format your choice. Prefer JSON there: records will be stored unparsed in the default index either way, and structured ones are far easier to search and to write a parser for later.

A single message can be up to 256 KiB. Over UDP keep messages within one datagram, since a fragmented datagram that loses a fragment is lost whole.

Time

The header's timestamp becomes @timestamp. Two things go wrong with it:

• Devices on local time. A UTC offset in the header is not kept, so a device logging local time produces events stamped hours away from when they happened. The platform corrects the common case automatically: the first pipe on the syslog router notices a record arriving between one and twelve hours out, rounds the difference to whole hours, and shifts that device's records by it, keeping the original time in @ts_orig. Configure the device for UTC anyway — the correction is learned per device after the fact, and does not handle offsets that are not whole hours.
• Clock drift. Skew under an hour is not corrected at all. Run NTP on the device. The Time Adjustment recipe shows the shape of a hand-written correction for cases the automatic one does not handle.

Forwarding From Hosts

Servers forward through a syslog agent rather than a built-in device setting:

• Linux — rsyslog or syslog-ng, both usually already installed. See Linux (RHEL) Syslog.
• Windows — Windows has no native syslog output, so an NXLog agent reads the event logs and sends them as JSON over syslog. See Windows Server.

Confirming It Works

A Running badge on the template or on the Fluency Syslog Endpoint application means the listener is up. It says nothing about whether any device is sending. Confirm from the device out:

1. On the device, find its own record of sending — a log counter, a connection status, a delivery error. Each guide names it.
2. Provoke a known event on the device — a login, a configuration change, logger on a Linux host — and note the time.
3. Search for it in the template's index. If it is not there, search for the device's address in @sender across the default index: if it is there, the transport works and the format is not being recognised; if it is nowhere, the problem is between the device and the listener.
4. On a collector, check its Management tab: the Queues counts should sit at zero. A rising upload queue means the collector is receiving but cannot ship to the platform.

When It Stops

Symptom	Usual causes
Nothing from the device, anywhere	No network path to the listener; the wrong port, or the right port with the wrong protocol (UDP to a TCP listener is silent at both ends); the protocol switched off on Syslog Ports; an outbound firewall on the device itself (ESXi ships with its syslog rule disabled).
The device reports a TLS or certificate error	The CA not imported; the cloud CA used for a collector or the reverse; the sender checking the collector's certificate name against its address; the device insisting on mutual TLS.
The device connects, but nothing is ever parsed	The wrong TLS framing for the port — see Choosing a Protocol.
Records are in the default index, not the template's	The device's format is not the one the parser recognises, or the template was installed after the records arrived.
Events stamped hours off	The device logs local time, and the correction has not learned it yet or the offset is not a whole number of hours.
Every device appears as one source	No host name in the headers, and the devices share a NAT or relay.
A device stopped working, not just logging	A fail-closed device lost its reliable destination.
Worked, then stopped, with no change on the device	The device addresses the cloud endpoint by IP and the endpoint's addresses changed; or a platform-side change below.

Changing the Platform Side Safely

Clearing a protocol in Update Config, Delete Syslog Config, changing the CA, or removing a listener from a collector stops every device sending to it — and a fail-closed device stops passing traffic, not merely logging. Nothing on the platform shows who is sending to which protocol. Before any of these changes, find out which devices use the listener, and move them first.

In This Section

• Syslog Ports — the cloud syslog endpoint's page, and the collector's listener ports.
• Ingress Management — the inventory of devices sending syslog, and noticing when one stops.

Related

• Fluency Collector — installing a collector to receive syslog on your own network.
• On-Prem / Syslog — per-device guides.
• Parser cookbooks — writing or customising a syslog parser.