Forwarding system tenant logs to a central LogMan.io

This guide describes how to forward logs from the system tenant on a satellite TeskaLabs LogMan.io deployment to a supersystem tenant on a central TeskaLabs LogMan.io system.

The satellite keeps collecting and processing its own system logs. In parallel, LogMan.io Integration Service (lmio-integ) forwards raw events over TCP to a dedicated LogMan.io Collector on the satellite. That collector is provisioned to a receiving tenant on the central system (recommended name: supersystem) and ships the data over CommLink.

Architecture overview

flowchart LR
  subgraph satellite [Satellite system]
    lane1[system event lane]
    lane2[system event lane]
    lane3[system event lane]
    integ[lmio-integ]
    collector[lmio-collector-slim<br/>supersystem-*]
    lane1 --> integ
    lane2 -- "TCP BSD syslog (RFC 6587)" --> integ
    lane3 --> integ
    integ --> collector
  end

  subgraph central [Central system]
    receiver[lmio-receiver<br/>tenant: supersystem]
    archive[Archive]
    receiver --> archive
  end

  collector -- CommLink --> receiver
  • Satellite: existing system event lanes, plus lmio-integ and a slim collector instance dedicated to forwarding.
  • Central: a receiving tenant (recommended name supersystem) with a standard system tenant setup.
  • Ports are not arbitrary. Each forwarded stream uses a fixed TCP port that must match both the collector inputs and the event lane integrations on the satellite.

Tenant name

This guide uses supersystem as the recommended receiving tenant name. You may choose a different name; use the same name consistently for the tenant, the collector instance, and the integ instance (for example supersystem-1).

Prerequisites

Before you start, ensure you have:

  • A satellite LogMan.io cluster with a working system tenant
  • A central LogMan.io cluster
  • Superuser access on both systems
  • Network connectivity from the satellite collector to the central receiver (/lmio-receiver)

1. Create the receiving tenant on the central system

On the central system, create a tenant that will receive the forwarded logs. The recommended name is supersystem.

Complete the system tenant setup for that tenant.

2. Deploy a forwarding collector on the satellite

Deploy a dedicated slim collector on the satellite and provision it to the receiving tenant on the central system.

/Site/model.yaml
services:
  ...

  lmio-collector-slim:
    instances:
      supersystem-1:
        node: <node-on-satellite-system>
        # Default open ports on Collector are disabled
        asab:
          config:
            smart:
              listen: ""
        # CommLink connection to the central system
        files:
          - conf/lmio-collector.yaml: |
              connection:CommLink:commlink:
                url: http://<central-system-address>/lmio-receiver

              output:CommLink:smart: {}

Replace:

  • <node-on-satellite-system> — node on the satellite cluster where the collector runs
  • <central-system-address> — address of the central system reachable from that node

Collector inputs for system streams

Provision and configure the Collector to forward the system streams to the central system.

On the central system, open Logsources >> Collectors. Select the new Collector located on the satellite system and do the provisioning. Then open the Collector configuration and configure the inputs for the system streams in Custom configuration.

Collector configuration

Each system event lane is forwarded to a different TCP port. Port numbers follow the system collector layout: the original collection port plus 10000 (for example, stream asab is collected on 9900 and forwarded on 19900).

Use input:TCPBSDSyslogRFC6587 on every input. The integ tcp_bsd_syslog_rfc6587 integration sends each log with RFC 6587 octet-counting framing, which preserves original message boundaries even when logs contain newline characters.

Only logs produced by real log sources are forwarded. The complex, activity, and others event lanes are omitted because they do not collect logs from external sources.

Collector configuration
input:TCPBSDSyslogRFC6587:asab:
  address: 127.0.0.1 19900
  output: asab
output:CommLink:asab: {}

input:TCPBSDSyslogRFC6587:nginx:
  address: 127.0.0.1 19910
  output: nginx
output:CommLink:nginx: {}

input:TCPBSDSyslogRFC6587:zookeeper:
  address: 127.0.0.1 19911
  output: zookeeper
output:CommLink:zookeeper: {}

input:TCPBSDSyslogRFC6587:zoonavigator:
  address: 127.0.0.1 19912
  output: zoonavigator
output:CommLink:zoonavigator: {}

input:TCPBSDSyslogRFC6587:elasticsearch:
  address: 127.0.0.1 19920
  output: elasticsearch
output:CommLink:elasticsearch: {}

input:TCPBSDSyslogRFC6587:kibana:
  address: 127.0.0.1 19921
  output: kibana
