Přeskočit obsah

Collector

Forwarding system tenant logs to a central LogMan.io

Tato příručka popisuje, jak přesměrovat protokoly od nájemce system na satelitním nasazení TeskaLabs LogMan.io do nájemce supersystem na centrálním systému TeskaLabs LogMan.io.

Satelit neustále sbírá a zpracovává své vlastní systémové protokoly. Paralelně LogMan.io Integration Service (lmio-integ) přeposílá surové události přes TCP do vyhrazeného LogMan.io Collector na satelitu. Tento kolektor je přiřazen k přijímacímu tenantu v centrálním systému (doporučený název: supersystem) a odesílá data přes CommLink.

Přehled architektury

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
  • Satelit: existující linky událostí system, plus lmio-integ a štíhlá instance kolektoru určená pro přeposílání.
  • Centrála: přijímací tenant (doporučený název supersystem) s běžným nastavením systémového tenanta.
  • Porty nejsou libovolné. Každý přeposílaný stream používá pevný TCP port, který musí odpovídat jak vstupům kolektoru, tak integracím linek událostí na satelitu.

Jméno nájemce

Tento průvodce používá supersystem jako doporučený název přijímajícího nájemce. Můžete zvolit jiný název; používejte však stejný název konzistentně pro nájemce, instanci sběrače a instanci integ (například supersystem-1).

Předpoklady

Než začnete, ujistěte se, že máte:

  • Satelitní cluster LogMan.io s funkčním nájemcem system
  • Centrální cluster LogMan.io
  • Přístup superuživatele v obou systémech
  • Síťové připojení ze satelitního sběrače do centrálního přijímače (/lmio-receiver)

1. Vytvořte příjemce nájemce v centrálním systému

Na centrálním systému vytvořte nájemce, který bude přijímat přeposlané záznamy. Doporučený název je supersystem.

Dokončete nastavení systému nájemce pro tohoto nájemce.

2. Nasadit přeposílací kolektor na satelitu

Nasadte dedikovaný odlehčený sběrač na satelit a připravte jej pro přijímajícího nájemce v centrálním systému.

/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: {}

Nahradit:

  • <node-on-satellite-system> — uzel na satelitním clusteru, kde běží kolektor
  • <central-system-address> — adresa centrálního systému dostupná z tohoto uzlu

Vstupy kolektoru pro systémové proudy

Zajistěte a nakonfigurujte sběrač tak, aby přeposílal systémové toky do centrálního systému.

Na centrálním systému otevřete Logsources >> Collectors. Vyberte nový Collector umístěný na satelitním systému a proveďte jeho zprovoznění. Poté otevřete konfiguraci Collectoru a nakonfigurujte vstupy pro systémové streamy v konfiguraci Custom.

Konfigurace sběrače

Každý kanál systémové události je přesměrován na jiný TCP port. Čísla portů odpovídají uspořádání systémového kolektoru: původní kolekční port plus 10000 (například stream asab je sbírán na 9900 a přesměrován na 19900).

Použijte input:TCPBSDSyslogRFC6587 u každého vstupu. Integrace tcp_bsd_syslog_rfc6587 odesílá každý záznam s rámováním počítajícím oktety podle RFC 6587, což zachovává původní hranice zpráv i tehdy, když záznamy obsahují znaky nového řádku.

Předávají se pouze záznamy vytvořené skutečnými zdroji záznamů. Větve událostí complex, activity a others jsou vynechány, protože nesbírají záznamy z externích zdrojů.

```yaml title="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: {}
```

Použijte model a nakonfigurujte kolektor pro přijímajícího nájemce na centrálním systému.

3. Deploy LogMan.io Integration Service on the satellite

Nasazujte lmio-integ na satelitu. Můžete spustit více instancí integ, včetně na stejném uzlu. Pojmenujte instanci konzistentně s přijímajícím nájemcem (například supersystem-1).

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

Sběrač a integrační služba na stejném uzlu

Sběrač LMIO musí být nasazen na stejném uzlu jako instance služby LMIO Integration Service, protože pro připojení se používá adresa 127.0.0.1.

4. Nakonfigurujte surové přeposílání na linkách událostí satelitního systému

Pro každou systémovou událostní linku na satelitu přidejte integraci tcp_bsd_syslog_rfc6587, která odesílá události na odpovídající TCP port na přeposílajícím sběrači.

Vynechané dráhy událostí

Přeposílány jsou pouze protokoly z reálných zdrojů protokolů. V tomto návodu nejsou zahrnuty proudy událostí complex, activity a others.

Konfigurace integrace v událostních pruzích
/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

Porty se musí shodovat

TCP port v každé integraci řady událostí musí odpovídat odpovídající adrese input:TCPBSDSyslogRFC6587 v konfiguraci kolektoru. Nesoulad portů způsobí, že bude tento tok tichounce vynechán při přeposílání.

