Archive¶

7. října 2026
v Administration, Archive
6 min čtení

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.