How-to
Build a Multi-Repository Syslog Server with LogScale Collector
Infrastructure · v1 · @sebastian · 10.8.2026
Run LogScale Collector as a syslog server, map separate listeners to repository-specific ingest tokens, and understand source settings that control delivery.
A LogScale Collector can act as a syslog server: it opens a UDP or TCP listener, receives syslog messages, and forwards them to a LogScale sink. Use one sink per repository ingest token and point each source at the matching sink. This gives every listener an explicit repository destination instead of sharing a broad credential across unrelated senders.[1][3]
This guide uses separate listener ports as the simplest, most auditable routing model. A UniFi sender uses one port and its UniFi repository token; a firewall uses a different port and its network-security repository token. Do not use one repository just because it is convenient if the sources have different access, retention, parser, or ownership requirements.
What you need
- A host with LogScale Collector installed and enrolled in Fleet Management, or a collector managed through a local configuration.
- A reachable LogScale URL.
- One repository ingest token for each destination repository.
- Firewall permission for inbound syslog traffic to each listener port and outbound HTTPS from the collector to LogScale.
- A decision about UDP versus TCP for each sender.
A repository ingest token is tied to a specific repository and parser. It ingests only into that associated repository; it is not a user login token and cannot be used to query LogScale.[3]
1. Design the listener-to-repository map
Write the routing plan before creating tokens or a collector config. For example:
| Sender group | Listener | Transport | Destination repository | Sink name |
|---|---|---|---|---|
| UniFi Network | 1514 | UDP | network-unifi | unifi_logscale |
| Firewall | 1515 | TCP | network-security | firewall_logscale |
The collector source has one sink target. Separate ports make that destination choice visible and easy to verify. If you must route one listener by sender identity or message content, treat that as a separate design: test the required transform or multi-destination configuration before using it for production traffic.
For UniFi, use the first listener and assign UniFi Syslog Parser to the network-unifi repository ingest token. The compatible dashboards are UniFi Basics, UniFi Security & Audit, UniFi Wi-Fi Quality, and UniFi Gateway Health.
2. Create one repository ingest token per destination
In each destination repository, create an ingest token and copy it only into the collector configuration or the platform’s secure configuration mechanism. Do not paste tokens into tickets, screenshots, articles, or shell history.
Use a clear naming scheme that describes both the sender class and repository, for example:
collector-unifi-sysloginnetwork-unificollector-firewall-sysloginnetwork-security
Attach the parser that belongs to the repository’s input. For the UniFi token, use the UniFi Syslog Parser. Repository ingest tokens are the correct boundary here because LogScale associates each such token with one repository and parser.[3]
Screenshot gate before publication: capture the repository’s ingest-token creation screen with token values hidden. A second screenshot should show the parser selection, but no real repository name if it reveals internal naming.
3. Create a collector configuration
Create a new collector configuration in LogScale Fleet Management, or update the local collector configuration if that is how your host is managed. The following example uses two repository-specific sinks and two distinct listeners. Replace the placeholder URL and environment variables; do not put literal production tokens in the file.
sinks:
unifi_logscale:
type: logscale
url: "https://LOGSCALE-URL.example"
token: "${UNIFI_INGEST_TOKEN}"
queue:
type: disk
maxLimitInMB: 10240
firewall_logscale:
type: logscale
url: "https://LOGSCALE-URL.example"
token: "${FIREWALL_INGEST_TOKEN}"
queue:
type: disk
maxLimitInMB: 10240
sources:
unifi_syslog_udp:
type: syslog
mode: udp
port: 1514
bind: "0.0.0.0"
maxEventSize: 1048576
workers: 4
sink: unifi_logscale
transforms:
- type: static_fields
fields:
source_type: "unifi_syslog_udp"
firewall_syslog_tcp:
type: syslog
mode: tcp
port: 1515
bind: "0.0.0.0"
maxEventSize: 1048576
strict: true
supportsOctetCounting: true
sink: firewall_logscale
transforms:
- type: static_fields
fields:
source_type: "firewall_syslog_tcp"
The structure follows the LogScale documentation’s syslog examples: define a token-authenticated LogScale sink, optionally add a disk queue, and connect each syslog source to a named sink.[1][2]
4. Understand the syslog source settings
Use the settings deliberately rather than copying every option into every listener.
| Setting | Purpose | Practical choice |
|---|---|---|
type: syslog | Declares a syslog listener. | Required for this use case. |
mode | Selects udp or tcp. | Match the sender. UDP has lower overhead but no delivery guarantees; TCP provides ordered, connection-oriented delivery.[1] |
port | Local port on which the collector listens. | Use a distinct port per repository mapping, such as 1514 and 1515. |
bind | Local interface address for the listener. | Use 0.0.0.0 only when the host must accept traffic on all IPv4 interfaces; bind to a dedicated logging-network address where possible. |
sink | Names the destination under sinks:. | This is the routing decision: unifi_syslog_udp goes to unifi_logscale. |
maxEventSize | Caps a received event’s size in bytes. | Start with 1048576 only when you expect large events; set a lower tested limit if you need tighter resource control. |
workers | Controls concurrent processing for a source. | Start modestly and increase only after observing queue depth and CPU use. |
strict | Applies stricter parsing behaviour for the TCP source. | Use only after validating your sender’s framing. |
supportsOctetCounting | Enables RFC6587 octet-count framing support for TCP syslog. | Enable when the sender uses that framing; do not assume it for every TCP sender. |
transforms | Adds or changes fields before forwarding. | Add a static source_type field so searches can identify the listener that received an event. |
The collector supports UDP and TCP syslog and automatically detects common RFC3164 and RFC5424 formats. For TCP it also documents RFC6587 framing support. Ports below 1024 require elevated privileges on Linux or Unix, so a port such as 1514 avoids that requirement.[1]
The disk queue in the example is intentional. The LogScale syslog documentation recommends a disk queue so messages can persist during network interruptions or collector restarts. Size it for your event rate and acceptable outage window rather than copying 10240 MB blindly.[1][2]
5. Publish, assign, and open the firewall
Publish the configuration and assign it to the collector host in Fleet Management. Then open only the required inbound ports from the approved sender networks. For the table above:
- Permit UniFi sender addresses to reach UDP
1514. - Permit firewall sender addresses to reach TCP
1515. - Do not expose these listeners to arbitrary networks.
If you choose standard syslog port 514, remember that Linux and Unix normally require elevated privileges to bind ports below 1024.[1]
6. Verify each route separately
Verify one sender and repository at a time:
- Confirm the collector host is online and has the expected configuration assigned.
- Generate a harmless event at the sender.
- Search the intended repository for
source_typeand confirm events arrive. - Confirm the event does not arrive in the other repository.
- For UniFi, verify the fields required by the dashboard and then open UniFi Basics.
A good verification query for the UniFi repository is:
source_type=unifi_syslog_udp
| groupBy([@collect.host, source_type], function=count())
If you do not see results, check the listener bind address, network firewall, sender port and protocol, token validity, and the source’s exact sink name. Do not rotate a token before ruling out a simple port or sink-name mismatch.
Troubleshooting
Events arrive, but in the wrong repository
The source is pointed to the wrong named sink, or the sink contains the wrong token. Compare source.<name>.sink with the sinks: key, then confirm the token belongs to the intended repository. Repository ingest tokens are repository-specific, so a correct token is part of the routing boundary.[3]
UDP events are missing intermittently
UDP does not provide delivery guarantees. Check packet loss, firewall state, and receiver capacity. If the sender supports TCP and reliable ordered delivery is important, test TCP in a non-production listener first.[1]
TCP sender connects but events do not parse
Inspect the raw messages and validate framing. The collector documents RFC6587 support through supportsOctetCounting; use that setting only when the sender actually emits octet-counted frames.[1][2]
Next step
Configure Forward UniFi Syslog to a Remote Server with the collector listener’s address and port, then use the UniFi Syslog Parser and the linked dashboards to turn the incoming data into an operational view.
Sources
[1] https://library.humio.com/falcon-logscale-collector/log-collector-config-common-source-syslog.html
[2] https://library.humio.com/falcon-logscale-collector/log-collector-config-examples-syslog.html
[3] https://library.humio.com/falcon-logscale-cloud/ingesting-data-tokens.html
Version history
By default each save after the first publish creates a new version. Drafts stay on v1. Overwrites update the current version in place. Open any version to view or download it.