Přeskočit obsah

Administration

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.