Přeskočit obsah

2026

How to continuously upload logs from the LogMan.io archive to S3 storage

LogMan.io Receiver uchovává neměnnou kopii každého surového logu ve svém archivu. Archiv je vaším dlouhodobým úložištěm, ale neuchovává data navždy: ve výchozím nastavení jsou oddíly po 18 měsících odstraněny z chladné fáze. Pokud je třeba surové logy uchovávat déle, například pro soulady, forenzní účely nebo jako záložní kopii mimo místo, nejjednodušší postup je průběžně nahrávat archiv do objektového úložiště kompatibilního s S3.

Tento průvodce popisuje jednostrannou, naplánovanou synchronizaci z fáze chlazení přijímače do S3 bucketu pomocí AWS CLI. Stejný postup funguje s AWS S3 i s providery kompatibilními se S3, jako je Oracle Cloud Object Storage.

Proč synchronizovat archiv s S3

Archiv přijímače je neměnný, orientovaný na sloupce a pouze pro přidávání. Každý přijatý záznam je uložen jednou a nikdy není upravován. Archiv je obvykle rozdělen do fází životního cyklu:

  • horké: nedávno zpracované partitiony, nejlépe umístěné na SSD
  • vlažné: partitiony po jednom dni, nejlépe umístěné na HDD
  • studené: dlouhodobá kopie, xz-komprimovaná, nejlépe umístěná na pomalé HDD nebo NAS

Ve výchozím nastavení zůstává oddíl v chladné fázi po dobu 18 měsíců a poté je smazán. To je doba uchovávání, kterou získáte přímo z krabice.

Synchronizace studené fáze s objektovým úložištěm vám přináší tři věci:

  • Delší zachování. Bucket se stává vaším archivem i po uplynutí 18měsíční výchozí doby.
  • Kopie mimo lokalitu. Data se nacházejí na jiném místě než cluster.
  • Levné úložiště. Objektové úložiště s životním cyklem STANDARD_IA nebo Glacier je levnější než uchovávání stejného objemu na discích clusteru.

Návrh archivu toto přímo podporuje. Názvy oddílů jsou globálně unikátní, takže oddíly mohou být přesunuty na sdílené nebo cloudové úložiště a správně znovu sestaveny bez kolizí.

Jak to funguje

Jádro je jediný příkaz:

aws s3 sync source_folder s3://your_bucket_name/destination_folder/

aws s3 sync je jednostranný, přidávající přenos. Nahrává soubory, které na cílovém místě chybí, mají odlišnou velikost nebo jsou novější lokálně. Soubory, které smažete lokálně, nikdy nejsou odstraněny z bucketu, pokud nepřidáte parametr --delete.

To je přesně chování, které chcete u archivní zálohy: koš se pouze zvětšuje a chyba operátora na lokální straně nemůže zničit kopii.

Synchronizace probíhá podle plánu (například každých deset minut z cron), takže nové oddíly jsou nahrány krátce poté, co se uzavřou a přejdou do studené fáze.

flowchart LR
  subgraph lmio [LogMan.io node]
    cold[lmio-receiver<br/>cold phase<br/>/data/hdd/lmio-receiver-1/cold]
  end

  subgraph cli [AWS CLI container]
    sync[aws s3 sync]
  end

  subgraph storage [Object storage]
    bucket[S3 bucket<br/>s3://bucket/tenant/]
  end

  cold -- "cron, every 10 min" --> sync
  sync --> bucket

Předpoklady

  • Nasazení LogMan.io s archivem přijímače a definovaným adresářem studené fáze
  • Přístup superuživatele (root) k uzlu, kde přijímač ukládá studenou fázi
  • S3-kompatibilní účet s bucketem, AWS S3 nebo jakýkoli poskytovatel, který podporuje S3 API
  • AWS CLI, nejlépe oficiální Docker image amazon/aws-cli

1. Vytvořte bucket a uživatele IAM

Vytvořte koš pro archiv. Doporučená nastavení koše:

  • Verzování: zapnuto: každé znovu nahrání změněného souboru uchovává předchozí verzi, chrání před přepsáním i smazáním.
  • Blokovat veřejný přístup: zapnuto (výchozí pro nové koše).
  • Výchozí šifrování: SSE-S3 (výchozí pro nové koše).
  • Pravidlo životního cyklu: pro archivovaný obsah přeneste do Glacier Instant Retrieval po 30 dnech a ukončete neaktuální verze po 90 dnech, aby verzování nerostlo bez omezení.

Vytvořte uživatele IAM bez přístupu do konzole, a poté připojte tuto inline politiku. Akce pro mazání jsou záměrně vynechány, takže záruka, že nedojde k odstranění, platí i v případě, že někdo později omylem přidá --delete do příkazu.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": "arn:aws:s3:::your_bucket_name"
    },
    {
      "Sid": "WriteObjects",
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject", "s3:AbortMultipartUpload"],
      "Resource": "arn:aws:s3:::your_bucket_name/*"
    }
  ]
}