output:CommLink:kibana: {}

input:TCPBSDSyslogRFC6587:kafka:
  address: 127.0.0.1 19922
  output: kafka
output:CommLink:kafka: {}

input:TCPBSDSyslogRFC6587:kafdrop:
  address: 127.0.0.1 19923
  output: kafdrop
output:CommLink:kafdrop: {}

input:TCPBSDSyslogRFC6587:mongo:
  address: 127.0.0.1 19924
  output: mongo
output:CommLink:mongo: {}

input:TCPBSDSyslogRFC6587:influxdb:
  address: 127.0.0.1 19930
  output: influxdb
output:CommLink:influxdb: {}

input:TCPBSDSyslogRFC6587:grafana:
  address: 127.0.0.1 19931
  output: grafana
output:CommLink:grafana: {}

input:TCPBSDSyslogRFC6587:telegraf:
  address: 127.0.0.1 19932
  output: telegraf
output:CommLink:telegraf: {}

input:TCPBSDSyslogRFC6587:linux-rsyslog-1:
  address: 127.0.0.1 19950
  output: linux-rsyslog-1
output:CommLink:linux-rsyslog-1: {}

input:TCPBSDSyslogRFC6587:lmio:
  address: 127.0.0.1 19999
  output: lmio
output:CommLink:lmio: {}

Apply the model and provision the collector to the receiving tenant on the central system.

3. Deploy LogMan.io Integration Service on the satellite

Deploy lmio-integ on the satellite. You can run multiple integ instances, including on the same node. Name the instance consistently with the receiving tenant (for example supersystem-1).

/Site/model.yaml
services:
  lmio-integ:
    instances:
      supersystem-1:
        node: <node-on-satellite-system>

Collector and Integration Service on the same node

LMIO Collector must be deployed on the same node as the LMIO Integration Service instance because the address 127.0.0.1 is used for the connection.

4. Configure raw forwarding on satellite system event lanes

For each system event lane on the satellite, add a tcp_bsd_syslog_rfc6587 integration that sends events to the matching TCP port on the forwarding collector.

Omitted event lanes

Only logs from real log sources are forwarded. The complex, activity, and others event lanes are not included in this guide.

Integration configuration in event lanes
/EventLanes/system/asab.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19900
/EventLanes/system/nginx.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19910
/EventLanes/system/zookeeper.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19911
/EventLanes/system/zoonavigator.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19912
/EventLanes/system/elasticsearch.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19920
/EventLanes/system/kibana.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19921
/EventLanes/system/kafka.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19922
/EventLanes/system/kafdrop.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19923
/EventLanes/system/mongo.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19924
/EventLanes/system/influxdb.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19930
/EventLanes/system/grafana.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19931
/EventLanes/system/telegraf.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19932
/EventLanes/system/linux-rsyslog-1.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19950
/EventLanes/system/lmio.yaml
integrations:
  - tcp_bsd_syslog_rfc6587:
      output_type: tcp
      address: 127.0.0.1 19999

Ports must match

The TCP port in each event lane integration must match the corresponding input:TCPBSDSyslogRFC6587 address in the collector configuration. Mismatched ports will silently drop that stream from forwarding.

5. Verify on the satellite collector

Check the forwarding collector logs. You should see TCP clients connecting for the configured streams:

Example output of LogMan.io Collector logs
14-Aug-2026 10:17:03.372795 NOTICE lmiocollector.ipc [sd id="mongo" peer="127.0.0.1 36656" tls="False"] TCP stream listener client connected.
14-Aug-2026 10:17:03.372901 NOTICE lmiocollector.ipc [sd id="grafana" peer="127.0.0.1 44610" tls="False"] TCP stream listener client connected.
14-Aug-2026 10:17:03.373178 NOTICE lmiocollector.ipc [sd id="kibana" peer="127.0.0.1 54026" tls="False"] TCP stream listener client connected.
14-Aug-2026 10:17:03.373287 NOTICE lmiocollector.ipc [sd id="telegraf" peer="127.0.0.1 41028" tls="False"] TCP stream listener client connected.
14-Aug-2026 10:17:03.373384 NOTICE lmiocollector.ipc [sd id="influxdb" peer="127.0.0.1 46368" tls="False"] TCP stream listener client connected.
14-Aug-2026 10:17:03.373476 NOTICE lmiocollector.ipc [sd id="asab" peer="127.0.0.1 35994" tls="False"] TCP stream listener client connected.
14-Aug-2026 10:17:03.374457 NOTICE lmiocollector.ipc [sd id="kafdrop" peer="127.0.0.1 48392" tls="False"] TCP stream listener client connected.

