LogScale Queries

How-to

Build a Multi-Repository Syslog Server with LogScale Collector

Infrastructure · v1 · @sebastian · 10.8.2026

All How-tos

Run LogScale Collector as a syslog server, map separate listeners to repository-specific ingest tokens, and understand source settings that control delivery.

MonitoringNetworkTroubleshooting

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 groupListenerTransportDestination repositorySink name
UniFi Network1514UDPnetwork-unifiunifi_logscale
Firewall1515TCPnetwork-securityfirewall_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-syslog in network-unifi
  • collector-firewall-syslog in network-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.

SettingPurposePractical choice
type: syslogDeclares a syslog listener.Required for this use case.
modeSelects udp or tcp.Match the sender. UDP has lower overhead but no delivery guarantees; TCP provides ordered, connection-oriented delivery.[1]
portLocal port on which the collector listens.Use a distinct port per repository mapping, such as 1514 and 1515.
bindLocal 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.
sinkNames the destination under sinks:.This is the routing decision: unifi_syslog_udp goes to unifi_logscale.
maxEventSizeCaps 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.
workersControls concurrent processing for a source.Start modestly and increase only after observing queue depth and CPU use.
strictApplies stricter parsing behaviour for the TCP source.Use only after validating your sender’s framing.
supportsOctetCountingEnables RFC6587 octet-count framing support for TCP syslog.Enable when the sender uses that framing; do not assume it for every TCP sender.
transformsAdds 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:

  1. Confirm the collector host is online and has the expected configuration assigned.
  2. Generate a harmless event at the sender.
  3. Search the intended repository for source_type and confirm events arrive.
  4. Confirm the event does not arrive in the other repository.
  5. 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.

  1. v1current

    10.8.2026, 19:04:19