Poté vytvořte přístupový klíč: Bezpečnostní údaje → Vytvořit přístupový klíč → „Aplikace běžící mimo AWS“. Tajný klíč je zobrazen pouze jednou.

2. Uložte přihlašovací údaje do úložiště

Na uzlu, který spouští ASAB Remote Control, nahrajte hodnoty přístupového klíče IAM ze kroku 1. Použijte /opt/site/gov.sh curl, aby byl požadavek autorizován lokálně (viz Používání Vaultu z příkazového řádku):

/opt/site/gov.sh curl -X PUT localhost:8891/vault/AWS_ACCESS_KEY_ID --data 'AKIA...'
/opt/site/gov.sh curl -X PUT localhost:8891/vault/AWS_SECRET_ACCESS_KEY --data 'wJalr...'

3. Nasaďte AWS CLI

Přidejte službu AWS CLI do model.yaml. Odkazujte na přístupový klíč a tajný klíč z Vaultu, nevkládejte je do modelu jako prostý text.

/Site/model.yaml
services:
  aws-cli:
    instances:
      1:
        node: <node-1>
      2:
        node: <node-2>

    descriptor:
      environment:
        AWS_ACCESS_KEY_ID: "{{AWS_ACCESS_KEY_ID}}"
        AWS_SECRET_ACCESS_KEY: "{{AWS_SECRET_ACCESS_KEY}}"
        AWS_DEFAULT_REGION: eu-central-1

secrets:
  AWS_ACCESS_KEY_ID: {}
  AWS_SECRET_ACCESS_KEY: {}

Použijte model a počkejte, až se spustí služba aws-cli. Položky Vault ze kroku 2 musí již existovat; pokud při použití chybí deklarované tajemství, Maestro vygeneruje náhodný token a uloží ho do Vault, ne platný klíč AWS.

4. Ověřte přihlašovací údaje

Ověřte přihlašovací údaje před prvním synchronizováním:

docker exec aws-cli-1 aws sts get-caller-identity
docker exec aws-cli-1 aws s3 ls s3://your_bucket_name/

5. Spusťte synchronizaci

Zdroj je adresář studené fáze přijímače. Předpona cíle by měla identifikovat nájemce, aby jeden bucket mohl sloužit celému clusteru:

docker exec aws-cli-1 aws s3 sync /data/hdd/lmio-receiver-<instance>/cold/ s3://your_bucket_name/<tenant>/
  • <instance> je obvykle 1 při instalaci na jednom uzlu, nebo číslo uzlu v clusteru.
  • <tenant> je jedinečné jméno nájemce, jehož protokoly nahráváte.

Nejprve náhled, toto uvádí, co by se přeneslo, a nic nepřenáší:

docker exec aws-cli-1 aws s3 sync /data/hdd/lmio-receiver-1/cold/ s3://your_bucket_name/tenant/ --dryrun

Užitečné přepínače:

Vlajka Účinek
--dryrun Zobrazit pouze plánované operace
--exclude '.DS_Store' --exclude '*.tmp' Přeskočit šum (opakovatelný)
--storage-class STANDARD_IA Levnější úložiště pro archivní obsah
--only-show-errors Tichý výstup pro cron
--exact-timestamps Přísnější detekce změn (stahování)

Nikdy nepřidávejte --delete

Nikdy nepřidávejte --delete, to je jediný přepínač, který by zrcadlil místní smazání do bucketu.

Jak funguje detekce změn

