Připojení nového zdroje protokolu k LogMan.io

Předpoklady

Nájemce

Každému zákazníkovi je přiřazen docker-compose.yml, lmio-collector.conf a dalších 8 souborů...ned jeden nebo více tenantů. Tenanti jsou jména ASCII psaná malými písmeny, která označují data/logy patřící uživateli a ukládají data každého tenanta do samostatného indexu ElasticSearch. Všechny pruhy událostí (viz níže) jsou také specifické pro tenanty.

Vytvoření tenanta v SeaCat Auth pomocí uživatelského rozhraní LogMan.io.

Chcete-li vytvořit tenanta, přihlaste se do uživatelského rozhraní LogMan.io s rolí superuživatele, což lze provést prostřednictvím provisioningu. Další informace o provisioningu naleznete v části Provisioning mode dokumentace SeaCat Auth.

V uživatelském rozhraní LogMan.io přejděte v levém menu do sekce Auth a vyberte možnost Tenants. Jakmile se tam dostanete, klikněte na možnost Vytvořit nájemce a napište tam název nájemce. Poté klikněte na modré tlačítko a nájemce by měl být vytvořen:

Poté přejděte na Pověřovací údaje a přiřaďte nově vytvořeného nájemce všem příslušným uživatelům.

Šablony indexů ElasticSearch

V Kibaně by měl mít každý tenant šablony indexů lmio-tenant-events a lmio-tenant-others, kde tenant je název tenantu (viz referenční úložiště site- poskytnuté společností TeskaLabs), aby byly každému poli přiřazeny správné datové typy.

To je nutné zejména u polí založených na čase, která by bez šablony indexu nefungovala a nemohly by být použity pro třídění a vytváření indexových vzorů v systému Kibana.

Šablona indexu ElasticSearch by měla být přítomna v úložišti site-. pod názvem es_index_template.json.

Indexové šablony lze vložit prostřednictvím Dev Tools v levém menu Kibaby.

Zásady životního cyklu indexů ElasticSearch

Správa životního cyklu indexů (ILM) v ElasticSearch slouží k automatickému uzavření nebo odstranění starých indexů (např. s daty staršími než tři měsíce), aby byl zachován výkon vyhledávání a datové úložiště bylo schopno ukládat aktuální data. Nastavení je přítomno v takzvané politice ILM.

ILM by měla být nastavena před načerpáním dat do ElasticSearch, aby se nový index našel a spojil se správnou politikou ILM. Další informace naleznete v oficiální dokumentaci: https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-index-lifecycle-management.html

Komponenty LogMan.io, jako je Dispatcher, pak používají zadaný alias ILM (lmio-) a ElasticSearch automaticky umístí data do správného indexu přiřazeného pomocí politiky ILM.

Nastavení by mělo být provedeno následujícím způsobem:

Vytvořit politiku ILM

K vytvoření politiky ILM v ElasticSearch lze použít Kibanu verze 7.x.

1.) Otevřete Kibanu

2.) Klikněte na položku Správa v levém menu

3.) V sekci ElasticSearch klikněte na položku Zásady životního cyklu indexu.

4.) Klikněte na modré tlačítko Vytvořit zásady

5.) Zadejte její název, který by měl být stejný jako předpona indexu, např. lmio-.

6.) Nastavte maximální velikost indexu na požadovanou velikost rolování, např. 25 GB (velikost rolování).

7.) Nastavte maximální stáří indexu, např. 10 dní (časový rollover).

8.) Klepněte na přepínač dole na obrazovce ve fázi Odstranit a zadejte dobu, po které má být index odstraněn, např. 120 dní od rolloveru.

9.) Klikněte na zelené tlačítko Uložit zásady

Použijte zásady v šabloně indexu

Do šablony indexu JSON přidejte následující řádky:

"settings": {
  "index": {
    "lifecycle": {
      "name": "lmio-",
      "rollover_alias": "lmio-"
    }
  }
},

Indexy ElasticSearch

Prostřednictvím nástroje PostMan nebo Kibana vytvořte následující požadavek HTTP na instanci služby ElasticSearch, kterou používáte.

1.) Vytvořte index pro analyzované události/logy:

PUT lmio-tenant-events-000001
{
  "aliases": {
    "lmio-tenant-events": {
      "is_write_index": true
    }
  }
}

2.) Vytvoření indexu pro nerozdělené a chybové události/logy:

PUT lmio-tenant-others-000001
{
  "aliases": {
    "lmio-tenant-others": {
      "is_write_index": true
    }
  }
}

Alias pak bude použit politikou ILM k distribuci dat do správného indexu ElasticSearch, takže se čerpadla nemusí starat o číslo indexu.

/Poznámka: Předpona a číslo indexu pro převrácení ILM musí být odděleny pomocí -000001, nikoli _000001!//

Dráha události

Pruh událostí v LogMan.io definuje, jakým způsobem jsou protokoly z konkrétního zdroje dat pro daného nájemce odesílány do clusteru. Každý pruh událostí je specifický pro shromážděný zdroj. Každý pruh událostí se skládá z jedné služby lmio-collector, jedné služby lmio-ingestor a jedné nebo více instancí služby lmio-parser.

Collector

LogMan.io Collector by měl běžet na sběrném serveru nebo na jednom či více serverech LogMan.io, pokud jsou součástí stejné vnitřní sítě. Ukázka konfigurace je součástí referenčního úložiště site-.