5. Ověřte na satelitním sběrači

Zkontrolujte protokoly sběrače přesměrování. Měli byste vidět, jak se k nakonfigurovaným proudům připojují TCP klienti:

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. Ověřte na centrálním systému

Na centrálním systému otevřete Archiv v přijímajícím nájemci (supersystem nebo název, který jste zvolili). Potvrďte, že přesměrované proudy přijímají data ze satelitu.

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

Ubiquiti UniFi Dream Machine (UDM) je populární volbou pro malé a středně velké sítě. Zajišťuje směrování, přepínání a Wi-Fi z jednoho zařízení — ale ve výchozím nastavení je pro váš SIEM něco jako černá skříňka. Jeho export NetFlow/IPFIX je vynikající způsob, jak nahlédnout pod kapotu: každou komunikaci, která prochází bránou, lze analyzovat, vyhledávat a korelovat uvnitř TeskaLabs LogMan.io.

Tento průvodce provádí celou cestu, od povolení exportu NetFlow na UDM až po sledování shromážděných záznamů toků v LogMan.io. Zde popsané nastavení je přesná konfigurace, kterou provozujeme v produkci v TeskaLabs na našem vlastním kancelářském routeru, takže každý níže uvedený krok je ověřený a funkční.

Proč NetFlow? Co získáte oproti obyčejným záznamům?

UDM již může odesílat události firewallu a systému přes syslog. NetFlow je odlišný: místo jednotlivých událostí poskytuje agregované záznamy toků popisující každé spojení, které prochází bránou:

  • Kdo s kým komunikoval — zdrojové a cílové IP adresy a porty
  • Kolik — přenesené pakety a bajty v každém směru
  • Na jak dlouho — časové značky začátku a konce toku
  • Jaký protokol — TCP, UDP, ICMP a tak dále

S toky ve vašem SIEM můžete odpovídat na otázky, na které běžný syslog nestačí:

  • „Který interní host mluví s tím podezřelým externím IP a kolik dat se přesunulo?“
  • „Jak vypadá náš běžný profil east-west provozu — a kdy se změnil?“
  • „Existuje hostitel, který vysílá beacony — malé, periodické toky na pevně daný cíl?“

NetFlow je nezávislý na typu přenosu a přátelský k šifrovanému provozu: i plně šifrovaná spojení produkují záznamy o tocích, protože metadata konverzace jsou viditelná i tehdy, když není vidět obsah. To z něj činí základní kámen přehlednosti sítě.

Poznámka k protokolům

Stroj snů exportuje toky v NetFlow v9 / IPFIX přes UDP. (IPFIX je standardizován jako NetFlow verze 10, což je způsob, jakým to uživatelské rozhraní UniFi označuje.) Obě varianty jsou transparentně zpracovávány kolektorem popsaným níže.

Přehled architektury

UDM vysílá NetFlow přes UDP, ale Collector LogMan.io využívá protokol Lumberjack (ten samý protokol, který používá Elastic Logstash) přes TCP. Čistým mostem mezi nimi je Filebeat, jehož vestavěný vstup netflow funguje jako UDP NetFlow/IPFIX collector a znovu publikuje každý dekódovaný záznam toku jako JSON událost.

┌─────────────┐   NetFlow v9 / IPFIX (UDP)   ┌──────────────────┐
│  UniFi UDM  │ ───────────────────────────► │  Filebeat        │
│  (gateway)  │     port 2055/udp            │  netflow input   │
└─────────────┘                              └────────┬─────────┘
                                                      │ Lumberjack (TCP 5044)
                                                      ▼
                                            ┌──────────────────┐
                                            │ LogMan.io        │
                                            │ Collector        │
                                            │ → Receiver       │
                                            │ → Discover, ...  │
                                            └──────────────────┘
  • UDM → Filebeat: NetFlow/IPFIX přes UDP, standardní port kolektoru 2055.
  • Filebeat → LogMan.io Collector: Lumberjack přes TCP, výchozí port 5044 — stejná integrace používaná pro všechny ostatní produkty Beats (Winlogbeat, Auditbeat, …).
  • Strana LogMan.io: Kolektor přijímá připojení Beats a příchozí pole stream určuje cílový stream / kanál událostí. Není potřeba žádný vlastní konektor — Filebeat je plnohodnotný komponent LogMan.io Collector.

1. Povolit export NetFlow na Dream Machine

Přihlaste se do aplikace UniFi Network (webové rozhraní vašeho UDM) a přejděte na:

Nastavení → CyberSecure → Protokolování provozu

UniFi síť: Nastavení exportu NetFlow (IPFIX) v CyberSecure → Záznamy provozu