sync porovnává velikost souboru a čas poslední úpravy. Soubor je nahrán, když na cíli chybí, liší se velikostí nebo je novější lokálně. Neprovádí porovnání kontrolních součtů, takže upravený soubor, který si zachoval přesnou velikost v bytech a má starší čas poslední úpravy než objekt S3, bude přeskočen. V praxi to bývá vzácné; soubor můžete vynutit použitím příkazu touch, pokud je třeba.

6. Naplánujte synchronizaci

Spouštějte synchronizaci každých deset minut z cronu. Použijte absolutní cestu k docker (cron má minimální PATH) a zaznamenejte výstup:

*/10 * * * * /usr/bin/docker exec aws-cli-1 aws s3 sync /data/hdd/lmio-receiver-1/cold/ s3://your_bucket_name/tenant/ --only-show-errors >> /var/log/lmio-sync.log 2>&1

Přidejte jeden řádek pro každou instanci přijímače LMIO. Synchronizace je inkrementální: po prvním spuštění přenáší pouze nové nebo změněné oddíly, takže každé spuštění je levné.

7. Ověřit

Po prvním spuštění zkontrolujte, zda se objekty zobrazují v koši:

docker exec aws-cli-1 aws s3 ls --recursive s3://your_bucket_name/tenant/ | tail

Porovnejte počet objektů s počtem oddílů v chladné fázi. Chladná fáze uchovává jeden adresář na oddíl, takže úspěšná synchronizace znamená, že každý adresář oddílu je přítomen na cílovém místě.

Cíle S3 mimo AWS

Stejný příkaz funguje i proti poskytovatelům kompatibilním se S3, například Oracle Cloud Object Storage. Přihlašovací údaje uchovávejte ve Vaultu jako ve krocích 2–3; rozšiřte prostředí služby aws-cli z kroku 3 o nastavení oblasti a kontrolního součtu (nejde o tajné údaje, musí být nastaveny v kontejneru, ne jako export na hostiteli):

/Site/model.yaml
    descriptor:
      environment:
        AWS_ACCESS_KEY_ID: "{{AWS_ACCESS_KEY_ID}}"
        AWS_SECRET_ACCESS_KEY: "{{AWS_SECRET_ACCESS_KEY}}"
        AWS_DEFAULT_REGION: <region>
        AWS_REQUEST_CHECKSUM_CALCULATION: when_required
        AWS_RESPONSE_CHECKSUM_VALIDATION: when_required

Použijte změnu a pak předejte koncový bod poskytovatele příkazu synchronizace:

docker exec aws-cli-1 aws s3 sync /data/hdd/lmio-receiver-1/cold/ s3://bucket/tenant/ \
  --endpoint-url https://<namespace>.compat.objectstorage.<region>.oraclecloud.com \
  --region <region>

Dva výhrady k této cestě:

  • Dvě proměnné kontrolního součtu v environment jsou vyžadovány pro AWS CLI 2.23.5+, jinak by byla odesílána CRC kontrolní suma, kterou OCI odmítá s zavádějící chybou The Content-Length header is required.
  • Přihlašovací údaje pocházejí z Customer Secret Keys v OCI konzoli, nikoli z IAM.

Závěr

Synchronizace archivu LogMan.io do S3-kompatibilního objektového úložiště je jediný příkaz aws s3 sync, malá IAM politika bez oprávnění k mazání a jeden řádek cron pro každou instanci přijímače. Výsledkem je levná, odolná, mimopracoviště kopie každého surového logu, která přežije nativní dobu uchovávání přijímače. Archiv je neměnný a názvy oddílů jsou globálně unikátní, takže koš je věrnou kopií studené fáze a místní chyba nikdy nemůže propagovat mazání do něj.

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.

Nové funkce v TeskaLabs LogMan.io v26.12

Datum vydání: 22.06.2026

LogMan.io v26.12 přináší zásadní vylepšení Alert Managementu včetně komprese ticketů, sjednocených úrovní závažnosti, SLA monitoringu a push notifikací. Discover ve výchozím stavu zobrazuje poslední 4 hodiny, podporuje až 1 000 řádků s nekonečným scrollováním a umožňuje filtrovat podle alert ticketu a navigaci zpět. Parsec přidává procesory pro VMware Aria Operations for Logs a SAP SAL logy a automatické parsování Windows Event Access polí.

Vytváření vlastních map oblastí ve formátu SVG

Modul Prozkoumat v TeskaLabs LogMan.io je část produktu, kde si uživatelé vytvářejí vlastní grafy na základě surových dat z logů.