LogMan.io Collector dokáže prostřednictvím konfigurace YAML otevřít port TCP/UDP, ze kterého bude získávat protokoly, číst soubory, otevřít server WEC, číst z témat Kafka, účtů Azure atd. Obsáhlá dokumentace je k dispozici zde: LogMan.io Collector

Následující ukázka konfigurace otevírá port 12009/UDP na serveru, na který je kolektor nainstalován, a přesměrovává shromážděná data prostřednictvím WebSocket na server lm11 na port 8600, kde by měl být spuštěn lmio-ingestor:

input:Datagram:UDPInput:
  adresa: 0.0.0.0:12009
  output: WebSocketOutput

output:WebSocket:WebSocketOutput:
  url: http://lm11:8600/ws
  tenant: mytenant
  debug: false
  prepend_meta: false

url je buď název hostitele serveru a port Ingestoru, pokud jsou Collector a Ingestor nasazeny na stejném serveru, nebo URL s https://, pokud je použit server Collector mimo vnitřní síť. Pak je nutné zadat certifikáty HTTPS, více informací naleznete v části output:WebSocket v příručce LogMan.io Collector Outputs.

Parametr tenant je název tenanta, ke kterému protokoly patří. Název tenantu se pak automaticky propaguje do Ingestoru a Parseru.

Ingestor

LogMan.io Ingestor přebírá zprávy logů z Collectoru spolu s metadaty a ukládá je do Kafky do tématu, které začíná předponou collected-tenant-, kde tenant je název tenantu, ke kterému logy patří, a technology je název technologie, ze které jsou data shromažďována, například microsoft-windows.

Následující sekce v souborech CONF je nutné nastavit vždy jinak pro každý pruh událostí:

# Výstup
[pipeline:WSPipeline:KafkaSink]
topic=sběrný-tenant-technologie

# Web API
[Web]
listen=0.0.0.0 8600

Port v sekci listen by měl odpovídat portu v konfiguraci YAML kolektoru (pokud je kolektor nasazen na stejném serveru) nebo nastavení v nginx (pokud jsou data sbírána ze serveru kolektoru mimo vnitřní síť). Viz referenční úložiště site-, které poskytli vývojáři společnosti TeskaLabs.

Parser

Parser by měl být nasazen ve více instancích, aby bylo možné škálovat výkon. Parsuje data z původních bajtů nebo řetězců do slovníku v zadaném schématu, jako je ECS (ElasticSearch Schema) nebo CEF (Common Event Format), přičemž používá parsovací skupinu z knihovny načtené v ZooKeeper. Je důležité zadat téma Kafka, ze kterého se má číst, což je stejné téma, jaké je zadáno v konfiguraci Ingestoru:

[deklarace]
library=zk://lm11:2181/lmio/library.lib
groups=Parsers/parsing-group
raw_event=log.original

# Pipeline
[pipeline:ParsersPipeline:KafkaSource]
topic=sběrný-tenant-technologie
group_id=lmio_parser_collected
auto.offset.reset=nejmenší

Parsers/parsing-group je umístění skupiny parsování z knihovny načtené do ZooKeeperu prostřednictvím LogMan.io Commander. Při prvním pokusu nemusí existovat, protože všechna data se pak automaticky odešlou do indexu lmio-tenant-others. Jakmile je parsovací skupina připravena, proběhne parsování a data lze zobrazit ve formátu dokumentu v indexu lmio-tenant-events.

Kafka topics

Před spuštěním všech tří služeb pomocí příkazu docker-compose up -d je důležité zkontrolovat stav konkrétního tématu Kafka collected-tenant-technology (kde tenant je název nájemce a technology je název připojené technologie/typu zařízení). V kontejneru Kafka (např.: docker exec -it lm11_kafka_1 bash) je třeba spustit následující příkazy:

/usr/bin/kafka-topics --zookeeper lm11:2181 --create --topic collected-tenant-technology --replication-factor 1 --partitions 6
/usr/bin/kafka-topics --zookeeper lm11:2181 --alter --topic collected-tenant-technology --config retention.ms=86400000

Parsování skupin

Pro většinu běžných technologií již TeskaLabs připravila parsovací skupiny podle schématu ECS. Obraťte se prosím na vývojáře společnosti TeskaLabs. Vzhledem k tomu, že všechny parsery jsou napsány v deklarativním jazyce, lze všechny parsovací skupiny v knihovně snadno upravit. Název skupiny by měl být stejný jako název atributu dataset zapsaný v deklaraci skupin parserů.

Další informace o našem deklarativním jazyce naleznete v oficiální dokumentaci: SP-Lang

Po nasazení skupiny parserů prostřednictvím nástroje LogMan.io Commander by měl být příslušný parser (příslušné parsery) restartován (restartovány).

Nasazení

Na serverech LogMan.io stačí spustit následující příkaz ve složce, do které je naklonováno úložiště site-:

docker-compose up -d

Kolekci protokolů lze poté zkontrolovat v kontejneru Docker Kafka prostřednictvím konzolového konzumenta Kafka:

/usr/bin/kafka-console-consumer --bootstrap-server lm11:9092 --topic collected-tenant-technology --from-beginning

Data jsou čerpána v Parseru z tématu collected-tenant-technology do tématu lmio-events nebo lmio-others a poté v Dispatcheru (lmio-dispatcher) do indexu lmio-tenant-events nebo lmio-tenant-others v ElasticSearch.