6. Verify on the central system

On the central system, open Archive in the receiving tenant (supersystem or the name you chose). Confirm that the forwarded streams are receiving data from the satellite.

How to Connect Ubiquiti Dream Machine to LogMan.io to Collect and Monitor NetFlows

A Ubiquiti UniFi Dream Machine (UDM) is a popular choice for small and mid-sized networks. It handles routing, switching, and Wi-Fi from a single appliance — but by default, it is something of a black box for your SIEM. Its NetFlow/IPFIX export is an excellent way to lift the hood: every conversation that crosses the gateway can be analyzed, searched, and correlated inside TeskaLabs LogMan.io.

This guide walks through the full path, from enabling NetFlow export on the UDM to monitoring the collected flow records in LogMan.io. The setup described here is the exact configuration we run in production at TeskaLabs on our own office router, so every step below is verified to work.

What’s new in TeskaLabs LogMan.io v26.12

Release date: 22.06.2026

LogMan.io v26.12 brings major enhancements to Alert Management, including ticket compression, unified severity levels, SLA monitoring, and push notifications. Discover defaults to the last 4 hours, supports up to 1,000 rows with infinite scroll, and lets you filter by alert ticket and navigate back. Parsec adds processors for VMware Aria Operations for Logs and SAP SAL logs and automatic parsing of Windows Event Access fields.

How to fix your application logs with AI

More than 57% of developers' time is spent in war rooms solving application performance issues rather than building new features (Cisco/Splunk Developer Survey, 2024). That's not a skills problem. It's a logging problem.

The logs your application writes today were crafted for the developer sitting at the keyboard. Someone who knows the code structure, remembers which module emits which message, and understands the internal state machine. When an incident hits at 02:00 in the morning, the person staring at those logs isn't that developer. It's an on-call engineer who doesn't know your code, or an AI agent parsing them for patterns.

Fixing Microsoft 365 Message Trace collection

Microsoft has changed the way Message Trace data is retrieved from Exchange Online. The original Reporting Webservice API that TeskaLabs LogMan.io used for Message Trace collection is being deprecated and replaced by a new Microsoft Graph API. If you collect Microsoft 365 Message Trace logs, you must update your Azure / Entra ID configuration, otherwise Message Trace collection will stop working.

  • in How-Tos
  • 10 min read

Creating Custom SVG Region Maps

The Explore module in TeskaLabs LogMan.io is the part of the product where users build their own charts on top of raw log data.

One of the chart types Explore offers is the Region Map. A region map takes the result of a group by query and colours regions of an image (typically a map) to reflect the value associated with each group. The image is a regular SVG file that you upload to the LogMan.io Library and reference from your chart definition.

  • in AI, Parser
  • 9 min read

Testing Local LLMs in Practice: Code Generation, Quality vs. Speed

Over the past few months, the landscape of open-weight large language models has changed dramatically. New models are being released at a pace that makes systematic evaluation difficult, yet increasingly necessary.

Most LLM comparisons still rely on synthetic benchmarks. While useful, they often fail to answer a more practical question:

How do these models perform in a real, production-like task?

This article presents a structured evaluation of local LLMs based on a concrete, repeatable, and measurable workload: autonomous code generation. Specifically, we focus on how well an autonomous agent, backed by these models, generates production-ready log parsers, and how that performance scales in terms of quality vs. speed.

Vector baselines and host behavior

Most security monitoring focuses on what happened, such as a failed login, a new admin, or a suspicious process. That approach is useful, but many strong warning signs do not come from one event. They come from a change in how a host behaves over time. When normal behavior starts to shift, that is often where analysts first see a real problem forming.

Vector baselines solve this by learning the usual shape of activity for each host and then detecting when that shape changes. Instead of writing and tuning many static thresholds, baselines let the system learn what is typical for each host or device.

When current behavior is statistically far from that learned normal, the baseline creates a signal or a complex event, that is visible in the Discover section.

What’s new in TeskaLabs LogMan.io v25.47

Release date: 16.02.2026

LogMan.io v25.47 introduces a complete redesign of the Observability interface, featuring intuitive point-and-click customization for Dashboards, Homepage, and Discover screens. This release also delivers significant performance improvements with an optimized row lookup algorithm and faster event replay capabilities.