Jedním z typů grafů, které Explore nabízí, je Mapy regionů.
Mapa regionů bere výsledek dotazu group by a barevně zvýrazňuje oblasti obrázku (obvykle mapy), aby odrážely hodnotu spojenou s každou skupinou.
Obrázek je běžný soubor SVG, který nahrajete do knihovny LogMan.io a odkážete na něj ve vaší definici grafu.

Mapy regionů nemusí být geografické. Cokoli, co lze nakreslit jako soubor pojmenovaných regionů, se může stát mapou regionů: diagram zón sítě, matice MITRE ATT&CK, plán podlaží datového centra, přehled jmenného prostoru Kubernetes, budova, uspořádání regálů. Pokud můžete svůj obor rozdělit na pevnou sadu pojmenovaných regionů a máte logové pole, které tyto názvy poskytuje, můžete z něj v Explore vytvořit mapu regionů.

Tento příspěvek vysvětluje, jak mechanismus funguje, jak vytvořit SVG, aby jej TeskaLabs LogMan.io mohl ovládat, a jak udělat mapu, aby se automaticky přizpůsobovala světlým a tmavým motivům produktu.
Krok za krokem si vytvoříme malou, ručně vytvořenou mapu síťových zón.

??? tip „Pod kapotou“

TeskaLabs LogMan.io Explore komponenta vykresluje grafy pomocí Apache ECharts, podporovaná backendovou mikroslužbou LogMan.io s názvem lmio-chart.

Jak funguje regionální mapa

Tok dat je přímočarý, jakmile ho máte v hlavě:

  1. Uživatel definuje graf typu „Regionální mapa“ v Explore, pole Seskupit podle (například network.zone) a Mapu (SVG soubor z knihovny).
  2. Dotaz vrátí řádky ve formátu (bucket_key, value); například ("dmz", 1283), ("lan", 47210), …
  3. Komponenta grafu načte SVG z knihovny TeskaLabs LogMan.io a zaregistruje jej jako mapu. LogMan.io považuje každý prvek v SVG, jehož atribut name odpovídá klíči „bucket“, za oblast mapy.
  4. TeskaLabs LogMan.io vybarví každou přiřazenou oblast pomocí barevného schématu grafu odpovídající její hodnotě. Oblasti, o kterých data nehovoří, jsou vybarveny neutrální barvou „bez dat“.

Celé porovnání se provádí porovnáním řetězců mezi klíčem koše a atributem name SVG prvku. Neděje se zde žádná magie, vy ovládáte názvy na obou stranách. Dohoda je: řetězce, které zdrojové pole vrací, musí být shodné s atributy name oblastí, které chcete obarvit.

!!! tip „Použijte Tabulku k přípravě dat“

Chcete-li definovat správné pole pro „seskupit podle“, použijte „Tabulku“ k vizualizaci výsledku dotazu. Přepněte na „Regionální mapu“, když budete spokojeni se zdrojovými daty.

Několik praktických důsledků:

  • Shoda je citlivá na velikost písmen. Zvolte jednu konvenci (malá písmena jsou normou v balíčkových mapách LogMan.io) a sladte s ní jak SVG, tak logovací pipeline. Pokud vaše pole uchovává hodnoty jako DMZ, ale oblast v SVG se jmenuje dmz, nic se nezobrazí.
  • Klíč koše je po normalizaci vždy řetězec. Pokud je vaše pole Skupina podle vícenásobné (["t1047", "t1059"]), hodnota stejného řádku se aplikuje na každou referencovanou oblast, jeden event se dvěma technikami obarví obě technikové krabičky.
  • Klíče koše, které nejsou přítomny v SVG, se jednoduše ignorují. Oblasti SVG, které nejsou nikdy spárovány s klíčem, se vykreslují ve výchozí barvě "žádná data".

Anatomie SVG mapy

Soubor SVG potřebuje k fungování jako mapu regionu pouze tři věci:

  1. Kořenový element <svg> s rozumným viewBox. LogMan.io používá viewBox pro rozvržení a zoom.
  2. Jedna skupina <g id="layer-regions">, která obsahuje pojmenované oblasti. Skupina je konvence, nikoli tvrdé pravidlo, ale udržuje soubor přehledný a odpovídá přiloženým mapám.
  3. Uvnitř této skupiny jeden element na oblast s atributem name="<bucket-key>". Obvykle je to <rect>, ale funguje jakýkoliv SVG tvar.