V sekci NetFlow (IPFIX):

  1. Povolte export NetFlow (IPFIX) a vyberte sítě, jejichž provoz má být exportován (my exportujeme všechny: kancelář, sandbox a výchozí síť).
  2. Nechte Verzi na 10 (IPFIX); níže uvedený kolektor podporuje také v9 a v5.
  3. Nastavte Adresu kolektoru na hostitele, na kterém běží váš kolektor Filebeat (v našem případě 10.17.160.2).
  4. Nastavte Port na 2055 (UDP) a nechte ID enginu na Auto.
  5. Nechte Režim vzorkování nastavený na Vypnuto, aby byl exportován každý tok — na úrovni kanceláře není třeba vzorkovat.
  6. V sekci Protokolování toků vyberte Veškerý provoz (nejen blokovaný provoz) a volitelně povolte další toky: Gateway DNS, UniFi Služby a Veškeré řízení zařízení UniFi.
  7. Použít změny.

Výchozí hodnoty pro Timeout Rate (5 minut) a Refresh Rate (20 paketů) fungují dobře; řídí, jak často jsou dlouhodobé toky znovu hlášeny a jak často jsou šablony znovu odesílány.

Tip

Na stejné obrazovce může Záznam činnosti (Syslog) směřovat běžné protokoly událostí UDM na server SIEM. To je samostatný, doplňkový kanál — tento článek se zaměřuje na export NetFlow.

UDM by měl okamžitě začít odesílat UDP datagramy na adresu kolektoru. Můžete ověřit z hostitele kolektoru pomocí:

$ sudo tcpdump -i any -c 20 udp port 2055
09:39:53.375526 lan0  In  IP 10.17.160.1.56014 > 10.17.160.2.2055: UDP, length 1392
09:39:54.055611 lan0  In  IP 10.17.160.1.56014 > 10.17.160.2.2055: UDP, length 1404
...

Zdroj (10.17.160.1) je samotná brána UDM. Datagramy o velikosti přibližně 1,4 KB jsou typické pakety NetFlow v9 / IPFIX nesoucí šablony a záznamy toků.

2. Spusťte sběrač NetFlow pro Filebeat

Filebeat spouštíme jako Docker kontejner na malém Linuxovém hostiteli uvnitř kancelářské sítě. Jakýkoli hostitel dosažitelný z UDM funguje; stačí, aby byl povolen vstup netflow a zveřejněn UDP port.

Příslušná část našeho docker-compose.yml:

  filebeat:
    image: docker.elastic.co/beats/filebeat:9.1.4
    container_name: filebeat
    user: root
    ports:
      - "2055:2055/udp"   # NetFlow/IPFIX collector for UniFi UDM
    volumes:
      - ./filebeat/filebeat.yml:/usr/share/filebeat/filebeat.yml:ro
      - ./filebeat/data:/usr/share/filebeat/data
    restart: unless-stopped

Poznámka o síťování

Kontejner běží na výchozí mostní síti Dockeru, takže je UDP port publikován pomocí ports:. Pokud očekáváte velmi vysoké objemy provozu, můžete místo toho spustit Filebeat s network_mode: host, abyste se vyhnuli uživatelskému NAT proxy — při provozu na úrovni kanceláře je publikovaný port naprosto v pořádku.

Samotná konfigurace Filebeatu (filebeat.yml) přidává vstup NetFlow:

filebeat.inputs:

  # NetFlow / IPFIX collector for the UniFi Dream Machine
  - type: netflow
    id: netflow-udm
    host: "0.0.0.0:2055"
    protocols: [ v5, v9, ipfix ]
    max_message_size: 10KiB
    expiration_timeout: 30m
    queue_size: 8192
    detect_sequence_reset: true
    fields:
      stream: netflow

Několik poznámek k možnostem:

  • protocols: [ v5, v9, ipfix ] — UDM komunikuje ve verzích v9/IPFIX; ostatní hodnoty jsou neškodné a připravené pro budoucnost.
  • expiration_timeout: 30m — jak dlouho se udržují neaktivní NetFlow relace/šablony před vypršením.
  • queue_size: 8192 — hloubka příjmové fronty UDP, aby se zabránilo ztrátě paketů při náhlých přívalech.
  • detect_sequence_reset: true — zahodí zastaralé šablony, pokud se UDM restartuje a jeho exportní čísla sekvencí se resetují.
  • Blok fields.stream: netflow označuje každý záznam toku polem stream: netflow. Jak je ukázáno níže, LogMan.io používá toto pole k směrování záznamů do vyhrazeného proudu, který udržuje data toku oddělená od vašich logovacích dat.

Použijte konfiguraci pře vytvořením kontejneru:

$ docker compose up -d --force-recreate filebeat

Papírový chyták