Minimální funkční příklad:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 600">
  <g id="layer-regions">
    <rect name="t1047" x="10"  y="20" width="100" height="40"/>
    <rect name="t1059" x="120" y="20" width="100" height="40"/>
  </g>
</svg>

Každý <rect> je oblast. TeskaLabs LogMan.io propojuje datový bod s názvem t1047 a hodnotou 42 s obdélníkem, jehož atribut name je t1047, a vybarvuje ho podle barevné škály.

Statické atributy fill a stroke na pojmenované oblasti jsou jen zástupné hodnoty, TeskaLabs LogMan.io je přepisuje při vykreslování barvou vypočítanou z dat. Můžete tam použít libovolnou barvu; záleží jen na tom při náhledu SVG mimo TeskaLabs LogMan.io.

Pracovní příklad: mapa síťových zón

Postavme malou mapu, která zbarví čtyři síťové zóny (DMZ, interní LAN, hostující WiFi a správa) podle počtu událostí zaznamenaných v každé zóně. Předpokládejme, že logovací pipeline vydává pole s názvem network.zone, jehož hodnoty jsou dmz, lan, guest a mgmt.

Krok 1: Rozhodněte o klíčích regionu

Klíče musí odpovídat hodnotám, které vaše data produkují. Volíme malá písmena a krátké identifikátory:

Štítek zóny Klíč regionu
demilitarizovaná zóna dmz
Interní LAN lan
Hosté WiFi guest
Management mgmt

Krok 2: Nakreslete SVG

Rozložte čtyři obdélníky na plátně o rozměrech 400 × 280, dvě řady po dvou. Každý obdélník je oblastí řízenou daty a nese odpovídající atribut name. Každý obdélník je doprovázen dvěma textovými popisky (čitelné lidské označení a surový klíč), které jsou chrome, ne data, takže nemusí mít name.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 280">
  <title>Network Zones</title>
  <g id="layer-regions">

    <!-- DMZ -->
    <rect name="dmz"
          x="20" y="20" width="160" height="100"
          fill="#eeeeee" stroke="#888888" stroke-width="1"/>
    <text x="100" y="65" text-anchor="middle"
          font-family="sans-serif" font-size="16" font-weight="bold"
          fill="currentColor">DMZ</text>
    <text x="100" y="90" text-anchor="middle"
          font-family="sans-serif" font-size="11"
          fill="currentColor">dmz</text>

    <!-- Internal LAN -->
    <rect name="lan"
          x="220" y="20" width="160" height="100"
          fill="#eeeeee" stroke="#888888" stroke-width="1"/>
    <text x="300" y="65" text-anchor="middle"
          font-family="sans-serif" font-size="16" font-weight="bold"
          fill="currentColor">Internal LAN</text>
    <text x="300" y="90" text-anchor="middle"
          font-family="sans-serif" font-size="11"
          fill="currentColor">lan</text>

    <!-- Guest WiFi -->
    <rect name="guest"
          x="20" y="160" width="160" height="100"
          fill="#eeeeee" stroke="#888888" stroke-width="1"/>
    <text x="100" y="205" text-anchor="middle"
          font-family="sans-serif" font-size="16" font-weight="bold"
          fill="currentColor">Guest WiFi</text>
    <text x="100" y="230" text-anchor="middle"
          font-family="sans-serif" font-size="11"
          fill="currentColor">guest</text>

    <!-- Management -->
    <rect name="mgmt"
          x="220" y="160" width="160" height="100"
          fill="#eeeeee" stroke="#888888" stroke-width="1"/>
    <text x="300" y="205" text-anchor="middle"
          font-family="sans-serif" font-size="16" font-weight="bold"
          fill="currentColor">Management</text>
    <text x="300" y="230" text-anchor="middle"
          font-family="sans-serif" font-size="11"
          fill="currentColor">mgmt</text>

  </g>
</svg>

SVG vypadá takto:

Network Zones DMZ dmz Internal LAN lan Guest WiFi guest Management mgmt

V tomto bodě jsou čtyři obdélníky pojmenovány (dmz, lan, guest, mgmt) a šedé výplně jsou zástupné symboly.
Když Explore vykreslí tuto mapu vůči dotazu seskupenému podle network.zone, TeskaLabs LogMan.io nahradí tyto šedé barvy barvami ze škály barev grafu a ponechá jakoukoli zónu, kterou dotaz nevrátil, v neutrální barvě „bez dat“.

Barvy přizpůsobené tématu: světlý a tmavý režim

TeskaLabs LogMan.io je dodáván se dvěma motivy (světlým a tmavým) a uživatelé mezi nimi mohou kdykoli přepínat.
Datově řízené vyplněné pojmenované oblasti nejsou problém: TeskaLabs LogMan.io je počítá z dat pomocí barevné škály a tyto barvy lze konfigurovat pro každý řídicí panel.
Problémem je grafické rozhraní: hranice, které rámují skupiny oblastí, oddělovací čáry, záhlaví sekcí, popisné štítky.
Tyto prvky musí vypadat správně v obou motivech a jejich barvy nelze pevně nastavit na černou nebo bílou.

Načítací modul mapy regionu to řeší tím, že rozpozná dva speciální atributy u libovolného SVG prvku:

  • data-fill="<CSS-variable-name>": při načtení načte načítací skript hodnotu pojmenované CSS proměnné z aktuálního dokumentu a zapíše ji do atributu fill elementu.
  • data-stroke="<CSS-variable-name>": totéž, pro stroke.

CSS proměnné pocházejí z tématu TeskaLabs LogMan.io založeného na Bootstrapu. Každé téma definuje své vlastní hodnoty pro stejná jmenná proměnná, což je důvod, proč jeden SVG může sloužit oběma tématům. Nejužitečnější proměnné pro tvorbu map jsou:

Proměnná Význam
--bs-body-color Výchozí text a barva popředí
--bs-body-bg Výchozí pozadí stránky
--bs-border-color Jemná barva okraje
--bs-primary Primární barva značky (královsky modrá v světlém motivu)
--bs-secondary Doplňková značka

Užitečné pravidlo: cokoliv, co není datově řízená pojmenovaná oblast (štítky, rámečky, oddělovače, hlavičkové obdélníky), by mělo určovat svou barvu pomocí data-fill a/nebo data-stroke, nikdy pomocí statické barvy. Tímto způsobem je SVG vykresleno správně v obou tématech, aniž byste museli udržovat dvě verze souboru.

Verze SVG síťových zón s ohledem na motiv

Každý textový štítek rozšíříme o data-fill="--bs-body-color", aby barva štítku odpovídala motivu. Můžeme také upravit tah zástupce každého pojmenovaného <rect>, aby se přizpůsobil, ačkoli to není striktně nutné, protože TeskaLabs LogMan.io překresluje okraje svou vlastní barvou okraje.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 280">
  <title>Network Zones</title>
  <g id="layer-regions">

    <!-- DMZ -->
    <rect name="dmz"
          x="20" y="20" width="160" height="100"
          fill="#eeeeee"
          data-stroke="--bs-border-color" stroke-width="1"/>
    <text x="100" y="65" text-anchor="middle"
          font-family="sans-serif" font-size="16" font-weight="bold"
          fill="currentColor" data-fill="--bs-body-color">DMZ</text>
    <text x="100" y="90" text-anchor="middle"
          font-family="sans-serif" font-size="11"
          fill="currentColor" data-fill="--bs-body-color">dmz</text>

    <!-- … the other three zones follow the same pattern … -->

  </g>
</svg>

Atributy data-fill / data-stroke se zpracovávají jednou při načtení SVG pro aktuální téma. Když uživatel změní téma, TeskaLabs LogMan.io znovu načte a znovu zaregistruje mapu s hodnotami z právě aktivního tématu. V SVG nemusíte nic dělat, aby toto přerenderování fungovalo.

Práce s editory SVG

Malé SVG mapy můžete psát ručně, jak jsme to udělali výše, ale pro cokoli přesahující několik oblastí budete chtít editor.

Většina editorů zvládá základy, s jednou zvláštností:

Některé SVG editory (včetně jinak velmi schopného webového Boxy SVG) odmítají přímo nastavit libovolné atributy, jako je name, na tvar.
Umožní vám však nastavit vlastní data atributy, jako je data-name.

Načítací program mapy regionu toto obejde tím, že data-name považuje za synonymum pro name. Při načítání kopíruje hodnotu data-name do name pro každý prvek, který ji má.