docker compose up -d samo o sobě nezaznamená změny v konfiguračním souboru připojeném přes soubor — běžící kontejner si ponechá starý konfigurační soubor. Použijte --force-recreate (nebo restartujte), kdykoli upravíte filebeat.yml.

3. Forward the records to LogMan.io

Collector LogMan.io nativně přijímá připojení Beats/Logstash (protokol Lumberjack) na TCP portu 5044. Na straně collectoru není nic zvláštního k nastavování — vstup Beats je ve výchozím nastavení povolen:

input:Beats:beats:
  output: beats
output:CommLink:beats: {}

Protože označení output: beats používá dynamické směrování proudů, každý příchozí událost je přiřazena ke proudu pojmenovanému podle jeho pole stream. Naše záznamy NetFlow nesou stream: netflow, takže skončí v netflow proudu a jeho přidružené událostní lince — není potřeba žádná konfigurace pro jednotlivé zdroje.

Nasměrujte Filebeat na kolektor přidáním výstupu Logstash (stejný blok, který používáme pro všechny naše ostatní vstupy Filebeat):

output.logstash:
  hosts: ["<collector-address>:5044"]

Nahraďte <collector-address> názvem hostitele nebo IP adresou vašeho LogMan.io Collectoru. Pokud je na vstupu Beats povoleno TLS, přidejte zde odpovídající sekci ssl, jak je popsáno v dokumentaci Beats, Logstash.

4. Ověřte potrubí od začátku do konce

Jakmile je vše připojeno, zkontrolujte každý skok:

A. Filebeat spustil vstup NetFlow — log by měl ukázat:

Starting netflow decoder
Starting udp server
Started listening for UDP connection
...
Loading and starting Inputs completed. Enabled inputs: 30

B. Toky přicházejí z UDM — sledujte port:

$ sudo tcpdump -i any udp port 2055

Měli byste vidět kontinuální tok datagramů o velikosti ~1,4 KB z IP adresy UDM.

C. Filebeat dekóduje a publikuje — periodický monitorovací snímek v logu Filebeat ukazuje, že jsou přidávány, publikovány a potvrzovány události toku:

"events": {"acked": 3927, "active": 0, "batches": 3, "total": 3927}

D. LogMan.io Collector přijímá — v rozhraní LogMan.io na webu by měl proud netflow zobrazovat příchozí události během několika sekund (viz další sekce).

5. Using the data in LogMan.io

Záznamy toku přicházejí do LogMan.io jako strukturované události JSON. V sekci Objevovat vyberte z rozbalovacího seznamu datový zdroj Netflow — poté můžete vyhledávat a filtrovat toky stejně jako jakákoli jiná logová data:

LogMan.io Objevte: události NetFlow

Například:

  • Všechny toky z nebo do konkrétního hostitele:related.ip:10.17.160.50
  • Traffic to non-standard destination ports:
    destination.port:4444
    
  • A specific protocol:
    network.transport:tcp
    

Odtud můžete vytvářet Dashboardy (nejaktivnější komunikující, bajty na hostitele, rozdělení podle protokolů, externí komunikace), nastavovat pravidla korelace v Korelátoru (např. upozornění na hostitele překračujícího práh bajtů směrem k danému cíli) nebo posílat záznamy do Baselineru, aby se naučil, jak vypadá normální provoz pro jednotlivé hostitele — přesně ten typ detekce změn chování, ve kterém vynikají flow data.

!!! tip „Přechod na jiné zdroje“

Můžete snadno přejít z záznamů NetFlow na jiné protokoly změnou zdroje dat na Události, nebo na ještě konkrétnější — například abyste zjistili, co podezřelý hostitel ještě prováděl.

Řešení problémů

Symptom Pravděpodobná příčina Opravit
Žádné události v protokolu Filebeat UDM neexportuje, nebo špatná IP/adresa portu kolektoru Zkontrolujte tcpdump -i any udp port 2055; potvrďte adresu/port sběrače 2055 v nastavení UniFi
UDP přijde, ale žádné toky nebyly dekódovány Firewall/nftables na hostiteli kolektoru blokuje UDP Povolte příchozí UDP/2055 z UDM
Port publikován, ale vstup netflow neběží Kontejner stále běží se starou konfigurací Znovu vytvořit: docker compose up -d --force-recreate filebeat
Toky publikovány, ale nic v LogMan.io Špatná adresa sběratele, nesoulad TLS nebo nesoulad názvu streamu Ověřte output.logstash.hosts; zkontrolujte protokoly Collector na 5044; potvrďte, že pole stream odpovídá očekávanému názvu streamu
Chyby dekódování po restartu UDM Stálé šablony detect_sequence_reset: true handles this; if problems persist, restart Filebeat

Více informací

Pokud potřebujete pomoc s připojením své síťové techniky k LogMan.io, kontaktujte podporu TeskaLabs na support@teskalabs.com.