Takže pokud váš editor nemůže nastavit name, nastavte místo toho data-name, výsledek je stejný.
Totéž platí pro data-fill a data-stroke: jsou to přátelské aliasy, které přijme každý rozumný editor.

Uploading the map to LogMan.io

Jakmile je SVG připraveno:

  1. Otevřete Knihovnu a přejděte na Dashboards / Widgets / Maps /.
  2. Nahrajte soubor SVG. Použijte popisný, stabilní název souboru. Název souboru je identifikátor, na který se budete odkazovat v grafu, a jeho přejmenování později poškodí všechny grafy, které na něj odkazují.
  3. V Prozkoumat vytvořte nový graf typu Mapy regionů.
  4. V bočním panelu nastavte:
    • Mapa: název souboru, který jste právě nahráli (například NetworkZones.svg).
    • Skupina podle: pole, jehož hodnoty odpovídají názvům regionů (network.zone v našem příkladu).
  5. (Volitelné) Nastavte Barvu v rozsahu a Meze škály přiblížení dle potřeby.

Graf se vykreslí okamžitě. Oblasti, pro které aktuální dotaz vrátil data, jsou zbarveny podle barevné škály grafu; oblasti bez dat zůstávají v neutrální barvě „žádná data“ a zůstávají interaktivní. Při najetí myší se zobrazí klíč oblasti, což je užitečné při ověřování, že vaše atributy name odpovídají datům.

Tipy a nástrahy

Krátká sbírka věcí, které mají tendenci kousat začínající autory:

  • Case sensitivity. DMZ ≠ dmz. Pick lowercase or uppercase, and apply it consistently in the parser/enricher that produces the field and in the SVG. The bundled maps use lowercase.
  • Stable filenames. The filename in Library / Dashboards / Widgets / Maps / is the map identifier. Renaming or moving the file breaks every chart that references it.
  • One name per region, but it can be on multiple elements. If you want both the <rect> and the text label inside it to react to hover, give them the same name. LogMan.io treats them as one logical region.
  • Avoid filters, gradients, and clip-paths on data-driven regions. LogMan.io overwrites fill and stroke on the matched element. If the visual you want depends on a <filter> or a <linearGradient> referenced from fill="url(#…)", it will not survive the overwrite.
  • Keep chrome out of the data path. Anything that should not be coloured by the query must not have a name attribute. Otherwise an unrelated bucket key with the same value will accidentally light up your section header.
  • Multi-valued fields colour multiple regions. If threat.technique.id for one event is ["t1047", "t1059"], both regions receive the same value from that row. This is usually what you want, but be aware of it when designing dashboards on top of multi-valued fields.
  • Generate the SVG when the map gets big. Hand-authoring is fine for a handful of regions, but once you reach dozens or more, a small script that emits the <rect> elements (with name for data and data-fill / data-stroke for chrome) from a structured source is far easier to maintain than a manually drawn file.
  • Region not lighting up? Check, in order: (1) the name attribute exists and is spelled exactly like the bucket key; (2) the SVG is inside the <g id="layer-regions"> group; (3) the Group by field actually produces the value you expect, verify in the Discover screen first.

Závěr

Mapa regionu je v jádru velmi malá smlouva: každý interaktivní region v SVG nese atribut name, a tento řetězec je tím, proti čemu TeskaLabs LogMan.io porovnává klíče vytvořené dotazem group by. Přidejte data-fill a data-stroke na jakýkoli prvek, který nakreslíte, a stejné SVG funguje pro světlé i tmavé téma bez úprav.

S těmito dvěma nápady v ruce (name pro data, data-fill / data-stroke pro motiv) můžete proměnit téměř jakoukoli strukturovanou doménu na použitelnou, na motivy reagující mapu oblastí v TeskaLabs LogMan.io Explore. Začněte malým ručně kresleným diagramem a přejděte na skript generátoru, když počet oblastí překročí trpělivost editoru SVG.

Nové funkce v TeskaLabs LogMan.io v25.47

Datum vydání: 16.02.2026

LogMan.io v25.47 přináší kompletní redesign rozhraní Observability s intuitivním přizpůsobením Dashboardů, Homepage a obrazovky Discover klikáním. Vydání také výrazně zlepšuje výkon díky optimalizovanému algoritmu row lookup a rychlejšímu replay událostí.