Úvod

Dokumentace TeskaLabs LogMan.io

Vítejte v dokumentaci TeskaLabs LogMan.io.

TeskaLabs LogMan.io

TeskaLabs LogMan.io™️ je softwarový produkt pro sběr, agregaci, ukládání a uchovávání logů, analýzu logů v reálném čase a rychlou reakci na incidenty v IT infrastruktuře, souhrnně označovaný jako log management.

TeskaLabs LogMan.io se skládá z centrální infrastruktury a sběračů protokolů, které jsou umístěny na sledovaných systémech, jako jsou servery nebo síťová zařízení. Kolektory protokolů shromažďují různé protokoly (operačního systému, aplikací, databází) a systémové metriky, jako je využití procesoru, paměti, místa na disku atd. Shromážděné události jsou v reálném čase odesílány do centrální infrastruktury ke konsolidaci, orchestraci a ukládání. Díky své povaze v reálném čase poskytuje LogMan.io upozornění na anomální situace z hlediska provozu systému (např. dochází místo na disku), dostupnosti (např. běží aplikace?), obchodu (např. je počet transakcí nižší než obvykle?) nebo bezpečnosti (např. nějaký neobvyklý přístup k serverům?).

TeskaLabs SIEM

TeskaLabs SIEM je nástroj pro správu bezpečnostních informací a událostí v reálném čase. TeskaLabs SIEM poskytuje v reálném čase analýzu a korelace bezpečnostních událostí a výstrah zpracovávaných systémem TeskaLabs LogMan.io. Aplikaci TeskaLabs SIEM jsme navrhli s cílem zlepšit pozici v oblasti kybernetické bezpečnosti a dodržování regulačních předpisů.

Více komponent

TeskaLabs SIEM a TeskaLabs LogMan.io jsou samostatné produkty. Díky modulární architektuře obsahují tyto produkty i další technologie TeskaLabs:

• TeskaLabs SeaCat Auth pro autentizaci, autorizaci včetně uživatelských rolí a jemné řízení přístupu.
• TeskaLabs SP-Lang je výrazový jazyk používaný na mnoha místech produktu.

Made with ❤️ by TeskaLabs

TeskaLabs LogMan.io™️ je produktem společnosti TeskaLabs.

Funkce

TeskaLabs LogMan.io je SIEM se správou protokolů v reálném čase.

• Multitenancy: Jedna instance TeskaLabs LogMan.io může obsluhovat více "tenantů" (zákazníků, oddělení).
• Multiuser: TeskaLabs LogMan.io může současně používat neomezený počet uživatelů.

Technologie

• ElasticSearch / OpenSearch
• Apache Kafka
• BitSwan

Kryptografie

• Transportní vrstva: TLS 1.2, TLS 1.3 a lepší
• Symetrická kryptografie: AES-128, AES-256, AES-512
• Asymetrická kryptografie: RSA, ECC.
• Metody Hash: SHA-256, SHA-384, SHA-512
• MAC funkce: HMAC
• HSM: PKCS#11 rozhraní.

Note

TeskaLabs LogMan.io používá pouze strong kryptografii, to znamená, že používáme pouze takové šifry, hashe a další algoritmy, které jsou kryptografickou komunitou a organizacemi, jako je ENISA nebo NIST, uznávány jako bezpečné.

Podporované zdroje logů

TeskaLabs Logman.io podporuje řadu různých technologií, které jsme uvedli níže.

Formáty

• Syslog RFC 5424 (IEFT)
• Syslog RFC 3164 (BSD)
• Syslog RFC 3195 (profil BEEP)
• Syslog RFC 6587 (Rámce přes TCP)
• Log událostí systému Windows
• SNMP
• ArcSight CEF
• LEEF
• JSON
• XML
• YAML
• Avro
• Vlastní formát logů

A mnoho dalších.

Prodejci a produkty

Cisco

• Cisco Firepower Threat Defense (FTD)
• Cisco Adaptive Security Appliance (ASA)
• Cisco Identity Services Engine (ISE)
• Cisco Meraki (zařízení MX, MS, MR)
• Přepínače Cisco Catalyst
• Systém Cisco IOS
• Cisco WLC
• Cisco ACS
• Cisco SMB
• Cisco UCS
• Cisco IronPort
• Cisco Nexus
• Směrovače Cisco
• Cisco VPN
• Cisco Umbrella

Palo Alto Networks

• Firewally nové generace Palo Alto
• Palo Alto Panorama (centralizovaná správa)
• Palo Alto Traps (ochrana koncových bodů)

Fortinet

• FortiGate (Firewally nové generace)
• FortiSwitch (přepínače)
• FortiAnalyzer (analýza logů)
• FortiMail (zabezpečení elektronické pošty)
• FortiWeb (Web Application Firewall)
• FortiADC
• FortiDDos
• FortiSandbox

Juniper Networks

• Řada Juniper SRX (firewally)
• Juniper MX Series (směrovače)
• Řada Juniper EX (přepínače)

Softwarové technologie Check Point

• Bezpečnostní brány Check Point
• Check Point SandBlast (prevence hrozeb)
• Check Point CloudGuard (zabezpečení cloudu)

Microsoft

• Microsoft Windows (operační systém)
• Microsoft Azure (cloudová platforma)
• Microsoft SQL Server (databáze)
• Microsoft IIS (webový server)
• Microsoft Office 365
• Microsoft Exchange
• Microsoft Sharepoint

Linux

• Ubuntu (distribuce)
• CentOS (distribuce)
• Debian (distribuce)
• Red Hat Enterprise Linux (distribuce)
• IPTables
• nftables
• Bash
• Cron
• Jádro (dmesg)

Oracle

• Databáze Oracle
• Oracle WebLogic Server (aplikační server)

Amazon Web Services (AWS)

• Amazon EC2 (virtuální servery)
• Amazon RDS (databázová služba)
• AWS Lambda (bezserverové výpočty)
• Amazon S3 (úložná služba)

VMware

• VMware ESXi (hypervizor)
• VMware vCenter Server (platforma pro správu)

F5 Networks

• F5 BIG-IP (řadiče pro doručování aplikací)
• F5 Advanced Web Application Firewall (WAF)

Barracuda Networks

• Firewall Barracuda CloudGen
• Barracuda Web Application Firewall
• Barracuda Email Security Gateway

Sophos

• Sophos XG Firewall
• Sophos UTM (Unified Threat Management)
• Sophos Intercept X (ochrana koncových bodů)

Aruba Networks (HPE)

• Přepínače Aruba
• Bezdrátové přístupové body Aruba
• Aruba ClearPass (řízení přístupu k síti)
• Aruba Mobility Controller

HPE

• iLO
• IMC
• HPE StoreOnce
• HPE Primera Storage
• HPE 3PAR StoreServ

Trend Micro

• Trend Micro Deep Security
• Trend Micro Deep Discovery
• Trend Micro TippingPoint (systém prevence narušení)
• Trend Micro Endpoint Protection Manager
• Trend Micro Apex One

Zscaler

• Zscaler Internet Access (Secure Web Gateway)
• Zscaler Private Access (vzdálený přístup)

Akamai

• Akamai (síť pro doručování obsahu a zabezpečení)
• Akamai Kona Site Defender (Web Application Firewall)
• Akamai Web Application Protector

Imperva

• Imperva Web Application Firewall (WAF)
• Imperva Database Security (monitorování databází)

SonicWall

• SonicWall Firewally nové generace
• SonicWall Email Security
• SonicWall Secure Mobile Access

WatchGuard Technologies

• WatchGuard Firebox (firewally)
• WatchGuard XTM (Unified Threat Management)
• WatchGuard Dimension (viditelnost zabezpečení sítě)

Apple

• macOS (operační systém)

Apache

• Apache Cassandra (databáze)
• Server Apache HTTP
• Apache Kafka
• Apache Tomcat
• Apache Zookeeper

NGINX

• NGINX (webový server a reverzní proxy server)

Docker

• Docker (kontejnerová platforma)

Kubernetes

• Kubernetes (orchestrace kontejnerů)

Atlassian

• Jira (sledování problémů a projektů)
• Confluence (software pro spolupráci)
• Bitbucket (spolupráce na kódu a řízení verzí)

Cloudflare

• Cloudflare (síť pro doručování obsahu a zabezpečení)

SAP

• SAP HANA (databáze)

Balabit

• syslog-ng

Open-source

• PostgreSQL (databáze)
• MySQL (Databáze)
• OpenSSH (vzdálený přístup)
• Dropbear SSH (vzdálený přístup)
• Jenkins (kontinuální integrace a kontinuální doručování)
• rsyslog
• GenieACS
• Haproxy
• spamassasin
• FreeRadius
• Bind
• DHCP
• Postfix
• Squid Cache
• Zabbix
• FileZilla

IBM

• IBM Db2 (databáze)
• IBM AIX (operační systém)
• IBM i (operační systém)

Brocade

• Přepínače Brocade

Google

• Google Cloud

Elastic

• ElasticSearch

Citrix

• Citrix Virtual Apps and Desktops (virtualizace)
• Citrix Hypervisor (virtualizace)
• Citrix ADC, NetScaler
• Citrix Gateway (vzdálený přístup)
• Citrix SD-WAN
• Citrix Endpoint Management (MDM, MAM)

Dell

• Dell EMC Isilon (síťové úložiště)
• Přepínače Dell PowerConnect
• Dell W-Series (přístupové body)
• Dell iDRAC
• Přepínače Dell Force10

FlowMon

• Flowmon Collector
• Flowmon Probe
• Flowmon ADS
• Flowmon FPI
• Flowmon APM

GreyCortex

• GreyCortex Mendel

Huawei

• Směrovače Huawei
• Přepínače Huawei
• Huawei Unified Security Gateway (USG)

Synology

• Synology NAS
• Synology SAN
• Synology NVR
• Synology Wi-Fi routery

Ubiquity

• UniFi

Avast

• Antivirus Avast

Kaspersky

• Kaspesky Endpoint Security
• Kaspesky Security Center

Kerio

• Kerio Connect
• Kerio Control
• Kerio Clear Web

Symantec

• Symantec Endpoint Protection Manager
• Symantec Messaging Gateway

ESET

• ESET Antivirus
• ESET Remote Administrator

AVG

• AVG Antivirus

Extreme Networks

• ExtremeXOS

IceWarp

• IceWarp Mail Server

Mikrotik

• Směrovače Mikrotic
• Přepínače Mikrotik

Pulse Secure

• Pulse Connect Secure SSL VPN

QNAP

• QNAP NAS

Safetica

• Safetica DLP

Veeam

• Veeam Backup and Restore

SuperMicro

• IPMI

Mongo

• MongoDB

YSoft

• SafeQ

Bitdefender

• Bitdefender GravityZone
• Bitdefender Network Traffic Security Analytics (NTSA)
• Bitdefender Advanced Threat Intelligence

Tento seznam není úplný, protože existuje mnoho dalších dodavatelů a produktů, které mohou odesílat logy do TeskaLabs LogMan.io pomocí standardních protokolů, jako je Syslog. Pokud usilujete o integraci konkrétní technologie, kontaktujte nás.

Extrakce logů SQL

TeskaLabs LogMan.io dokáže extrahovat logy z různých databází SQL pomocí ODBC (Open Database Connectivity).

Mezi podporované databáze patří:

Databáze:

• PostgreSQL
• Databáze Oracle
• IBM Db2
• MySQL
• SQLite
• MariaDB
• SAP HANA
• Sybase ASE
• Informix
• Teradata
• Amazon RDS (Relational Database Service)
• Google Cloud SQL
• Azure SQL Database
• Snowflake

TeskaLabs LogMan.io Architektura

lmio-collector

LogMan.io Collector slouží k přijímání logů z různých zdrojů, jako je SysLog NG, soubory, Windows Event Forwarding, databáze prostřednictvím konektorů ODBC atd. Logy mohou být dále zpracovávat deklarativním procesorem a vkládat do LogMan.io Ingestor prostřednictvím WebSocket.

lmio-ingestor

LogMan.io Ingestor přijímá události přes WebSocket, transformuje je do formátu čitelného pro Kafku. a vloží je do tématu Kafka collected-. Existuje více ingestorů pro různé formátů událostí, například SysLog, databáze, XML atd.

lmio-parser

LogMan.io Parser běží ve více instancích pro příjem různých formátů příchozích událostí. (různá témata Kafky) a/nebo stejné události (instance pak běží ve stejné skupině Kafky). a události se mezi ně rozdělují). LogMan.io Parser načítá knihovnu LogMan.io prostřednictvím ZooKeeper nebo ze souborů načítat deklarativní parsery a obohacovače z nakonfigurovaných skupin parsování.

Pokud byly události analyzovány načteným parserem, jsou vloženy do Kafka tématu lmio-events, v opačném případě vstoupí do tématu lmio-others Kafka.

lmio-dispatcher

LogMan.io Dispatcher načítá události z tématu lmio-events Kafka a odesílá je jak všem přihlášeným (přes ZooKeeper) instancím LogMan.io Correlator a ElasticSearch v systému příslušném indexu, kde lze všechny události vyhledávat a vizualizovat pomocí Kibany.

LogMan.io Dispatcher běží také ve více instancích.

lmio-correlator

LogMan.io Correlator používá ZooKeeper k odběru všech instancí LogMan.io Dispatcher. pro příjem analyzovaných událostí (logů atd.). Poté LogMan.io Correlator načte knihovnu LogMan.io. ze ZooKeeperu nebo ze souborů a vytváří korelátory na základě deklarativní konfigurace. Události vytvořené korelátory (Window Correlator, Match Correlator) jsou pak předávány dolů LogMan.io Dispatcher a LogMan.io Watcher prostřednictvím Kafky.

lmio-watcher

LogMan.io Watcher sleduje změny ve vyhledávačích používaných v LogMan.io parserech a LogMan.io korelátorech. instance. Když dojde ke změně, jsou upozorněny všechny spuštěné komponenty, které používají knihovnu LogMan.io. prostřednictvím tématu Kafka lmio-lookups o této změně a vyhledávání je aktualizováno v ElasticSearch, který slouží jako trvalé úložiště pro všechna vyhledávání.

lmio-integ

LogMan.io Integ umožňuje integraci LogMan.io s podporovanými externími systémy prostřednictvím očekávaného formátu zpráv. a výstupního/vstupního protokolu.

Podpora

Živá nápověda

Náš tým je k dispozici na našem kanálu živé podpory na adrese Slack. Můžete přímo poslat zprávu našim interním odborníkům, konzultovat své plány, problémy a výzvy a dokonce získat online živou pomoc přes sdílenou obrazovku, takže se nemusíte bát zásadních upgradů apod. Přístup je poskytován zákazníkům s aktivním plánem podpory.

E-mailová podpora

Kontaktujte nás na adrese: support@teskalabs.com

Hodiny podpory

Úroveň podpory 5/8 je dostupná v pracovní dny podle českého kalendáře, 09-18 středoevropského času (Evropa/Praha).

V závislosti na vašem aktivním plánu podpory je k dispozici také úroveň podpory 24/7.

Ended: Úvod

Uživatelská přiručka

Uživatelská příručka

TeskaLabs LogMan.io poskytuje uživatelské rozhraní navržené pro hladší interakci se softwarovými komponentami LogMan.io.

Úvod do uživatelského rozhraní LogMan.io

Discover

Discover je domovská stránka služby LogMan.io.

Jednotlivé sekce můžete snadno procházet na panelu bočního menu:

Boční menu

• Discover
• Dashboardy
• Export
• Knihovna
• Vyhledávání
• Nástroje
• Údržba
• Autorizace

Horní panel aplikace LogMan.io se skládá z následujících částí:

• Motiv (tmavý nebo světlý režim)
• Volba jazyka
• Nájemci
• Můj účet

Prompt

• Syntaxe Lucene se používá pro specifikaci vyhledávání a filtrování požadovaných hodnot atributů.
• Například: filtrování pro následující hodnoty: event.dataset "Microsoft-office-365" AND event.action: "UserLoggedIn".
• Je možné vyfiltrovat hodnoty požadovaného časového okna v absolutních nebo relativních hodnotách.

Vizualizace množství a četnosti příchozích protokolů v čase

Příchozí události v posledním časovém okně

Přístrojové panely

• Dashboardy slouží k vizualizaci dat. Podle obrázku výše si můžete vybrat z široké škály možností widgetů, včetně koláčových grafů, sloupcových grafů, tabulek a widgetů s jednotlivými hodnotami. Každý widget má v levém horním rohu možnost přepnutí na tabulku kliknutím.
• Pomocí řádku Prompt můžete vyfiltrovat hodnoty, které vás zajímají, včetně časového okna.

Knihovna

Knihovna je místo, kde je uložen veškerý obsah dostupný v LogMan.io. Obvykle se dělí na následující části:

• Korelátory
• Dashboardy
• Parsery
• Schémata

Korelátory

• Sada korelačních a detekčních pravidel umožňující vyhledat vzor v sérii událostí, které by mohly signalizovat potenciální zranitelnost.
• Mohou to být případy, jako je několikanásobné neúspěšné přihlášení v krátkém časovém období, neobvyklá ip adresa apod.
• Korelátory jsou zapsány ve formátu .yaml.

Parsery

• Parsery jsou komponenty odpovědné za primární analýzu a rozklad protokolu nebo události bezprostředně po jejich příchodu do LogMan.io.

• Logy jsou analyzovány na základní analyzovatelné atributy, jako je @timestamp, ip.address, user.name atd.

Nástroje

LogMan.io používá následující open-source nástroje:

• Jupyter: skupina softwarových produktů umožňující programování prostřednictvím webových rozhraní.

• Zookeper: open-source server pro vysoce spolehlivou distribuovanou koordinaci cloudových aplikací.

• Kafka : open-source platforma pro distribuované streamování událostí, která se používá pro vysoce výkonné datové pipeline a streamingovou analýzu.

• Grafana: multiplatformní open-source analytická a interaktivní vizualizační webová aplikace. Po připojení k podporovaným zdrojům dat poskytuje grafy, diagramy a upozornění pro web.

• Kibana: software pro vizualizaci dat na panelu pro Elasticsearch, který je k dispozici se zdrojovým kódem.

LogMan.io Průzkumník

Obrazovka Discover pomáhá uživateli prozkoumat data ve velkém rozlišení a zobrazit všechny požadované detaily. Uživatel může zadávat dotazy pro zvýšení podrobnosti vyhledávání.

Přehled Discover

Detail Discover

Dashboardy LogMan.io

Obrazovka Dashboards umožňuje uživateli zobrazovat data v různých widgetech. Podobně jako v Discover - podle dotazů a časového rozsahu - lze filtrovat požadovaný výstup. Widgety lze na mřížce dashboardu libovolně umisťovat a měnit jejich velikost.

Příklad ovládacího panelu Office 365

Hlavní přehled

Dashboard se zobrazením grafu a tabulky

Příklad vlastního řídicího panelu

Exporty

LogMan.io Export je nástroj, který poskytuje prostředky pro dotazování a export dat z různých technologií. Uživatel může tyto exporty vytvářet, spouštět, odstraňovat nebo stahovat.

Knihovna

LogMan.io Library (dále "knihovna") je nástroj pro zobrazení podrobností o dostupných knihovnách LogMan.io. Uživatel má možnost spravovat soubory nebo sekce.

Tip

Více informací o knihovně naleznete zde.

LogMan.io Lookups

LogMan.io Lookups slouží ke správě Lookups.

Tip

Širší informace o vyhledávání najdete zde.

Nástroje LogMan.io

LogMan.io Tools je obrazovka pro rychlý přístup k externím komponentám, jako je Kibana, Grafana atd. Je široce přizpůsobitelná.

Řízení přístupu

Auth je modul uživatelského rozhraní LogMan.io, který slouží ke správě pověření.

Tip

Chcete-li získat více informací o modulu Auth, podívejte se do jeho repozitáře na GitHub.com.

Pověření

Obrazovka Pověření poskytuje funkce pro správu uživatelských pověření.

Tenanti

Obrazovka "Tenants" poskytuje funkce pro správu tenantů.

Zdroje

Obrazovka Zdroje poskytuje funkce správy zdrojů.

Role

Obrazovka Role poskytuje funkci správy rolí.

Relace

Obrazovka Relace poskytuje funkce správy relací.

Konfigurace

Konfigurace LogMan.io umožňuje spravovat (nejen) konfiguraci LogMan.io.

Služby

LogMan.io Services zobrazí seznam používaných služeb a jejich podrobnosti.

Pokročilý režim

Některé obrazovky mohou zobrazovat více informací, obvykle v technické podobě (tzv. JSON). Takový režim se nazývá "pokročilý režim".

Pokročilý režim lze v prohlížeči aktivovat stisknutím CTRL 1 v systému Linux a CTRL Q v systému Windows - a deaktivovat opětovným stisknutím CTRL 1 nebo CTRL Q.

Ve výchozím nastavení je pokročilý režim deaktivován.

Tabulka s aktivovaným rozšířeným režimem

Tabulka s deaktivovaným pokročilým režimem

Tabulka s aktivovaným pokročilým režimem

Obrazovka s deaktivovaným rozšířeným režimem

Ended: Uživatelská přiručka

Adminitrátorská přiručka

Adminitrátorská přiručka

Instalace

TeskaLabs LogMan.io lze na výpočetní zdroje nainstalovat ručně. Výpočetní zdroje zahrnují fyzické servery, virtuální servery, soukromé a veřejné cloudové výpočetní/VM instance atd.

Danger

TeskaLabs LogMan.io NELZE provozovat pod uživatelem root (superuživatelem). Porušení tohoto pravidla může vést k významným rizikům pro kybernetickou bezpečnost.

Předpoklady

• Hardware (fyzický nebo virtualizovaný server)
• OS Linux: (v případě zájmu kontaktujte laskavě naši podporu).
• IP konektivita, která zahrnuje odchozí přístup k internetu (po počáteční instalaci může být omezena).
• server SMTP
• doména DNS, i interní pro nastavení HTTPS
• Přihlašovací údaje k "docker.teskalabs.com" (pokud je nemáte, kontaktujte naši podporu).

Ze serveru Bare Metal do operačního systému

Note

Tuto část přeskočte, pokud instalujete na virtuální počítač, resp. na hostitele s již nainstalovaným operačním systémem.

Předpoklady

• Server, který odpovídá předepsané organizaci datového úložiště.
• Bootovací USB disk s Ubuntu Server 22.04 LTS; nejnovější vydání.
• Přístup k serveru vybavenému monitorem a klávesnicí; případně přes IPMI.
• Připojení k internetu pro server, IPv4 zajišťuje server DHCP.

Note

Jedná se o další předpoklady nad rámec obecných předpokladů uvedených výše.

Kroky

1) Spusťte server pomocí bootovacího USB disku se systémem Ubuntu Server.

Vložte bootovací USB disk do USB portu serveru a zapněte server.

Jako spouštěcí zařízení použijte oddíl UEFI na paměti USB.

V zaváděcí nabídce vyberte možnost "Try or Install Ubuntu Server".

2) Jako jazyk vyberte "English ".

3) V případě potřeby proveďte aktualizaci na nový instalační program

4) Vyberte české rozložení klávesnice

5) Vyberte typ instalace "Ubuntu Server ".

6) Konfigurace síťového připojení

Toto je konfigurace sítě pro účely instalace, konečná konfigurace sítě se může lišit.
Pokud používáte server DHCP, je konfigurace sítě automatická.

DŮLEŽITÉ: Musí být k dispozici připojení k internetu.

IP adresu serveru si poznamenejte pro budoucí použití.

7) Přeskočení nebo konfigurace proxy serveru

Přeskočte (stiskněte tlačítko "Hotovo") konfiguraci serveru proxy.

8) Potvrzení vybrané adresy zrcadla

Stisknutím tlačítka "Hotovo" potvrďte zvolenou adresu zrcadla.

9) Zvolte "Vlastní rozložení úložiště ".

Vlastní rozložení úložiště, které vytvoříme, je následující:

Připojení	Velikost	Systém souborů	Odddělení	Část RAID	Skupina svazků	Logický svazek	.
/boot/efi	1G	fat32	1
SWAP	64G		2
/boot	512M	ext4	3	md0	1
/	50G	etx4			2	systemvg	rootlv
/var/log	50G	etx4				loglv

10) Určete dvě jednotky systémového úložiště

Dvě systémové úložné jednotky jsou uspořádány symetricky, aby byla zajištěna redundance v případě selhání jedné systémové jednotky.

Note

Rychlé a pomalé úložiště se zde NEKONFIGURUJE během instalace operačního systému, ale později z nainstalovaného operačního systému.

11) Nastavte první systémové úložiště jako primární spouštěcí zařízení

Tento krok vytvoří první GPT oddíl s UEFI, který je připojen na adrese /boot/efi. Velikost tohoto oddílu je přibližně 1 GB.

12) Nastavte druhé systémové úložiště jako sekundární spouštěcí zařízení.

Na druhém systémovém úložišti se vytvoří další oddíl UEFI.

13) Vytvoření oddílů SWAP na obou systémových úložných jednotkách

Na každou ze dvou jednotek přidejte oddíl GPT o velikosti 64G a naformátujte swap.

Na příslušné systémové úložné jednotce vyberte položku "volné místo" a poté "Přidat oddíl GPT".

Výsledné rozložení je následující:

14) Vytvoření oddílu GPT pro RAID1 na obou jednotkách systémového úložiště

Na každou ze dvou jednotek přidejte oddíl GPT s veškerým zbývajícím volným místem. Formát je "Ponechat neformátovaný", protože tento oddíl bude přidán do pole RAID1. Položku "Size" (Velikost) můžete ponechat prázdnou, abyste využili veškeré zbývající místo na zařízení.

Výsledkem je položka "oddíl" místo "volného místa" na příslušných jednotkách.

15) Vytvoření softwarového pole RAID1

Vyberte "Vytvořit softwarový RAID (md)".
Název pole je md0 (výchozí).
Úroveň RAID je "1 (zrcadlený)".

Vyberte dva oddíly z předchozího kroku, ponechte je označené jako "aktivní" a stiskněte tlačítko "Vytvořit".

Rozložení systémových úložných jednotek je následující:

16) Vytvoření BOOT oddílu RAID1

Přidejte oddíl GPT na md0 RAID1 z předchozího kroku.

Velikost je 512 MB, formát ext4 a přípojné místo /boot.

17) Nastavte oddíl LVM na RAID1.

Zbývající prostor na RAID1 bude spravován pomocí LVM.

Přidejte oddíl GPT na RAID1 md0 pomocí položky "free space" (volné místo) v zařízení md0.

Použijte maximální dostupné místo a nastavte formát na "Leave unformatted". Položku "Velikost" můžete ponechat prázdnou, abyste využili veškeré zbývající místo v zařízení.

18) Nastavení skupiny systémových svazků LVM

Vyberte možnost "Vytvořit skupinu svazků (LVM)".
Název skupiny svazků je systemvg.

Vyberte dostupný oddíl na md0, který byl vytvořen výše.

19) Vytvoření kořenového logického svazku

Přidejte logický svazek s názvem rootlv na systemvg (v položce "free space"), velikost je 50G, formát je ext4 a připojení je /.

20) Přidání vyhrazeného logického svazku pro systémové protokoly

Přidejte logický svazek s názvem loglv na systemvg, velikost je 50G, formát je ext4 a přípojka je "Other" a /var/log.

21) Potvrďte rozložení systémových úložných jednotek.

Stisknutím tlačítka "Done" (Hotovo) v dolní části obrazovky a nakonec tlačítka "Continue" (Pokračovat) potvrďte použití akcí na jednotkách systémového úložiště.

22) Nastavení profilu

Vaše jméno: TeskaLabs Admin (Správce laboratoří)
Název vašeho serveru: lm01 (například)
Zvolte si uživatelské jméno: tladmin

Zvolte dočasné heslo, bude odstraněno na konci instalace.

23) Nastavení SSH

Vyberte možnost "Nainstalovat server OpenSSH"

24) Přeskočte snapy serveru

Stiskněte tlačítko "Hotovo", na této obrazovce nebudou nainstalovány žádné snapy serveru.

25) Počkejte, až bude server nainstalován

Trvá to přibližně 10 minut.

Po dokončení instalace, včetně aktualizace zabezpečení, vyberte možnost "Reboot Now".

26) Po výzvě vyjměte USB disk ze serveru.

Stisknutím tlačítka "Enter" pokračujte v procesu restartu.

Note

Tento krok můžete přeskočit, pokud instalujete přes IPMI.

27) Spusťte server do nainstalovaného operačního systému

Na obrazovce GRUB vyberte možnost "Ubuntu" nebo počkejte 30 sekund.

28) Přihlaste se jako tladmin

29) Aktualizujte operační systém

sudo apt update
sudo apt upgrade
sudo apt autoremove

30) Konfigurace pomalého ukládání dat

Pomalé datové úložiště (HDD) je připojeno na /data/hdd.

Předpokládejme, že server poskytuje následující disková zařízení /dev/sdc, /dev/sdd, /dev/sde, /dev/sdf, /dev/sdg a /dev/sdh.

Vytvořte softwarové pole RAID5 na /dev/md1 se souborovým systémem ext4 připojeným na /data/hdd.

sudo mdadm --create /dev/md1 --level=5 --raid-devices=6 /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh

Note

Pro pole RAID6 použijte --level=6.

Vytvořte souborový systém EXT4 a přípojný bod:

sudo mkfs.ext4 /dev/md1
sudo mkdir -p /data/hdd

Do /etc/fstab zadejte následující řádek:

/dev/md1 /data/hdd ext4 defaults,noatime 0 1

Připojte disk:

sudo mount /data/hdd

Note

Sestavení pole RAID může trvat značně dlouho. Průběh můžete sledovat pomocí cat /proc/mdstat. Restartování serveru je během výstavby pole RAID bezpečné.

Konstrukci můžete urychlit zvýšením rychlostních limitů:

sudo sysctl -w dev.raid.speed_limit_min=5000000
sudo sysctl -w dev.raid.speed_limit_max=50000000

Toto nastavení rychlostního limitu vydrží až do příštího restartu.

31) Konfigurace rychlého ukládání dat

Rychlé datové úložiště (SSD) je připojeno na adrese /data/ssd.

Za předpokladu, že server poskytuje následující disková zařízení /dev/nvme0n1 a /dev/nvme1n1.

Vytvořte softwarové pole RAID1 na /dev/md2 se souborovým systémem ext4, připojeným na /data/ssd.

sudo mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1
sudo mkfs.ext4 /dev/md2
sudo mkdir -p /data/ssd

Do /etc/fstab zadejte následující řádek:

/dev/md2 /data/ssd ext4 defaults,noatime 0 1

Připojte jednotku:

sudo mount /data/ssd

32) Instalace operačního systému je dokončena

Zde je video, které rekapituluje proces instalace:

Z operačního systému do Dockeru

Předpoklady

• Spuštěný server s nainstalovaným operačním systémem.
• Přístup k serveru přes SSH, uživatel tladmin s oprávněním provádět sudo.
• Pomalé úložiště připojené na /data/hdd.
• Rychlé úložiště připojené na /data/ssd.

Kroky

1) Přihlaste se k serveru přes SSH jako uživatel tladmin.

ssh tladmin@<ip-of-the-server>

2) Konfigurace přístupu SSH

Nainstalujte veřejné klíče SSH pro uživatele tladmin:

cat > /home/tladmin/.ssh/authorized_keys

Omezení přístupu:

sudo vi /etc/ssh/sshd_config

Změny v ssh_config:

PermitRootLogin ne
PubkeyAuthentication yes
PasswordAuthentication ne

3) Zvýšení parametru VM max_map_count

Zapište tento obsah do souboru /etc/sysctl.d/01-vm.conf.

vm.max_map_count=262144

4) Instalace nástroje Docker

Docker je nezbytný pro nasazení všech mikroslužeb LogMan.io v kontejnerech, konkrétně Apache Kafka, ElasticSearch, NGINX a jednotlivých streamovacích pump atd.

Vytvořte logický svazek dockerlv se souborovým systémem EXT4:

sudo lvcreate -L100G -n dockerlv systemvg
sudo mkfs.ext4 /dev/systemvg/dockerlv
sudo mkdir /var/lib/dockervv

Zadejte následující řádek do /etc/fstab:

/dev/systemvg/dockerlv /var/lib/docker ext4 defaults,noatime 0 1

Připojení svazku:

sudo mount /var/lib/docker

Nainstalujte balíček Docker:

sudo apt-get install ca-certificates curl gnupg lsb-release
sudo mkdir -p /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo usermod -aG docker tladmin

Znovu se přihlaste k serveru, abyste použili změnu skupiny.

5) Nainstalujte git

sudo apt install git

6) Konfigurace rozlišení názvů hostitelů (volitelně)

Klastr TeskaLabs LogMan.io vyžaduje, aby každý uzel dokázal ze svého hostitelského jména přeložit IP adresu libovolného jiného uzlu klastru. Pokud nakonfigurovaný server DNS tuto možnost neposkytuje, je třeba do souboru /etc/hosts vložit názvy uzlů a jejich IP adresy.

sudo vi /etc/hosts

Příklad:

192.168.108.120 lm01
192.168.108.121 lm11
192.168.108.122 lm21

7) Restartujte server

sudo reboot

Z Dockeru do běžícího LogMan.io

Kroky

1) Vytvoření struktury složek

sudo mkdir -p \
  /data/ssd/zookeeper/data \
  /data/ssd/zookeeper/log \
  /data/ssd/kafka/kafka-1/data \
  /data/ssd/elasticsearch/es-master/data \
  /data/ssd/elasticsearch/es-hot01/data \
  /data/ssd/elasticsearch/es-warm01/data \
  /data/hdd/elasticsearch/es-cold01/data \
  /data/ssd/influxdb/data \
  /data/hdd/nginx/log

Změna vlastnictví na složku elasticsearch data:

sudo chown -R 1000:0 /data/ssd/elasticsearch
sudo chown -R 1000:0 /data/hdd/elasticsearch

2) Naklonujte konfigurační soubory webu do složky /opt:

cd /opt
git clone https://gitlab.com/TeskaLabs/<PARTNER_GROUP>/<MY_CONFIG_REPO_PATH>

Přihlaste se na docker.teskalabs.com.

cd <MY_CONFIG_REPO_PATH>
docker login docker.teskalabs.com

Vstupte do úložiště a nasaďte soubor Docker Compose specifický pro server:

docker compose -f docker-compose-<SERVER_ID>.yml pull
docker compose -f docker-compose-<SERVER_ID>.yml build
docker compose -f docker-compose-<SERVER_ID>.yml up -d

Zkontrolujte, zda jsou všechny kontejnery spuštěny:

docker ps

Hardware pro TeskaLabs LogMan.io

Jedná se o hardwarovou specifikaci určenou pro vertikální škálovatelnost. Je optimalizována pro ty, kteří plánují vybudovat počáteční TeskaLabs LogMan.io cluster s co nejnižšími náklady, avšak s možností postupného přidávání dalšího hardwaru podle toho, jak se cluster rozrůstá. Tato specifikace je také plně kompatibilní se strategií horizontální škálovatelnosti, což znamená přidání jednoho nebo více nových serverových uzlů do clusteru.

Specifikace

• Skříň: 2U
• Přední přihrádky na pevné disky: Pro datové pevné disky, hot-swap.
• Zadní přihrádky pro pevné disky: 2 pozice pro disky, 2,5", pro pevné disky s operačním systémem, hot-swap.
• Procesor: 1× AMD EPYC 32 jader
• Operační paměť: 256 GB DDR4 3200, s použitím 64GB modulů
• Datové SSD: 2x 2TB SSD NVMe, PCIe 3.0+
• Datový řadič SSD: nebo použijte sloty NVMe na základní desce.
• Datové HDD: 3x 18TB SATA 2/3+ nebo SAS 1/2/3+, 6+ Gb/s, 7200 ot.
• Řadič datového HDD: HBA nebo karta v režimu IT, SATA nebo SAS, JBOD, bez RAID, hot-swap
• OS HDD: 2x 128GB+ SSD SATA 2/3+, HBA, bez RAID, přímo připojený k základní desce SATA
• Síťová karta: 2x 1Gbps+ Ethernet NIC
• Napájecí zdroj: redundantní 920W
• IPMI nebo ekvivalentní zařízení

Note

RAID je implementován v softwaru/OS.

Vertikální škálovatelnost

• Přidání jednoho dalšího procesoru (celkem 2 procesory), pro tuto možnost je nutná základní deska se 2 sloty pro procesory.
• Přidejte paměť RAM až do velikosti 512 GB
• Přidejte až 9 dalších Data HDD, maximálně 198 TB prostoru při použití 12x 18 TB HDD v RAID5

Note

K dispozici jsou také varianty 3U a 4U s 16, resp. 24 pozicemi pro disky.

---

Poslední aktualizace: květen 2023

Datové úložište

TeskaLabs LogMan.io pracuje s několika různými úrovněmi datových úložišť, aby bylo dosaženo optimální izolace dat, výkonu a nákladů.

Struktura ukládání dat

Schema: Doporučená struktura datového úložiště.

Rychlé úložiště dat

Rychlé úložiště dat (známé také jako "horká" úroveň) obsahuje nejčerstvější logů a další události přijaté do systému TeskaLabs LogMan.io. Doporučujeme používat nejrychlejší možnou třídu úložiště pro dosažení nejlepší propustnosti a výkonu vyhledávání. Komponenta reálného času (Apache Kafka) rovněž používá rychlé datové úložiště pro perzistenci datového toku.

• Doporučené časové rozpětí: jeden den až jeden týden.
• Doporučená velikost: 2 TB - 4 TB
• Doporučená redundance: Doporučená redundance: RAID 1, další redundanci zajišťuje aplikační vrstva.
• Doporučený hardware: SSD NVMe PCIe 4.0 a lepší.
• Fyzická zařízení pro rychlé ukládání dat MUSÍ BÝT spravována nástrojem mdadm
• Přípojný bod: /data/ssd
• Souborový systém: Pro optimální výkon se doporučuje nastavit příznak noatime.

Strategie zálohování

Příchozí události (protokoly) jsou kopírovány do archivního úložiště, jakmile vstoupí do TeskaLabs LogMan.io. To znamená, že vždy existuje způsob, jak v případě potřeby "přehrát" události do TeskaLabs LogMan.io. Také data jsou replikována do ostatních uzlů clusteru ihned po příchodu do clusteru. Z tohoto důvodu se tradiční zálohování nedoporučuje, ale je možné.

Obnovu zajišťují komponenty clusteru replikací dat z ostatních uzlů clusteru.

Example

/data/ssd/kafka-1
/data/ssd/elasticsearch/es-master
/data/ssd/elasticsearch/es-hot1
/data/ssd/zookeeper-1
/data/ssd/influxdb-2
...

Pomalé datové uložiště

Pomalé úložiště obsahuje data, ke kterým není nutné přistupovat rychle, a obvykle obsahuje starší logy a události, například teplé a studené indexy pro ElasticSearch.

• Doporučená redundance: softwarový RAID 6 nebo RAID 5; RAID 0 pro virtualizované/cloudové instance s redundancí základního úložiště.
• Doporučený hardware: Nákladově efektivní pevné disky, SATA 2/3+, SAS 1/2/3+.
• Typická velikost: desítky TB, např. 18 TB
• Řídicí karta: (režim IT): SATA nebo HBA SAS
• Fyzická zařízení pro pomalé ukládání dat MUSÍ BÝT spravována softwarovým RAID (mdadm).
• Přípojný bod: /data/hdd
• Souborový systém: Pro optimální výkon se doporučuje nastavit příznak noatime.

Výpočet kapacity clusteru

Toto je vzorec pro výpočet celkové dostupné kapacity clusteru na pomalém datovém úložišti.

celkem = (disky-raid) * kapacita * servery / replika

• disky je počet pomalých disků pro ukládání dat na server
• raid je režie RAID, 1 pro RAID5 a 2 pro RAID6
• kapacita je kapacita disku pro pomalé ukládání dat
• servery je počet serverů
• replica je replikační faktor v ElasticSearch

Example

(6[disků]-2[raid6]) * 18TB[kapacita] * 3[servery] / 2[replika] = 108TB

Strategie zálohování

Data uložená na pomalém datovém úložišti jsou VŽDY replikována do ostatních uzlů clusteru a také uložena v archivu. Z tohoto důvodu se tradiční zálohování nedoporučuje, ale je možné (vezměte v úvahu obrovskou velikost pomalého úložiště).

Obnovu zajišťují komponenty clusteru replikací dat z ostatních uzlů clusteru.

Example

/data/hdd/elasticsearch/es-warm01
/data/hdd/elasticsearch/es-warm02
/data/hdd/elasticsearch/es-cold01
/data/hdd/mongo-2
/data/hdd/nginx-1
...

Strategie ukládání velkých pomalých dat

Pokud bude vaše pomalé datové úložiště větší než >50 TB, doporučujeme jako optimální strategii pro škálování pomalého datového úložiště použít řadiče HBA SAS, expandéry SAS a JBOD. Připojení úložišť SAS lze řetězit, aby bylo možné připojit velký počet jednotek. Externí šasi JBOD lze také připojit pomocí SAS a poskytnout tak prostor pro další disky.

RAID 6 vs RAID 5

RAID 6 a RAID 5 jsou oba typy RAID (redundantní pole nezávislých disků), které používají prokládání dat a paritu k zajištění redundance dat a vyššího výkonu.

RAID 5 používá prokládání dat na více disků, přičemž jeden paritní blok se počítá pro všechny disky. Pokud dojde k selhání jednoho z disků, lze data stále rekonstruovat pomocí paritních informací. Pokud však druhý disk selže dříve, než je první disk nahrazen, jsou data ztracena.

Naproti tomu pole RAID 6 používá prokládání a dva nezávislé paritní bloky, které jsou uloženy na samostatných discích. Pokud dojde k selhání dvou disků, lze data stále rekonstruovat pomocí paritních informací. RAID 6 poskytuje ve srovnání s RAID 5 další úroveň ochrany dat. RAID 6 však také zvyšuje režii a snižuje kapacitu úložiště kvůli dvěma paritním blokům.

Pokud jde o pomalé ukládání dat, je RAID 5 obecně považován za méně bezpečný než RAID 6, protože data protokolu jsou obvykle životně důležitá a selhání dvou disků by mohlo způsobit ztrátu dat. V tomto případě je nejlepší RAID 6, protože dokáže přežít dvě selhání disku a poskytuje větší ochranu dat.

V případě pole RAID 5 je potřebný počet disků (N-1), kde N je počet disků v poli. Je to proto, že jeden z disků se používá pro paritní informace, které slouží k rekonstrukci dat v případě selhání jednoho disku. Chcete-li například vytvořit pole RAID 5 s kapacitou 54 TB, budete potřebovat alespoň čtyři (4) disky, každý o kapacitě alespoň 18 TB.

V případě pole RAID 6 je potřebný počet disků (N-2). Je to proto, že používá dvě sady paritních informací uložených na samostatných discích. Díky tomu může RAID 6 přežít selhání až dvou disků, než dojde ke ztrátě dat. Chcete-li například vytvořit pole RAID 6 s kapacitou 54 TB, budete potřebovat nejméně pět (5) disků, každý o kapacitě alespoň 18 TB.

Je důležité si uvědomit, že pole RAID 6 vyžaduje více místa na disku, protože používá dva paritní bloky, zatímco RAID5 používá pouze jeden. Proto RAID 6 vyžaduje ve srovnání s RAID 5 další disky. RAID 6 však poskytuje dodatečnou ochranu a dokáže přežít i dvě selhání disku.

Za zmínku stojí, že data v pomalém datovém úložišti jsou replikována napříč clusterem (pokud je to možné), aby byla zajištěna další redundance dat.

Tip

K výpočtu požadavků na úložiště použijte Online RAID Calulator.

Systémové úložiště

Systémové úložiště je určeno pro operační systém, instalace softwaru a konfigurace. V systémovém úložišti nejsou uložena žádná provozní data. Instalace na virtualizačních platformách využívá běžně dostupný lokálně redundantní diskový prostor.

• Doporučená velikost: 250 GB a více
• Doporučený hardware: dva (2) místní disky SSD v softwarovém RAID 1 (zrcadlení), SATA 2/3+, SAS 1/2/3+.

V případě potřeby se doporučuje následující rozdělení úložiště na parity:

• EFI oddíl, připojený na /boot/efi, velikost 1 GB.
• výměnný oddíl, 64 GB
• Softwarový RAID1 (mdadm) na zbytku prostoru
• Zaváděcí oddíl na RAID1, připojený na /boot, velikost 512 MB, souborový systém ext4.
• Oddíl LVM na RAID1, zbytek dostupného prostoru se skupinou svazků systemvg.
• Logický svazek LVM rootlv, připojený na /, velikost 50 GB, souborový systém ext4
• Logický svazek LVM loglv, připojený na /var/log, velikost 50 GB, souborový systém ext4
• Logický svazek LVM dockerlv, připojený na /var/lib/docker, velikost 100 GB, souborový systém ext4 (je-li k dispozici)

Strategie zálohování systémového úložiště

Doporučujeme pravidelně zálohovat všechny souborové systémy v systémovém úložišti, aby je bylo možné v případě potřeby použít pro obnovení instalace. Zálohovací strategie je kompatibilní s většinou běžných zálohovacích technologií na trhu.

• Cíl bodu obnovy (RPO): úplné zálohování jednou týdně nebo po větších údržbových pracích, přírůstkové zálohování jednou denně.
• Cíl doby obnovy (RTO): 12 hodin.

Note

RPO a RTO jsou doporučené za předpokladu vysoce dostupného nastavení clusteru LogMan.io. To znamená tři a více uzlů, aby úplný výpadek jediného uzlu neměl dopad na dostupnost služby.

Ukládání archivních dat

Ukládání dat do archivu je doporučené, ale nepovinné. Slouží k velmi dlouhému uchovávání dat a k redundanci. Představuje také ekonomický způsob dlouhodobého ukládání dat. Data nejsou v clusteru k dispozici online, je třeba je v případě potřeby obnovit zpět, což je spojeno s určitým intervalem "time-to-data".

Data jsou při kopírování do archivu komprimována, typický kompresní poměr se pohybuje v rozmezí 1:10 až 1:2 v závislosti na povaze logů.

Data jsou do úložiště replikována po počáteční konsolidaci na rychlém datovém úložišti, prakticky ihned po požití do clusteru.

• Doporučené technologie: SAN / NAS / Cloudové úložiště (AWS S3, MS Azure Storage).
• Přípojný bod: /data/archive (pokud je k dispozici)

Note

Veřejné cloudy lze použít jako úložiště pro archivaci dat. V takovém případě je třeba povolit šifrování dat, aby byla data chráněna před neoprávněným přístupem.

Vyhrazené archivační uzly

Pro velké archivy se doporučují vyhrazené archivační uzly (servery). Tyto uzly by měly používat připojení disků HBA SAS a distribuce operačního systému orientované na úložiště, jako je Unraid nebo TrueNAS.

Co nedoporučujeme

• Nedoporučujeme používat úložiště NAS / SAN pro ukládání dat.
• Pro ukládání dat nedoporučujeme používat hardwarové řadiče RAID apod.

Správa úložišť

V této kapitole je uveden praktický příklad konfigurace úložiště pro TeskaLabs LogMan.io. Úložiště LogMan.io nemusíte konfigurovat ani spravovat, pokud k tomu nemáte konkrétní důvod, LogMan.io se dodává v plně nakonfigurovaném stavu.

Za předpokladu následující hardwarové konfigurace:

• SSD disky pro rychlé ukládání dat: /dev/nvme0n1, /dev/nvme1n1.
• HDD disky pro pomalé ukládání dat: /dev/sde, /dev/sdf, /dev/sdg

Tip

Ke sledování aktuálního stavu úložných zařízení použijte příkaz lsblk.

Vytvoření softwarového pole RAID1 pro rychlé ukládání dat

mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1
mkfs.ext4 /dev/md2
mkdir -p /data/ssd

Přidejte přípojné body do /etc/fstab:

/dev/md2 /data/ssd ext4 defaults,noatime 0 2

Připojení souborových systémů pro ukládání dat:

mount /data/ssd

Tip

Pomocí cat /proc/mdstat zkontrolujte stav softwarového RAID.

Vytvoření softwarového pole RAID5 pro pomalé ukládání dat

mdadm --create /dev/md1 --level=5 --raid-devices=3 /dev/sde /dev/sdf /dev/sdg
mkfs.ext4 /dev/md1
mkdir -p /data/hdd

Note

Pro RAID6 použijte --level=6.

Přidejte přípojné body do /etc/fstab:

/dev/md1 /data/hdd ext4 defaults,noatime 0 2

Připojení souborových systémů pro ukládání dat:

mount /data/hdd

Zvětšit velikost datového úložiště

Při stále rostoucích objemech dat je velmi pravděpodobné, že budete potřebovat zvětšit (alias rozšířit) datové úložiště, a to buď na rychlém, nebo pomalém datovém úložišti. To se provádí přidáním nového datového svazku (např. fyzického disku nebo virtuálního svazku) do počítače - nebo u některých virtualizovaných řešení - zvětšením stávajícího svazku.

Note

Úložiště dat lze rozšířit bez jakýchkoli prostojů.

Příklad navyšování kapacity pomalého datového úložiště

Předpokládejme, že chcete přidat nový disk /dev/sdh do pomalého datového úložiště /dev/md1:

mdadm --add /dev/md1 /dev/sdh

Nový disk se přidá jako náhradní zařízení.

Stav pole RAID můžete zkontrolovat:

cat /proc/mdstat

Písmeno (S) za zařízením znamená náhradní zařízení.

RAID se zvětší na náhradní zařízení:

mdadm --grow --raid-devices=4 /dev/md1

Číslo 4 je třeba upravit tak, aby odpovídalo skutečnému nastavení RAID.

Zvětšete souborový systém:

resize2fs /dev/md1

Síťové nastavení

Tato část dokumentace je určena k tomu, aby vás provedla procesem nastavení a správy sítě TeskaLabs LogMan.io. Pro zajištění bezproblémové funkčnosti je důležité dodržovat předepsanou konfiguraci sítě popsanou níže.

Schema: Síťový přehled clusteru LogMan.io.

Přední síť

Přední ("fronting") síť je privátní segment L2 nebo L3, který slouží ke sběru logů. Z tohoto důvodu musí být přístupná ze všech zdrojů logů.

Každý uzel (server) má vyhrazenou adresu IPv4 ve frontingové síti. Podporován je také protokol IPv6.

Přední síť musí být dostupná na všech místech clusteru LogMan.io.

Uživatelská síť

Uživatelská síť je privátní segment L2 nebo L3, který slouží pro přístup uživatele k webovému uživatelskému rozhraní. Z tohoto důvodu musí být přístupný všem uživatelům.

Každý uzel (server) má v uživatelské síti vyhrazenou adresu IPv4. Podporována je také IPv6.

Uživatelská síť musí být dostupná na všech místech clusteru LogMan.io.

Interní síť

Interní síť je soukromý segment L2 nebo L3, který se používá pro soukromou komunikaci clusteru. MUSÍ BÝT vyhrazena pro TeskaLabs LogMan.io bez vnějšího přístupu, aby byla zachována bezpečnostní obálka clusteru.

Každý uzel (server) má vyhrazenou adresu IPv4 ve vnitřní síti. Podporována je také IPv6.

Vnitřní síť musí být dostupná na všech místech clusteru LogMan.io.

Kontejnery spuštěné na uzlu používají síťový režim "host" ve vnitřní síti. To znamená, že síťový zásobník kontejneru není izolován od uzlu (hostitele), a kontejner nemá přidělenou vlastní IP-adresu.

Připojení

Každý uzel (alias server) má následující požadavky na konektivitu:

• Přední síť:

• Minimálně 10Gbitová síťová karta, doporučeno 2x propojená 10Gbitová síťová karta.

• Uživatelská síť:

• 1Gbitová síťová karta: * 1Gbitová síťová karta

• Vnitřní síť: * Gbit 1,5 Nbit: Doporučená síťová karta: * minimálně 10Gbitová síťová karta, doporučená 2x propojená 10Gbitová síťová karta

• IPMI, je-li k dispozici na úrovni serveru

Připojení k internetu (NAT, firewall, za proxy serverem) pomocí přední sítě NEBO vnitřní sítě.

Cluster

TeskaLabs LogMan.io lze nasadit na jeden server (tzv. "uzel") nebo do clusteru. TeskaLabs LogMan.io podporuje také geo-clustering.

Geo-clustering

Geo-clustering je technika používaná k zajištění redundance proti selhání replikací dat a služeb na více geografických místech. Cílem tohoto přístupu je minimalizovat dopad nepředvídaných selhání, katastrof nebo přerušení, ke kterým může dojít v jedné lokalitě, tím, že se zajistí, aby systém mohl nadále fungovat bez přerušení z jiné lokality.

Geo-clustering zahrnuje nasazení více instancí systému LogMan.io v různých geografických oblastech nebo datových centrech a jejich konfiguraci tak, aby fungovaly společně jako jeden logický celek. Tyto instance jsou propojeny pomocí vyhrazeného síťového připojení, které jim umožňuje komunikovat a koordinovat své činnosti v reálném čase.

Jednou z hlavních výhod geo-clusteringu je, že poskytuje vysokou úroveň redundance proti selhání. V případě výpadku v jednom místě převezmou jeho řízení zbývající instance systému a pokračují v činnosti bez přerušení. To nejen pomáhá zajistit vysokou dostupnost (HA) a provozuschopnost, ale také snižuje riziko ztráty dat a výpadků.

Další výhodou geo-clusteringu je, že může zajistit lepší výkon a škálovatelnost tím, že umožňuje vyrovnávání zátěže a sdílení zdrojů ve více lokalitách. To znamená, že zdroje lze dynamicky přidělovat a přizpůsobovat měnícím se požadavkům, což zajišťuje, že systém je vždy optimalizován z hlediska výkonu a efektivity.

Celkově je geo-clustering výkonnou technikou, která pomáhá zajistit vysokou dostupnost, odolnost a škálovatelnost pro jejich kritické aplikace a služby. Replikací zdrojů ve více geografických lokalitách mohou organizace minimalizovat dopady výpadků a přerušení provozu a zároveň zvýšit výkon a efektivitu.

Lokality

Lokalita "A"

Lokalita "A" je první lokalitou, která se má vybudovat. V nastavení s jedním uzlem je to také jediné umístění.

Uzel 11 je první sestavený server clusteru.

Uzly v tomto umístění jsou pojmenovány "Uzel lmaX". X je pořadové číslo serveru (např. 1, 2, 3, 4 atd.). Pokud vám dojdou čísla, pokračujte malými písmeny (např. a, b, c atd.).

Podrobnosti o uzlech naleznete v doporučené specifikaci hardwaru.

Umístění B, C, D atd.

Umístění B (a C, D atd.) jsou další umístění clusteru.

Uzly v těchto lokalitách jsou pojmenovány "Uzel lmLX". L je malé písmeno, které představuje umístění v abecedním pořadí (např. a, b, c). X je pořadové číslo serveru( např. 1, 2, 3, 4 atd.). Pokud vám dojdou čísla, pokračujte malými písmeny (např. a, b, c atd.).

Podrobnosti o uzlech naleznete v doporučené specifikaci hardwaru.

Koordinační místo "X"

Klastr MUSÍ mít lichý počet umístění, aby se předešlo Split-brain problem. Z tohoto důvodu doporučujeme vytvořit malou koordinační lokalitu s jedním uzlem (uzel lmx1). Doporučujeme použít virtualizační platformu pro "uzel x1", nikoli fyzický hardware.

V tomto umístění se neukládají žádná data (protokoly, události).

Rozložení clusteru

Jednotlivé uzly "clusteru"

Uzel: (Umístění a, server 1).

Dva velké a jeden malý uzel

Uzly: lma1, lmb1, lmx1.

Tři uzly, tři umístění

Uzly: lma1, lmb1, lmc1.

Čtyři velké a jeden malý uzel

Uzly: lma1, lma2, lmb1, lmb2, lmx1.

Šest uzlů, tři umístění

Uzly lma1, lma2, lmb1, lmb2, lmc1, lmc2.

Větší clustery

Větší clustery obvykle zavádějí specializaci uzlů.

Životní cyklus dat

Data (např. logy, události, metriky) jsou ukládána v několika fázích dostupnosti, v zásadě v chronologickém pořadí. To znamená, že nejnovější logy jsou uloženy v nejrychlejším datovém úložišti a podle toho, jak stárnou, jsou přesunuty do pomalejšího a levnějšího datového úložiště a nakonec do offline archivu nebo jsou odstraněny.

Schema: Životní cyklus dat v systému TeskaLabs LogMan.io..

Životní cyklus je řízen funkcí ElasticSearch nazvanou Index Lifecycle Management (ILM).

Správa životního cyklu indexu

Funkce Index Lifecycle Management (ILM) v ElasticSearch slouží k automatickému uzavírání nebo mazá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 (lm_) a ElasticSearch automaticky umístí data do správného indexu přiřazeného pomocí politiky ILM.

Architektura Hot-Warm-Cold (HWC)

HWC je rozšíření standardní rotace indexů poskytované ElasticSearch ILM a je dobrým nástrojem pro správu dat časových řad. Architektura HWC nám umožňuje přidělit konkrétní uzly jedné z fází. Při správném použití spolu s architekturou clusteru to umožní dosáhnout maximálního výkonu a využít dostupný hardware na maximum.

Horká fáze

Obvykle existuje určité časové období (týden, měsíc atd.), kdy se chceme intenzivně dotazovat na indexy, přičemž cílem je spíše rychlost než úspora paměti (a dalších zdrojů). Tehdy se hodí fáze "Hot", která nám umožní mít index s více replikami, rozložený a přístupný na více uzlech pro optimální uživatelský komfort.

Horké uzly

Horké uzly by měly využívat rychlé části dostupného hardwaru, využívat většinu procesorů a rychlejší IO.

Teplá fáze

Jakmile toto období skončí a indexy již nebudou dotazovány tak často, využijeme jejich přesunutí do fáze "Warm", která nám umožní snížit počet uzlů (nebo se přesunout do uzlů s méně dostupnými zdroji) a replik indexů, čímž se sníží zatížení hardwaru, ale zároveň zůstane zachována možnost poměrně rychlého prohledávání dat.

Teplé uzly

Teplé uzly, jak název napovídá, stojí na rozcestí mezi tím, že slouží výhradně pro účely ukládání dat, a zároveň si zachovávají určitý výkon procesoru pro zpracování příležitostných dotazů.

Studená fáze

Někdy existují důvody, proč je třeba data uchovávat delší dobu (dané zákonem nebo nějakým interním předpisem). Nepředpokládá se, že by se na data někdo dotazoval, ale zároveň je zatím nelze smazat.

Studené uzly

Zde přicházejí na řadu studené uzly, může jich být málo, mají jen málo prostředků CPU, nemají potřebu používat SSD disky, naprosto si vystačí s pomalejším (a případně větším) úložištěm.

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

Archivní fáze

Fáze archivace je v návrhu volitelná. Jedná se o offline dlouhodobé úložiště. Nejstarší data ze studené fáze by mohla být pravidelně přesouvána do archivní fáze namísto jejich mazání.

Uplatňují se standardní zásady archivace provozní organizace SIEM. Archivovaná data musí být zašifrována.

Je také možné předávat určité logy přímo z teplé fáze do archivační fáze.

Vytvoření zásad ILM

Kibana

K vytvoření zásad 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ř. lm_.

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

Upravte šablonu (šablony) indexu.

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

"settings": {
  "index": {
    "lifecycle": {
      "name": "lm_",
      "rollover_alias": "lm_"
    }
  }
},

Kibana

Kibanu verze 7.x lze použít k propojení zásad ILM se šablonou indexu ES.

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 Správa indexů.

4.) V horní části vyberte možnost Šablona indexu

5.) Vyberte požadovanou šablonu indexu, např. lm_

6.) Klepněte na tlačítko Upravit

7.) Na obrazovce Nastavení přidejte:

{
  "index": {
    "lifecycle": {
      "name": "lm_",
      "rollover_alias": "lm_"
    }
  }
}

8.) Klikněte na Uložit

Vytvořte nový index, který bude využívat nejnovější šablonu indexu.

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:

PUT lm_tenant-000001
{
  "aliases": {
    "lm_": {
      "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.

Warning

Prefix a číslo indexu pro převrácení ILM musí být odděleny pomocí -000001, nikoli _000001!

Note

Ujistěte se, že ve zdroji není žádná konfigurace předpony indexu, jako je tomu v ElasticSearchSink v potrubí. Konfigurace kódu by nahradila konfiguraci souboru.

Zálohování a obnovení Elasticsearch

Snímky

Nachází se v části Stack Management -> Snapshot and Restore. Snímky jsou uloženy v umístění úložiště. Struktura je následující. Samotný snímek je pouze ukazatel na indexy, které obsahuje. Samotné indexy jsou uloženy v samostatném adresáři a jsou ukládány inkrementálně. To v podstatě znamená, že pokud vytváříte snímek každý den, starší indexy jsou ve snímku pouze znovu odkazovány, zatímco do záložního adresáře se skutečně kopírují pouze nové indexy.

Úložiště

Nejprve je třeba nastavit úložiště snímků. Zadejte umístění, kde se úložiště snímků nachází, například /backup/elasticsearch. Tato cesta musí být přístupná ze všech uzlů v clusteru. V případě Elasticsearch běžícího v dockeru to zahrnuje připojení prostoru uvnitř kontejnerů dockeru a jejich restartování.

Zásady

Pro zahájení pořizování snímků je třeba vytvořit zásady. Zásada určuje prefix pojmenování vytvářených snímků, určuje úložiště, které bude používat pro vytváření snímků, Vyžaduje nastavení plánu, indexy (definované pomocí vzorů nebo konkrétních názvů indexů - například lmio-mpsv-events-*). Dále je v zásadě možné určit, zda má ignorovat nedostupné indexy, povolit částečné indexy a zahrnout globální stav. Jejich použití závisí na konkrétním případu, ve kterém bude politika snímků použita, a ve výchozím nastavení se nedoporučují. K dispozici je také nastavení pro automatické mazání snímků a definice vypršení platnosti. I ty závisí na konkrétní politice, samotné snapshoty jsou však velmi malé (paměťově), pokud nezahrnují globální stav, což se dá očekávat, protože jsou to jen ukazatele na jiné místo, kde jsou uložena skutečná data indexu.

Obnovení snapshotu

Chcete-li obnovit snímek, jednoduše vyberte snímek obsahující index nebo indexy, které chcete obnovit, a zvolte "Obnovit". Poté je třeba zadat, zda chcete obnovit všechny indexy obsažené ve snímku, nebo jen jejich část. Obnovené indexy můžete přejmenovat, můžete také obnovit indexy z části snímku a při jejich obnově upravit nastavení indexů. Nebo je obnovit na výchozí hodnoty. Indexy se pak podle zadání obnoví zpět do clusteru.

Upozornění

Při odstraňování snímků mějte na paměti, že abyste mohli obnovit zálohované indexy, musí být pokryty snímkem. To znamená, že když například vymažete některé indexy z clusteru a poté odstraníte snímek, který obsahoval odkaz na tyto indexy, nebudete je moci obnovit.

Plán kontinuity

Matice rizik

Matice rizik definuje úroveň rizika na základě porovnání kategorie "Pravděpodobnost" výskytu incidentu s kategorií "Dopad". Oběma kategoriím je přiřazeno skóre od 1 do 5. Vynásobením skóre pro "Pravděpodobnost" a "Dopad" se získá celkové skóre rizika.

Pravděpodobnost

Likelihood	Score
Vzácná	1
Nepravděpodobná	2
Možná	3
Pravděpodobná	4
Téměř jistá	5

Dopad

Impact	Score	Description
Nevýznamné	1	Funkčnost není ovlivněna, výkon není snížen, odstávka není nutná.
Nezávážné	2	Funkčnost není ovlivněna, výkon není snížen, odstávka ovlivněného uzlu clusteru je nutná.
Středně závažné	3	Funkčnost není ovlivněna, výkon je snížen, odstávka postiženého uzlu clusteru je nutná.
Závažné	4	Funkčnost je ovlivněna, výkon je výrazně snížen, je nutná odstávka clusteru.
Katastrofální	5	Úplná ztráta funkčnosti.

Scénáře incidentu

Úplné selhání systému

Dopad: Katastrofální (5)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: středně vysoká

Zmírnění rizika:

• Geograficky rozložený klastr
• Aktivní využívání monitorování a upozorňování
• Profylaktická údržba
• Silné kybernetické zabezpečení

Obnova:

1. Kontaktujte podporu a/nebo dodavatele a konzultujte strategii.
2. Obnovte funkčnost hardwaru.
3. Obnovte systém ze zálohy konfigurace webu.
4. Obnovte data z offline zálohy (začněte od nejčerstvějších dat a pokračujte do historie).

Ztráta uzlu v clusteru

Dopad: Střední (4)
Pravděpodobnost: Malá pravděpodobnost (2)
Úroveň rizika: střední-nízká

Zmírnění rizika:

• Geograficky rozložený klastr
• Aktivní využívání monitorování a upozorňování
• Profylaktická údržba

Obnova:

1. Kontaktujte podporu a/nebo prodejce a konzultujte strategii.
2. Obnovte funkčnost hardwaru.
3. Obnovte systém ze zálohy konfigurace webu.
4. Obnovte data z offline zálohy (začněte od nejčerstvějších dat a pokračujte do historie).

Ztráta jednotky rychlého úložiště v jednom uzlu clusteru

Dopad: Drobný (2)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: střední-nízká

Rychlé disky jsou v poli RAID 1, takže ztráta jednoho disku není kritická. Zajistěte rychlou výměnu selhané jednotky, abyste zabránili selhání druhé rychlé jednotky. Druhé selhání rychlého disku bude eskalovat na "Ztrátu uzlu v clusteru".

Zmírnění rizika:

• Aktivní používání monitorování a upozorňování
• Profylaktická údržba
• Včasná výměna porouchané jednotky

Obnova:

1. Vypněte postižený uzel clusteru
2. Co nejdříve vyměňte selhávající jednotku rychlého úložiště
3. Zapněte postižený uzel clusteru
4. Ověřte správnou rekonstrukci pole RAID1

Note

Výměna rychlé úložné jednotky za provozu je podporována na zvláštní přání zákazníka.

Nedostatek místa v rychlém úložišti

Dopad: Střední (3)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: středně vysoká

Tato situace je problematická, pokud k ní dojde na více uzlech clusteru současně. K identifikaci této situace před její eskalací použijte monitorovací nástroje.

Zmírnění rizika:

• Aktivní používání monitorování a upozorňování
• Profylaktická údržba

Obnova:

1. Odstraňte nepotřebná data z rychlého úložného prostoru.
2. Upravte konfiguraci životního cyklu tak, aby se data dříve přesunula do pomalého úložného prostoru.

Ztráta jednotky pomalého úložiště v jednom uzlu clusteru

Dopad: Nevýznamný (1)
Pravděpodobnost: Pravděpodobná (4)
Úroveň rizika: střední-nízká

Pomalé disky jsou v poli RAID 5 nebo RAID 6, takže ztráta jednoho disku není kritická. Zajistěte rychlou výměnu selhané jednotky, abyste zabránili dalšímu selhání jednotky. Druhé selhání disku v poli RAID 5 nebo třetí selhání disku v poli RAID 6 bude eskalovat na "Ztrátu uzlu v clusteru".

Zmírnění rizika:

• Aktivní používání monitorování a upozorňování
• Profylaktická údržba
• Včasná výměna porouchané jednotky

Obnova:

1. Vyměňte selhávající pomalou úložnou jednotku co nejdříve (hot swap).
2. Ověřte správnou rekonstrukci pomalého úložiště RAID

Nedostatek místa v pomalém úložišti

Dopad: Střední (3)
Pravděpodobnost: Pravděpodobná (4)
Úroveň rizika: středně vysoká

Tato situace je problematická, pokud k ní dojde na více uzlech clusteru současně. K identifikaci této situace před její eskalací použijte monitorovací nástroje.

Zmírnění rizika:

• Aktivní používání monitorování a upozorňování
• Profylaktická údržba
• Včasné rozšíření velikosti úložiště pomalých dat

Obnova:

1. Odstraňte nepotřebná data z pomalého úložného prostoru.
2. Upravte konfiguraci životního cyklu tak, aby byla data z pomalého úložného prostoru odstraněna dříve.

Ztráta systémové jednotky v jednom uzlu clusteru

Dopad: Menší (2)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: střední-nízká

Systémové disky jsou v poli RAID 1, takže ztráta jednoho disku není kritická. Zajistěte rychlou výměnu selhané jednotky, abyste zabránili druhému rychlému selhání jednotky. Druhé selhání systémové jednotky bude eskalovat na "Ztrátu uzlu v clusteru".

Zmírnění rizika: V případě, že se jedná o chybu, která by mohla vést k poškození disku, je nutné, abyste se vyhnuli riziku:

• Aktivní používání monitorování a výstrah
• Profylaktická údržba
• Včasná výměna porouchané jednotky

Obnova:

1. Vyměňte selhání rychlé úložné jednotky co nejdříve (jak vyměnit).
2. Ověřte správnou rekonstrukci pole RAID1

Nedostatek místa v úložišti systému

Dopad: Střední (3)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: nízká

Použijte monitorovací nástroje k identifikaci této situace před eskalací.

Zmírnění rizika:

• Aktivní využívání monitorování a upozorňování
• Profylaktická údržba

Obnova:

1. Odstraňte nepotřebná data ze systémového úložného prostoru.
2. Kontaktujte podporu nebo prodejce.

Ztráta síťového připojení v jednom uzlu clusteru

Dopad: (2)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: střední-nízká

Zmírnění rizika:

• Aktivní používání monitorování a upozorňování
• Profylaktická údržba
• Redundantní síťové připojení

Obnova:

1. Obnovení síťového připojení
2. Ověřte správný provozní stav clusteru

Selhání clusteru ElasticSearch

Dopad: (4)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: středně vysoká

Zmírnění rizika:

• Aktivní používání monitorování a upozorňování
• Profylaktická údržba
• Včasná reakce na zhoršující se stav clusteru ElasticSearch

Obnova:

1. Kontaktujte podporu a/nebo dodavatele a konzultujte strategii.

Selhání uzlu ElasticSearch

Dopad: Menší (2)
Pravděpodobnost: Pravděpodobná (4)
Úroveň rizika: střední-nízká

Zmírnění rizika:

• Aktivní využívání monitorování a upozorňování
• Profylaktická údržba
• Včasná reakce na zhoršující se stav clusteru ElasticSearch

Obnova:

1. Sledování automatického opětovného připojení uzlu ElasticSearch ke clusteru
2. Pokud porucha přetrvává několik hodin, kontaktujte podporu / dodavatele.

Selhání clusteru Apache Kafka

Dopad: (4)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: střední-nízká

Zmírnění rizika:

• Aktivní využívání monitorování a upozorňování
• Profylaktická údržba
• Včasná reakce na zhoršující se stav clusteru Apache Kafka

Obnova:

1. Kontaktujte podporu a/nebo dodavatele a konzultujte strategii.

Selhání uzlu Apache Kafka

Dopad: Drobné (2)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: nízká

Snížení rizika: nízká (nízká):

• Aktivní využívání monitorování a upozorňování
• Profylaktická údržba
• Včasná reakce na zhoršující se stav clusteru Apache Kafka

Obnova:

1. Sledování automatického opětovného připojení uzlu Apache Kafka ke clusteru
2. Pokud porucha přetrvává několik hodin, kontaktujte podporu / dodavatele.

Selhání clusteru Apache ZooKeeper

Dopad: (4)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: střední-nízká

Zmírnění rizika:

• Aktivní využívání monitorování a upozorňování
• Profylaktická údržba
• Včasná reakce na zhoršující se stav clusteru Apache ZooKeeper.

Obnova:

1. Kontaktujte podporu a/nebo dodavatele a konzultujte strategii.

Selhání uzlu Apache ZooKeeper

Dopad: Nevýznamný (1)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: nízká

Snížení rizika: nízká (nízká):

• Aktivní využívání monitorování a upozorňování
• Profylaktická údržba
• Včasná reakce na zhoršující se stav clusteru Apache ZooKeeper.

Obnova:

1. Sledujte automatické připojení uzlu Apache ZooKeeper ke clusteru.
2. Pokud porucha přetrvává několik hodin, kontaktujte podporu / dodavatele.

Selhání mikroslužby bezstavové cesty dat (kolektor, parser, dispečer, korelátor, watcher)

Dopad: Menší (2)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: střední-nízká

Zmírnění rizika:

• Aktivní využívání monitorování a upozorňování
• Profylaktická údržba

Zotavení:

1. Restartujte selhávající mikroslužbu.

Selhání bezstavové podpůrné mikroslužby (všechny ostatní)

Dopad: Nevýznamný (1)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: střední a nízká

Zmírnění rizika:

• Aktivní využívání monitorování a upozorňování
• Profylaktická údržba

Zotavení:

1. Restartujte selhávající mikroslužbu.

Výrazné snížení výkonu systému

Dopad: Mírné (3)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: středně vysoká

Zmírnění rizika:

• Aktivní používání monitorování a upozorňování
• Profylaktická údržba

Zotavení:

1. Identifikace a odstranění hlavní příčiny snížení výkonu
2. V případě potřeby pomoci kontaktujte dodavatele nebo podporu

Strategie zálohování a obnovy

Offline zálohování příchozích protokolů

Příchozí protokoly jsou duplikovány do offline zálohovacího úložiště, které není součástí aktivního clusteru LogMan.io (proto je "offline"). Offline záloha poskytuje možnost obnovit logy do LogMan.io po kritické poruše apod.

Strategie zálohování pro rychlé úložiště dat

Příchozí události (logy) se kopírují do archivního úložiště, jakmile vstoupí do LogMan.io. To znamená, že vždy existuje způsob, jak v případě potřeby "přehrát" události do systému TeskaLabs LogMan.io. Také data jsou replikována do ostatních uzlů clusteru ihned po příchodu do clusteru. Z tohoto důvodu se tradiční zálohování nedoporučuje, ale je možné.

Obnovu zajišťují komponenty clusteru replikací dat z ostatních uzlů clusteru.

Strategie zálohování pro pomalé ukládání dat

Data uložená v pomalém úložišti dat jsou VŽDY replikována do ostatních uzlů clusteru a také uložena v archivu. Z tohoto důvodu se tradiční zálohování nedoporučuje, ale je možné (vezměte v úvahu obrovskou velikost pomalého úložiště).

Obnovu zajišťují komponenty clusteru replikací dat z ostatních uzlů clusteru.

Strategie zálohování systémového úložiště

Doporučuje se pravidelně zálohovat všechny systémy souborů v systémovém úložišti, aby je bylo možné v případě potřeby použít pro obnovení instalace. Zálohovací strategie je kompatibilní s většinou běžných zálohovacích technologií na trhu.

• Cíl bodu obnovy (RPO): úplné zálohování jednou týdně nebo po větších údržbových pracích, přírůstkové zálohování jednou denně.
• Cíl doby obnovy (RTO): 12 hodin.

Note

RPO a RTO jsou doporučené za předpokladu vysoce dostupného nastavení clusteru LogMan.io. To znamená tři a více uzlů, aby úplný výpadek jednoho uzlu neměl vliv na dostupnost služby.

Obecná pravidla zálohování a obnovy

1. Zálohování dat: Pravidelně zálohujte data na bezpečné místo, například do cloudového úložiště nebo na záložní pásky, abyste minimalizovali ztrátu dat v případě selhání.

2. Plánování zálohování: Stanovte plán zálohování, který odpovídá potřebám organizace, například denní, týdenní nebo měsíční zálohování.

3. Ověřování zálohování: Pravidelně ověřujte integritu zálohovaných dat, abyste zajistili, že je lze použít pro obnovu po havárii.

4. Testování obnovy: Pravidelně testujte obnovu záložních dat, abyste se ujistili, že proces zálohování a obnovy funguje správně, a abyste identifikovali a vyřešili případné problémy dříve, než se stanou kritickými.

5. Uchovávání záloh: Stanovte zásady uchovávání záloh, které vyváží potřebu dlouhodobého uchování dat a náklady na jejich uchovávání.

Monitorování a upozorňování

Monitorování je důležitou součástí plánu kontinuity, protože pomáhá včas odhalit potenciální selhání, identifikovat příčinu selhání a podpořit rozhodování během procesu obnovy.

Mikroslužby LogMan.io poskytují rozhraní API OpenMetrics a/nebo odesílají svou telemetrii do databáze InfluxDB a jako monitorovací nástroj používají nástroj Grafana.

1. Strategie monitorování: Pro sběr telemetrie ze všech mikroslužeb v clusteru, operačního systému a hardwaru se používá rozhraní OpenMetrics API. Telemetrie se sbírá jednou za minutu. K ukládání telemetrických dat se používá InfluxDB. Jako webové uživatelské rozhraní pro kontrolu telemetrie se používá Grafana.

2. Upozorňování a oznamování: Monitorovací systém je nakonfigurován tak, aby generoval výstrahy a oznámení v případě potenciálních selhání, jako je málo místa na disku, vysoké využití prostředků nebo zvýšená chybovost.

3. Monitorovací panely: Monitorovací panely jsou k dispozici v prostředí Grafana a zobrazují nejdůležitější metriky systému, jako je využití prostředků, míra chybovosti a doba odezvy.

4. Konfigurace monitorování: Pravidelně jsou prováděny revize a aktualizace konfigurace monitorování, aby bylo zajištěno, že je účinná a že odráží změny v systému.

5. Školení v oblasti monitorování: Pro monitorovací tým a další relevantní strany jsou poskytována školení týkající se monitorovacího systému a monitorovacích panelů v aplikaci Grafana.

Architektura vysoké dostupnosti

Systém TeskaLabs LogMan.io je nasazen ve vysoce dostupné architektuře (HA) s více uzly, aby se snížilo riziko selhání jednoho bodu.

Architektura vysoké dostupnosti je návrhový vzor, jehož cílem je zajistit, aby systém zůstal funkční a dostupný i v případě selhání nebo přerušení provozu.

V clusteru LogMan.io zahrnuje architektura vysoké dostupnosti následující součásti:

1. Vyrovnávání zátěže: Rozložení příchozího provozu mezi více instancí mikroslužeb, čímž se zvyšuje odolnost systému a snižuje dopad selhání.

2. Redundantní úložiště: Ukládání dat redundantně ve více uzlech úložiště, aby se zabránilo ztrátě dat v případě selhání úložiště.

3. Více zprostředkovatelů: Použití více zprostředkovatelů v systému Apache Kafka pro zvýšení odolnosti systému přenosu zpráv a snížení dopadu selhání zprostředkovatele.

4. Automatické převzetí služeb při selhání: Automatické mechanismy failover, jako je například volba lídra v Apache Kafka, zajišťují, že systém bude fungovat i v případě selhání uzlu clusteru.

5. Monitorování a upozorňování: Použití monitorovacích a výstražných komponent k detekci potenciálních selhání a spuštění mechanismů automatického převzetí služeb při selhání v případě potřeby.

6. Průběžné aktualizace: Upgrade systému bez narušení jeho běžného provozu, a to tak, že se uzly upgradují postupně, bez odstávky.

7. Replikace dat: Replikace protokolu ve více uzlech clusteru, aby bylo zajištěno, že systém bude fungovat i v případě selhání jednoho nebo více uzlů.

Komunikační plán

Jasný a dobře komunikovaný plán reakce na selhání a komunikace se zúčastněnými stranami pomáhá minimalizovat dopady selhání a zajistit, aby všichni byli na stejné vlně.

1. Identifikace zúčastněných stran: Identifikujte všechny zúčastněné strany, které může být třeba informovat během havárie a po ní, například zaměstnance, zákazníky, dodavatele a partnery.

2. Zúčastněné organizace: Provozovatel LogMan.io, integrující strana a dodavatel (TeskaLabs).

3. Komunikační kanály: Komunikační kanály, které se budou používat během katastrofy a po ní, jsou Slack, e-mail, telefon a SMS.

4. Plán eskalace: Určete eskalační plán, abyste zajistili, že během katastrofy budou ve správný čas informováni ti správní lidé a že komunikace bude koordinovaná a účinná.

5. Aktualizace a údržba: Pravidelně aktualizujte a udržujte komunikační plán, abyste zajistili, že odráží změny v organizaci, například nové zúčastněné strany nebo komunikační kanály.

Nastavení ElasticSearch

Šablony indexů

Před načtením dat do ElasticSearch, měla by být přítomna šablona indexu, 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 indexové šablony nefungovala a nemohly by být použity pro třídění a vytváření indexových vzorů v nástroji Kibana.

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

Vložení indexové šablony prostřednictvím PostMan nebo Kibana, vytvořte následující požadavek HTTP na instanci ElasticSearch, kterou používáte:

PUT _template/lmio-
{
  //Deploy to <SPECIFY_WHERE_TO_DEPLOY_THE_TEMPLATE>
  "index_patterns" : ["lmio-*"],
  "version": 200721, // Zvyšte tuto hodnotu s každou verzí
  "order" : 9999998, // Snižte tuto hodnotu s každou verzí
  "settings": {
    "index": {
      "lifecycle": {
        "name": "lmio-",
        "rollover_alias": "lmio-"
      }
    }
  },
  "mappings": {
    "properties": {
      "@timestamp": {"type": "date", "format": "strict_date_optional_time||epoch_millis" },
      "rt": {"type": "date", "format": "strict_date_optional_time||epoch_second" },
      ...
  }
}

Tělo požadavku je obsahem souboru es_index_template.json.

Správa životního cyklu indexu

Správa životního cyklu indexů (ILM) v ElasticSearch slouží k automatickému uzavírání nebo mazá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 (lm_) 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

Kibana

K vytvoření zásad 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ř. lm_.

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

Upravte šablonu (šablony) indexu.

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

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

Kibana

Kibanu verze 7.x lze použít k propojení zásad ILM se šablonou indexu ES.

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 Správa indexů.

4.) V horní části vyberte možnost Šablona indexu

5.) Vyberte požadovanou šablonu indexu, např. lmio-

6.) Klepněte na tlačítko Upravit

7.) Na obrazovce Nastavení přidejte:

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

8.) Klikněte na Uložit

Vytvořte nový index, který bude využívat nejnovější šablonu indexu

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

PUT lmio-tenant-events-000001
{
  "aliases": {
    "lmio-tenant-events": {
      "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!//

Konfigurace dalších součástí LogMan.io

Čerpadla nyní mohou používat zásady ILM prostřednictvím vytvořeného aliasu, kterým je ve výše uvedeném případě lm_tenant. Konfigurační soubor by pak měl vypadat takto:

[pipeline:<PIPELINE>:ElasticSearchSink].
index_prefix=lm_tenant
doctype=_doc

Čerpadlo vždy vloží data do aliasu lm_tenant, kde se ILM postará o správné přiřazení k indexu, např. lm_-000001.

/Poznámka: Ujistěte se, že ve zdroji není žádná konfigurace předpony indexu, jako je tomu v ElasticSearchSink v pipeline. Konfigurace kódu by nahradila soubor configuration.//.

Architektura Hot-Warm-Cold (HWC)

HWC je rozšířením standardní rotace indexů, kterou poskytuje ElasticSearch ILM, a je dobrým nástrojem pro správu dat časových řad. Architektura HWC nám umožňuje přidělit konkrétní uzly jedné z fází. Při správném použití spolu s architekturou clusteru to umožní dosáhnout maximálního výkonu a využít dostupný hardware na maximum.

Hot

Obvykle existuje určité časové období (týden, měsíc atd.), kdy se chceme intenzivně dotazovat na indexy, přičemž cílem je spíše rychlost než úspora paměti (a dalších zdrojů). Tehdy se hodí fáze "Hot", která nám umožní mít index s více replikami, rozložený a přístupný na více uzlech pro optimální uživatelský komfort.

Horké uzly

Horké uzly by měly využívat rychlé části dostupného hardwaru, využívat většinu procesorů a rychlejší IO.

Teplý

Jakmile toto období skončí a indexy již nebudou dotazovány tak často, využijeme jejich přesunutí do fáze "Warm", která nám umožní snížit počet uzlů (nebo se přesunout do uzlů s méně dostupnými zdroji) a replik indexů, čímž se sníží zatížení hardwaru, ale zároveň zůstane zachována možnost přiměřeně rychlého prohledávání dat.

Teplé uzly

Teplé uzly, jak název napovídá, stojí na rozcestí mezi tím, že slouží výhradně pro účely ukládání dat, a zároveň si zachovávají určitý výkon procesoru pro zpracování příležitostných dotazů.

Studený

Někdy existují důvody, proč je třeba data uchovávat delší dobu (dané zákonem nebo nějakým interním předpisem). Nepředpokládá se, že se na data bude někdo dotazovat, ale zároveň je zatím nelze smazat.

Studené uzly

Zde přicházejí na řadu studené uzly, může jich být málo, mají jen málo prostředků CPU, nemají potřebu používat SSD disky, naprosto si vystačí s pomalejším (a případně větším) úložištěm.

Závěr

Využití funkce HWC ILM v plném rozsahu vyžaduje určitou přípravu, je třeba ji zvážit při budování produkčního clusteru ElasticSearch. Přidaná hodnota však může být v závislosti na konkrétních případech použití velmi vysoká.

Nastavení InfluxDB

Konfigurace souboru Docker-compose.yaml pro Influx v1.x

  influxdb:
    restart: on-failure:3
    image: influxdb:1.8
    ports:
      - "8083:8083"
      - "8086:8086"
      - "8090:8090"
    svazky:
      - /<path_on_host>/<where_you_want_data>:/var/lib/influxdb
    prostředí:
      - INFLUXDB_DB=<your_db>
      - INFLUXDB_USER=telegraf
      - INFLUXDB_ADMIN_ENABLED=true
      - INFLUXDB_ADMIN_USER=<your_user>
      - INFLUXDB_ADMIN_PASSWORD=<your_password>
    logování:
      options:
        max-size: 10m

Konfigurace souboru Docker-compose.yaml pro Influx v2.x

  influxdb:
    image: influxdb:2.0.4
    restart: 'always'
    ports:
      - "8086:8086"
    volumes:
      - /data/influxdb/data:/var/lib/influxdb2
    prostředí:
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_USERNAME=telegraf
      - DOCKER_INFLUXDB_INIT_PASSWORD=my-password
      - DOCKER_INFLUXDB_INIT_ORG=my-org
      - DOCKER_INFLUXDB_INIT_BUCKET=my-bucket
      - DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=my-super-secret-auth-token

Spusťte kontejner InfluxDB

docker-compose up -d

Použít rozhraní uživatelského rozhraní na:

http://localhost:8086/

Jak zapisovat/mazat data pomocí přílivu CLI:

docker exec -it <influx-container> bash

influx write \
  -b my-bucket \
  -o my-org \
  -p s \
  'myMeasurement,host=myHost testField="testData" 1556896326' \
  -t ${vůj-token}

influx delete \
       -bucket my-bucket \
       --org my-org \
       --start 2001-03-01T00:00:00Z \
       --stop 2021-04-14T00:00:00Z \
       --token ${vůj-token}

Další informace: https://docs.influxdata.com/influxdb/v2.0/write-data/

Nastavení zásad uchovávání

Politika uchovávání řídí, jak dlouho chcete data v InfluxDB uchovávat, nastavujete název politiky, kterých databází se týká, jak dlouho budete data uchovávat, replikaci a nakonec skupinu (v níže uvedeném případě DEFAULT) DEFAULT se používá pro všechny zdroje, které při vkládání dat do InfluxDB nezadávají skupinu.

docker exec <container_name> influx -execute CREATE RETENTION POLICY "<name_your_policy>" ON "<your_db>" DURATION 47h60m REPLICATION 1 DEFAULT

Změna existující politiky

`docker exec influx -execute ALTER RETENTION POLICY "autogen" on "/" duration 100d``

Odstranění starých dat

Pozor na uvozovky delete from "<collection>" where "<field>" = '<value>'

Odstranění starých dat v konkrétním poli

Při rekonfiguraci zdrojů se možná budete chtít zbavit některých starých hodnot v konkrétních polích, aby nezatěžovaly vizualizace. Můžete tak učinit pomocí příkazu folloging:

DROP SERIES WHERE "" = ''`

Snížení vzorkování

https://docs.influxdata.com/influxdb/v1.8/guides/downsample_and_retain/ pokud chcete použít více pravidel pro různé zdroje dat, použijte jiný název skupiny než DEFAULT a podle toho nakonfigurujte své zdroje, například v telegrafu použijte:

Příklad specifických zásad uchovávání (telegraf)

Používá se, pokud chcete nastavit různé uchovávání pro různé zdroje.

[[outputs.influxdb]
]
## Název existující retenční politiky, do které se má zapisovat.  Prázdný řetězec zapisuje do
## výchozí zásady uchovávání.  Uplatní se pouze při použití protokolu HTTP.
# retention_policy = "**telegraf1**"

`docker exec influx -execute CREATE RETENTION POLICY "" ON "" DURATION 47h60m REPLICATION 1 telegraf1``

Ended: Adminitrátorská přiručka

Návody

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.

Průvodce nasazením LogMan.io pro partnery

Předimplementační analýza

Každá dodávka by měla začít předimplementační analýzou, která obsahuje seznam všech zdrojů logů, které by měly být připojeny k LogMan.io. Výstupem analýzyje tabulka, kde každý pruh popisuje jeden zdroj logů, způsob, jakým jsou logy shromažďovány (čtení souborů, předávání logů na cílový port atd.), kdo je za zdroj logů z pohledu zákazníka zodpovědný a odhad, kdy by měl být zdroj logů připojen. Viz následující obrázek:

Na obrázku jsou další dva sloupce, které nejsou součástí předimplementační analýzy a které se vyplní později, až dojde k implementaci (kafka topic & dataset). Předem více informací naleznete v části Pásma událostí níže.

MUSÍ BÝT definováno, která doména (URL) bude použita pro hostování LogMan.io. Zákazník nebo partner si MUSÍ sám zajistit příslušné HTTPS SSL certifikáty (viz nginx níže), např. pomocí Let's Encrypt nebo jiné certifikační autority.

LogMan.io cluster a sběrné servery

Servery

Na konci předimplementační analýzy by mělo být jasné, jak velký by měl být objem shromažďovaných protokolů (v událostech nebo zprávách protokolu za sekundu, zkráceně EPS). Protokoly se vždy sbírají z infrastruktury zákazníka, kde je alespoň jeden server vyhrazený pro sběr protokolů (tzv. log collector).

Pokud jde o cluster LogMan.io, existují tři způsoby:

• LogMan.io cluster je nasazen v infrastruktuře zákazníka na fyzických a/nebo virtuálních strojích (on-premise).
• cluster LogMan.io je nasazen v infrastruktuře partnera a je k dispozici pro více zákazníků, přičemž každému zákazníkovi je přidělen jeden nájemce (SoC, SaaS atd.).

Další informace o konfiguraci fyzických serverů naleznete v části Hardwarová specifikace.

Architektura clusteru

V obou způsobech clusteru MUSÍ být pro cluster LogMan.io k dispozici alespoň jeden server (pro PoC) nebo alespoň tři servery (pro nasazení). Pokud je cluster nasazen v infrastruktuře zákazníka, mohou servery fungovat také jako sběrné servery, takže v tomto případě není třeba mít vyhrazený sběrný server. Architektura tří serverů se může skládat ze tří podobných fyzických serverů nebo ze dvou fyzických serverů a jednoho malého libovolného virtuálního počítače.

Menší nebo nekritická nasazení jsou možná v konfiguraci s jedním strojem.

Další informace o organizaci clusteru LogMan.io naleznete v části Architektura clusteru.

Ukládání dat

Každý fyzický nebo nearbitrační server v clusteru LogMan.io by měl mít k dispozici dostatečné diskové úložiště, aby mohl uchovávat data za požadované časové období z předimplementační analýzy. Mělo by existovat alespoň jedno rychlé (pro aktuální nebo jednodenní zprávy protokolů a témata Kafka) a jedno pomalejší (pro starší data, metadata a konfigurace) datové úložiště namapované na /data/ssd a /data/hdd. Protože všechny služby LogMan.io běží jako kontejnery Docker, složka /var/lib/docker by měla být také namapována na jedno z těchto úložišť.

Podrobné informace o organizaci diskových úložišť, připojování atd. naleznete v části Úložiště dat.

Instalace

DOPORUČENÝM operačním systémem je Linux Ubuntu 22.04 LTS nebo novější. Alternativy jsou Linux RedHat 8 a 7, CentOS 7.

Názvy hostitelů serverů LogMan.io v clusteru LogMan.io by měly mít zápis lm01, lm11 atd. Pokud jsou použity samostatné sběrné servery (viz výše), není požadavek na pojmenování jejich hostitelských jmen. Pokud je součástí dodávky TeskaLabs, měl by být vytvořen uživatel tladmin s právy sudoer.

Na každém serveru (clusteru LogMan.io i kolektoru) by měly být nainstalovány git, docker a docker-compose.

Podrobný návod naleznete v části Manuální instalace.

Všechny služby se pak vytvoří a spustí pomocí příkazu docker-compose up -d ze složky, do které je naklonován repozitář webu (viz následující část):

$ cd /opt/site-tenant-siterepository/lm11
$ docker-compose up -d

Přihlašovací údaje dockeru poskytne partnerovi tým TeskaLabs.

Úložiště a konfigurace webu

Každý partner získá přístup do úložiště GitLab společnosti TeskaLabs, aby zde mohl spravovat konfigurace pro nasazení, což je doporučený způsob ukládání konfigurací pro budoucí konzultace se společností TeskaLabs. Každý partner však může používat i vlastní úložiště GitLab nebo jakékoli jiné úložiště Git a poskytnout týmu TeskaLabs příslušné přístupy (alespoň pro čtení).

Každé nasazení u každého zákazníka by mělo mít samostatný site repository, bez ohledu na to, zda je nainstalován celý cluster LogMan.io, nebo jsou nasazeny pouze sběrné servery. Struktura úložiště site by měla vypadat následovně:

Každý serverový uzel (server) by měl mít samostatnou podsložku v horní části úložiště GitLab. Dále by zde měla být složka s LogMan.io library, která obsahuje deklarace pro parsování, korelaci atd. skupin, config, která obsahuje konfiguraci obrazovky Discover v uživatelském rozhraní a ovládacích panelech, a složka ecs se šablonami indexů pro ElasticSearch.

Každý partner získá přístup k úložišti referenčních stránek, kde jsou připraveny všechny konfigurace včetně parserů a nastavení Discover.

ElasticSearch

Každý uzel v clusteru LogMan.io by měl obsahovat alespoň jeden uzel ElasticSearch master, jeden uzel ElasticSearch data_hot, jeden uzel ElasticSearch data_warm a jeden uzel ElasticSearch data_cold. Všechny uzly ElasticSearch jsou nasazeny prostřednictvím nástroje Docker Compose a jsou součástí úložiště webu/konfigurace. Libovolné uzly v clusteru obsahují pouze jeden hlavní uzel ElasticSearch.

Pokud je použita architektura jednoho serveru, měly by být repliky v ElasticSearch nastaveny na nulu (to bude také poskytnuto po konzultaci s TeskaLabs). Pro ilustraci viz následující úryvek ze souboru Docker Compose, kde je vidět, jak je nasazen horký uzel ElasticSearch:

  lm21-es-hot01:
    network_mode: host
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.2
    depends_on:
      - lm21-es-master
    environment:
      - network.host=lm21
      - node.attr.rack_id=lm21 # Nebo název datového centra. To je určeno pro ES, aby mohlo efektivně a bezpečně spravovat repliky
                                # Pro menší instalace -> název hostitele je v pořádku
      - node.attr.data=hot
      - node.name=lm21-es-hot01
      - node.roles=data_hot,data_content,ingest
      - cluster.name=lmio-es # V podstatě "název databáze"
      - cluster.initial_master_nodes=lm01-es-master,lm11-es-master,lm21-es-master
      - discovery.seed_hosts=lm01:9300,lm11:9300,lm21:9300
      - http.port=9201
      - transport.port=9301 # Interní komunikace mezi uzly
      - "ES_JAVA_OPTS=-Xms16g -Xmx16g -Dlog4j2.formatMsgNoLookups=true"
      # - path.repo=/usr/share/elasticsearch/repo # Tato volba je povolena na vyžádání po instalaci! Není součástí počátečního nastavení (ale máme ji zde, protože je to dílna).
      - ELASTIC_PASSWORD=$ELASTIC_PASSWORD
      - xpack.security.enabled=true
      - xpack.security.transport.ssl.enabled=true
 ...

Další informace o službě ElasticSearch včetně vysvětlení horkých (nejnovějších, jednodenních dat na SSD), teplých (starších) a studených uzlů naleznete v části Nastavení služby ElasticSearch.

ZooKeeper a Kafka

Každý uzel serveru v clusteru LogMan.io by měl obsahovat alespoň jeden uzel ZooKeeper a jeden uzel Kafka. ZooKeeper je úložiště metadat dostupné v celém clusteru, kam Kafka ukládá informace o konzumentech témat, názvech témat atd. a kam LogMan.io ukládá aktuální soubory library a config (viz níže). Nastavení Kafky a ZooKeeperu lze zkopírovat z úložiště referenčního webu a konzultovat s vývojáři TeskaLabs.

Služby

Následující služby by měly být dostupné alespoň na jednom z uzlů LogMan.io a patří mezi ně:

• (webový server s certifikátem HTTPS, viz úložiště referenčních stránek).
• influxdb (úložiště metrik, viz InfluxDB Setting).
• mongo (databáze pro přihlašovací údaje uživatelů, relace atd.)
• telegraf (shromažďuje telemetrické metriky z infrastruktury, nory a ElasticSearch a odesílá je do InfluxDB, měl by být nainstalován na každém serveru)
• burrow (shromažďuje telemetrické metriky z Kafky a odesílá je do InfluxDB)
• seacat- auth (TeskaLabs SeaCat Auth je služba OAuth, která ukládá svá data do mongo)
• asab-library (spravuje knihovnu library s deklaracemi)
• asab-config (spravuje sekci config)
• lmio-remote-control (monitoruje další mikroslužby jako asab-config)
• lmio-commander (nahrává knihovnu do ZooKeeper)
• lmio-dispatcher (odesílá data z témat lmio-events a lmio-others Kafka do ElasticSearch, měl by běžet alespoň ve třech instancích na každém serveru)

Další informace o SeaCat Auth a jeho části pro správu v uživatelském rozhraní LogMan.io naleznete v dokumentaci TeskaLabs SeaCat Auth.

Informace o tom, jak nahrát knihovnu z úložiště webu do ZooKeeper, najdete v příručce LogMan.io Commander.

UŽIVATELSKÉ ROZHRANÍ

Následující uživatelská rozhraní by měla být nasazena a zpřístupněna prostřednictvím nginx. První implementace by měla být vždy projednána s vývojáři společnosti TeskaLabs.

• LogMan.io UI (viz LogMan.io User Interface)
• Kibana (zjišťovací obrazovka, vizualizace, ovládací panely a monitorování nad ElasticSearch).
• Grafana (ovládací panely telemetrie nad daty z InfluxDB)
• ZooKeeper UI (správa dat uložených v ZooKeeper)

Následující obrázek ukazuje Parsery z knihovny importované do ZooKeeper v ZooKeeper UI:

Nasazení rozhraní LogMan.io UI

Nasazení uživatelského rozhraní LogMan.io je při správném nastavení částečně poloautomatický proces. Existuje tedy několik kroků k zajištění bezpečného nasazení uživatelského rozhraní:

• Artefakt nasazení uživatelského rozhraní by měl být stažen prostřednictvím úložiště azure, které partnerovi poskytli vývojáři společnosti TeskaLabs. Informace o tom, kde je konkrétní aplikace uživatelského rozhraní uložena, lze získat z CI/CD obrazu úložiště aplikace.
• Doporučuje se používat verze tagged, ale mohou nastat situace, kdy je žádoucí použít verzi master. Informace, jak ji nastavit, najdete v souboru docker-compose.yaml úložiště referenčního webu.
• Aplikace uživatelského rozhraní musí být sladěna se službami, aby byl zajištěn nejlepší výkon (obvykle nejnovější tag verze). Pokud si nejste jisti, kontaktujte vývojáře společnosti TeskaLabs.

Vytvoření nájemce

Každému zákazníkovi je přiřazen jeden nebo více tenantů. Nájemci jsou malá jména ASCII, která označují data/logy patřící uživateli a ukládají data každého nájemce do samostatného indexu ElasticSearch. Všechny pruhy událostí (viz níže) jsou také specifické pro jednotlivé nájemce.

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

Chcete-li vytvořit nájemce, 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 do části Pověřovací údaje a přiřaďte nově vytvořeného tenanta všem příslušným uživatelům.

Indexy ElasticSearch

V systému Kibana by měl mít každý nájemce šablony indexů lmio-tenant-events a lmio-tenant-others, kde tenant je název nájemce (viz úložiště referenčních stránek poskytnuté společností TeskaLabs). Šablony indexů lze vložit prostřednictvím nástroje Dev Tools v levém menu aplikace Kibaba.

Po vložení šablon indexů by měla být ručně vytvořena politika ILM (správa životního cyklu indexů) a první indexy, přesně podle pokynů v příručce Nastavení ElasticSearch.

Kafka

V systému Kafka neexistuje žádné specifické nastavení pro vytváření nájemců, kromě níže uvedených pruhů událostí. Vždy se však ujistěte, že témata lmio-events a lmio-others jsou vytvořena správně. Následující příkazy by měly být spuštěny v kontejneru Kafka (např.: docker exec -it lm11_kafka_1 bash):

# # LogMan.io
/usr/bin/kafka-topics --zookeeper lm11:2181 --create --topic lmio-events --replication-factor 1 --partitions 6
/usr/bin/kafka-topics --zookeeper lm11:2181 --create --topic lmio-others --replication-factor 1 --partitions 6
/usr/bin/kafka-topics --zookeeper lm11:2181 --alter --topic lmio-events --config retention.ms=86400000
/usr/bin/kafka-topics --zookeeper lm11:2181 --alter --topic lmio-others --config retention.ms=86400000

# LogMan.io+ & SIEM
/usr/bin/kafka-topics --zookeeper lm11:2181 --create --topic lmio-events-complex --replication-factor 1 --partitions 6
/usr/bin/kafka-topics --zookeeper lm11:2181 --create --topic lmio-lookups --replication-factor 1 --partitions 6

Každé téma Kafky by mělo mít alespoň 6 oddílů (které lze automaticky použít pro paralelní spotřebu), což je vhodný počet pro většinu nasazení.

Důležitá poznámka

Následující část popisuje připojení pruhů událostí k LogMan.io. Znalost architektury LogMan.io z dokumentace je povinná.

Pruhy událostí

Pásma událostí v LogMan.io definují způsob odesílání protokolů do clusteru. Každý pruh událostí je specifický pro shromážděný zdroj, proto by jeden řádek v tabulce předimplementační analýzy měl odpovídat jednomu pruhu událostí. 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í úložiště referenčního webu.

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 úložiště referenčních stránek poskytnuté 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 jsou pak automaticky odesílána 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án repozitář 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, viz výše) do indexu lmio-tenant-events nebo lmio-tenant-others v ElasticSearch.

SIEM

Část SIEM by nyní měla být vždy projednána s vývojáři TeskaLabs, kteří zajistí první korelační pravidla a záznamy do konfiguračních souborů a Docker Compose. Část SIEM se skládá především z různých instancí lmio-correlators a lmio-watcher.

Další informace naleznete v části LogMan.io Correlator.

Rozšíření parseru Pipeline

Knihovnu LogMan.io dodáváme se standardními parsery uspořádanými do předem definovaných skupin. Někdy však budete chtít proces parsování rozšířit o vlastní parsery nebo obohacovače.

Uvažujme následující vstupní událost, která má být analyzována parsery z knihovny LogMan.io s ID skupiny lmio_parser_default_syslog_rfc3164:

<163>Feb 22 14:12:56 vmhost01 2135: ERR042: Něco se pokazilo.

Taková událost bude rozebrána do strukturované události, která vypadá takto:

{
   "@timestamp": 1614003176,
   "ecs.version": "1.6.0",
   "event.kind": "event",
   "event.dataset": "syslog.rfc3164",
   "message": "ERR042: Something went wrong.\n",
   "host.name": "vmhost01",
   "tenant": "default",
   "log.syslog.priority": 163,
   "log.syslog.facility.code": 20,
   "log.syslog.severity.code":: 3,
   "event.ingested": 1614004510.4724128,
   "_s": "SzOe",
   "_id": "[ID]",
   "log.original": "<163>Feb 22 14:12:56 vmhost01 2135: ERR042: Něco se pokazilo.\n"
}

Vstupní událost však obsahuje další zajímavé klíčové slovo - chybový kód "ERR042", který není součástí strukturované události. Tuto hodnotu můžeme extrahovat do vlastního pole strukturované události přidáním obohacovače (typ parseru), který rozřízne část události "message" a vybere kód chyby.

Najděte skupinu parserů, kterou chcete rozšířit

Ve výše uvedeném příkladu používáme parsery s ID skupiny lmio_parser_default_syslog_rfc3164. Přejděme tedy do složky této skupiny v knihovně LogMan.io:

# ... nebo jiné umístění souboru lmio-ecs
$ cd syslog_rfc3164-parser

Vytvoření nového deklaračního souboru

Ve výchozím nastavení bez přípony jsou ve složce skupiny parserů tyto soubory:

$ ls -l
p01-parser.YAML p02-parser.YAML

Tyto soubory obsahují deklarace parserů. Pro deklaraci nového obohacovače vytvořte soubor e01-enricher.yaml.

• Písmeno "e" znamená "enricher".
• "01" znamená prioritu, kterou bude mít tento obohacovač.
• Znak "-enricher" můžete nahradit čímkoli, co pro vás bude mít smysl
• "yaml" je povinné rozšíření

Přidání obsahu do souboru deklarace

Definujte

Deklarace je soubor YAML s hlavičkou YAML (v našem případě prázdnou) a povinným blokem definice. Přidáváme standardní obohacovač s názvem "Obohacovač chybového kódu".

Do souboru deklarace přidáme následující text:

---
define:
  název: Error Code Enricher
  typ: enricher/standard

Predikát

Chceme, aby se náš obohacovač aplikoval pouze na vybrané zprávy, proto musíme deklarovat predikát pomocí deklarativního jazyka.

Aplikujme obohacení na zprávy z hostitele vmhost01.

Do deklaračního souboru přidáme následující text:

predikát:
  !EQ
  - !ITEM EVENT host.name
  - "vmhost01"

Obohatit

Při pohledu na "zprávu" příkladové události chceme zprávu rozdělit dvojtečkami, vzít hodnotu první položky výsledků a uložit ji jako "error.code" (nebo jiné pole ECS).

Toho můžeme dosáhnout opět pomocí deklarativního jazyka.

Do deklaračního souboru přidejte následující text:

obohatit:
  !DICT
  s: !EVENT
  set:
    error.code: !CUT
      co: !ITEM EVENT zpráva
      oddělovač: ":
      pole: 0

Výsledná událost předávaná parsovacímu pipeline se bude skládat ze všech polí z původní události a z jednoho dalšího pole "error.code", jehož hodnota je výsledkem !CUT vyjmutí pole "message" z původní události (!ITEM EVENT message) pomocí : jako delimiteru a vyzvednutí položky na indexu 0.

Takto vypadá výsledný obsah souboru e01-enricher.yaml:

---
define:
  name: Error Code Enricher
  typ: obohacovač/standard
predikát:
  !EQ
  - !ITEM EVENT host.name
  - "vmhost01"
obohatit:
  !DICT
  with: !EVENT
  set:
    error.code: !CUT
      co: !ITEM EVENT zpráva
      oddělovač: ":
      pole: 0

Použít změny

Nová deklarace by měla být uložena ve správě verzí. Instance lmio-parser, která používá ID skupiny parserů, musí být restartována.

Závěr

Do pipeline parserů lmio_parser_default_syslog_rfc3164 jsme přidali nový obohacovač.

Nové události z hostitele vmhost01 budou nyní analyzovány a obohaceny, což povede k této výstupní události:

{
   "@timestamp": 1614003176,
   "ecs.version": "1.6.0",
   "event.kind": "event",
   "event.dataset": "syslog.rfc3164",
   "message": "ERR042: Something went wrong.\n",
   "host.name": "vmhost01",
   "tenant": "default",
   "log.syslog.priority": 163,
   "log.syslog.facility.code": 20,
   "log.syslog.severity.code":: 3,
   "event.ingested": 1614004510.4724128,
   "_s": "SzOe",
   "_id": "[ID]",
   "log.original": 2135: ERR042: Něco se pokazilo.\n": "log": "<163>Feb 22 14:12:56 vmhost01 2135: ERR042: Něco se pokazilo.\n",
   "error.code": "ERR042"
}

Ended: Návody

Referenční příručka

Referenční příručka

Collector

LogMan.io Collector

Konfigurace

Ve výchozím nastavení kolektor očekává konfigurační soubor lmio-collector.yaml ve složce /data/. Cestu k souboru lze přepsat v souboru site.conf:

[config]
path=./etc/lmio-collector.yaml
key=./etc/aes.key

Klíč AES musí být zadán, pokud mají být hesla v konfiguraci šifrována. pomocí LogMan.io Commander (viz jeho dokumentace), tj. !encpwd "<ENCRYPTED_LMIO_PASSWORD>". V opačném případě šifrování nebude fungovat.

Samotná konfigurace je soubor YAML založený na deklarativním jazyce BSPump.

Zde každá sekce začíná buď vstup:, transformace:, nebo výstup:. Výstup vytvoří pipeline BSPump se zadanými sink/output a konverzními procesory. Transformace provádí předzpracování události předtím, než je předána výstupu. Input přidá zdroj/vstup do dané pipeline pomocí output: <OUTPUT_ID> příkaz.

input|transform|output:<TYPE>:<ID>

Každý vstup a výstup je založen na typu, který je uveden za :. Poslední sekce je ID, které slouží k referenci (například výše zmíněný input-output).

Použití

Docker Compose

verze: '3'
services:

  lmio-collector:
    docker.teskalabs.com/<PARTNER_CODE>/lmio-collector
    container_name: lmio-collector
    volumes:
      - ./lmio-collector:/data
    network_mode: host
    porty:
      - "8888:8888"

Příkazový řádek

python3 ./lmio-collector.py -c etc/site.conf

Příklad konfigurace

Konfigurace může vypadat takto. Viz vysvětlení v komentářích:

---
input:ODBC:ODBCInput:
  host: 192.168.99.100
  port: 3306
  uživatel: root
  heslo: root
  db: sampledb
  ovladač: Ovladač: MySQL ODBC 8.0 Unicode Driver
  dotaz: SELECT jméno_jméno, příjmení, strana FROM znaky;
  # true/false
  last_value_enabled: true
  # Zadejte tabulku pro SELECT max({}) from {};
  last_value_table: characters
  # Pro úplné zadání dotazu na poslední hodnotu použijte příkaz
  # last_value_query:
  # Sloupec v dotazu, který má být použit pro získání poslední hodnoty
  last_value_column: id
  # První hodnota, od které se má začít
  last_value_start: 0
  # Trvalé úložiště pro aktuální poslední hodnotu
  last_value_storage: Poslední_hodnota_úložiště: "./etc/mysql_character_last_value_storage"
  # Jak často se má dotaz provádět (v sekundách)
  chilldown_period: 5
  output: UnixSocketOutput

input:WEC:WECInput:
  WEC: listen: # Kde vystavit server na: "0.0.0.0 8081"
  cert: # Zadejte cestu k certifikátu: "/data/cert.pem" # Zadejte cestu k certifikátu
  key: "/data/key.pem" # Zadejte cestu k soukromému klíči
  # Zadejte miniaturní otisky certifikátů vydavatele (CA) oddělené mezerou
  issuer_thumbprints: "d6982fff2104f21ab0c7ccb279217abe29c9808c"

  dotazy: # Zadejte dotaz WEC ve formátu <QUERY_PATH> <QUERY_TEXT>\n
    System *[System[(Level=1 nebo Level=2 nebo Level=3 nebo Level=4 nebo Level=0 nebo Level=5)]]
    Bezpečnost *[Security[(Level=1 nebo Level=2 nebo Level=3 nebo Level=4 nebo Level=0 nebo Level=5)]]
  read_existing_events: true

  connection_retries: 60 # Kolik opakování je přijatelné
  connection_retries_wait: 10.0 # Čekání na opakování spojení
  heartbeat: 60 # Jak často by měl být při odběru volán heartbeat (v sekundách)

  # Uložení poslední hodnoty
  # Při změně "queries" také zvažte smazání souboru
  last_value_storage: "/data/wec_last_value_storage"

  # Výstup
  output: WebSocketOutputForWindows

input:WinRM:WinRMInput:
  endpoint: http://127.0.0.1:5985/wsman
  # Autentizace
  transport: ntlm
  server_cert_validation: ignore
  # cert_pem:, cert_key_pem:
  username: <DOMAIN>\<USER> # Uživatel musí být ve skupině "Event Log Readers"
  heslo: pwd
  # Čtení 1000 systémových protokolů jednou za 2 sekundy
  Příkaz: wevtutil qe system /c:1000 /rd:true
  chilldown_period: 2
  # Kontrola duplicit:
  duplicity_check: true
  # Pracuje s příkazem "wevtutil qe system /c:500 /rd:true"
  duplicity_reverse_order: true
  # Trvalé uložení aktuální poslední hodnoty
  last_value_storage: "/data/winrm_last_value_storage"
  # Zadejte vlastní výstup
  output: WebSocketOutputForWindows

# Funguje pouze na počítači se systémem Windows, tj. nefunguje v linuxovém kontejneru Docker.
input:WinEvent:WinEventInput:
  server: localhost
  event_type: System
  last_value_storage: "/data/winevent_last_value_storage"
  # Optimalizace
  # Události, které mají být načteny najednou
  buffer_size: 1024
  # Zadejte vlastní výstup
  output: FileTestOutput

input:Stream:TCPInput:
  adresa: 127.0.0.1:8888
  output: UnixSocketOutput

input:SubProcess:SubProcessInput:
  Příkaz: tail -f /data/tail.log
  output: příkaz pro zadání příkazu: UnixSocketOutput

input:File:FileInput:
  cesta: /data/lines/*
  chilldown_period: 10
  output: Výstup: UnixSocketOutput

input:XML:XMLInput:
  cesta: XML: XML: cesta: /data/xml/*
  chilldown_period: 10
  # Každý vstup může explicitně specifikovat svůj výstup
  output: XMLUnixSocketOutput


# Deklarativní předzpracování
transform:Declarative:DeclarativeProcessor1:
  # Zadejte deklarační soubor
  declaration: /data/output_declaration.yaml
  # Specifikujte výstup
  output: UnixSocketOutput

# Transformujte XML do slovníku
transform:XMLToDict:MyXMLParser:
  výstup: XMLUnixSocketOutput


output:UnixSocket:UnixSocketOutput:
  adresa: /myunixsocket
  # Nastavte na true, aby bylo povoleno protokolování událostí
  debug: false

output:WebSocket:WebSocketOutputForWindows:
  url: http://127.0.0.1:9999/ws

output:UnixSocket:XMLUnixSocketOutput:
  adresa: /myunixsocket
  # Pro WebSocket použijte "url" místo "address"

output:File:FileTestOutput:
  Cesta: /data/my_output_file.txt

Následuje příklad deklarativního předzpracování, které v případě výše uvedeného příkladu probíhá v transform:Declarative:DeclarativeProcessor1 těsně předtím, než je událost předána do transform:DeclarativeProcessor1. výstupu definovanému adresou.

--- !DICT
s: !EVENT
set:
  zákazníkem: MyBrilliantCustomer

LogMan.io Collector

Vstupy

Dostupné vstupy a možnosti konfigurace

input:Kafka:, input:ODBC:, input:TCP:, input:Stream:, input:Datagram:, input:SubProcess:, input:SmartFile:, input:FileBlock:, input:File:, input:XML:, input:AzureEventHub:, input:BitDefender, input:Zabbix

Vstupy Microsoft Office 365 naleznete v kapitole Sběr z Microsoft Office 365. Pro vstupy ze systému Windows viz kapitolu Collecting from Windows.

input:Kafka

Tato volba je dostupná od verze v22.32.

Vytvoří konzumenta Kafky pro konkrétní .topic(s).

Možnosti konfigurace související s navázáním spojení:

bootstrap_servers: # uzly Kafka, ze kterých se mají zprávy číst (například `kafka1:9092,kafka2:9092,kafka3:9092`)

Konfigurační možnosti související s nastavením Kafka Consumer:

topic:  # Název témat, ze kterých se mají zprávy číst (například `lmio-events` nebo `^lmio.*`)
group_id:  # Název skupiny spotřebitelů (například: `collector_kafka_consumer`)
refresh_topics:  # (nepovinné) Pokud se očekává, že během konzumace bude vytvořeno více témat odpovídajících názvu tématu, tato volba určuje v sekundách, jak často se mají obnovovat odběry témat (například: `300`).

Volby bootstrap_servers, topic a group_id jsou vždy povinné.

topic může být jméno, seznam jmen oddělených mezerami nebo jednoduchý regex (pro porovnání všech dostupných témat použijte ^.*)

Další možnosti konfigurace naleznete v https://github.com/edenhill/librdkafka/blob/master/CONFIGURATION.md.

input:ODBC

Zajišťuje vstup prostřednictvím připojení ovladače ODBC k zadané databázi.

Možnosti konfigurace související s navázáním spojení:

host:  # Název hostitele databázového serveru
port:  # Port, na kterém běží databázový server
user:  # Uživatelské jméno pro přihlášení k databázovému serveru (obvykle technický/přístupový účet)
heslo:  # Heslo pro výše uvedeného uživatele
driver:  # Předinstalovaný ovladač ODBC (viz seznam níže)
db:  # Název databáze, ke které se má přistupovat
connect_timeout:  # (nepovinné) Časový limit připojení v sekundách pro fond ODBC (výchozí: 1)
reconnect_delay:  # (nepovinné) Zpoždění opětovného připojení v sekundách po vypršení časového limitu pro fond ODBC (výchozí: 5,0)
output_queue_max_size:  # (nepovinné) Maximální velikost výstupní fronty, tj. úložiště v paměti (výchozí: 10)
max_bulk_size:  # (nepovinné) Maximální velikost jedné hromadné fronty složené z příchozích záznamů (výchozí 2)
output:  # Na který výstup se mají příchozí události posílat

Možnosti konfigurace týkající se dotazování do databáze:

query:  # Dotaz pro pravidelné volání databáze
chilldown_period:  # Určuje v sekundách, jak často bude výše uvedený dotaz volán (výchozí: 5)
last_value_enabled:  # Zapnout kontrolu duplicity poslední hodnoty (true/false)
last_value_table:  # Zadejte tabulku pro SELECT max({}) from {};
last_value_column:  # Sloupec v dotazu, který se použije pro získání poslední hodnoty
last_value_storage:  # Trvalé úložiště pro aktuální poslední hodnotu (výchozí: ./var/last_value_storage)
last_value_query:  # (nepovinné) Pro úplné zadání dotazu na poslední hodnotu (v případě, že je tato možnost nastavena, nebude se brát v úvahu last_value_table)
last_value_start:  # (nepovinné) První hodnota, od které se má začít (výchozí: 0)

Dostupné ovladače ODBC pro input:ODBC:

ODBC Driver 17 for SQL Server, MySQL ODBC 8.0 Unicode Driver, MySQL ODBC 8.0 ANSI Driver, Oracle 19 ODBC driver, MariaDB

Tyto ovladače jsou předinstalovány v kontejneru lmio-collector Docker.

input:TCP, input:Stream, input:Datagram.

Tyto vstupy naslouchají na dané adrese nebo v daném souboru pomocí TCP/UDP nebo unixového socketu. Ujistěte se, že porty nebo soubory jsou propagovány i mimo kontejner Docker, pokud používáte Docker.

Možnosti konfigurace pro naslouchání na dané cestě:

adresa:  # 127.0.0.1:8888 nebo /data/mysocket).
výstup:  # Na který výstup se mají posílat příchozí události

Následující konfigurační možnosti jsou k dispozici pouze pro input:Datagram:

max_packet_size:  # (nepovinné) Určuje maximální velikost paketů v bajtech (výchozí: 65536).
receiver_buffer_size:  # (nepovinné) Omezuje velikost vyrovnávací paměti přijímače v bajtech (výchozí: 0)

input:TCPBSDSyslogRFC6587, input:TCPBSDSyslogNoFraming

Speciální případy vstupu TCP pro parsování SysLog přes TCP. Další informace naleznete v https://datatracker.ietf.org/doc/html/rfc6587 a https://datatracker.ietf.org/doc/html/rfc3164#section-4.1.1

Možnosti konfigurace pro naslouchání na dané cestě:

address:  # 127.0.0.1:8888 nebo /data/mysocket).
výstup:  # Na který výstup se mají posílat příchozí události

Následující konfigurační možnosti jsou k dispozici pouze pro input:TCPBSDSyslogRFC6587:

max_sane_msg_len:  # (nepovinné) Maximální velikost zprávy SysLog, která má být přijata, v bajtech (výchozí: 10000)

Následující konfigurační volby jsou dostupné pouze pro input:TCPBSDSyslogNoFraming:

buffer_size:  # (nepovinné) Maximální velikost zprávy SysLog, která má být přijata, v bajtech (výchozí: 64 * 1024).
varianta:  # (nepovinné) Varianta formátu příchozí zprávy SysLog, může být `auto`, `nopri` bez čísla PRI na začátku a `standard` s PRI (výchozí: auto)

input:SubProcess

Vstup SubProcess spustí příkaz jako podproces sběrače LogMan.io, zatímco příkaz pravidelně kontroluje jeho výstup na stdout (řádky) a stderr.

Konfigurační možnosti zahrnují:

příkaz:  # tail -f /data/tail.log).
output:  # Na který výstup se mají odesílat příchozí události
line_len_limit:  # (nepovinné) Limit délky jednoho načteného řádku (výchozí: 1048576)
ok_return_codes:  # (nepovinné) Které návratové kódy označují stav běhu příkazu (výchozí: 0)

input:SmartFile

Simuluje chování tail -f na více souborech, jejichž obsah může být dynamicky měněn. nebo mohou být soubory zcela odstraněny jiným procesem.

Vstup Smart File vytvoří sledovaný objekt souboru pro každou cestu k souboru, která je zadána v poli konfiguraci v možnostech cesta.

Sledovaný soubor pravidelně kontroluje, zda se v něm nevyskytují nové řádky, a pokud se nějaký vyskytne, je řádek načten v bajtech a předán dále do pipeline včetně metainformací jako je název souboru a extrahované části cesty k souboru (viz konfigurace extract_ níže).

Aktuální pozice v souboru je uložena v paměti poslední pozice v proměnné position. Pokud je soubor s uložením poslední pozice smazán nebo není zadán, jsou všechny soubory načteny znovu. po restartu LogMan.io Correlator, tj. žádná perzistence znamená reset čtení při restartu.

Pozor: Pokud je velikost souboru menší než předchozí zapamatovaná velikost souboru, soubor se znovu přečte jako celek a odešle se do potrubí rozdělený na řádky.

Mezi dostupné možnosti konfigurace patří:

cesta:  (výchozí: /data/smarttest/*).
last_position_storage:  Trvalé úložiště pro aktuální pozice v načítaných souborech (výchozí: ./var/last_position_storage)
scan_period: (nepovinné) Perioda skenování souborů v sekundách (výchozí: 3)
read_size: (nepovinné) Jeden cyklus čtení v bajtech (výchozí: 4096)
recursive: (nepovinné) Rekurzivní skenování zadaných cest (výchozí: True)
newline: (nepovinné) Oddělovač řádků souboru, např. \n (výchozí je oddělovač řádků OS)
preserve_newline: (nepovinné) Zachování znaku nového řádku ve výstupu (výchozí: False)

Následující konfigurační volby umožňují kontrolovat, zda čas modifikace načítaných souborů není starší než zadaný limit. Například limit ignore_older_than pro načítané soubory lze nastavit na ignore_older_than: 20d nebo ignore_older_than: 100s.

ignore_older_than: (nepovinné) Limit ve dnech, hodinách, minutách nebo sekundách pro čtení pouze souborů změněných po tomto limitu (výchozí: "", např. "1d", "1h", "1m", "1s").
read_only_increments:  (nepovinné) číst pouze řádky vytvořené po spuštění aplikace (výchozí: True)

K dispozici jsou také volby pro extrakci informací z názvu souboru nebo cesty k souboru pomocí regulárního výrazu. Extrahované části jsou pak uloženy jako metadata (která implicitně obsahují jedinečné meta ID a název souboru). Konfigurační volby začínají předponou extract_ a zahrnují následující:

extract_source:  # (nepovinné) název_souboru nebo cesta_k_souboru (výchozí: cesta_k_souboru)
extract_regex:  # (nepovinný) regex pro extrakci názvů polí ze zdroje extraktu (ve výchozím nastavení vypnuto)

extract_regex musí obsahovat pojmenované skupiny. Názvy skupin se použijí jako klíče polí pro extrahované informace. Nepojmenované skupiny nevytvářejí žádná data.

Uvažujte například následující konfiguraci:

extract_regex: ^/data/(?P<dvchost>\w+)/(?P<tenant>\w+)\.log$

Extrahovaná metadata pro soubor /data/myserver.xyz/tenant-1.log budou následující

{
  "meta": {
    "dvchost": "myserver.xyz",
    "tenant": "tenant-1"
  }
}

Následující příklad konfigurace vstupu SmartFile s extrakcí atributů z názvu souboru pomocí regexu a související výstup File:

input:SmartFile:SmartFileInput:
  cesta: ./etc/tail.log
  extract_source: název_souboru
  extract_regex: ^(?P<dvchost>\w+).log$
  output: FileOutput

output:File:FileOutput:
  cesta: /data/my_path.txt
  prepend_meta: true
  debug: true

prepend_meta: true předvyplní metainformace, jako jsou extrahované názvy polí, do řádku/události protokolu jako dvojice klíč-hodnota oddělené mezerami

input:File, input:FileBlock, input:XML

Tyto vstupy načítají zadané soubory po řádcích (input:File) nebo jako celý blok (input:FileBlock, input:XML). a předávají jejich obsah dále do koncovky.

V závislosti na režimu pak mohou být soubory přejmenovány na <FILE_NAME>-processed. a je-li jich pomocí zástupného znaku zadáno více, bude otevřen další soubor, načten a zpracován stejným způsobem.

Dostupné konfigurační možnosti pro otevírání, čtení a zpracování souborů zahrnují:

cesta:  # Zadejte cestu k souboru (souborům), lze použít i zástupné znaky (např. /data/lines/*).
chilldown_period:  # Pokud je v cestě použito více souborů nebo zástupný znak, zadejte, jak často v sekundách se mají kontrolovat nové soubory (výchozí: 5)
output:  # Na který výstup se mají posílat příchozí události
mode:  # (nepovinné) Režim, ve kterém se bude soubor číst (výchozí: 'rb')
newline:  # (nepovinné) Oddělovač řádků souboru (výchozí je hodnota os.linesep)
post:  # (nepovinné) Určuje, co se má se souborem stát po přečtení - delete (smazání souboru), noop (žádné přejmenování), move (přejmenování na `<FILE_NAME>-processed`, výchozí)
exclude (vyloučit):  # (nepovinné) Cesta k názvům souborů, které mají být vyloučeny (má přednost před 'include')
include:  # (nepovinné) Cesta k názvům souborů, které mají být zahrnuty
encoding:  # (nepovinné) Kódování hlsetů obsahu souboru
move_destination:  # (nepovinné) Cílová složka pro příspěvek 'move', ujistěte se, že je mimo cestu uvedenou výše
lines_per_event:  # (nepovinné) Počet řádků, po kterých metoda čtení přejde do klidového stavu, aby umožnila ostatním operacím provést jejich úkoly (výchozí: 10000)
event_idle_time:  # (nepovinné) Doba v sekundách, po kterou metoda čtení přejde do klidového stavu, viz výše (výchozí: 0,01)

Výstupy kolektoru LogMan.io

Výstup kolektoru je specifikován následovně:

výstup:<output-type>:<output-name>:
  debug: false
  ...

Běžné možnosti výstupu

V každém výstupu lze metainformace zadat jako slovník v atributu meta.

meta:
    (nepovinné) Vlastní meta informace, které budou později k dispozici v LogMan.io Parseru v kontextu události.

Metainformace tenant lze zadat přímo v konfiguraci výstupu.

Debug

debug (nepovinné)

Určuje, zda se má výstup zapisovat také do protokolu pro ladění.
Výchozí: false

Předvyplní metainformace

prepend_meta (nepovinné)

Předpřipojí metainformace k příchozí události jako dvojice klíč-hodnota oddělené mezerami.
Výchozí: false

Note

Metainformace zahrnují název souboru nebo informace z něj extrahované (v případě zadávání inteligentních souborů), vlastní definovaná pole (viz níže) atd.

Výstup TCP

Výstup událostí přes TCP na server zadaný IP adresou a portem.

output:TCP:<output-name>:
  adresa: <IP address>:<Port>
  ...

Adresa

address

Adresa serveru se skládá z IP adresy a portu.

Hint

Podporovány jsou adresy IPv4 a IPv6.

Maximální velikost paketů

max_packet_size (nepovinné)

Zadejte maximální velikost paketů v bajtech.
Výchozí hodnota: 65536

Velikost vyrovnávací paměti příjemce

receiver_buffer_size (nepovinné)

Omezuje velikost vyrovnávací paměti přijímače v bajtech.
Výchozí hodnota: 0

Výstup UDP

Vypíše události přes UDP na zadanou IP adresu a port.

output:UDP:<output-name>:
  adresa: <IP address>:<Port>
  ...

Adresa

address

Adresa serveru se skládá z IP adresy a portu.

Hint

Podporovány jsou adresy IPv4 a IPv6.

Maximální velikost paketů

max_packet_size (nepovinné)

Zadejte maximální velikost paketů v bajtech.
Výchozí hodnota: 65536

Velikost vyrovnávací paměti příjemce

receiver_buffer_size (nepovinné)

Omezuje velikost vyrovnávací paměti přijímače v bajtech.
Výchozí hodnota: 0

Výstup WebSocket

Vypíše události přes WebSocket na zadanou adresu URL.

output:WebSocket:<output-name>:
  url: <Server URL>
  ...

URL

url

Zadejte cílovou adresu URL WebSocket. Například http://example.com/ws

Nájemce

tenant

Jméno nájemce, kterému je LogMan.io Collector určen, jméno nájemce je předáno LogMan.io parseru a vloženo do události.

Neaktivní čas

inactive_time (nepovinné)

Zadejte neaktivní čas v sekundách, po kterém budou nečinné webové sokety uzavřeny.
Výchozí hodnota: 60

Velikost výstupní fronty

output_queue_max_size (nepovinné)

Určuje velikost výstupní fronty v paměti pro každý webový soket.

Cesta k uložení trvalých souborů

buffer (nepovinné)

Cesta, do které se ukládají trvalé soubory, když je připojení Web Socket offline.

Možnosti konfigurace SSL

Následující konfigurační možnosti určují připojení SSL (HTTPS):

• cert: zadejte cestu k certifikátu
• key: zadejte cestu k soukromému klíči
• cafile: zadejte soubor pro ověření partnera (nepovinné, výchozí: žádný).
• password: zadejte heslo k souboru s klíčem (nepovinné, výchozí: žádné).
• capath: zadejte cestu k ověření peera (nepovinné, výchozí: žádné).
• ciphers: Zadejte vlastní šifry SSL (nepovinné, výchozí: žádné).
• dh_params: Diffie-Hellmanovy (D-H) parametry výměny klíčů (TLS) (nepovinné, výchozí: žádné).
• verify_mode: Jedna z možností CERT_NONE, CERT_OPTIONAL nebo CERT_REQUIRED (nepovinné) více informací naleznete na: https://github.com/TeskaLabs/asab/blob/master/asab/net/tls.py

Výstupní soubor

Vypíše události do zadaného souboru.

output:File:<output-name>:
  path: /data/output.log
  ...

Cesta

path

Cesta k výstupnímu souboru.

Při použití nástroje Docker se ujistěte, že je umístění výstupního souboru přístupné v kontejneru Docker.

Příznaky

flags (nepovinné)

Jeden z O_CREAT a O_EXCL, přičemž první z nich říká výstupu, aby vytvořil soubor, pokud neexistuje.

Výchozí: O_CREAT

Režim

mode (nepovinné)

Režim, ve kterém bude soubor zapsán. Výchozí: ab (připojit bajty).

Unixová zásuvka (datagram)

Vypíše události do datagramově orientované Unix Domain Socket.

output:UnixSocket:<output-name>:
  address: <path>
  ...

Adresa

address

Cesta k unixovému soketu, např. /data/myunix.socket.

Maximální velikost paketů

max_packet_size (nepovinné)

Zadejte maximální velikost paketů v bajtech.
Výchozí hodnota: 65536

Unixová zásuvka (stream)

Vypíše události do proudově orientované Unix Domain Socket.

output:UnixStreamSocket:<output-name>:
  address: <path>
  ...

Adresa

address

Cesta k unixovému soketu, např. /data/myunix.socket.

Maximální velikost paketů

max_packet_size (nepovinné)

Zadejte maximální velikost paketů v bajtech.
Výchozí hodnota: 65536

Tiskový výstup

Pomocný výstup, který vytiskne události do terminálu.

output:Print:<output-name>:
  ...

Null Output

Pomocné výstupy, které zahazují události.

output:Null:<output-name>:
  ...

LogMan.io Collector

Transformace

Dostupné transformace

transform:Declarative:, transform:XMLToDict:

Před předáním události zadanému výstupu, může uživatelsky definovaná deklarace předzpracovat příchozí událost (řádek protokolu atd.). Viz příklad níže.

transform:Declarative: poskytuje deklarativní procesor, který se konfiguruje prostřednictvím deklarativní konfigurace (YAML).

transform:XMLToDict: se typicky používá pro soubory XML a události systému Windows z WinRM.

Shromažďování do vyhledávačů

Soubory

Pravidelné shromažďování vyhledávání ze souborů, například CSV, použijte vstup input:FileBlock: s následující konfigurací:

cesta:  # zadejte složku lookup, kam se budou ukládat lookupy ze souborů (např. /data/lookups/mylookup/*).
chilldown_period:  # Určete, jak často v sekundách se mají kontrolovat nové soubory (výchozí: 5)

FileBlock přečte všechny soubory v jednom bloku (jedna událost je celý obsah souboru) a předá jej nakonfigurovanému výstupu, což je obvykle output:WebSocket.

Tímto způsobem je vyhledávání předáno LogMan.io Ingestoru a nakonec LogMan.io Parseru, kde může být vyhledávání zpracováno a uloženo do ElasticSearch. Viz část "Parsing lookups" v dokumentaci LogMan.io Parser.

Ukázková konfigurace

input:FileBlock:MyLookupFileInput:
  cesta: /data/lookups/mylookup/*
  chilldown_period: 10
  output: Výstup: LookupOutput

output:WebSocket:LookupOutput:
  url: https://lm1/files-ingestor-ws
  ...

Tabulka obecných atributů ECS

| Atribut | Popis | Hodnoty jako příklad | | | | | | |---|-------------------------------------------|---|---|---|---| | @timestamp | Datum/čas vzniku události | 2022-05-23T08:05:34.853Z | | | | | | client.ip | IP adresa zařízení, které bylo použito při záznamu aktivity. IP adresa se zobrazuje ve formátu IPv4 nebo IPv6. | 52.108.224.1 | | | | | cnt | Počet událostí | 1 | | | | | | destination.ip | Původní cílová IP adresa zařízení, která byla použita při záznamu aktivity | 85.162.11.26 | | | | | | | ecs.version | ECS version this event conforms to | 1.0.0 | | | | | | | event.action | Popis původní události, která vyvolala vytvoření daného protokolu. | UserLoggedIn, MessageTrace, FilePreviewed | | | | | | event.original | Úplný a nezměněný protokol pro audit | 10.42.42.42 - - [07/Dec ... | | | | | http.request.method | Požadavek HTTP je akce, která má být provedena na prostředku identifikovaném daným Request-URL | get | | | | | | | http.response.body.bytes | Velikost požadavku HTTP v bytech. | 2571 | | | | | http.response.status_code | Stavové kódy odpovědi HTTP udávají, zda byl konkrétní požadavek HTTP úspěšně dokončen. | 200 | | | | | http.version | Aktuální verze protokolu pro přenos hypertextu | 1.1 | | | | | | | host.hostname | Název hostitele. | webserver-blog-prod | | | | | | zpráva | Textová reprezentace významných informací z události pro stručné zobrazení v prohlížeči protokolu | "GET /blog HTTP/1.1" 200 2571 | | | | | | | service.name | Váš vlastní název pro tuto službu | Company blog | | | | | | service.type | Typ služby použité s touto instancí | apache | | | | | | source.geo. | Pole pro geolokaci | | | | | | | url.original | Původní url cesta | /blog | | | | | | user.name | Jméno uživatele | jdoe | | | | | | user_agent. | Pole popisující agenta uživatele | | | | | | | | event.dataset | Název datasetu | microsoft-office-365 | | | | | | event.id | Jedinečná identifikační hodnota | b4b4c44c-ff30-4ddd-bfbe-44e082570800 | | | | | | | event.ingested | Časové razítko příchodu události do centrálního úložiště dat | 2022-05-23T08:05:34.853Z | | | | | | | event.kind | Hodnota tohoto pole může být použita k informování o tom, jak mají být tyto druhy událostí zpracovány | alert, enrichment, event, metric, state, pipeline_error, signal | | | | | | log.original | Surový formát protokolu, který je přijat před provedením procesu parcingu. | {"AppAccessContext": {"AADSessionId": "94a0c71a-0698-4459-8ac3-1136ddd17a09", "CorrelationId": "dcaf6ba0-405b-5000-319c-db415ddca242"}, "CreationTime": "2022-10-05T15:43:28", "Id":: "675966ba-84a5-4cda-55d1-08daa6e8592f", "Operation": "FileModified", "OrganizationId": "571c8d2c-1ae2-486d-a17c-81bf54cbaa15", "RecordType": 6, "UserKey": "i:0h.f|membership|1003200224fe6604@live.com", "UserType": 0, "Version": 1, "Workload": "SharePoint", "ClientIP": "20.49.129.255", "ObjectId": "https://teskalabscom.sharepoint.com/sites/Shared Documents/Docs/o365 - logs.xlsx", "UserId": "UserId": "john.doe@teskalabs.com", "CorrelationId": "dcaf6ba0-405b-5000-319c-db415ddca242", "EventSource": "SharePoint", "ItemType": "File", "ListId": "4c7ebfdd-6ad0-4c6e-a190-1cde4fcce4f6", "ListItemUniqueId": "f35fdc8a-8cef-4860-aa88-a9d8c457b950", "Site": "f9483e3f-a2b8-474e-8d5f-5bcbdf6906e9", "UserAgent": "MSWAC", "WebId": "7222901e-8a44-4475-94ea-8b5b0934555d", "FileSizeBytes": 18871, "SourceFileExtension": "xlsx", "SiteUrl": "https://teskalabscom.sharepoint.com/sites/CybersecDocuments/", "SourceFileName": "o365 - parsing.xlsx", "SourceRelativeUrl": "Shared Documents/Parsing/prj-prima"} | | | | | organization.id | ID původní zdrojové organizace události. | TeskaLabsCom.onmicrosoft.com | | | | | | recipient.address | E-mailová adresa původního příjemce zprávy | accounting@teskalabs.com | | | | | | | sender.address | E-mailová adresa původního odesílatele zprávy | support@teskalabs.com | | | | | | source.ip | IP adresa zdrojového zařízení nebo systému | 149.72.113.167 | | | | | | tenant | Identifikace nájemce v každé události | výchozí | | | | | | user.id | Identifikace uživatele v každé události. | automata@teskalabs.com | | | | | | | | | | |

Sběr událostí z Apache Kafka

Tato volba je k dispozici od verze v22.32

TeskaLabs LogMan.io Collector umí sbírat události z Apache Kafka, konkrétně z jeho témat. Události uložené v Kafce mohou obsahovat jakákoli data kódovaná v bajtech, například protokoly o různých akcích uživatelů, správců, systému, zařízení a zásad.

Předpoklady

Pro vytvoření konzumenta Kafka je třeba znát boostrap_servers, tedy umístění uzlů Kafka, a také topic, odkud se mají data číst.

Vstupní nastavení kolektoru LogMan.io

LogMan.io Collector poskytuje vstupní sekci input:Kafka:, kterou je třeba zadat v konfiguraci YAML. Konfigurace vypadá následovně:

input:Kafka:KafkaInput:
  bootstrap_servers: <BOOTSTRAP_SERVERS>
  topic: <TOPIC>
  group_id: <GROUP_ID>
  ...

Vstup vytvoří konzumenta Kafky pro konkrétní .topic(y).

Možnosti konfigurace související s navázáním spojení:

bootstrap_servers: # uzly Kafka, ze kterých se mají zprávy číst (například `kafka1:9092,kafka2:9092,kafka3:9092`)

Konfigurační možnosti související s nastavením Kafka Consumer:

topic:  # Název témat, ze kterých se mají zprávy číst (například `lmio-events` nebo `^lmio.*`)
group_id:  # Název skupiny spotřebitelů (například: `collector_kafka_consumer`)
refresh_topics:  # (nepovinné) Pokud se očekává, že během konzumace bude vytvořeno více témat odpovídajících názvu tématu, tato volba určuje v sekundách, jak často se mají obnovovat odběry témat (například: `300`).

Volby bootstrap_servers, topic a group_id jsou vždy povinné.

topic může být jméno, seznam jmen oddělených mezerami nebo jednoduchý regex (pro porovnání všech dostupných témat použijte ^.*)

Další možnosti konfigurace naleznete v https://github.com/edenhill/librdkafka/blob/master/CONFIGURATION.md.

Shromažďování událostí z Azure Event Hub

Tato možnost je k dispozici od verze v22.45

TeskaLabs LogMan.io Collector může shromažďovat události z Microsoft Azure Event Hub prostřednictvím nativního klienta nebo Kafky. Události uložené v Azure Event Hub mohou obsahovat jakákoli data kódovaná v bajtech, například protokoly o různých akcích uživatelů, správců, systému, zařízení a zásad.

Nastavení Azure Event Hub

Aby mohl LogMan.io Collector číst události, je třeba získat následující pověření: Řetězec připojení,název rozbočovače událostíaskupina spotřebitelů`.

Získat řetězec připojení z Azure Event Hubu

1) Přihlaste se do Azure portal s právy správce do příslušného jmenného prostoru Azure Event Hubs. Prostor názvů Azure Event Hubs je k dispozici v části Resources (Zdroje).

2) Ve vybraném jmenném prostoru Azure Event Hubs Namespace klikněte na Sdílené zásady přístupu v části Nastavení v levé nabídce. Klikněte na tlačítko Přidat, zadejte název zásady (doporučený název je: LogMan.io Collector) a mělo by se zobrazit pravé vyskakovací okno s podrobnostmi o zásadě.

3) Ve vyskakovacím okně vyberte možnost Poslouchat, aby bylo zásadě povoleno číst z rozbočovačů událostí přidružených k danému jmennému prostoru. Viz následující obrázek.

4) Zkopírujte řetězec Connection string-primary key a klikněte na tlačítko Save. Zásada by měla být viditelná v tabulce uprostřed obrazovky. Řetězec připojení začíná předponou Endpoint=sb://.

Získat skupinu spotřebitelů

5) V oboru názvů Azure Event Hubs vyberte v levé nabídce možnost Event Hubs.

6) Klikněte na rozbočovač událostí, který obsahuje události, jež mají být shromažďovány.

7) V rozbočovači událostí klikněte na tlačítko + Skupina spotřebitelů uprostřed obrazovky.

8) V pravém vyskakovacím okně zadejte název skupiny spotřebitelů (doporučená hodnota je lmio_collector) a klikněte na tlačítko Vytvořit.

9) Tento postup opakujte pro všechny rozbočovače událostí určené ke konzumaci.

10) Zapište název skupiny konzumentů a všech rozbočovačů událostí pro případnou konfiguraci LogMan.io Collector.

Vstupní konfigurace LogMan.io Collector

Azure Event Hub Input

V konfiguraci LogMan.io Collector YAML je třeba zadat vstup s názvem input:AzureEventHub::

input:AzureEventHub:AzureEventHub:
  connection_string: <CONNECTION_STRING>
  Eventhub_name: <EVENT_HUB_NAME>
  consumer_group: <CONSUMER_GROUP>
  výstup: <OUTPUT>

<CONNECTION_STRING>, <EVENT_HUB_NAME> a <CONSUMER_GROUP> jsou poskytovány prostřednictvím výše uvedeného průvodce.

Pro parser jsou k dispozici následující meta volby: azure_event_hub_offset, azure_event_hub_sequence_number, azure_event_hub_enqueued_time, azure_event_hub_partition_id, azure_event_hub_consumer_group a azure_event_hub_eventhub_name.

Výstupem jsou události jako proud bajtů, podobně jako na vstupu Kafky.

Alternativa: Vstup Kafka

Azure Event Hub také poskytuje (s výjimkou uživatelů základní úrovně) rozhraní Kafka, takže lze použít standardní vstup Kafka pro LogMan.io Collector. V Kafce existuje více možností ověřování, včetně oauth atd. Pro účely dokumentace a opakovaného použití připojovacího řetězce se však upřednostňuje prosté ověřování SASL pomocí připojovacího řetězce z výše uvedeného návodu.

input:Kafka:KafkaInput:
  bootstrap_servers: <NAMESPACE>.servicebus.windows.net:9093
  topic: <EVENT_HUB_NAME>
  group_id: <CONSUMER_GROUP>
  security.protocol: SASL_SSL
  sasl.mechanisms: PLAIN
  sasl.username: "$ConnectionString"
  sasl.password: <CONNECTION_STRING>
 <OUTPUT>

<CONNECTION_STRING>, <EVENT_HUB_NAME> a <CONSUMER_GROUP> jsou uvedeny ve výše uvedeném průvodci, <NAMESPACE> v názvu prostředku Azure Event Hub (rovněž zmíněném ve výše uvedeném průvodci).

Pro parser jsou k dispozici následující meta volby: _kafka_key, _kafka_headers, _kafka_topic, _kafka_partition a _kafka_offset.

Výstupem jsou události jako proud bajtů.

Collecting events from Google Cloud PubSub

This option is available from version v23.27 onwards

TeskaLabs LogMan.io Collector can collect events from Google Cloud PubSub using a native asynchronous consumer.

Google Cloud PubSub Documentation

Google Cloud Pull Subscription Explanation

Prerequisites

In Pub Sub, the following information need to be gathered:

1.) The name of the project the messages are to be consumed from

How to create a topic in a project

2.) the subscription name created in the topic the messages are to be consumed from

How to create a PubSub subscription

3.) Service account file with a private key to authorize to the given topic and subscription

How to create a service account

LogMan.io Collector Input setup

Google Cloud PubSub Input

The input named input:GoogleCloudPubSub: needs to be provided in the LogMan.io Collector YAML configuration:

input:GoogleCloudPubSub:GoogleCloudPubSub:
  subscription_name: <NAME_OF_THE_SUBSCRIPTION_IN_THE_GIVEN_TOPIC>
  project_name: <NAME_OF_THE_PROJECT_TO_CONSUME_FROM>
  service_account_file: <PATH_TO_THE_SERVICE_ACCOUNT_FILE>
  output: <OUTPUT>

<NAME_OF_THE_SUBSCRIPTION_IN_THE_GIVEN_TOPIC>, <NAME_OF_THE_PROJECT_TO_CONSUME_FROM> and <PATH_TO_THE_SERVICE_ACCOUNT_FILE> must be provided from the Google Clould Pub Sub

The output is events as a byte stream with the following meta information: publish_time, message_id, project_name and subscription_name.

Commit

The commit/acknowledgement is done automatically after each individual bulk of messages is processed, so the same messages are not set by PubSub repeatedly. The default bulk is 5000 messages and can be changed in the input configuraion via max_messages option:

max_messages: 10000

Sběr od společnosti BitDefender

TeskaLabs LogMan.io může shromažďovat protokoly BitDefenderu z požadavků provedených BitDefenderem, jak je uvedeno v dokumentaci API serveru: https://www.bitdefender.com/business/support/en/77209-135319-setpusheventsettings.html

Konfigurace sběrače LogMan.io

Na serveru LogMan.io, kam jsou protokoly přeposílány, spusťte instanci LogMan.io Collector s následující konfigurací. V části poslouchat nastavte příslušný port nakonfigurovaný v části Předávání protokolů v produktu BitDefender.

Konfigurace serveru BitDefender

input:BitDefender:BitDefenderAPI:
  poslouchat: 0.0.0.0 <PORT_SET_IN_FORWARDING> ssl
  cert: <PATH_TO_PEM_CERT>
  key: <PATH_TO_PEM_KEY_CERT>
  cafile: <PATH_TO_PEM_CA_CERT>
  kódování: utf-8
  výstup: WebSocketOutput

output:WebSocket:WebSocketOutput:
  url: http://<LMIO_SERVER>:<YOUR_PORT>/ws
  nájemce: <YOUR_TENANT>
  debug: false
  prepend_meta: false

Sběr ze zařízení založených na systému Cisco IOS

Tato metoda sběru je určena pro sběr protokolů z produktů Cisco, které pracují s operačním systémem IOS, jako je přepínač Cisco Catalyst 2960 nebo směrovač Cisco ASR 9200.

Konfigurace protokolu

Konfigurace vzdálené adresy kolektoru a úrovně protokolování:

CATALYST(config)# logging host <hostname or IP of the LogMan.io collector> transport tcp port <port-number>
CATALYST(config)# logging trap informational
CATALYST(config)# service timestamps log datetime year msec show-timezone
CATALYST(config)# logging origin-id <hostname>

Formát protokolu obsahuje následující pole:

• časové razítko ve formátu UTC s:

  • rok měsíc, den
  • hodina, minuta a sekunda
  • milisekunda

• název hostitele zařízení

• úroveň protokolu je nastavena na informační

Příklad výstupu:

<189>36: CATALYST: Aug 22 2022 10:11:25.873 UTC: %SYS-5-CONFIG_I: Konfigurace z konzole provedena správcem na vty0 (10.0.0.44).

Synchronizace času

Je důležité, aby byl čas zařízení Cisco synchronizován pomocí NTP.

Předpoklady jsou následující: * připojení k internetu (pokud používáte veřejný server NTP). * nakonfigurovaná možnost jmenného serveru (pro překlad dotazu DNS)

LAB-CATALYST(config)# no clock timezone
LAB-CATALYST(config)# no ntp
LAB-CATALYST(config)# ntp server <hostname or IP of NTP server>

Příklad konfigurace se serverem Google NTP:

CATALYST(config)# no clock timezone
CATALYST(config)# no ntp
CATALYST(config)# do show ntp associations
%NTP není povoleno.

CATALYST(config)# ntp server time.google.com
CATALYST(config)# do show ntp associations

      address ref clock st when poll reach delay offset disp
*~216.239.35.4 .GOOG.            1 58 64 377 15.2 0.58 0.4
 * master (synchronizovaný), # master (nesynchronizovaný), + selected, - candidate, ~ configured

CATALYST(config)# do show clock
10:57:39.110 UTC Po 22. 8. 2022

Sběr od společnosti Citrix

TeskaLabs LogMan.io může sbírat logy Citrix pomocí Syslogu prostřednictvím předávání logů přes TCP (doporučeno) nebo UDP komunikaci.

Citrix ADC

Pokud jsou zařízení Citrix připojena prostřednictvím ADC, existuje následující návod, jak povolit Syslog přes TCP. Ujistěte se, že jste vybrali správný server LogMan.io a port, na který chcete předávat protokoly.

• Jak povolit Syslog přes TCP v ADC

F5 BIG-IP

Pokud jsou k zařízení F5 BIG-IP připojena zařízení Citrix, použijte následující návod. Ujistěte se, že jste vybrali správný server LogMan.io a port, na který se mají předávat protokoly.

• Konfigurace systému BIG-IP pro odesílání protokolů na vzdálený server syslog

Konfigurace sběrače LogMan.io

Na serveru LogMan.io, kam jsou protokoly přeposílány, spusťte instanci LogMan.io Collector s následující konfigurací.

Předávání protokolů přes TCP

input:TCPBSDSyslogRFC6587:Citrix:
  Adresa: Citrix: Citrix: Citrix: Citrix: Citrix: Citrix: Citrix: Citrix: Citrix: Citrix: Citrix: cit: 0.0.0.0:<PORT_SET_IN_FORWARDING>
  Výstup: WebSocketOutput

output:WebSocket:WebSocketOutput:
  url: http://<LMIO_SERVER>:<YOUR_PORT>/ws
  nájemce: <YOUR_TENANT>
  debug: false
  prepend_meta: false

Předávání protokolu přes UDP

input:Datagram:Citrix:
  adresa: 0.0.0.0:<PORT_SET_IN_FORWARDING>
  output: WebSocketOutput

output:WebSocket:WebSocketOutput:
  url: http://<LMIO_SERVER>:<YOUR_PORT>/ws
  nájemce: <YOUR_TENANT>
  debug: false
  prepend_meta: false

Sběr z brány FortiGate

TeskaLabs LogMan.io může sbírat protokoly z FortiGate přímo nebo prostřednictvím FortiAnalyzer prostřednictvím předávání protokolů přes TCP (doporučeno) nebo UDP komunikaci.

Předávání protokolů do LogMan.io

V systému FortiGate i FortiAnalyzer musí být vybrán typ Syslog spolu s příslušným portem. Přesné návody naleznete na následujícím odkazu:

• FortiAnalyzer Log Forwarding Setting

Konfigurace kolektoru LogMan.io

Na serveru LogMan.io, kam se předávají protokoly, spusťte instanci LogMan.io Collector s následující konfigurací. V části adresa nastavte příslušný port nakonfigurovaný v části Log Forwarding v aplikaci FortiAnalyzer.

Předávání protokolů přes TCP

input:TCPBSDSyslogRFC6587:Fortigate:
  adresa: 0.0.0.0:<PORT_SET_IN_FORWARDING>
  Výstup: WebSocketOutput

output:WebSocket:WebSocketOutput:
  url: http://<LMIO_SERVER>:<YOUR_PORT>/ws
  nájemce: <YOUR_TENANT>
  debug: false
  prepend_meta: false

Předávání protokolu přes UDP

input:Datagram:Fortigate:
  adresa: 0.0.0.0:<PORT_SET_IN_FORWARDING>
  Výstup: 0.0.0: 0.0.0: 0.0.0: WebSocketOutput

output:WebSocket:WebSocketOutput:
  url: http://<LMIO_SERVER>:<YOUR_PORT>/ws
  nájemce: <YOUR_TENANT>
  debug: false
  prepend_meta: false

Shromažďování protokolů ze služby Microsoft 365

TeskaLabs LogMan.io může shromažďovat protokoly z Microsoft 365, dříve Microsoft Office 365.

Existují následující třídy protokolů Microsoft 365:

1) Auditní protokoly: Obsahují informace o různých akcích a událostech uživatelů, správců, systému a zásad z Azure Active Directory, Exchange a SharePoint.

2) Sledování zpráv: Poskytuje možnost získat přehled o e-mailovém provozu procházejícím poštovním serverem Microsoft Office 365 Exchange.

Povolení auditu Microsoft 365

Ve výchozím nastavení je pro podnikové organizace Microsoft 365 a Office 365 povoleno protokolování auditu. Při nastavování protokolování organizace Microsoft 365 nebo Office 365 byste však měli ověřit stav auditování Microsoft Office 365.

1) Přejděte na stránku https://compliance.microsoft.com/ a přihlaste se.

2) V levém navigačním podokně centra shody Microsoft 365 klikněte na položku Audit.

3) Klikněte na banner Zahájit zaznamenávání aktivit uživatelů a správců.

Může trvat až 60 minut, než se změna projeví.

Další podrobnosti naleznete v části Zapnutí nebo vypnutí auditování.

Konfigurace služby Microsoft 365

Nejprve je třeba nakonfigurovat službu Microsoft 365.

Kroky:

1) Nastavte předplatné Microsoft 365 a předplatné Azure.

Potřebujete předplatné služby Microsoft 365 a předplatné služby Azure, které bylo přidruženo k předplatnému služby Microsoft 365. Pro začátek můžete použít zkušební předplatné Microsoft 365 i Azure.
Další podrobnosti naleznete v části Welcome to the Office 365 Developer Program.

2) Zaregistrujte svou instanci aplikace TeskaLabs LogMan.io v Azure AD.

To vám umožní vytvořit identitu pro TeskaLabs LogMan.io a přiřadit mu specifická oprávnění, která potřebuje ke shromažďování protokolů z rozhraní Microsoft 365 API.

Přihlaste se do Azure portal pomocí pověření z předplatného Microsoft 365, které chcete používat.

3) Přejděte do služby Azure Active Directory.

4) Na stránce Azure Active Directory vyberte možnost "Registrace aplikací" (1) a poté vyberte možnost "Nová registrace" (2).

5) Vyplňte registrační formulář pro aplikaci TeskaLabs LogMan.io.

• Název: "TeskaLabs LogMan.io"
• Podporované typy účtů: "Pouze účet v tomto organizačním adresáři"
• Adresa URL přesměrování: Žádné

Stisknutím tlačítka "Register" proces dokončíte.

6) Shromážděte základní informace

Na portálu Azure uložte následující informace ze stránky registrované žádosti:

• ID aplikace (klienta)
• ID adresáře (nájemce)

7) Vytvoření klientského tajemství

Client secret slouží k bezpečné autorizaci a přístupu k TeskaLabs LogMan.io.

Po zobrazení stránky pro vaši aplikaci vyberte v levém panelu položku Certifikáty a tajemství (1). Poté vyberte záložku "Klientské tajemství" (2). Na této kartě vytvořte nová tajemství klienta (3).

8) Vyplňte informace o novém klientském tajemství

• Popis: "TeskaLabs LogMan.io klientské tajemství"
• Platnost: 24 měsíců

Pro pokračování stiskněte tlačítko "Add".

9) Kliknutím na ikonu schránky zkopírujte tajnou hodnotu klienta do schránky.

Uložte Hodnotu (nikoli ID tajného klienta) pro konfiguraci TeskaLabs LogMan.io.

10) Zadejte oprávnění pro přístup aplikace TeskaLabs LogMan.io k rozhraním API pro správu Microsoft 365.

Přejděte do sekce Registrace aplikací > Všechny aplikace na portálu Azure a vyberte "TeskaLabs LogMan.io".

11) V levém podokně vyberte položku API Permissions (Oprávnění API) (1) a poté klikněte na tlačítko Add a permission (Přidat oprávnění) (2).

12) Na kartě Microsoft API vyberte možnost Microsoft 365 Management APIs.

13) Na výsuvné stránce vyberte všechny typy oprávnění.

• Delegovaná oprávnění
• ActivityFeed.Read
• ActivityFeed.ReadDlp
• ServiceHealth.Read
• Oprávnění aplikace
• ActivityFeed.Read
• ActivityFeed.ReadDlp
• ServiceHealth.Read

Klikněte na tlačítko "Přidat oprávnění" a dokončete.

14) Přidejte oprávnění "Microsoft Graph".

• Delegovaná oprávnění
• AuditLog.Read.All
• Oprávnění aplikace
• AuditLog.Read.All

Vyberte "Microsoft Graph", "Delegated permissions", poté vyhledejte a vyberte "AuditLog.Read.All" v "Audit Log".

Poté opět vyberte "Microsoft Graph", "Application permissions", poté vyhledejte a vyberte "AuditLog.Read.All" v "Audit Log".

15) Přidání oprávnění "Office 365 Exchange online" pro shromažďování zpráv o sledování zpráv.

Znovu klikněte na "Přidat oprávnění".
Poté přejděte na "APIs my organization uses" (Rozhraní API, které používá moje organizace).
Do vyhledávacího řádku zadejte "Office 365 Exchange Online".
Nakonec vyberte položku "Office 365 Exchange Online".

Vyberte možnost "Application permissions".
Do vyhledávacího řádku zadejte "ReportingWebService".
Zaškrtněte políčko "ReportingWebService.Read.All".
Nakonec klikněte na tlačítko "Přidat oprávnění".

16) Udělení souhlasu správce

17) Přejděte do služby Azure Active Directory

18) Přejděte na položku Role a správci

19) Přiřazení role TeskaLabs LogMan.io do role Global Reader

Do vyhledávacího řádku zadejte "Global Reader".
Poté klikněte na položku "Global Reader".

Vyberte možnost "Přidat přiřazení".
Do vyhledávacího řádku zadejte "TeskaLabs LogMan.io". Případně použijte "ID aplikace (klienta)" z předchozích kroků.
Vyberte položku "TeskaLabs LogMan.io", položka se objeví ve "Vybraných položkách". Stiskněte tlačítko "Přidat".

Congratulujeme! Váš Microsoft 365 je nyní připraven ke sběru protokolu.

Konfigurace TeskaLabs LogMan.io

connection:MSOffice365:

Nejprve je třeba nastavit připojení pro pravidelné obnovování tokenu OAuth:

connection:MSOffice365:MSOffice365Connection:
  client_id:  # ID aplikace (klienta) z Azure Portal
  tenant_id:  # ID adresáře (nájemce) z portálu Azure
  client_secret: # Hodnota klientského tajemství z Azure Portal
  resources:  # (nepovinné) prostředky, ze kterých chcete získat data, oddělené čárkou (,) (výchozí: https://manage.office.com,https://outlook.office365.com)

Vždy je třeba zadat Client ID, tenant ID a client secret.

input:MSOffice365Source:

Konfigurační možnosti pro nastavení připojení a dotazů:

připojení:  # ID připojení MSOffice365 
content_type:  # (nepovinné) Typ obsahu získaných protokolů (výchozí: Audit.AzureActiveDirectory Audit.Exchange Audit.SharePoint Audit.General)
resource:  # (nepovinný) zdroj, ze kterého se mají data získat (výchozí: https://manage.office.com)

output:  # Na který výstup se mají odesílat příchozí události

kódování:  # (nepovinné) Kódování hromadného obsahu odpovědi serveru (výchozí: utf-8)
last_value_storage:  # (nepovinné) Trvalé úložiště pro aktuální poslední hodnotu (výchozí: ./var/last_value_storage)

Příklad konfigurace

input:MSOffice365Source:MyMSOffice365Source:
  připojení: MSOffice365Connection:: MSOffice365Connection
  ... 

vstup:MSOffice365MessageTraceSource:

Možnosti konfigurace pro nastavení zdroje dat pro sledování zpráv MS Office:

připojení:  # ID připojení MSOffice365

output:  # Na který výstup se mají odesílat příchozí události

resource:  # (nepovinný) zdroj, ze kterého se mají získávat data (výchozí: https://outlook.office365.com)
kódování:  # (nepovinné) Kódování harsetu hromadného obsahu odpovědi serveru (výchozí: utf-8)
last_value_storage:  # (nepovinné) Trvalé úložiště pro aktuální poslední hodnotu (výchozí: ./var/last_value_storage)
refresh:  # (nepovinné) Interval obnovování v sekundách pro získávání zpráv z rozhraní API (výchozí: 600)

Příklad konfigurace ####

input:MSOffice365MessageTraceSource:MSOffice365MessageTraceSource:
  připojení: MSOffice365Connection
  ... 

Obnovení tajemství klienta

Platnost klientského tajemství vyprší po 24 měsících a je třeba jej pravidelně obnovovat.

1) Přejděte do služby Azure Active Directory.

2) Přejděte na "App registrations" (Registrace aplikací) a vyberte "TeskaLabs LogMan.io".

3) Vytvořte nové klientské tajemství.

Přejděte do části "Certifikáty a tajemství".
Na kartě "Klientské tajemství" stiskněte tlačítko "Nový klientský sekret".
V poli Popis vyplňte "TeskaLabs LogMan.io Client Secret 2". Pro nová klientská tajemství používejte rostoucí čísla.
Zvolte vypršení platnosti "730 dní (24 mothns)". Stiskněte tlačítko "Přidat".

4) Překonfigurujte TeskaLabs LogMan.io tak, aby používal nové klientské tajemství.

5) Odstraňte staré klientské tajemství.

Vysvětlení atributů Microsoft 365

Atribut		Popis	Hodnoty jako příklad	Poznámky	Úplný seznam (ext)
o365.audit.ActorContextId		ID účtu uživatele nebo služby, který akci provedl.	571c8d2c-1ae2-486d-a17c-81bf54cbaa15
o365.audit.ApplicationId		Identifikátor aplikace (jedinečný řetězec písmeno+číslo)	89bee1f7-5e6e-4d8a-9f3d-ecd601259da7
o365.audit.AzureActiveDirectoryEventType		Typ události Azure Active Directory. Následující hodnoty označují typ události.	0 - Označuje událost přihlášení k účtu. 1 - Označuje událost zabezpečení aplikace Azure.
o365.audit.DeviceProperties		Vlastnosti zdrojového zařízení, například operační systém, typ prohlížeče atd.	Name: "OS" Value: "Linux" } {2 položky Název: "BrowserType" Hodnota: "Firefox" } {2 položky Name: "IsCompliantAndManaged" Value: "False" } {2 items Name: "SessionId" Value: "e94ad17c-354f-4009-a9ee-34900770e997"	Parcing těchto vlastností stále probíhá
o365.audit.ErrorNumber		Řetězec kódu chyby, který lze použít ke klasifikaci typů chyb, které se vyskytnou, a který by měl být použit k reakci na chyby.	0, 50140, 501314 ...	https://learn.microsoft.com/en-us/azure/active-directory/develop/reference-aadsts-error-codes
o365.audit.ExtraProperties		Zatím nedefinováno	//
o365.audit.FileSizeBytes		Velikost souboru v bytech	23301
o365.audit.InterSystemsId		Řetězec jedinečného ID mezi systémy	acc33436-ee63-4d81-b6ee-544998a1c7d9
o365.audit.IntraSystemId	Řetězec unikátních vnitrosystémových ID	01dd20c0-edb9-4aaa-a51b-2bf38e1a8900
o365.audit.ItemName		Unikátní název položky	b1379a75-ce5e-4fa3-80c6-89bb39bf646c
o365.audit.LogonError		Chybová zpráva zobrazená po neúspěšném přihlášení	InvalidUserNameOrPassword, TriggerBrowserCapabilitiesInterrupt, InvalidPasswordExpiredPassword
o365.audit.ObjectId		Cesta URL k přístupnému souboru	https://telescopetest.sharepoint.com/sites/Shared Documents/Docs/o365 - logs.xlsx
o365.audit.RecordType		Typ operace uvedený v záznamu. Tato vlastnost označuje službu nebo funkci, ve které byla operace spuštěna.	6		https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema#auditlogrecordtype
o365.audit.ResultStatus		Spuštěná odezva	Úspěch, Neúspěch
o365.audit.SourceFileExtension		Přípona zpřístupněného souboru (typ formátu).	.xlsx, .pdf, .doc atd.
o365.audit.SourceFileName		Název souboru, ke kterému uživatel přistupoval	"o365.attributesexplained.xlsx"
o365.audit.SupportTicketId		ID potenciálního požadavku na podporu poté, co uživatel otevřel požadavek na podporu v Azure Active Directory.	//	ID tiketu podpory zákazníka pro akci v situacích "act-on-behalf-of".
o365.audit.TargetContextId		GUID organizace, do které patří cílový uživatel.	571c8d2c-1ae2-486d-a17c-81bf54cbaa15
o365.audit.UserKey			Alternativní ID uživatele identifikovaného ve vlastnosti UserID. Tato vlastnost je například vyplněna jedinečným ID pasu (PUID) pro události prováděné uživateli v aplikaci SharePoint. Tato vlastnost může také uvádět stejnou hodnotu jako vlastnost UserID pro události vyskytující se v jiných službách a události prováděné systémovými účty.	i:0h.f|membership|1003200224fe6604@live.com
o365.audit.UserType		Typ uživatele, který provedl operaci. Následující hodnoty označují typ uživatele.	0 - Běžný uživatel. 2 - Správce v organizaci Microsoft 365.1 3 - Správce datového centra Microsoft nebo systémový účet datového centra. 4 - Systémový účet. 5 - Aplikační účet. 6 - Příkazce služby. 7 - Vlastní zásada. 8 - Systémová zásada.
o365.audit.Version			Udává číslo verze činnosti (identifikované vlastností Operation), která je protokolována.	1
o365.audit.Workload		Služba Microsoft 365, ve které k činnosti došlo.	AzureActiveDirectory
o365.message.id	Jedná se o ID internetové zprávy (známé také jako ID klienta), které se nachází v záhlaví zprávy v poli Message-ID:.	08f1e0f6806a47b4ac103961109ae6ef@server.domain	Toto ID by mělo být jedinečné; ne všechny odesílající poštovní systémy se však chovají stejně. V důsledku toho je možné, že při dotazování na základě jediného ID zprávy získáte výsledky pro více zpráv.
o365.message.index		Hodnota indexu MessageTrace	1, 2, 3 ...
o365.message.size	Velikost odeslané/přijaté zprávy v bytech.	33489
o365.message.status	Následující akce po odeslání zprávy.	Delivered, FilteredAspam, Expanded		https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/run-a-message-trace-and-view-results
o365.message.subject	Předmět zprávy; lze zapsat jednoznačně.	"Závazný nabídkový dopis pro paní Smithovou"

Další informace

• Schéma událostí správy Office 365
• Office 365 Management Activity reference

Sběr protokolů z databáze pomocí ODBC

Úvod

Doporučeným způsobem získávání protokolů a dalších událostí z databází je použití ODBC. ODBC poskytuje jednotný způsob, jak připojit LogMan.io k různým databázovým systémům.

Ovladač a konfigurace ODBC

Musíte zajistit ovladač ODBC pro databázový systém, který chcete integrovat s LogMan.io. Příslušný ovladač ODBC musí být kompatibilní s Ubuntu 20.04 LTS, 64bit.

Ovladače ODBC je třeba nasadit do kolektoru LogMan.io, konkrétně do adresáře /odbc. Případně vám naše podpora pomůže nasadit správný ovladač ODBC pro váš databázový systém nebo poskytne LogMan.io Collector s přibaleným ovladačem ODBC.

_Poznámka: Upozornění: ovladače ODBC jsou vystaveny softwaru LogMan.io collector prostřednictvím takzvaných svazků Docker.

Konfigurace ODBC se provádí v souborech /odbc/odbcinst.ini a odbc.ini.

Vstupní konfigurace kolektoru

Specifikace vstupního zdroje je input:ODBC:.

Příklad konfigurace kolektoru ODBC:

input:ODBC:ODBCInput:
  dsn: Driver={FreeTDS};Server=MyServer;Port=1433;Database=MyDatabase;TDS_Version=7.3;UID=MyUser;PWD=MyPassword
  dotaz: SELECT * FROM viewAlerts WHERE {increment_where_clause} ORDER BY Cas Time;
  increment_strategy: date
  increment_first_value: "2020-10-01 00:00:00.000"
  increment_column_name: "Time"
  chilldown_period: 30
  output: WebSocket
  last_value_storage: /data/var/last_value_storage

Konfigurace MySQL ODBC

Ovladače MySQL ODBC lze získat na následujícím odkazu. Balíček ovladačů je třeba rozbalit do adresáře /odbc/mysql.

Záznamy v /odbc/odbcinst.ini:

[MySQL ODBC 8.0 Unicode Driver]
Driver=/odbc/mysql/libmyodbc8w.so
UsageCount=1

[MySQL ODBC 8.0 ANSI Driver]
Driver=/odbc/mysql/libmyodbc8a.so
UsageCount=1

Konfigurace Microsoft SQL Server ODBC

Ovladače Microsoft SQL Server ODBC lze získat na následujícím odkazu.

Položky v souboru /odbc/odbcinst.ini:

[ODBC Driver 17 for SQL Server]
Description=Ovladač ODBC 17 pro SQL Server od společnosti Microsoft
Driver=/odbc/microsoft/msodbcsql17/lib64/libmsodbcsql-17.6.so.1.1
UsageCount=1

Příklad připojovacího řetězce:

Driver={ODBC Driver 17 for SQL Server};Server=<server_name>;Authentication=ActiveDirectoryPassword;UID=<username>;PWD=<password>;Database=<database>;TrustServerCertificate=Yes

Alternativní konfigurace Microsoft SQL Server ODBC

Alternativní připojení k Microsoft SQL Serveru poskytuje projekt FreeTDS, resp. jeho ovladač ODBC.

Položky v souboru /odbc/odbcinst.ini:

[FreeTDS]
Description=Ovladač FreeTDS pro Linux a MSSQL
Driver=/odbc/freetds/libtdsodbc.so
Setup=/odbc/freetds/libtdsodbc.so
UsageCount=1

Příklad připojovacího řetězce:

Driver={FreeTDS};Server=<server_name>;Port=<server_port>;Database=<database>;UID=<username>;PWD=<password>;TDS_Version=7.3

Konfigurace MariaDB ODBC

Ovladače MariaDB ODBC lze získat na následujícím odkazu.

Konfigurace SAP IQ, Sybase IQ, Sybase ASE ODBC

Ovladače ODBC SAP IQ / Sybase IQ / Sybase ASE / SQL Anywhere je třeba stáhnout ze stránek podpory SAP. Balíček ovladačů je třeba rozbalit do adresáře /odbc/sybase.

Záznam v /odbc/odbcinst.ini:

[ODBC Driver for Sybase IQ]
Description=Sybase IQ
Driver=/odbc/sybase/IQ-16_1/lib64/libdbodbc17.so
UsageCount=1

Příklad připojovacího řetězce:

Driver={ODBC Driver for Sybase IQ};UID=<username>;PWD=<password>;Server=<server_name>;DBN=<database_name>;CommLinks=TCPIP{host=<host>;port=<port>};DriverUnicodeType=1

Řešení problémů

Přidat ODBC Trace

Pokud potřebujete lepší přehled o připojení ODBC, můžete povolit trasování ODBC.

Přidejte tuto část do souboru /odbc/odbcinst.ini :

[ODBC]
Trace = yes
TraceFile = /odbc/trace.log

Poté se spustí kolektor, výstup trasování systému ODBC se uloží do souboru /odbc/trace.log. Tento soubor je dostupný i mimo kontejner.

Ověření konfigurace ODBC

K ověření připravenosti ODBC lze použít příkaz odbcinst -j (spuštěný v kontejneru):

# odbcinst -j
unixODBC 2.3.6
DRIVERS............: /etc/odbcinst.ini
SYSTÉMOVÉ ZDROJE DAT: /etc/odbc.ini
ZDROJE DAT SOUBORŮ..: datových zdrojů: /etc/ODBCDataSources
UŽIVATELSKÉ ZDROJE DAT..: Odbc.ini: /root/.odbc.ini
SQLULEN Velikost.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Velikost: 8

Docker-compose

Kolektor LogMan.io lze spustit pomocí docker-compose.

Toto je výtah příslušných položek ze souboru docker-compose.yaml:

lmio-collector:
  image: docker.teskalabs.com/lmio/lmio-collector

  ...

  svazky:
    - /odbc/odbcinst.ini:/etc/odbcinst.ini
    - /odbc/odbc.ini:/etc/odbc.ini
    - /odbc:/odbc

  ...

  network_mode: host

Poté je třeba znovu vytvořit kolektor LogMan.io pomocí:

docker-compose up -d

Více informací

• Příklady řetězců připojení ODBC: https://www.connectionstrings.com

Shromažďování protokolů ze systému Microsoft Windows

Existuje více způsobů, jak shromažďovat protokoly, respektive Události systému Windows ze systému Microsoft Windows.

Sběr pomocí nástroje Window Event Collector (WEC/WEF)

Window Event Collector (WEC) bez agenta odesílá protokoly z počítačů se systémem Windows prostřednictvím služby Windows Event Forwarding (WEF) do kolektoru LogMan.io. Kolektor LogMan.io funguje jako Window Event Collector (WEC). Konfiguraci WEF lze zajistit pomocí zásad skupiny buď centrálně spravovaných serverem Active Directory, nebo pomocí místních zásad skupiny. Tato strategie nevyžaduje žádnou konfiguraci v počítačích se systémem Windows.

Tip

Tuto metodu doporučujeme pro shromažďování protokolů událostí systému Windows.

Schema: Průběh událostí sbírky WEC/WEF v TeskaLabs LogMan.io.

Možnosti konfigurace WEC

Specifikace vstupu: input:WEC:

listen: <ADDRESS> <PORT> <OPTIONAL SSL># 0.0.0.0 5985" pro HTTP s Kerbros nebo "0.0.0.0 5986 ssl" pro HTTPS.
dotazy:  # Dotazy na události systému Windows oddělené novými řádky, které určují, které události systému Windows mají být načteny v odběrech.
výstup:  # Na který výstup se mají příchozí události odesílat
last_value_storage:  # Trvalé úložiště pro aktuální poslední hodnotu (výchozí: ./var/last_value_storage)
read_existing_events:  # (nepovinné) Informuje počítače se systémem Windows, zda mají odesílat existující události (true/false, výchozí: true)
connection_retries:  # (nepovinné) Kolik opakovaných pokusů v řadě je přijatelných pro počítače se systémem Windows (výchozí: 60)
connection_retries_wait:  # (nepovinné) Jak dlouho v sekundách se má čekat na opakování připojení (výchozí: 10.0)
heartbeat:  # (nepovinné) Jak často v sekundách se má při odběru volat srdeční tep (výchozí: 60)
backlog:  # (nepovinné) Určuje počet čekajících spojení, která bude fronta držet (výchozí: 128)
servertokens:  # (nepovinné) Řídí, zda bude zahrnuto pole hlavičky odpovědi "Server" ("full") nebo podvržené pole "prod" (výchozí: full).
cors: # (nepovinné) Určuje atributy CORS (výchozí: žádné)

Nastavení queries s dotazy na události systému Windows může vypadat následovně (název dotazu následovaný jeho definicí):

  dotazy:
    Systém: Úroveň: "*[System[(Úroveň=1 nebo Úroveň=2 nebo Úroveň=3 nebo Úroveň=4 nebo Úroveň=0 nebo Úroveň=5)]]"
    Bezpečnost: "*[System[(Level=1 nebo Level=2 nebo Level=3 nebo Level=4 nebo Level=0 nebo Level=5)]]"

Dotazy lze zadat pro každý typ protokolu událostí okna, včetně:

• Aplikace pro protokoly aplikací
• System pro systémové protokoly
• Security pro bezpečnostní protokoly

Dotazy lze omezit pro určité zdrojové IP adresy nebo ID strojů pomocí seznamu identifikátorů YAML na konci dotazu. ID stroje je jedinečné pro každý počítač se systémem Windows a je založeno na názvu hostitele domény.

  dotazy:
    Systém:
      Úroveň: "*[System[(Level=1 nebo Level=2 nebo Level=3 nebo Level=4 nebo Level=0 nebo Level=5)]]"

    Zabezpečení:
      "*[System[(Level=1 nebo Level=2 nebo Level=3 nebo Level=4 nebo Level=0 nebo Level=5)]]"
    ...
    Aplikace:
      "*[System[(Level=1 nebo Level=2 nebo Level=3 nebo Level=4 nebo Level=0 nebo Level=5)]]":
        - 192.168.111.128
        - 192.168.111.128
        - "APP.example.com"
    ...

Tímto způsobem budou aplikační protokoly odesílat pouze počítače se systémem Windows s IP adresami 192.168.111.128, 192.168.111.128 a s ID stroje APP.example.com (jejich odběr bude obsahovat dotaz na aplikaci).

Pro WEC existují dvě možnosti ověřování:

1. Kerberos a Active Directory
2. Vzájemné ověřování SSL pomocí certifikátu HTTPS

Ověřování Kerberos

Ověřování Kerberos využívá pro ověřování a šifrování předávání protokolů příslušné Kerberos tikety domény Active Directory vydané řadičem domény. Server WEC (kolektor LogMan.io) naslouchá na serveru HTTP na portu tcp/5985. Toto ověřování vyžaduje Active Directory.

Možnosti konfigurace kolektoru LogMan.io WEC pro ověřování Kerberos

listen: 0.0.0.0 5985
last_value_storage:  # Trvalé úložiště pro aktuální poslední hodnotu (výchozí: ./var/last_value_storage)
read_existing_events:  # (nepovinné) Informuje počítače se systémem Windows, zda mají odesílat existující události (true/false, výchozí: true)
connection_retries:  # (nepovinné) Kolik opakovaných pokusů v řadě je přijatelných pro počítače se systémem Windows (výchozí: 60)
connection_retries_wait:  # (nepovinné) Jak dlouho v sekundách se má čekat na opakování připojení (výchozí: 10.0)
heartbeat:  # (nepovinné) Jak často v sekundách se má při odběru volat srdeční tep (výchozí: 60)
backlog:  # (nepovinné) Určuje počet čekajících spojení, která bude fronta držet (výchozí: 128)
servertokens:  # (nepovinné) Řídí, zda bude zahrnuto pole hlavičky odpovědi "Server" ("full") nebo podvržené pole "prod" (výchozí: full).
cors: # (nepovinné) Určuje atributy CORS (výchozí: žádné)
output:  # Na který výstup se mají posílat příchozí události

Nastavení ověřování Kerberos

Předpoklady

• Řadič domény Microsoft Active Directory (v tomto příkladu s IP adresou 192.168.0.1 a názvem hostitele ad.example.om, názvem domény example.om / EXAMPLE.OM).
• Hostitelský počítač s operačním systémem Linux a sběrným systémem LogMan.io (v tomto příkladu s IP adresou 192.168.0.2 a jménem hostitele lmio-wec).
• Datum a čas kolektoru LogMan.io MUSÍ být synchronizovány s NTP.
• Kolektor LogMan.io MUSÍ používat server DNS služby Active Directory.

Konfigurace na serverech Windows

1) Vytvoření nového uživatele v Active Directory

Přejděte do Administrative Tools > Active Directory Users and Computers > example.om > Users (Uživatelé).

Klikněte pravým tlačítkem myši a vyberte možnost Nový > Uživatel

Zadejte následující informace:

• Křestní jméno: lmio-wec.
• Celé jméno: TeskaLabs LogMan.io
• Přihlašovací jméno uživatele: lmio-wec

Nastavení hesla pro uživatele. Tento příklad používá Heslo01!.

Zrušte zaškrtnutí políčka "Uživatel musí při příštím přihlášení změnit heslo".

Zaškrtněte políčko "Heslo nikdy nevyprší".

Stiskněte tlačítko "Next" a poté tlačítko "Finish" pro vytvoření uživatele.

Nakonec klikněte pravým tlačítkem myši na nového uživatele, klikněte na položku Vlastnosti a otevřete kartu Účet: * Zaškrtněte políčko "Tento účet podporuje 128bitové šifrování Kerberos AES". * Zaškrtněte políčko "Tento účet podporuje 256bitové šifrování Kerberos AES".

Nový uživatel lmio-wec je nyní připraven.

2) Na serveru DNS vytvořte záznam A pro lmio-wec.example.om.

Přejděte na Administrativní nástroje > DNS > Přesměrování vyhledávacích zón > example.om

Klikněte pravým tlačítkem myši a zvolte "Nový hostitel (A nebo AAAA)...".

Přidejte záznam s názvem lmio-wec a IP adresou 192.168.0.2.

Zaškrtněte možnost "Vytvořit přidružený záznam ukazatele (PTR)".

Stiskněte tlačítko "Přidat hostitele" a dokončete.

Hint: Toto nastavení DNS můžete ověřit příkazem ping.

3) Na příkazovém řádku serveru řadiče domény Active Directory nakonfigurujte hlavní název pro hostitele a službu běžící na kolektoru LogMan.io provedením následujících příkazů

Vytvořte hlavní jméno hostitele a související soubor s klíčovou tabulkou:

> ktpass /princ host/lmio-wec.example.om@EXAMPLE.OM /pass Password01! /mapuser EXAMPLE\lmio-wec -pType KRB5_NT_PRINCIPAL /out host-lmio-wec.keytab /crypto AES256-SHA1

Tip

Budete muset použít heslo, které jste nastavili pro uživatele lmio-wec.

Vytvořte hlavní název služby a související soubor s klíčovou tabulkou:

> ktpass /princ http/lmio-wec.example.om@EXAMPLE.OM /pass Password01! /mapuser EXAMPLE\lmio-wec -pType KRB5_NT_PRINCIPAL /out http-lmio-wec.keytab /crypto AES256-SHA1

Tip

Budete muset použít heslo, které jste nastavili pro uživatele lmio-wec.

Konfigurace ##### v kolektoru LogMan.io

1. Zkopírujte vygenerované tabulky klíčů ze serveru Windows Active Directory Domain Controller do adresáře /tmp počítače LogMan.io collector.

2. Nainstalujte klienta Kerberos na kolektor LogMan.io

Pro Linux Ubuntu použijte:

# sudo apt update -y && sudo apt install krb5-user -y

1. Upravte konfigurační soubor Kerberosu v kolektoru LogMan.io.

Konfigurační soubor systému Kerberos se obvykle nachází na adrese /etc/krb5.conf.

Do sekce [domain_realm] přidejte:

.example.om = EXAMPLE.OM
example.om = EXAMPLE.OM

V sekci [realms] přidejte:

EXAMPLE.OM= {
kdc = example.om
admin_server = example.om
}

1. Pomocí nástroje ktutil sloučte dva soubory keytab vygenerované z příkazů ktpass v kolektoru LogMan.io.

# ktutil 
 1. ktutil: rkt /tmp/host-lmio-wec.keytab 
 2. ktutil: rkt /tmp/http-lmio-wec.keytab 
 3. ktutil: wkt /tmp/lmio-result.keytab
 4. ktutil: q

1. Ověřte sloučený keytab v kolektoru LogMan.io

# klist -e -k -t /tmp/lmio-result.keytab

 Název keytab: FILE:/tmp/lmio-result.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
3 08/04/22 15:06:24 host/lmio-wec.example.om@EXAMPLE.OM (aes256-cts-hmac-sha1-96) 
4 08/04/22 15:06:24 http/lmio-wec.example.om@EXAMPLE.OM (aes256-cts-hmac-sha1-96)

1. Přesuňte nový soubor keytab na místo v kolektoru LogMan.io.

# cp /tmp/lmio-result.keytab /etc/krb5.keytab
# rm /tmp/*.keytab
# chmod a+r /etc/krb5.keytab

1. Otestujte, zda ověřování pomocí služby Active Directory při použití keytabu úspěšně funguje.

   Spusťte následující příkaz na kolektoru LogMan.io. Pokud je konfigurace správná, bude vytvořen a do mezipaměti uložen ticket-granting ticket (TGT). Tento příkaz by měl být vyvolán se stejným uživatelem operačního systému, jako je spuštěna služba LogMan.io.

   # kinit -kt /etc/krb5.keytab http/lmio-wec.example.om@EXAMPLE.OM
   

2. Ověřte, zda byl tiket získán spuštěním klist jako stejný uživatel z předchozího kroku.

   # klist
   Ticket cache: FILE:/tmp/krb5cc_0
   Výchozí zadavatel: http/lmio-wec.example.om@EXAMPLE.OM
   
   Platný počáteční principál služby Expires
   08/04/22 15:09:29 08/05/22 01:09:29 krbtgt/EXAMPLE.OM@EXAMPLE.OM
   Obnovit do 08/05/22 15:09:29
   

3. Skončili jsme.

   Nyní vytvořte objekt zásad skupiny pro předávání událostí systému Windows z počítače se systémem Windows do systému Linux WEC (podívejte se na část "Konfigurace zásad skupiny" níže).

   Adresa URL pro WEF je:
   http://<WEC_SERVER_HOSTNAME>:5985/wsman/SubscriptionManager/WEC,Refresh=<Refresh interval in seconds>

Ověřování certifikátem HTTPS

Ověřování WEC je alternativou ke Kerberosu, pomocí certifikátů HTTPS očekává server WEC (kolektor LogMan.io) poskytnutí serveru HTTPS na portu tcp/5986. Toto ověřování lze provozovat bez služby Active Directory.

Možnosti konfigurace kolektoru LogMan.io WEC pro ověřování certifikátem HTTPS

Následující volby slouží k nastavení ověřování certifikátů HTTPS.

listen: 0.0.0.0 5986 ssl
cert:  # Zadejte cestu k certifikátu serveru WEC
key:  # Zadejte cestu k soukromému klíči serveru WEC 
issuer_thumbprints:  # d6986fef2104f21ab0c7ccb279217abe29c0808a).
heslo:  # (nepovinné) Zadejte heslo souboru soukromého klíče (výchozí: žádné)
cafile (soubor s klíčem):  # (nepovinné) Zadejte soubor pro ověření peera (výchozí: žádný)
capath:  # (nepovinné) Zadejte cestu k ověření peera (výchozí: žádná)
ciphers:  # (nepovinné) Zadejte vlastní šifry SSL (výchozí: žádné)
dh_params:  # (nepovinné) Parametry výměny klíčů Diffie-Hellman (D-H) (TLS) (výchozí: žádné)
verify_mode:  # (nepovinné) Prázdné nebo jedno z následujících: CERT_NONE, CERT_OPTIONAL nebo CERT_REQUIRED

Požadavky na certifikát TLS/SSL:

• Certifikát WEF (klient) MUSÍ mít rozšířené použití klíče X509 v3: TLS Web Client Authentication.
• Certifikát WEC (server) MUSÍ mít X509 v3 Extended Key Usage: TLS Web Server Authentication.

Nápověda: V případě potřeby můžete použít certifikáty poskytnuté certifikační autoritou. Ujistěte se, že certifikáty splňují výše uvedená kritéria.

Nápověda: K vygenerování certifikátů certifikační autority, serveru WEC a klienta WEF můžete použít nástroj XCA.

Nápověda: Ke generování příslušných certifikátů můžete použít také správce certifikátů systému Windows.

Adresa URL pro WEF je:
https://<WEC_SERVER_HOSTNAME>:5986/wsman/SubscriptionManager/WEC,Refresh=<Refresh interval in seconds>,IssuerCA=<Thumbprint of the issuing CA certificate>

Konfigurace zásad skupiny

Na počítačích se systémem Windows, které mají odesílat protokoly na LogMan.io, musí být nakonfigurováno předávání událostí systému Windows (WEF).

Konfiguraci Windows Event Forwarding může poskytnout:

• Místní zásady skupiny
• Zásady skupiny Active Directory

Předpoklady:

Ujistěte se, že je povolen WinRM, že brána firewall neomezuje síťové připojení a že hostitelský název serveru WEC je důvěryhodný na zdrojovém počítači se systémem Windows. Chcete-li povolit WinRM, spusťte jako správce následující příkaz:

winrm qc -q

Server WEC je třeba přidat mezi důvěryhodné hostitele, aby WinRM umožnil komunikaci s WEC:

winrm set winrm/config/client '@{TrustedHosts="<SERVER_HOSTNAME>"}'

Po dokončení nastavení nakonfigurujte předávání událostí systému Windows (další informace a snímky obrazovky jsou k dispozici na https://docs.microsoft.com/cs-cz/advanced-threat-analytics/configure-event-collection ):

Místní zásady skupiny

Konfiguraci místních zásad skupiny lze použít pro konfiguraci jednotlivých počítačů se systémem Windows.

1. Otevřete Redaktor místních zásad skupiny

Stiskněte klávesy Win+R a zadejte: gpedit.msc.

1. Přejděte na:

Šablony pro správu\Součásti systému Windows\Předávání událostí`.

1. Konfigurace zásad Cílový správce odběru

1. Přidejte novou položku Server

pro ověřování Kerberos a Active Directory (port tcp/5985):

Server=http://<WEC_HOSTNAME>:5985/wsman/SubscriptionManager/WEC,Refresh=<Refresh interval in seconds>

Pro ověření HTTPS (port tcp/5986):

Server=https://<WEC_HOSTNAME>:5986/wsman/SubscriptionManager/WEC,Refresh=<Refresh interval in seconds>,IssuerCA=<Thumbprint of the issuing CA certificate>

Doporučený interval Refresh je 60 sekund.

Otisk certifikátu je řetězec SHA-1, malá písmena, např. d6986fef2104f21ab0c7ccb279217abe29c0808a.

Pokud je přítomna zprostředkující certifikační autorita, pak IssuerCA musí ukazovat na vydávající zprostředkující certifikační autoritu, NE na kořenovou certifikační autoritu.

1. Stisknutím tlačítka "Apply" uložte změny

2. V příkazovém řádku spusťte gpupdate /force.

3. Povolte protokol zabezpečení (viz níže)

Další informace naleznete v části: https://docs.microsoft.com/en-us/windows/win32/wec/setting-up-a-source-initiated-subscription

Zásady skupiny služby Active Directory

Konfigurace zásad skupiny služby Active Directory je vhodná pro konfiguraci většího počtu počítačů se systémem Windows, připojených k příslušnému řadiči domény. 1. Otevřete konzolu pro správu zásad skupiny a upravte objekt

• Na úvodní obrazovce vyberte možnost Nástroje pro správu. Zobrazí se seznam dostupných nástrojů pro správu, včetně nástroje Správa zásad skupiny nainstalovaného v předchozí části.

• Chcete-li otevřít Konzolu pro správu zásad skupiny (GPMC), zvolte možnost Správa zásad skupiny.

1. Vytvořit objekt zásad skupiny
2. V konzole pro správu zásad skupiny vyberte vlastní organizační jednotku (OU), například MyCustomOU. Pravým tlačítkem myši vyberte organizační jednotku a zvolte možnost Vytvořit objekt GPO v této doméně a propojit jej zde...:

• Zadejte název nového objektu GPO, například My custom GPO, a vyberte OK. Tento vlastní objekt GPO můžete volitelně založit na existujícím objektu GPO a sadě možností zásad.

1. Konfigurace objektu GPO
2. Vlastní objekt GPO je vytvořen a propojen s vaší vlastní organizační jednotkou. Chcete-li nyní nakonfigurovat nastavení zásad, vyberte pravým tlačítkem myši vlastní objekt GPO a zvolte možnost Upravit...:

• Otevře se Editor správy zásad skupiny, který vám umožní upravit objekt GPO:

1. Nakonfigurujte Zásady předávání událostí v části Konfigurace počítače (jak je uvedeno výše v části "Zásady místní skupiny" na této stránce dokumentace).

2. Povolte protokol zabezpečení (viz níže)

Povolit protokol zabezpečení

WEF nemá ve výchozím nastavení přístup k bezpečnostnímu protokolu. Aby bylo možné povolit předávání bezpečnostního protokolu, MUSÍ být do WEF přidána Síťová služba.

1. Spusťte Editor zásad skupiny (zadejte gpedit.msc).
2. Přejděte do části Konfigurace počítače > Šablony pro správu > Součásti systému Windows > Služba protokolu událostí > Zabezpečení.
3. Upravte položku "Konfigurace přístupu k protokolu"
4. Povolte zásady
5. Do pole Log Access zadejte: (A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573 (A;;0x1;;;NS)`
6. Použijte příkaz gpupdate /force

Test

Následujícím příkazem vytvoříte testovací událost v počítači se systémem Windows:

eventcreate /Id 500 /D "Toto je testovací zpráva pro ověření sběru protokolu WEC/WEF." /T ERROR /L System

Testovací protokol by měl okamžitě dorazit do LogMan.io.

Řešení problémů

Protokol událostí systému Windows Forwaring

Kanál událostí Eventlog-forwardingPlugin/Operational zaznamenává příslušné informace o počítačích, které jsou nastaveny na předávání protokolů do kolektoru. Obsahuje také informace o možných problémech s odběrem WEF. K prozkoumání použijte aplikaci "Prohlížeč událostí".

Shromažďování pomocí WinRM

Připojení k požadovanému počítači se systémem Windows bez použití agenta a spuštění příkazu pro sběr jako samostatného procesu pro sběr jeho standardního výstupu.

Specifikace vstupu: input:WinRM:

Vstup WinRM se připojí ke vzdálenému stroji Windows Server, kde zavolá zadaný příkaz. Poté pravidelně kontroluje nový výstup na stdout a stderr, takže se chová podobně jako input:SubProcess.

Možnosti konfigurace kolektoru LogMan.io WinRM

endpoint:   # http://MyMachine:5985/wsman).
transport: ntlm # Typ ověřování
server_cert_validation:  # Zadejte ověření platnosti certifikátu (výchozí: ignorovat)
cert_pem:  # (nepovinné) Zadejte cestu k certifikátu (pokud používáte HTTPS)
cert_key_pem:  # (nepovinné) Zadejte cestu k soukromému klíči
username:  # (nepovinné) Pokud používáte ověřování uživatelským jménem (například přes ntlm), zadejte uživatelské jméno ve formátu <DOMAIN>\<USER>
heslo:  # Heslo výše uvedeného ověřovaného uživatele
výstup:  # Na který výstup se mají posílat příchozí události

Následující konfigurace objasňuje příkaz, který má být vzdáleně volán:

# Čtení 1000 systémových protokolů jednou za 2 sekundy
příkaz:  # příkaz, který má být vzdáleně volán (např. wevtutil qe system /c:1000 /rd:true).
chilldown_period:  # Jak často v sekundách se má vzdálený příkaz volat, pokud je ukončen (výchozí: 5)
duplicity_check:  # Určuje, zda se mají kontrolovat duplicity na základě času (true/false)
duplicity_reverse_order:  # Určete, zda se mají duplicity kontrolovat v obráceném pořadí (např. protokoly přicházejí v sestupném pořadí).
last_value_storage:  # Trvalé úložiště pro aktuální poslední hodnotu při kontrole duplicity (výchozí: ./var/last_value_storage)

Shromažďování agentem na počítači se systémem Windows

V této variantě běží kolektor LogMan.io jako agent na požadovaném počítači se systémem Windows a shromažďuje události systému Windows.

Specifikace vstupu: input:WinEvent

Poznámka: input:WinEvent funguje pouze na počítači se systémem Windows.

Tento vstup pravidelně čte události systému Windows ze zadaného typu události.

Možnosti konfigurace kolektoru LogMan.io WinEvent

server:  # (nepovinné) Určete zdroj událostí (výchozí: localhost, tj. celý místní počítač).
event_type:  # (nepovinné) Určuje typ události, která se má načíst (výchozí: System)
buffer_size:  # (nepovinné) Určete, kolik událostí se má načíst v jednom dotazu (výchozí: 1024)
event_block_size:  # (nepovinné) Určete množství událostí, po kterém bude proveden čas nečinnosti, aby mohly být provedeny další operace (výchozí: 100)
event_idle_time:  # (nepovinné) Zadejte výše uvedenou dobu nečinnosti v sekundách (výchozí: 0,01).
last_value_storage:  # Trvalé úložiště pro aktuální poslední hodnotu (výchozí: ./var/last_value_storage)
output:  # Na který výstup se mají posílat příchozí události

Typ události lze zadat pro každý typ protokolu událostí okna, včetně:

• Aplikace pro protokoly aplikací.
• System pro systémové protokoly
• Security pro bezpečnostní protokoly atd.

Shromažďování událostí ze služby Zabbix

Info

Tato možnost je k dispozici od verze v23.09.

TeskaLabs LogMan.io Collector může shromažďovat události ze Zabbixu prostřednictvím Zabbix API. Vstup Zabbix shromažďuje jak historii (první volání hostitelů a položek), tak události:

https://www.zabbix.com/documentation/2.4/en/manual/api/reference/event/get

https://www.zabbix.com/documentation/current/en/manual/api/reference/history/get

Nastavení vstupu kolektoru LogMan.io

V konfiguraci LogMan.io Collector YAML je třeba zadat vstup s názvem input:Zabbix::

input:Zabbix:Zabbix:
  url: <ZABBIX_API_URL>
  auth: <AUTH>
  encoding:  # nepovinné: kódování požadavku Zabbix API (výchozí: utf-8)
  sleep:  # nepovinné: sleep v sekundách mezi jednotlivými požadavky na API, vyšší hodnota znamená méně požadavků, ale větší zatížení CPU serverů Zabbix (výchozí: 60)
  refresh:  # nepovinné: obnovení hostitele a položek/nových metrik v sekundách (výchozí: 900)
  max_requests:  # nepovinné: maximální počet požadavků na rozhraní Zabbox API najednou (výchozí: 100)
  output: <OUTPUT>

<ZABBIX_API_URL> je url adresa rozhraní Zabbix API, obvykle https://<ZABBIX>/api_jsonrpc.php

<AUTH> je autorizační token rozhraní Zabbix API.

<OUTPUT> je ID požadovaného výstupu v rámci konfigurace LogMan.io Collector YAML

Ended: Collector

Parser

Kaskádový parser

Příklad

---
define:
  název: Syslog RFC5424
  typ: parser/cascade
  field_alias: field_alias.default
  encoding: utf-8 # none, ascii, utf-8 ... (výchozí: utf-8)
  target: parsed # nepovinné, určete cíl parsované události (výchozí: parsed)

predicate:
  !AND
  - !CONTAINS
    what: !EVENT
    podřetězec: "ASA
  - !INCLUDE predicate_filter

parse:
  !REGEX.PARSE
  what: !EVENT
  regex: '^(\w{1,3}\s+\d+\s\d+:\d+:\d+)\s(?:(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})|([^\s]+))\s%ASA-\d+-(.*)$'
  položky:
    - rt:
        !DATETIME.PARSE
        value: !ARG
        format: '%b %d %H:%M:%S'
        flags: Y
    - dvchost

Sekce define

Tato sekce obsahuje společnou definici a metadata.

Položka name

Kratší lidsky čitelný název této deklarace.

Item type

Typ této deklarace, musí být parser/cascade.

Položka field_alias

Název vyhledávače aliasů polí, který se má načíst, aby bylo možné v deklaraci použít aliasové názvy atributů událostí vedle jejich kanonických názvů.

Položka encoding

Kódování příchozí události.

Položka target (nepovinné)

Výchozí cílové potrubí analyzované události, pokud není v poli context uvedeno jinak. Mezi možnosti patří: parsed, lookup, unparsed.

Položka description (nepovinné)

Dlouhý, případně víceřádkový, lidsky čitelný popis deklarace.

Sekce predicate (nepovinné)

Predikát filtruje příchozí události pomocí výrazu. Pokud výraz vrátí hodnotu True, vstoupí událost do sekce parse. Pokud výraz vrátí False, událost se přeskočí.

Ostatní vrácené hodnoty jsou nedefinované.

Tuto sekci lze použít k urychlení parsování přeskočením řádků se zjevně nerelevantním obsahem.

Včetně vnořených predikátových filtrů

Predikátové filtry jsou výrazy umístěné ve vyhrazeném souboru, které lze zahrnout do mnoha různých predikátů jako jejich části.

Pokud chcete zahrnout externí filtr predikátu, který se nachází buď ve složce include, nebo ve složce filters. (jedná se o globální složku umístěnou v nejvyšší hierarchii knihovny LogMan.io), použijte příkaz !INCLUDE:

!INCLUDE predicate_filter

kde predicate_filter je název souboru s příponou .yaml. Obsahem souboru predicate_filter.yaml je výraz, který má být zahrnut, jako např:

---
!EQ
- !ITEM EVENT category
- "MyEventCategory"

Sekce parse

Tato sekce specifikuje vlastní mechanismus parsování. Očekává, že bude vrácen slovník nebo None, což znamená, že parsování nebylo úspěšné.

Typické příkazy v sekci parse

Příkaz !FIRST umožňuje specifikovat seznam deklarací parsování, které budou vyhodnoceny v pořadí (shora dolů), přičemž první deklarace, která vrátí hodnotu jinou než None, iteraci ukončí a tato hodnota je vrácena.

Příkaz !REGEX.PARSE umožňuje transformovat řádek protokolu do slovníkové struktury. Umožňuje také připojit dílčí parsery pro další rozklad podřetězců.

Výstupní směrování

Označení, že parser nebude analyzovat událost, kterou dosud obdržel, je třeba v rámci kontextu nastavit atribut cíl na hodnotu nerozparsováno. Pak mohou událost přijmout a rozebrat další parsery v koncovce.

Stejným způsobem lze cíl nastavit na různé cílové skupiny, například parsed.

Pro nastavení cíle v kontextu se používá příkaz !CONTEXT.SET:

- !CONTEXT.SET
  co: <... expression ...>
  set:
    cíl: neparazitovaný

Příklad použití v parseru. Pokud příchozí události neodpovídá žádný regex, událost je odeslána do cíle unparsed, takže ostatní parsery v řadě ji mohou zpracovat.

!FIRST
- !REGEX.PARSE
co: !EVENT
regex: '^(one)\s(two)\s(three)$'
items:
  - 1
  - dva
  - tři
- !REGEX.PARSE
co: !EVENT
regex: '^(uno)\s(duo)\s(tres)$'
items:
  - jedna
  - dva
  - tři
# Zde začíná zpracování částečně rozebrané události
- !CONTEXT.SET
set:
  cíl: nerozparsováno
- !DICT
set:
  nerozbaleno: !EVENT

Komplexní parser událostí

Parser komplexních událostí analyzuje příchozí komplexní události, jako jsou události vyhledávání. (tj. vytvoření, aktualizace, smazání vyhledávání) a vkládá je do tématu lmio-output. v Kafce.

Odtud jsou parsované komplexní události rovněž odesílány do tématu input. pomocí instancí LogMan.io Watcher, takže korelátory a dispečery mohly na události také reagovat.

Ukázka deklarace

Ukázka deklarace YAML pro události vyhledávání v komplexním parseru událostí může vypadat následovně:

p00_json_preprocessor.yaml

---
define:
  name: Preprocesor pro JSON s extrakcí nájemce
  type: parser/preprocessor
  tenant: JSON.tenant

funkce: lmiopar.preprocessor.JSON

p01_lookup_event_parser.yaml

---
define:
  name: Lookup Event Parser
  typ: parser/cascade

predicate:
  !AND
  - !ISNOT
    - !ITEM CONTEXT JSON.lookup_id
    - !!null
  - !ISNOT
    - !ITEM CONTEXT JSON.action
    - !!null

parse:
  !DICT
  set:
    "@timestamp": !ITEM CONTEXT "JSON.@timestamp"
    end: !ITEM CONTEXT "JSON.@timestamp"
    deviceVendor: TeskaLabs
    deviceProduct: LogMan.io
    dvc: 172.22.0.12
    dvchost: lm1
    deviceEventClassId: lookup:001
    name: !ITEM CONTEXT JSON.action
    fname: !ITEM CONTEXT JSON.lookup_id
    fileType: lookup
    categoryObject: /Host/Application
    categoryBehavior: /Modify/Configuration
    categoryOutcome: /Success
    categoryDeviceGroup: /Application
    type: Base
    tenant: !ITEM CONTEXT JSON.tenant
    customerName: !ITEM CONTEXT JSON.tenant

Deklarace by měly být vždy součástí knihovny LogMan.io.

Konfigurace parseru LogMan.io

Nejprve je třeba určit, ze které knihovny se mají načítat deklarace, což může být buď ZooKeeper, nebo File.

Každá spuštěná instance parseru také musí vědět, které skupiny má načíst z knihoven, viz níže:

# Deklarace

[deklarace]
library=zk://zookeeper:12181/lmio/library.lib ./data/declarations
groups=cisco-asa@syslog
include_search_path=filters/parser;filters/parser/syslog
raw_event=event.original
count=počet
tenant=tenant
timestamp=end

groups - názvy skupin, které mají být použity z knihovny, oddělené mezerami; pokud je skupina se nachází v podsložce složky, použijte jako oddělovač lomítko, např. parsers/cisco-asa@syslog

Pokud je knihovna prázdná nebo skupiny nejsou zadány, jsou všechny události, včetně jejich kontextových položek, vynechány do tématu lmio-others Kafka a zpracovány dispečerem LogMan.io. protože nebyly analyzovány.

include_search_path - určuje složky pro vyhledávání souborů YAML, které budou později použity ve výrazu !INCLUDE (například !INCLUDE myFilterYAMLfromFiltersCommonSubfolder) v deklaracích, oddělených znakem ;. Uvedením hvězdičky * za lomítkem v cestě budou rekurzivně zahrnuty všechny podadresáře. Výraz !INCLUDE očekává jako vstup název souboru bez cesty a bez přípony. Chování je podobné atributu -I include při sestavování kódu v jazyce C/C++.

raw_event - název pole vstupní zprávy protokolu událostí (také známé jako raw).

tenant - název pole nájemce/klienta, do kterého je ukládána informace

count - název pole, do kterého se ukládá počet událostí, výchozí hodnota je 1

timestamp - název pole atributu časového razítka

Dále je potřeba vědět, která témata Kafky se mají použít na vstupu a výstupu, jestliže parsování bylo úspěšné nebo neúspěšné. Je třeba také nakonfigurovat připojení Kafka aby se vědělo, ke kterým serverům Kafka se má připojit.

# Připojení Kafka

[connection:KafkaConnection]
bootstrap_servers=lm1:19092;lm2:29092;lm3:39092

[pipeline:ParsersPipeline:KafkaSource]
topic=collected
# group_id=lmioparser

# Kafka sinks

[pipeline:EnrichersPipeline:KafkaSink]
topic=parsed

[pipeline:ParsersPipeline:KafkaSink]
topic=unparsed

Poslední povinná sekce určuje, které téma Kafky se má použít pro informace o změnách ve vyhledávání (tj. seznamy odkazů) a která instance ElasticSearch se mají načíst.

# ``Persistentní úložiště pro vyhledávání

[asab:storage]  # tato sekce se používá v lookups
type=elasticsearch

[elasticsearch]
url=http://elasticsearch:9200

# Aktualizovat vyhledávací pipelines

[pipeline:LookupChangeStreamPipeline:KafkaSource]
topic=lookups

[pipeline:LookupModificationPipeline:KafkaSink]
topic=lookups

Instalace

Docker Compose

  lmio-parser:
    docker.teskalabs.com/lmio/lmio-parser
    volumes:
      - ./lmio-parser:/data

Konfigurace nové instance LogMan.io Parseru

Vytvoření nové instance parseru pro nový zdroj dat (soubory, vyhledávání, SysLog atd.) je třeba provést následující tři kroky:

• Vytvoření nového tématu Kafka, do kterého se budou načítat shromážděná data.
• Konfigurace přidružených instancí parseru LogMan.io v úložišti site-repository.
• Nasazení

Vytvoření nového tématu Kafka, do kterého se načtou shromážděná data

Nejprve je třeba vytvořit nové téma shromážděných událostí.

Témata sbíraných událostí jsou specifická pro každý typ zdroje dat a nájemce (zákazníka). Standard pro pojmenování takových témat Kafka je následující:

collected-<tenant>-<type>

kde tenant je název tenantu psaný malými písmeny a typ je typ zdroje dat. Mezi příklady patří např:

collected-railway-syslog
collected-ministry-files
collected-johnandson-databases
collected-marksandmax-lookups

Shromážděné téma pro všechny nájemce může mít následující formát:

collected-default-lookups

Vytvoření nového tématu Kafky:

1.) Vstupte do libovolného kontejneru Kafka pomocí docker exec -it o2czsec-central_kafka_1 bash.

2.) Pomocí následujícího příkazu vytvořte téma pomocí /usr/bin/kafka-topics:

/usr/bin/kafka-topics --zookeeper lm1:12181,lm2:22181,lm3:32181 --create --topic collected-company-type -partitions 6 --replication-factor 1

Počet oddílů závisí na očekávaném množství dat a počtu instancí LogMan.io Parseru. Protože ve většině nasazení jsou v clusteru tři běžící servery, doporučuje se použít alespoň tři oddíly.

Konfigurace přidružených instancí LogMan.io Parser v úložišti site-repository

Zadejte úložiště webu s konfiguracemi pro cluster LogMan.io. Další informace o úložišti site repository naleznete v části Názvoslovné standardy v sekci Reference.

Poté v každé složce serveru (např. lm1, lm2, lm3) vytvořte následující položku v adresáři docker-compose.yml:

 <tenant>-<type>-lmio-parser:
    restart: on-failure:3
    image: docker.teskalabs.com/lmio/lmio-parser
    network_mode: host
    depends_on:
      - kafka
      - elasticsearch-master
    volumes:
      - /<tenant>-<type>/lmio-parser:/data
      - ../lookups:/lookups
      - /data/hdd/log/<tenant>-<type>/lmio-parser:/log
      - /var/run/docker.sock:/var/run/docker.sock

Nahraďte <tenant> názvem nájemce/zákazníka (například železnice) a <type> typem dat (například vyhledávání), příklady zahrnují:

railway-lookups-lmio-parser
default-lookups-lmio-parser
hbbank-syslog-lmio-parser

Pokud je položka Docker Compose obsažena v souboru docker-compose.yml, postupujte podle následujících kroků:

1.) V každé složce serveru (lm1, lm2, lm3) vytvořte složku <tenant>-<type>.

2.) V adresářích <tenant>-<type> vytvořte adresář lmio-parser.

3.) Ve vytvořené složce lmio-parser vytvořte soubor lmio-parser.conf.

4.) Upravte soubor lmio-parser.conf a zadejte následující konfiguraci:

[asab:docker]
name_prefix=<server_name>-
socket=/var/run/docker.sock

# Deklarace

[deklarace]
library=zk://lm1:12181,lm2:22181,lm3:32181/lmio/library.lib ./data/declarations
groups=<group>
raw_event=raw_event
count=počet
tenant=tenant
timestamp=@timestamp

# API

[asab:web]
listen=0.0.0.0 0

[lmioparser:web]
listen=0.0.0.0 0

# Protokolování

[logging:file]
path=/log/log.log
backup_count=3
rotate_every=1d

# Připojení Kafka

[connection:KafkaConnection]
bootstrap_servers=lm1:19092,lm2:29092,lm3:39092

[pipeline:ParsersPipeline:KafkaSource]
topic=collected-<tenant>-<type>
group_id=lmio_parser_<tenant>_<type>

# Kafka sinks

[pipeline:EnrichersPipeline:KafkaSink]
topic=lmio-events

[pipeline:ParsersPipeline:KafkaSink]
topic=lmio-others

[pipeline:ErrorPipeline:KafkaSink]
topic=lmio-others

[asab:zookeeper]
servers=lm1:12181,lm2:22181,lm3:32181
path=/lmio/library.lib

[zookeeper]
urls=lm1:12181,lm2:22181,lm3:32181
servers=lm1:12181,lm2:22181,lm3:32181
path=/lmio/library.lib

# Vyhledat trvalé úložiště

[asab:storage]  # tato sekce se používá v lookups
type=elasticsearch

[elasticsearch]
url=http://<server_name>:9200/
username=<secret_username>
password=<secret_password>

# Aktualizovat vyhledávací pipelines

[pipeline:LookupChangeStreamPipeline:KafkaSource]
topic=lmio-lookups
group_id=lmio_parser_<tenant>_<type>_<server_name>

[pipeline:LookupModificationPipeline:KafkaSink]
topic=lmio-lookups

# Metriky

[asab:metrics]
target=influxdb

[asab:metrics:influxdb]
url=http://lm4:8086/
db=db0
username=<secret_username>
password=<secret_password>

kde nahradí každý výskyt:

<group> se skupinou deklarací parseru načtenou v ZooKeeperu; Další informace naleznete v části Reference v této dokumentaci v sekci Knihovna.

<server_name> názvem kořenové složky serveru, například lm1, lm2, lm3

<tenant> s názvem vašeho nájemce, například hbbank, default, railway atd.

<type> s typem vašeho zdroje dat, jako jsou vyhledávání, syslog, soubory, databáze atd.

<secret_username> a <secret_password> s přihlašovacími údaji k technickému účtu ElasticSearch a InfluxDB, které si můžete prohlédnout v dalších konfiguracích v úložišti webu.

Další informace o tom, co jednotlivé části konfigurace znamenají, naleznete v části Konfigurace v postranní nabídce.

Nasazení

Chcete-li nasadit nový parser, proveďte následující kroky:

1.) Přejděte na každý ze serverů LogMan.io (lm1, lm2, lm3).

2.) Proveďte git pull ve složce úložiště webu, která by měla být umístěna v adresáři /opt.

3.) Spusťte docker-compose up -d <tenant>-<type>-lmio-parser pro spuštění instance LogMan.io Parseru.

4.) Nasaďte a nakonfigurujte SyslogNG, LogMan.io Ingestor atd. pro odesílání shromážděných dat do collected-<tenant>-<type> tématu Kafka.

4.) Podívejte se do logů ve složce /data/hdd/log/<tenant>-<type>/lmio-parser na případné chyby k ladění.

(nahraďte odpovídajícím způsobem <tenant> a <type>).

Poznámky

Chcete-li vytvořit datový tok pro vyhledávání, použijte jako typ vyhledávání a podívejte se do sekce Vyhledávání v postranní nabídce. abyste správně vytvořili skupinu deklarací parsování.

DNS Enricher

DNS Enricher obohacuje událost o informace načtené ze serverů DNS, například o názvy hostitelů.

Příklad

Deklarace

  ---
  define:
    name: DNSEnricher
    typ: enricher/dns
    dns_server: 8.8.8.8,5.5.4.8 # nepovinné

  atributy:

    ip:
      hostname: host.hostname

    source.ip:
      hostname:
        - host.hostname
        - source.hostname

Vstup

{
    "source.ip": "142.251.37.110",
}

Výstup

{
    "source.ip": "142.251.37.110", 
    "host.hostname": "prg03s13-in-f14.1e100.net",
    "source.hostname": "prg03s13-in-f14.1e100.net"
}

Sekce define

Tato sekce definuje název a typ obohacovače, který je v případě obohacovače DNS vždy enricher/dns.

Položka name

Kratší lidsky čitelný název této deklarace.

Item type

Typ této deklarace, musí být enricher/dns.

Položka dns_server

Seznam serverů DNS, které mají být požádány o informace, oddělený čárkou ,.

Sekce attributes

Zadejte slovník s atributy, ze kterého se má načíst IP adresa nebo jiné informace pro vyhledávání DNS.

Za každým atributem by měl následovat další slovník se seznamem klíčů, které se mají získat ze serveru DNS.

Hodnotou každého klíče je pak buď řetězec s názvem atributu události, do kterého se má vyhledaná hodnota uložit, nebo seznam, pokud se má hodnota vložit do více než jednoho atributu události.

Vyhledávání a obohacování aliasů polí

Lookup

Field Alias lookup obsahuje informace o kanonických názvech atributů událostí, spolu s jejich možnými aliasy (jako jsou zkrácené názvy atd.).

ID vyhledávacího pole Alias musí obsahovat následující podřetězec: field_alias

Záznam vyhledávání má následující strukturu:

klíč: canonical_name
hodnota: {
    "aliases": [
        alias1, # f. e. krátký název
        alias2, # f. e. dlouhý název
        ...
    ]
}

Pseudonymy polí lze zadat v parserech, standardních obohacovačích a korelátorech. definovat, takže názvy aliasů použité v deklarativním souboru (jako !ITEM EVENT alias). jsou při přístupu k existujícímu prvku přeloženy na kanonické názvy (tj. !ITEM EVENT alias nebo !ITEM EVENT canonical_name).

Také by se mělo použít vyhledávání v obohacovači aliasů polí pro transformaci všechny aliasy na kanonické názvy po úspěšném rozboru v LogMan.io Parseru.

Obohacovač

Field Alias obohacuje událost o kanonické názvy existujících atributů, které jsou pojmenovány jedním ze zadaných aliasů, a zároveň odstraní aliasové atributy v události.

Deklarace

---
define:
  název: FieldAliasEnricher
  typ: enricher/fieldalias
  lookup: field_alias.default

Sekce define

Tato sekce definuje název a typ obohacovače, který je v případě Field Alias vždy enricher/fieldalias.

Položka name

Kratší lidsky čitelný název této deklarace.

Položka type

Typ této deklarace, musí být enricher/fieldalias.

IP2Location Enricher (OBSOLETE)

Tento obohacovač je zastaralý, místo něj použijte IPEnricher.

IP2Location obohacuje událost o zadané atributy umístění na základě hodnoty IPV4 nebo IPV6.

Příklad

Deklarace

---
define:
  name: IP2Location
  typ: enricher/ip2location

zones:
  - myLocalZone
  - ip2location
  - ...

atributy:
  ip_addr1:
    country_short: firstCountry
    city: firstCity
    L: firstL
  ip_addr2:
    country_short: secondCountry
    město: secondCity
    L: secondL
  ...

Vstupní údaje

Feb 5 10:50:01 0:0:0:0:0:ffff:1f1f:e001 %ASA-1-105043 test

Výstup

{
    'rt': 1580899801.0,
    'msg': 'test',
    'ip_addr1': '0:0:0:0:0:ffff:1f1f:e001',
    "firstCountry": "CZ",
    "firstCity": "Brno",
    "firstL": {
        "lat": 49.195220947265625,
        'lon': 16.607959747314453
    }
}

Sekce define

Tato sekce definuje název a typ obohacovače, který je v případě IP2Location vždy enricher/ip2location.

Položka name

Kratší lidsky čitelný název této deklarace.

Položka type

Typ této deklarace, musí být enricher/ip2location. Hodnota enricher/geoip je zastaralý ekvivalent.

Sekce zones

Určuje seznam zón (databázových souborů nebo streamů), které bude obohacovač používat. Použije se první zóna, která úspěšně provede vyhledávání, proto je seřaďte podle priority.

Sekce attributes

Zadejte slovník s atributy událostí IPV6, které má vyhledávání obsahovat, například dvchost. Uvnitř slovníku uveďte pole/atributy z vyhledávání, které se budou načítat. plus název atributu v události za ním. Například:

  ip_addr1:
    country_short: firstCountry
    city: firstCity
    L: firstL

bude vyhledávat IP na GEO lookup pro IP uloženou event["ip_addr1"], načte country_short, city, L z vyhledávání (pokud je přítomno) a namapuje je na event["firstCountry"], event["firstCity"], event["firstL"]

Atributy vyhledávání

Následující atributy vyhledávání, pokud jsou v zóně vyhledávání přítomny, lze použít pro další mapování:

country_short: string
country_long: řetězec
region: řetězec
city: string
isp: string
L: slovník (obsahuje: lat: float, lon: float)
domain: string
poštovní směrovací číslo: řetězec
časové pásmo: řetězec
netspeed: string
idd_code: string
area_code: string
weather_code: string
weather_name: string
mcc: string
mnc: string
mobile_brand: string
elevation: float
usage_type: string

Vysoce výkonné parsování

Vysoce výkonné parsování je parsování, které je kompilováno přímo do strojového kódu, tedy zajišťuje nejvyšší možnou rychlost parsování příchozích událostí.

Všechny vestavěné preprocesory i deklarativní výrazy !PARSE a !DATETIME.PARSE. nabízejí vysoký výkon parsování.

Procedurální parsování

Aby bylo možné strojový/instrukční kód zkompilovat prostřednictvím LLVM a C, musí všechny výrazy obsahovat definici procedurálního parsování, což znamená, že každý znak(y) ve vstupním řetězci parsování musí mít definovanou výstupní délku. a výstupní typ.

Zatímco u preprocesorů je procedura transparentní a uživateli se nezobrazuje, ve výrazech !PARSE a !DATETIME.PARSE musí být přesný postup s typy a formátem definován v atributu format:

!DATETIME.PARSE
what: "2021-06-11 17"
format:
  - rok: {type: ui64, format: d4}
  - '-'
  - měsíc: {typ: ui64, formát: d2}
  - '-'
  - den: {typ: ui64, formát: d2}
  - ' '
  - hour: {typ: ui64, formát: d2}

První položka v atributu format odpovídá prvnímu znaku (prvním znakům) v příchozí zprávě, zde je rok vytvořen z prvních čtyř znaků a převeden na celé číslo (2021).

Pokud je uveden pouze jeden znak, je přeskočen a není uložen ve výstupní analyzované struktuře.

Vysoce výkonné výrazy

!DATETIME.PARSE

!DATETIME.PARSE implicitně vytvoří z analyzované struktury čas data, která má následující atributy:

• rok

• měsíc

• den

• hodina (nepovinné)

• minute (nepovinné)

• second (nepovinné)

• mikrosekunda (nepovinné)

Formát - dlouhá verze

Atributy je třeba zadat ve vstupním poli format:

!DATETIME.PARSE
what: "2021-06-11 1712X000014"
format:
  - rok: {type: ui64, format: d4}
  - '-'
  - měsíc: {typ: ui64, formát: d2}
  - '-'
  - den: {typ: ui64, formát: d2}
  - ' '
  - hour: {typ: ui64, formát: d2}
  - minuta: {typ: ui64, formát: d2}
  - 'X'
  - mikrosekunda: {type: ui64, format: dc6}

Formát - zkrácená verze

Formát format může používat zkrácený zápis se zástupci %Y, %m, %d, %H, %M, %S a %u (mikrosekunda), které představují čísla bez znaménka podle formátu ve výše uvedeném příkladu:

!DATETIME.PARSE
what: "2021-06-16T11:17Z"
format: "%Y-%m-%dT%H:%MZ"

Příkaz format lze zjednodušit, pokud je formát data standardizován, například RFC3339 nebo iso8601:

!DATETIME.PARSE
what: "2021-06-16T11:17Z"
formát: iso8601

Pokud je časová zóna jiná než UTC, je třeba ji také explicitně zadat:

!DATETIME.PARSE
what: "2021-06-16T11:17Z"
formát: iso8601
timezone: Evropa/Praha

Dostupné typy

Celé číslo

• {type: ui64, format: d2} - přesně 2 znaky na celé číslo bez znaménka

• {type: ui64, format: d4} - přesně 4 znaky na celé číslo bez znaménka

• {type: ui64, format: dc6} - 1 až 6 znaků na celé číslo bez znaménka

IP Enricher

IP Enricher rozšiřuje události o geografické a další údaje související s danou IPv6 nebo IPv4 adresou. Tento modul nahrazuje IP2Location Enricher a GeoIP Enricher, které jsou nyní zastaralé.

Deklarace

Sekce define

Tato sekce definuje název a typ obohacovače.

Položka name

Krátký lidsky čitelný název této deklarace.

Položka type

K dispozici jsou čtyři typy obohacovačů IP, které se liší verzí IP (IPv4 nebo IPv6) a adresou IP. (celé číslo nebo řetězec). Použití celočíselného vstupu je rychlejší a preferovanou možností.

• enricher/ipv6 zpracovává IPv6 adresy ve formátu 128bitového desítkového čísla (například 281473902969579).
• enricher/ipv4 zpracovává IPv4 adresy v 32bitovém desítkovém celočíselném formátu (například 3221226219).
• enricher/ipv6str zpracovává adresy IPv6 ve formátu šestnáctkových řetězců oddělených dvojtečkami. (například 2001:db8:0:0:1:0:0:1), jak je definováno v RFC 5952. Umí také převádět a zpracovávat řetězcové adresy IPv4 (jako enricher/ipv4str).
• enricher/ipv4str zpracovává adresy IPv4 ve formátu tečkovaného desítkového řetězce (například 192.168.16.0). jak je definováno v RFC 4001.

Položka base_path

Určuje základní cestu URL, která obsahuje soubory vyhledávací zóny. Může ukazovat na: * adresář místního souborového systému, např. /path/to/files/ * umístění v nástroji zookeeper, např. zk://zookeeper-server:2181/path/to/files/ * umístění HTTP, např. http://localhost:3000/path/to/files/

Sekce tenants

Nástroj IP Enricher lze nakonfigurovat pro nastavení více uživatelů. Tato sekce obsahuje seznam nájemců, které by měl obohacovač zohlednit při vytváření vyhledávání specifických pro nájemce. Události anotované s nájemcem, který není uveden v této sekci, získají pouze globální obohacení (viz níže).

Sekce zones

Určuje seznam vyhledávacích zón, které má obohacovač použít, a informaci, zda jsou globální. nebo specifické pro nájemce.

Globální vyhledávače mohou obohatit jakoukoli událost bez ohledu na jejího nájemce. Vyhledávání specifická pro nájemce mohou obohatit pouze události s odpovídajícím kontextem nájemce.

Zóny vyhledávání by měly být seřazeny podle své priority, od nejvyšší po nejnižší, protože vyhledávání iteruje přes zóny postupně. a zastaví se, jakmile je nalezena první shoda.

zones:
- nájemce: lookup-zone-1.pkl.gz
- nájemce: lookup-zone-2.pkl.gz
- global: lookup-zone-glob.pkl.gz

Názvy zón se musí shodovat s odpovídajícími názvy souborů včetně přípony. Vyhledávací soubory global musí existovat přímo v adresáři base_path. Vyhledávací soubory tenant musí být uspořádány v adresáři base_path do složek podle příslušných nájemců. Například za předpokladu, že jsme deklarovali první_tenant a druhý_tenant, výše uvedená deklarace zón očekává. následující strukturu souborů:

/base_path/
- first_tenant/
  - lookup-zone-1.pkl.gz
  - lookup-zone-2.pkl.gz
- second_tenant/
  - lookup-zone-1.pkl.gz
  - lookup-zone-2.pkl.gz
- lookup-zone-glob.pkl.gz

Příchozí událost, jejíž contxt je second_tenant, se nejprve pokusí najít shodu s v lookupu second_tenant/lookup-zone-1.pkl.gz, poté v lookupu second_tenant/lookup-zone-1.pkl.gz. second_tenant/lookup-zone-2.pkl.gz a nakonec v lookup-zone-glob.pkl.gz.

Sekce atributy

Tento oddíl určuje, které atributy události obsahují adresu IP a jaké atributy budou přidány k události, pokud bude nalezena shoda. Má následující slovníkovou strukturu:

ip_adresa: 
  název_atributu_vyhledávání: název_atributu_události

IP adresa se získá z atributu události ip_address. Pokud odpovídá nějaké vyhledávací zóně, uloží se hodnota lookup_attribute_name. do event_attribute_name. Například:

source_ip:
  kód_země: source_country

To se pokusí přiřadit událost na základě atributu source_ip a uložit odpovídající hodnotu country_code do pole události source_country.

Obohacení názvu zóny

Může být užitečné zaznamenat název vyhledávací zóny, ve které došlo ke shodě. Chcete-li do události přidat název zóny, použijte jako název atributu vyhledávání zone, např:

source_ip:
  zóna: název_zdroje_zóny

Tím se do pole události jméno_zdroje_zóny přidá název odpovídajícího vyhledávání.

Všimněte si, že pokud je ve vyhledávání pole s názvem "zone", použije se jeho hodnota místo názvu vyhledávání.

Název vyhledávání se nastavuje při vytváření souboru vyhledávání. Ve výchozím nastavení je to název zdrojového souboru, ale lze jej nastavit na jinou hodnotu. Podrobnosti viz příkaz lmiocmd ipzone from-csv v LogMan.io Commander.

Příklad použití

Deklarační soubor

---
define:
  name: IPEnricher
  typ: enricher/ipv6

nájemci:
  - some-tenant
  - another-tenant

zóny:
  - tenant: lookup-zone-1.pkl
  - globální: ip2location.pkl.gz

atributy:
  ip_addr1:
    country_code: sourceCountry
    city_name: sourceCity
    L: sourceLocation
  ip_addr2:
    country_code: destinationCountry
    název_města: destinationCity
    L: destinationL
  ...

Zde obohacovač načte IP adresu z atributu události ip_addr1. Poté se pokusí najít adresu ve svých vyhledávacích ojektech: nejprve v ojektech lookup-zone-1.pkl, poté v ip2location.pkl.gz. Pokud najde shodu, načte hodnoty vyhledávání country_code, city_name a L a uloží je do příslušných polí událostí sourceCountry, sourceCity a sourceLocation. Pro druhou adresu ip_addr2 se postupuje obdobně. Výsledek je vidět níže.

Vstupní údaje

Feb 5 10:50:01 0:0:0:0:0:ffff:1f1f:e001 %ASA-1-105043 test

Výše uvedený řádek lze analyzovat do následujícího slovníku.

{
    'rt': 1580899801.0,
    "msg": "test",
    'ip_addr1': '0:0:0:0:0:ffff:1f1f:e001'
}

Toto je předáno IP Enricheru, který jsme deklarovali výše.

Výstup

{
    'rt': 1580899801.0,
    "msg": "test",
    'ip_addr1': '0:0:0:0:0:ffff:1f1f:e001',
    "sourceCountry": "CZ",
    "sourceCity": "Brno",
    "sourceLocation": (49.195220947265625, 16.607959747314453)
}

Soubor pro vyhledávání zóny IP

Soubor IP lookup je slovník Pythonu. Lze jej jednoduše vytvořit ze souboru CSV pomocí příkazu lmiocmd ipzone from-csv který najdete v LogMan.io Commander. CSV musí obsahovat řádek záhlaví s názvy sloupců. Musí obsahovat sloupec ip_from a ip_to a alespoň jeden další sloupec. sloupec s požadovanými hodnotami vyhledávání.

Například:```csv

ip_from,ip_to,zone_info,latitude,longitude 127.61.100.0,127.61.111.255,my secret base,48.224673,-75.711505 127.61.112.0,127.61.112.255,my submarine,22.917923,267.490378 ```

POZNÁMKA Zóny definované v jednom vyhledávacím souboru se nesmí překrývat.

POZNÁMKA IP zóny v souboru CSV jsou považovány za uzavřené intervaly, tj. pole ip_from i ip_to jsou zahrnuta do zóny, kterou ohraničují.

IP2Location

Tento příkaz je také schopen vytvořit vyhledávací soubor z IP2Location™ CSV databází. Všimněte si, že tyto soubory neobsahují názvy sloupců, takže řádek záhlaví je třeba do souboru CSV přidat ručně. před vytvořením vyhledávacího souboru.

IP Resolve Enricher & Expression

IP Resolve obohacuje událost o kanonické hostitelské jméno a/nebo IP na základě buď IP adresy A sítě/prostoru, nebo libovolného hostitelského jména A sítě připojené k IP adrese ve vyhledávání.

ID vyhledávání IP Resolve musí obsahovat následující podřetězec: ip_resolve

Záznam vyhledávání má následující strukturu:

klíč: [IP, síť]
hodnota: {
    "hostnames": [
        canonical_hostname,
        hostname2,
        hostname3
        ...
    ]
}

Příklad

Deklarace #1 - Obohacovač

---
define:
  name: IPResolve
  typ: enricher/ipresolve
  lookup: lmio_ip_resolve # nepovinné

source:
  - ip_addr_and_network_try1
  - ip_addr_and_network_try2
  - hostname_and_network_try3
  - [!IP.PARSE ip4, !ITEM EVENT network4]
  ...

ip: ip_addr_try1
hostname: host_name

Deklarace #2 - Výraz

!IP.RESOLVE
zdroj:
  - ip_addr_and_network_try1
  - ip_addr_and_network_try2
  - hostname_and_network_try3
  - [!IP.PARSE ip4, !ITEM EVENT network4]
  ...
ip: ip_addr_try1
hostname: host_name
with: !EVENT
lookup: lmio_ip_resolve # nepovinné

Input

Feb 5 10:50:01 0:0:0:0:0:ffff:1f1f:e001 %ASA-1-105043 test

Výstup

{
    'rt': 1580899801.0,
    'msg': 'test',
    'ip_addr_try1': 281471203926017,
    'host_name': 'my_hostname'
}

Sekce define

Tato sekce definuje název a typ obohacovače, který je v případě IP Resolve vždy enricher/ipresolve.

Položka name

Kratší lidsky čitelný název této deklarace.

Položka type

Typ této deklarace, musí být enricher/ipresolve.

Sekce source

Zadejte seznam atributů, které se mají vyhledat. Každý atribut by měl být v následujícím formátu:

[IP, síť]
[hostname, network]

Pokud není síť zadána, použije se global.

První úspěšné vyhledávání vrátí výstupní hodnoty (ip, hostname).

Sekce ip

Zadejte atribut, do kterého se uloží vyhledaná IP adresa.

Sekce hostname

Zadejte atribut, do kterého se uloží vyhledané kanonické jméno hostitele. Kanonické hostitelské jméno je první v hodnotě hostnames vyhledávání.

Načtení vyhledávání ze souboru

Data vyhledávání IP Resolve lze načíst ze souboru pomocí nástroje LogMan.io Collector input:FileBlock.

Data jsou tedy k dispozici v LogMan.io Parseru, kde by měla být odeslány do cíle lookup. Do tématu input tedy lookup nevstoupí, ale do tématu lookups, odkud bude zpracován. LogMan.io Watcher, aby aktualizoval data v ElasticSearch.

LogMan.io Watcher očekává následující formát události:

{
    'action': 'full',
    'data': {
        "items": [{
                '_id': [!IP.PARSE 'MyIP', 'MyNetwork'],
                'hostnames': ['canonical_hostname', 'short_hostname', 'another_short_hostname']
            }
        ]
    },
    "lookup_id": "customer_ip_resolve
}

kde action se rovná full znamená, že stávající obsah vyhledávání by měl být nahrazen položkami items v data

Pro vytvoření této struktury použijte následující deklarativní příklad Kaskádový parser:

---
define:
  název: Demo parseru IPResolve
  typ: parser/cascade
  target: lookup

parse:
    !DICT
    set:
      action: full
      lookup_id:
        !JOIN
        items:
          - !ITEM CONTEXT filename
          - ip_resolve
        oddělovač: "_
      data:
        !DICT
        set:
          položky:
            !FOR
            each:
                !REGEX.SPLIT
                co: !EVENT
                regex: "\n
            do:
                !FIRST
                - !CONTEXT.SET
                  set:
                    _temp:
                      !REGEX.SPLIT
                      co: !ARG
                      regex: ';'
                - !DICT
                  set:
                    _id:
                      - !IP.PARSE
                        value: !ITEM CONTEXT _temp.0
                      - MyNetworkOrSpace
                    hostnames:
                      !LIST
                      append:
                        - !ITEM CONTEXT _temp.1
                        - !ITEM CONTEXT _temp.2

Parsování vyhledávání

Když je vyhledávání přijato z LogMan.io Collector prostřednictvím LogMan.io Ingestor, může to být buď celý obsah lookupu (full frame), nebo jen jeden záznam (delta frame).

Předzpracování

Na základě formátu vstupního souboru vyhledávání by měl být použit preprocesor aby se zjednodušily následující deklarace a optimalizovala rychlost načítání vyhledávání. Obvykle se použije preprocesor JSON, XML nebo CSV:

---
define:
  název: Preprocesor pro CSV
  typ: parser/preprocessor

funkce: lmiopar.preprocessor.CSV

Takto zpracovaný obsah souboru je uložen v CONTEXT, odkud k němu lze přistupovat.

Full frame

Pro uložení celého vyhledávání v ElasticSearch prostřednictvím LogMan.io Watcher, a informovat o změně další instance LogMan.io Parser a LogMan.io Correlator. v celém vyhledávání, je třeba použít deklaraci Cascade Parser s konfigurací target: lookup.

Tímto způsobem nebude lookup vstupovat do tématu input, ale do tématu lookups, odkud bude zpracován. LogMan.io Watcher, aby aktualizoval data v ElasticSearch.

LogMan.io Watcher očekává následující formát události:

{
    'action': 'full',
    'data': {
        "items": [{
                "_id": "myId",
                ...
            }
        ]
    },
    'lookup_id': 'myLookup'
}

kde action se rovná full znamená, že stávající obsah vyhledávání by měl být nahrazen položkami items v data.

Pro vytvoření této struktury použijte následující deklarativní příklad Kaskádový parser.

Ukázka deklarace

---
define:
  název: Demo of lookup loading parser
  typ: parser/cascade
  target: lookup

parse:
    !DICT
    set:
      action: full
      lookup_id: myLookup
      data:
        !DICT
        set:
          items:
            !FOR
            each: !ITEM CONTEXT CSV
            do:
              !DICT
              set:
                _id: !ITEM ARG myId
                ...

Když obsah vyhledávání vstoupí do parseru LogMan.io, parsovaný vyhledávač se odešle do LogMan.io Watcher, aby jej uložil do ElasticSearch.

Delta frame

Aby bylo možné aktualizovat JEDNU položku v existujícím vyhledávání v ElasticSearch prostřednictvím LogMan.io Watcher, a informovat o změně ostatní instance LogMan.io Parser a LogMan.io Correlator. v lookupu, je třeba použít deklaraci Cascade Parser s konfigurací target: lookup.

Položka lookup tak nebude vstupovat do tématu input, ale do tématu lookups, odkud bude zpracována. LogMan.io Watcher, aby aktualizoval data v ElasticSearch.

LogMan.io Watcher očekává následující formát události:

{
    'action': 'update_item',
    'data': {
        "_id": "existingOrNewItemId",
        ...
    },
    "lookup_id": "myLookup
}

kde action se rovná update_item znamená, že stávající obsah položky vyhledávání by měl být nahradit položky v data, nebo by měla být vytvořena nová položka vyhledávání.

Pro vytvoření této struktury použijte následující deklarativní příklad Cascade Parser.

Ukázka deklarace

---
define:
  název: Demo of lookup item loading parser
  typ: parser/cascade
  cíl: lookup

parse:
    !DICT
    set:
      action: update_item
      lookup_id: myLookup
      data:
        !DICT
        set:
          _id: !ITEM CONTEXT CSV.0.myID
          ...

Když obsah vyhledávání vstoupí do parseru LogMan.io, parsovaný vyhledávač se odešle do LogMan.io Watcher, aby jej uložil do ElasticSearch.

MAC Vendor Enricher

MAC Vendor obohacuje událost o zadané atributy dodavatele na základě hodnoty jejich MAC adresy (pro zjištění dodavatele se bere v úvahu pouze prvních 6 znaků).

Příklad

Deklarace

---
define:
  name: MACVendor
  typ: enricher/macvendor
  lookup: lmio_mac_vendor # nepovinné

atributy:
  MAC1: detectedVendor1
  MAC2: detectedVendor2
  ...

Vstup

Feb 5 10:50:01 0:0:0:0:0:ffff:1f1f:e001 %ASA-1-105043 5885E9001183

Výstup

{
    'rt': 1580899801.0,
    "MAC1": "5885E9001183",
    "detectedVendor1": "Realme Chongqing Mobile Telecommunications Corp Ltd",
}

Sekce define

Tato sekce definuje název a typ obohacovače, který je v případě Mac Vendor vždy enricher/macvendor.

Položka name

Kratší lidsky čitelný název této deklarace.

Položka type

Typ této deklarace, musí být enricher/macvendor.

Sekce attributes

Zadejte slovník s atributy MAC události event, podle kterých se má vyhledávat, například MAC1. Uvnitř slovníku uveďte název atributu v události, do kterého má být zjištěný dodavatel uložen. Například:

  MAC1:
    MAC: MAC: DetectedVendor1

vyhledá ve vyhledávači Mac Vendor uložený MAC event["MAC1"], načte dodavatele do event["detectedVendor1"], pokud byl úspěšně vyhledán.

Vyhledávací soubory

Vyhledávací soubory obohacující dodavatele MAC jsou založeny na standardu OUI: standards-oui.ieee.org/oui.txt

Soubory jsou uloženy v adresáři s výchozí cestou (/lookups/macvendor), který lze v konfiguraci přepsat:

[lookup:lmio_mac_vendor]
path=...

lmio_mac_vendor je zadané ID vyhledávání v definici obohacovače, které je ve výchozím nastavení lmio_mac_vendor.

Parser Builder

Builder je nástroj pro snadnou tvorbu deklarací parserů/obohacovačů.

Chcete-li spustit sestavovač, spusťte:

python3 builder.py -w :8081 ./example/asa-parser

Argument(y) cesty určují složku (nebo složky) s deklaracemi parserů a obohacovačů (alias soubory YAML). Doporučuje se ukazovat do knihovny YAML.

Soubory YAML se načítají v pořadí, jak je určeno příkazovým řádkem, a poté seřazením souborů *.yaml nalezených v příslušném adresáři podle abecedy.

Argument -I umožňuje určit adresáře, které budou použity jako základ pro direktivu !INCLUDE. Je povoleno zadat více položek.

Argument -w slouží k zadání portu HTTP.

Parser preprocesoru

parser preprocessor umožňuje předzpracovat vstupní událost pomocí imperativního kódu, např. Python, Cython, C atd.

Příklad

---
define:
  název: Demo vestavěného preprocesoru Syslog
  typ: parser/preprocesor
  tenant: (nepovinné)
  count: CEF.cnt # (nepovinné)

function: lmiopar.preprocessor.Syslog_RFC5424

tenant určuje atribut tenanta, který má být načten a předán do context['tenant'] pro další distribuci analyzovaných a nerozparsovaných událostí do specifických tenantů. indexům/úložištím v LogMan.io Dispatcher

count určuje atribut count s počtem událostí, které mají být načteny a předány do context['count'].

Vestavěné preprocesory

Modul lmiopar.preprocessor obsahuje následující běžně používané preprocesory. Tyto preprocesory jsou optimalizovány pro nasazení s vysokým výkonem.

Vestavěný preprocesor Syslog RFC5425

funkce: lmiopar.preprocessor.Syslog_RFC5424

Toto je preprocesor pro protokol Syslog (nový) podle RFC5425.

Vstupem pro tento preprocesor je platná položka protokolu Syslog, např:

<165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog 10 ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] Záznam protokolu událostí aplikace.

Výstupem je, část zprávy protokolu v události a analyzované prvky v context.syslog_rfc5424.

událost: Záznam v protokolu událostí aplikace.

context:
  Syslog_RFC5424:
    PRI: 165
    FACILITY: 20
    PRIORITA: 5
    VERZE: 1
    TIMESTAMP: 2003-10-11T22:14:15.003Z
    HOSTNAME: mymachine.example.com
    APP_NAME: evntslog
    PROCID: 10
    MSGID: ID47
    STRUCTURED_DATA:
      exampleSDID@32473:
        iut: 3
        eventSource: Aplikace:
        eventID: 1011
      ...

Vestavěný preprocesor Syslog RFC3164

funkce: lmiopar.preprocessor.Syslog_RFC3164

Toto je preprocesor pro BSD syslog protokol (starý) podle RFC3164.

Preprocesor Syslog RFC3164 lze konfigurovat v sekci define:

define:
  type: parser/preprocessor
  year: 1999
  časové pásmo: Evropa/Praha

year určuje číselnou reprezentaci roku, která bude použita na časovou značku protokolů. Můžete také zadat smart (výchozí) pro pokročilý výběr roku na základě měsíce.

timezone určuje časové pásmo protokolů, výchozí je UTC.

Vstupem pro tento preprocesor je platný záznam Syslogu, např:

<34>Oct 11 22:14:15 mymachine su[10]: 'su root' selhalo pro lonvick na /dev/pts/8

Výstupem je, zpráva část logu v události a rozebrané prvky v context.syslog_rfc3164.

událost: "``su root' selhalo pro lonvick na /dev/pts/8"

context:
  Syslog_RFC3164:
    PRI: 34
    PRIORITA: 2
    FACILITY: 4
    TIMESTAMP: '2003-10-11T22:14:15.003Z'
    HOSTNAME: mymachine
    TAG: su
    PID: 10

TAG a PID jsou nepovinné parametry.

Vestavěný preprocesor CEF

funkce: lmiopar.preprocessor.CEF

Toto je preprocesor pro CEF neboli Common Event Format.

define:
  typ: parser/preprocesor
  year: 1999
  časové pásmo: Evropa/Praha

year určuje číselnou reprezentaci roku, která bude použita na časovou značku protokolů. Můžete také zadat smart (výchozí) pro pokročilý výběr roku na základě měsíce.

timezone určuje časové pásmo protokolů, výchozí je UTC.

Vstupem pro tento preprocesor je platná položka CEF, např:

CEF:0|Výrobce|Produkt|Verze|foobar:1:2|Neúspěšné heslo|Medium| eventId=1234 app=ssh categorySignificance=/Informational/Warning categoryBehavior=/Authentication/Verify

Výstupem je část protokolu s hlášením v události a analyzované prvky v context.CEF:

context:
  CEF:
    Verze: 0
    DeviceVendor: Vendor
    DeviceProduct: Product
    DeviceVersion: Verze:
    DeviceEventClassID: "foobar:1:2
    Name: Název: Failed password
    Závažnost: Heslo: Střední

    EventId: '1234'
    aplikace: ssh
    categorySignificance: /Informational/Warning
    categoryBehavior: /Authentication/Verify

CEF může obsahovat také hlavičku Syslog. To je podporováno řetězením příslušného preprocesoru Syslog s preprocesorem CEF. Podrobnosti naleznete v kapitole o řetězení preprocesorů.

Vestavěný preprocesor pro formáty protokolu serveru Apache HTTP

Existují vysoce výkonné preprocesory pro běžné přístupové protokoly serveru Apache HTTP.

function: lmiopar.preprocessor.Apache_Common_Log_Format

Toto je preprocesor pro Apache Common Log Format.

funkce: lmiopar.preprocessor.Apache_Combined_Log_Format

Toto je preprocesor pro kombinovaný formát protokolu Apache.

Příklad společného protokolu Apache

Vstup:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

Výstup:

kontext:
  Apache_Access_Log:
    HOST: '127.0.0.1'
    IDENT: '-'
    USERID: "frank
    TIMESTAMP: '2000-10-10T20:55:36.000Z'
    METODA: "GET
    RESOURCE: "/apache_pb.gif
    PROTOKOL: "HTTP/1.0
    STATUS_CODE: 200
    DOWNLOAD_SIZE: 2326

Příklad kombinovaného protokolu Apache

Vstupní data:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [cs] (Win98; I ;Nav)"

Výstup:

kontext:
  Apache_Access_Log:
    HOST: '127.0.0.1'
    IDENT: '-'
    USERID: "frank
    TIMESTAMP: '2000-10-10T20:55:36.000Z'
    METODA: "GET
    RESOURCE: "/apache_pb.gif
    PROTOKOL: "HTTP/1.0
    STATUS_CODE: 200
    DOWNLOAD_SIZE: 2326
    REFERE": http://www.example.com/start.html
    USER_AGENT: Mozilla/4.08 [cs] (Win98; I ;Nav)

Vestavěný preprocesor Microsoft ULS

funkce: lmiopar.preprocessor.Microsoft_ULS

Toto je preprocesor pro Microsoft_ULS podle Microsoft Docs.

Pro protokoly Microsoft SharePoint ULS, které neobsahují název serveru ani korelační pole, je k dispozici speciální preprocesor:

lmiopar.preprocessor.Microsoft_ULS_Sharepoint`.

Preprocesor Microsoft SharePoint ULS lze nakonfigurovat v sekci define:

define:
  type: parser/preprocessor
  year: 1999
  časové pásmo: Evropa/Praha

year určuje číselnou reprezentaci roku, která bude použita na časovou značku protokolů. Můžete také zadat smart (výchozí) pro pokročilý výběr roku na základě měsíce.

timezone určuje časové pásmo protokolů, výchozí je UTC.

Vstupem pro tento preprocesor je platný záznam Microsoft ULS Sharepoint, např:

04/28/2021 12:31:57.69 mssdmn.exe (0x38E0) 0x4D10 SharePoint Server Search Connectors:SharePoint dvt6 High SetSTSErrorInfo ErrorMessage = Chyba z webu SharePoint: WebExceptionStatus: Podkladové spojení bylo uzavřeno: hr = 90141214 [sts3util.cxx:6994] search\native\gather\protocols\sts3\sts3util.cxx 3aeca97a-a9db-4010-970e-fe01483bfd4f

Výstupem je část zprávy protokolu v události a analyzované prvky v context.Microsoft_ULS.

událost: Zpráva obsažená v protokolu.

context:
  Microsoft_ULS:
    ČASOVÉ RAZÍTKO 1619613117.69
    PROCES: mssdmn.exe (0x38E0)
    THREAD: 0x4D10
    PRODUCT: SharePoint Server Search
    KATEGORIE: Konektory:SharePoint
    EVENTID: dvt6
    ÚROVEŇ: Vysoká

Query String preprocesor

funkce: lmiopar.preprocessor.Query_String

Toto je preprocesor pro řetězec dotazu (key=value&key=value...), jako jsou metainformace z LogMan.io Collector.

Příklad vstupu:

file_name=log.log&search=true

Výstupem je část logu v události a analyzované prvky v context.QUERY_STRING.

událost: Zpráva obsažená v protokolu.

context:
  QUERY_STRING:
    Název_souboru: log.log
    search: true

JSON vestavěný preprocesor

funkce: lmiopar.preprocessor.JSON

Jedná se o preprocesor pro formát JSON. Očekává vstup v binárním nebo textovém formátu, výstupní slovník je umístěn v události.

Vstupem pro tento preprocesor je tedy platný zápis JSON.

Vestavěný preprocesor XML

function: lmiopar.preprocessor.XML

Jedná se o preprocesor pro formát XML. Očekává vstup v binárním nebo textovém formátu, výstupní slovník je umístěn v události.

Vstupem pro tento preprocesor je tedy platný záznam XML, např:

<?xml version="1.0" encoding="UTF-8"?>
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
   <System>
      <Provider Name="Schannel" Guid="{1f678132-5938-4686-9fdc-c8ff68f15c85}" />
      <EventID>36884</EventID>
      <Version>0</Version>
      <Level>2</Level>
      <Task>0</Task>
      <Opcode>0</Opcode>
      <Keywords>0x8000000000000000</Keywords>
      <TimeCreated SystemTime="2020-06-26T07:12:01.331577900Z" />
      <EventRecordID>30286</EventRecordID>
      <Correlation ActivityID="{8e20742a-4b06-0002-c274-208e064bd601}" />
      <Execution ProcessID="788" ThreadID="948" />
      <Channel>Systém</Channel>
      <Computer>XX</Computer>
      <Security UserID="S-1-5-21-1627182167-2524376360-74743131-1001" />
   </System>
   <UserData>
      <EventXML xmlns="LSA_NS">
         <Name>localhost</Name>
      </EventXML>
   </UserData>
   <RenderingInfo Culture="en-US">
      <Message>Certifikát přijatý ze vzdáleného serveru neobsahuje očekávaný název. Proto není možné určit, zda se připojujeme ke správnému serveru. Název serveru, který jsme očekávali, je localhost. Požadavek na připojení TLS se nezdařil. Přiložené údaje obsahují certifikát serveru.</Message>
      <Level>Chyba</Level>
      <Task />
      <Opcode>Informace</Opcode>
      <Channel>Systém</Channel>
      <Provider />
      <Keywords />
   </RenderingInfo>
</Event>

Výstup preprocesoru v event:

{
  "System.EventID": "36884",
  "System.Version": "0",
  "System.Level": "2",
  "System.Task": "0",
  "System.Opcode": "0",
  "System.Keywords": "0x8000000000000000",
  "System.EventRecordID": "30286",
  "System.Channel": "System",
  "System.Computer": "XX",
  "UserData.EventXML.Name": "localhost",
  "RenderingInfo.Message": "Certifikát přijatý ze vzdáleného serveru neobsahuje očekávaný název. Není proto možné určit, zda se připojujeme ke správnému serveru. Název serveru, který jsme očekávali, je localhost. Požadavek na připojení TLS se nezdařil. Přiložené údaje obsahují certifikát serveru.",
  "RenderingInfo.Level": "Error",
  "RenderingInfo.Opcode": "Info",
  "RenderingInfo.Channel": "System"
}

Vestavěný preprocesor CSV

funkce: lmiopar.preprocessor.CSV

Toto je preprocesor pro formát CSV. Očekává vstup v binárním nebo textovém formátu, výstupní slovník je umístěn v události.

Vstupem pro tento preprocesor je tedy platný záznam CSV, např:

user,last_name\njack,black\njohn,doe

Výstup preprocesoru v context["CSV"]:

{
  "lines": [
    {"user": "jack", "last_name": "black"},
    {"user": "john", "last_name": "doe"}
  ]
}

Parametry

V sekci define preprocesoru CSV, lze nastavit následující parametry pro čtení CSV:

oddělovač: (výchozí: ",")
escapechar: únikový znak
doublequote: povolí dvojité uvozovky (výchozí: true)
lineterminator: znak pro ukončení řádku, buď \n, nebo \r (výchozí je oddělovač řádků operačního systému)
quotechar: výchozí znak uvozovek (výchozí: "\"")
quoting: typ uvozovek
skipinitialspace: vynechá počáteční mezeru (výchozí: false)
strict: přísný režim (výchozí: false)

Vlastní preprocesory

Vlastní preprocesory lze volat z parseru, příslušný kód musí být přístupný mikroslužbě parseru běžným způsobem importu Pythonu.

---
define:
  název: Ukázka vlastního preprocesoru Pythonu.
  typ: parser/preprocesor

funkce: mypreprocessors.preprocessor

mypreprocessors je modul odpovídající složce __init__.py, který obsahuje funkci preprocessor().

Parser určuje funkci, která se má zavolat. Používá se notace Pythonu a automaticky se provede import modulu.

Signatura funkce:

def preprocessor(context, event):
  ...
  return event

Preprocesor může (1) modifikovat událost (!EVENT) a/nebo (2) modifikovat kontext (!CONTEXT).

Výstup funkce preprocessor bude předán následnému parseru. Preprocesorový parser nevytváří přímo parsované události. Pokud funkce vrátí None, parsování eveny se tiše ukončí. Pokud funkce vyvolá výjimku, bude výjimka zaznamenána a událost bude předána do výstupu unparsed.

Řetězení preprocesorů

Preprocesory lze řetězit, aby bylo možné analyzovat složitější vstupní formáty. Výstup (neboli událost) prvního preprocesoru je přiveden jako vstup druhého preprocesoru (a tak dále).

Například vstupem je formát CEF se záhlavím Syslog RFC3164:

<14>Jan 28 05:51:33 connector-test CEF_PARSED_LOG: CEF:0|Výrobce|Produkt|Verze|foobar:1:2|Neúspěšné heslo|Medium| eventId=1234 app=ssh categorySignificance=/Informational/Warning categoryBehavior=/Authentication/Verify

Potrubí obsahuje dva preprocesory:

p01_parser.yaml:

---
define:
  název: Preprocesor pro část zprávy Syslog RFC5424
  type: parser/preprocessor
  nájemce: Syslog_RFC5424.STRUCTURED_DATA.soc@0.tenant

funkce: lmiopar.preprocessor.Syslog_RFC5424

p02_parser.yaml:

---
define:
  name: Preprocesor pro část zprávy CEF
  typ: parser/preprocesor

funkce: lmiopar.preprocessor.CEF

a finální parser p03_parser.yaml:

---
define:
  name: Finalizovat rozborem události do slovníku
  typ: parser/cascade

parse:
  !DICT
  set:
    Syslog_RFC5424: !ITEM CONTEXT Syslog_RFC5424
    CEF: !ITEM CONTEXT CEF
    Message: !EVENT

Příklad výstupu:

context:
  CEF:
    Verze: 0
    DeviceVendor: Vendor
    DeviceProduct: Product
    DeviceVersion: Verze:
    DeviceEventClassID: "foobar:1:2
    Name: Název: Failed password
    Závažnost: Heslo: Střední

    EventId: '1234'
    aplikace: ssh
    categorySignificance: /Informational/Warning
    categoryBehavior: /Authentication/Verify

  Syslog_RFC3164:
    PRI: 14
    FACILITY: 1
    PRIORITA: 6
    HOSTNAME: connector-test'
    TAG: CEF_PARSED_LOG
    TIMESTAMP': '2020-01-28T05:51:33.000Z'

  Zpráva: "Provedení: 1. Provedení: 2. Provedení: 3: ''

Vestavěný preprocesor Cisco ASA

funkce: lmiopar.preprocessor.CiscoASA

Warning

Tento preprocesor bude nahrazen parserem založeným na SP-Lang.

Standardní obohacovač

Standardní obohacovač obohacuje analyzovanou událost o další pole. Obohacení probíhá po jednom z kaskádových parserů v rámci skupiny parserů. úspěšně porovnal a rozebral původní vstup.

Příklad

---
define:
  name: Příklad standardního obohacovače
  type: enricher/standard
  field_alias: field_alias.default

enrich:
  - !DICT
    with: !EVENT
    set:
      myEnrichedField:
        !LOWER
        what: "You Have Been Enriched"

Sekce define

Tato sekce obsahuje společnou definici a metadata.

Položka name

Kratší lidsky čitelný název deklarace obohacovače.

Položka type

Typ této deklarace, musí být enricher/standard.

Položka field_alias

Název vyhledávače aliasů polí, který se má načíst, aby bylo možné v deklaraci použít aliasové názvy atributů událostí vedle jejich kanonických názvů.

Položka description (nepovinné)

Dlouhý, případně víceřádkový, lidsky čitelný popis deklarace.

Sekce enrich

Tato sekce určuje skutečné obohacení příchozí události. Očekává, že bude vrácen slovník.

Typické příkazy v sekci enrich

Příkaz !DICT umožňuje přidat pole / atributy k již analyzované události

Testování parserů

Je důležité testovat parsery a ověřovat jejich funkčnost s různými vstupy. LogMan.io nabízí nástroje pro ruční i automatizované testování parserů.

LogMan.io Parse Utility

Tato utilita je určena pro ruční spouštění parserů z příkazového řádku. Je užitečná pro testování, protože na vstup aplikuje vybrané skupiny parserů a nezpracované události ukládá do vyhrazeného souboru, takže parser lze vylepšovat, dokud není tento "nezpracovaný" výstup prázdný. Je určen pro parsování velmi rozsáhlých vstupů.

Nástroj parse je program pro příkazový řádek. Spouští se následujícím příkazem:

python3 ./parse.py -i input-syslog.txt -u unparsed-syslog.txt ./example/syslog_rfc5424-parser

-i, --input-file určuje soubor se vstupními řádky pro parsování

-u, --unparsed-file určuje soubor, do kterého se budou ukládat nerozparsované události ze vstupního souboru

a dále následuje skupina(y) parserů z knihovny, odkud se mají načíst deklarativní parsery.

Následující aplikace spustí parsování na daném vstupním souboru se záznamy rozdělenými novými řádky, jako např:

Feb 5 10:50:01 192.168.1.1 %ASA-1-105043 test1
Feb 5 10:55:10 192.168.1.1 %ASA-1-105043 test2
Feb 10 8:25:00 192.168.A1.1 X %ASA-1-105044 test3

a vytvoří soubor pouze s nerozčleněnými událostmi, který má stejnou strukturu:

Feb 10 8:25:00 192.168.A1.1 X %ASA-1-105044 test3

Parser Unit test

Parser LogMan.io poskytuje nástroj pro provádění unit testů nad knihovnou deklarací parserů a obohacovačů.

Pro začátek:

python3 ./test.py ./example [--config ./config.json]

Nástroj vyhledá testy v knihovně, načte je a pak je provede v zadaném pořadí.

Formát jednotkových testů

Soubor s jednotkovými testy musí být umístěn v adresáři test a jeho název musí odpovídat šabloně test*.yaml. Jeden testovací soubor YAML může obsahovat jeden nebo více dokumentů YAML se specifikací testu.

---
vstup: |
  řádek 1
  řádek 2
  ...

skupiny:

  # To znamená, že bude analyzováno vše ze vstupu
  unparsed: []

  parsed:
    - msg: line
      num: 1
    - msg: line
      num: 2

Ended: Parser

Correlator

Konfigurace korelátoru LogMan.io

Nejprve je třeba určit, ze které knihovny se mají načítat deklarace, což může být buď ZooKeeper, nebo File.

Každá spuštěná instance parseru také musí vědět, které skupiny má načíst z knihoven, viz níže:

# Deklarace

[deklarace]
library=zk://zookeeper:12181/lmio/library.lib ./data/declarations
groups=Firewall Common Authentication
include_search_path=filters;filters/firewall;filters/common;filters/authentication
timestamp=@timestamp

groups - názvy skupin, které mají být použity z knihovny, oddělené mezerami; pokud je skupina se nachází v podsložce složky, použijte jako oddělovač lomítko, např. correlators/Firewall

include_search_path - určuje složky, ve kterých se mají hledat soubory YAML, které se později použijí ve výrazu !INCLUDE (např. !INCLUDE myFilterYAMLfromFiltersCommonSubfolder) v deklaracích, oddělené znakem ;. Uvedením hvězdičky * za lomítkem v cestě budou rekurzivně zahrnuty všechny podadresáře. Výraz !INCLUDE očekává jako vstup název souboru bez cesty a bez přípony. Chování je podobné atributu -I include při sestavování kódu v jazyce C/C++.

timestamp - název pole atributu timestamp pro kontrolu normalizace po zpracování spouštěče události.

Dále je potřeba vědět, která témata Kafky použít na vstupu a výstupu (pro spouštěče událostí). Je třeba také nakonfigurovat připojení Kafka, aby bylo známo, ke kterým serverům Kafka se připojit.

# Připojení Kafka

[connection:KafkaConnection]
bootstrap_servers=lm1:19092;lm2:29092;lm3:39092

[pipeline:CorrelatorsPipeline:KafkaSource]
topic=lmio-events
group_id=lmio_correlator_firewall

# Kafka sink pro spouštění událostí

[pipeline:OutputPipeline:KafkaSink]
topic=lmio-output

Poslední povinná sekce určuje, které téma Kafky se má použít pro informace o změnách ve vyhledávání (tj. seznamy odkazů) a která instance ElasticSearch se mají načíst.

# ``Persistentní úložiště pro vyhledávání

[asab:storage]
type=elasticsearch

[elasticsearch]
url=http://elasticsearch:9200

# Aktualizovat vyhledávací pipelines

[pipeline:LookupChangeStreamPipeline:KafkaSource]
topic=lookups
group_id=lmio_correlator_firewall

[pipeline:LookupModificationPipeline:KafkaSink]
topic=lookups

Instalace

Docker Compose

  lmio-correlator:
    docker.teskalabs.com/lmio/lmio-correlator.
    volumes:
      - ./lmio-correlator:/data

Entity Correlator

Příklad

define:
  name: Detekce chování uživatelské entity
  description: Detekce chování uživatelské entity
  type: correlator/entity  
  rozpětí: 5
  zpoždění: 5m # doba analýzy = zpoždění + rozlišení         

predikát:
  !AND
  - !EQ
    - !ITEM EVENT zpráva
    - "FAIL"  
  - !EQ
    - !ITEM EVENT device.vendor
    - "Microsoft"
  - !EQ
    - !ITEM EVENT device.product
    - "Exchange Server"

vyhodnotit:
  dimenze: [tenant, source.user] 
  by: # Název pole události s časem události
  resolution: # jednotka je sekunda
  lookup_seen: active_users
  lookup_lost: inactive_users

spouštěče:
  ztracené:
    - událost:
        !DICT
        typ: "{str:any}"
        with:
          name: "User lost detected on periodic analysis"
          type: "Correlation"
          severity: "Low"
  seen:
    - událost:
        !DICT
        typ: "{str:any}"
        with:
          name: "User seen detected on periodic analysis"
          type: "Correlation"
          severity: "Low"

Sekce define

Tato sekce obsahuje společnou definici a metadata.

Položka name

Kratší lidsky čitelný název této deklarace.

Item type

Typ této deklarace, musí být correlator/entity.

Položka span

Určuje šířku okna. Jednotkou je rozlišení.

Položka delay (nepovinné)

Analýza proběhne po zadané době v sekundách a tato doba je založena na rozlišení.

Pokud je potřeba tuto dobu prodloužit, a tedy analýzu zpozdit, lze zadat možnost delay, například 300 (300 sekund), 1h (3600 sekund / jedna hodina) atd.

Položka field_alias

Název vyhledávače aliasů polí, který se má načíst, aby bylo možné v deklaraci použít aliasové názvy atributů událostí vedle jejich kanonických názvů.

Položka aggregation_count_field

Název atributu, který určuje počet událostí v rámci jedné agregované události, a tím ovlivňuje součet událostí v analýze. Výchozí hodnota je 1.

Položka disabled

Logická hodnota, která určuje, zda je deklarace zakázána/povolena pro korelaci. Výchozí hodnota je false.

Položka description (nepovinné)

Dlouhý, případně víceřádkový, lidsky čitelný popis deklarace.

Sekce predicate (nepovinné)

Predikát filtruje příchozí události pomocí výrazu. Pokud výraz vrátí hodnotu True, vstoupí událost do sekce evaluate. Pokud výraz vrátí False, událost se přeskočí.

Ostatní vrácené hodnoty jsou nedefinované.

Včetně vnořených predikátových filtrů

Predikátové filtry jsou výrazy umístěné ve vyhrazeném souboru, které lze zahrnout do mnoha různých predikátů jako jejich části.

Pokud chcete zahrnout externí filtr predikátu, který se nachází buď ve složce include, nebo ve složce filters. (jedná se o globální složku umístěnou v nejvyšší hierarchii knihovny LogMan.io), použijte příkaz !INCLUDE:

!INCLUDE predicate_filter

kde predicate_filter je název souboru s příponou .yaml. Obsahem souboru predicate_filter.yaml je výraz, který má být zahrnut, jako např:

---
!EQ
- !ITEM EVENT category
- "MyEventCategory"

Sekce vyhodnotit

Sekce evaluate určuje primární klíč, rozlišení a další atributy, které se použijí na příchozí událost. Funkce evaluate má za úkol přidat událost do dvourozměrné struktury definované časem a prvotním klíčem.

Položka dimension

Určuje jednoduchý nebo složený primární klíč (nebo dimenzi) pro událost. Rozměr dimension je definován názvy vstupních polí události.

Příklad jednoduchého primárního klíče:

vyhodnotit:
  dimenze: Název zákazníka

Příklad složeného primárního klíče:

vyhodnotit:
  dimenze: [CustomerName, DestinationAddress, DestinationHostname]: ```: [CustomerName, DestinationAddress, DestinationHostname]

Pokud je přesně jedna dimenze jako DestinationHostname v původní události seznamem a korelace by měla proběhnout pro každou z hodnot dimenze, měla by být dimenze zabalena do [``]`:

vyhodnotit:
  dimenze: [CustomerName, DestinationAddress, [DestinationHostname]]: ```: [CustomerName, DestinationAddress, [DestinationHostname]].

Položka by

Určuje název pole vstupní události, které obsahuje informaci o datu/času, jež bude použita pro vyhodnocení.

Položka resolution (nepovinné)

Určuje rozlišení časové agregace korelátoru. Jednotkou je sekunda.

vyhodnotit:
  rozlišení: # 1 hodina

Výchozí hodnota: 3600

Položka lookup_seen

lookup_seen určuje ID vyhledávání, kam se zapisují viděné entity s časem posledního vidění.

Položka lookup_lost

lookup_lost určuje ID vyhledávání, kam se mají zapisovat ztracené entity s časem poslední analýzy

Sekce triggers

Sekce triggers určuje druhy akcí, které mají být provedeny při periodické analýze.

Podporovány jsou akce ztratil a viděl.

Podrobnosti viz kapitola correlator triggers.

Spouštěče seen

Spouštěče Seen se spustí, když analýza najde události, které vstoupily do okna v analyzovaném čase.

Dimenzi (název entity) lze získat pomocí !ITEM EVENT dimension.

Časové razítko poslední události, která vstoupila do okna v zadané dimenzi, lze získat prostřednictvím !ITEM EVENT last_event_timestamp (entita aktualizována).

Příklad:

  viděno:
    - vyhledávání: user_inventory
      klíč: !ITEM EVENT dimenze
      set:
        last_seen: !ITEM EVENT last_event_timestamp

lost spouští

Ztracené spouštěče se provedou, když analýza zjistí, že v analyzovaném čase nepřišla do zadané dimenze žádná událost (odpadnutí entity).

Dimenzi (název entity) lze získat prostřednictvím !ITEM EVENT dimension.

Příklad:

  ztraceno:
    - událost:
        !DICT
        typ: "{str:any}"
        with:
          name: "User drop detected on periodic analysis"
          type: "Correlation"
          severity: "Low"

Vyhledávání událostí

Když dojde ke změně v některém z vyhledávačů nebo jeho položek, obvykle v důsledku vyvolané události vyhledávání nebo změny prostřednictvím uživatelského rozhraní, jsou všechny instance LogMan.io Correlator informovány pomocí příchozí události.

Změnou vyhledávání může být buď vytvoření, nebo odstranění vyhledávání, popř. vytvoření, aktualizace, vymazání i vymazání způsobené vypršením platnosti. jednotlivých položek vyhledávání.

Události vyhledávání jsou odesílány každou komponentou, která vytváří události vyhledávání, do témat lmio-lookups. Pokud byla aktualizace ElasticSearch úspěšná, LogMan.io Watcher odešle událost také do tématu lmio-stores Kafka, aby informoval o aktualizaci stavu vyhledávání.

Struktura události Lookup

Událost Lookup je struktura JSON se třemi povinnými atributy: action, lookup_id a data. Atributy @timestamp a tenant. jsou přidány automaticky, stejně jako další nakonfigurované atributy. metaatributy.

action

Určuje akci, kterou událost vyhledávání způsobila. Akce se provede na celém vyhledávání nebo jen na jedné z jeho položek. Všechny dostupné akce a s nimi spojené události najdete v seznamu níže.

lookup_id

ID/název vyhledávání. ID vyhledávání v událostech vyhledávání obsahuje také název nájemce za znakem tečky ., aby každá komponenta věděla, pro kterého nájemce je vyhledávání určeno.

data

Specifikace od lookup data (tj. položka lookup), která mají být vytvořena/aktualizována, a také metainformace (pro případ smazání položky).

Položky vyhledávání obsahují své ID v atributu _id struktury data. Parametr _id je řetězec založený na:

Jednoduchý klíč

Pokud má vyhledávání pouze jeden klíč (např. userName), _id je v případě řetězce samotná hodnota.

'data': {
    '_id': 'JohnDoe'
}
...

Pokud je hodnota bajtová, _id je řetězcová reprezentace hodnoty dekódovaná v UTF-8. Pokud hodnota není ani řetězec, ani bajty, pracuje se s ní stejně jako s ID při použití složených klíčů.

Složený klíč

Pokud se vyhledávání skládá z více klíčů (např. [userName, location]), je _id hash reprezentací hodnoty.

Původní hodnoty jsou pak uloženy v atributu _klíče uvnitř struktury data:

'data': {
    '_id': '<INTERNAL_HASH>',
    '_keys': ["JohnDoe", "Company 1"]
}
...

Vytvořit vyhledávání

Při vytváření vyhledávání se vytvoří následující akce:

{
    '@timestamp': <UNIX_TIMESTAMP>,
    'tenant': <TENANT>,
    "action": "create_lookup",
    "data": {},
    "metadata": {
        "_keys": ["key1name", "key2name" ...]
        ...
    },
    "lookup_id": "myLookup.tenant
}

Metaúdaje obsahují informace o vytvoření vyhledávání, například názvy jednotlivých klíčů (např. [userName, location]) v případě složených klíčů.

Odstranit vyhledávání

Při mazání vyhledávání se provede následující akce:

{
    '@timestamp': <UNIX_TIMESTAMP>,
    'tenant': <TENANT>,
    "action": "delete_lookup",
    "data": {},
    "lookup_id": "myLookup.tenant
}

Vytvořit položku

Při vytvoření položky se vytvoří následující akce:

{
    '@timestamp': <UNIX_TIMESTAMP>,
    'tenant': <TENANT>,
    "action": "create_item",
    "data": {
        "_id": "newItemId",
        "_keys": [],
        ...
    },
    "lookup_id": "myLookup.tenant
}

Aktualizovat položku

Při aktualizaci položky se provede následující akce:

{
    '@timestamp': <UNIX_TIMESTAMP>,
    'tenant': <TENANT>,
    "action": "update_item",
    "data": {
        "_id": "existingOrNewItemId",
        "_keys": [],
        ...
    },
    "lookup_id": "myLookup.tenant
}

Odstranit položku

Při smazání položky se provede následující akce.

Vypršení platnosti

V případě vymazání z důvodu vypršení platnosti:

{
    '@timestamp': <UNIX_TIMESTAMP>,
    'tenant': <TENANT>,
    "action": "delete_item",
    "data": {
        "_id": "existingItemId",
        "reason": "expiration
    },
    "lookup_id": "myLookup.tenant
}

Upozornění: Pokud není zakázána možnost use_default_expiration_when_update (nastavena na false). v metainformacích vyhledávání, bude platnost obnovena při každé aktualizaci položky vyhledávání. (aktuální čas + výchozí expirace). K vymazání v důsledku vypršení platnosti tedy dojde pouze tehdy, pokud mezitím nedošlo k žádné aktualizaci položky po dobu trvání expirace.

Smazat

Z jiných důvodů:

{
    '@timestamp': <UNIX_TIMESTAMP>,
    'tenant': <TENANT>,
    "action": "delete_item",
    "data": {
        "_id": "existingItemId",
        "reason": "delete
    },
    "lookup_id": "myLookup.tenant
}

Spouštěče korelátoru

Spouštěče definují výstup korelátorů. Nacházejí se v sekci trigger korelátoru. Každý korelátor může definovat mnoho spouštěčů (jedná se o seznam).

Spouštěč může přistupovat k původní události pomocí příkazu !EVENT, je to poslední událost, která prošla vyhodnocovacím testem.

Hodnota z funkce agregátoru je k dispozici v !ARG.

Spouštěč event

Tento spouštěč vloží novou událost/upozornění do primární datové cesty.

Příklad spouštěče události:

trigger:
  - událost:
      !DICT
      typ: "{str:any}"
      with:
        AnalyzeValue:
          !GET
          from: !ARG RESULTS
          what: 0
        LastEvent: !EVENT
        AnotherAttribute: Foo

Může existovat až 5 výsledků, podobně jako v agregátoru mean spike:

spouštěč:
  - událost:
      !DICT
      typ: "{str:any}"
      with:
        události: !ARG EVENTS
        MeanSpike:
          !GET
          from: !ARG RESULTS
          what: 0
        MeanSpikeLastCount:
          !GET
          from: !ARG RESULTS
          what: 1
        MeanSpikeMean:
          !GET
          from: !ARG RESULTS
          what: 2

spouštěč lookup

Spouštěč Lookup manipuluje s obsahem vyhledávání. To znamená, že může přidávat (set), inkrementovat (add), dekrementovat (sub) a odstraňovat (delete) záznam v lookupu.

Záznam je identifikován pomocí klíče, což je jedinečný primární klíč.

Příklad spouštěče, který přidá položku do vyhledávání UserList:

 trigger:
  - lookup: UserList
    key: !ITEM EVENT Jméno uživatele
    set:
      Časové razítko: !NOW
      Foo: Bar

Příklad spouštěče, který odstraní položku z vyhledávacího seznamu UserList:

 trigger:
  - lookup: UserList
    smazat: !ITEM EVENT Jméno uživatele

Příklad spouštěče, který zvýší čítač (pole my_counter) v položce vyhledávání UserList:

 trigger:
  - lookup: UserList
    key: !ITEM EVENT Jméno uživatele
    add: my_counter

Příklad spouštěče, který snižuje čítač (pole my_counter) v položce vyhledávání UserList:

 trigger:
  - lookup: UserList
    key: !ITEM EVENT Jméno uživatele
    sub: my_counter

Pro add i sub lze název pole čítače vynechat. Proto se implicitně použije výchozí atribut _counter:

 trigger:
  - lookup: UserList
    key: !ITEM EVENT Jméno uživatele
    sub:

Pokud pole čítače neexistuje, vytvoří se s výchozí hodnotou 0.

Poznámka: K položkám vyhledávání lze přistupovat z deklarativních výrazů pomocí položek !LOOKUP.GET a !LOOKUP.CONTAINS.

spouštěč notification

Tento spouštěč vloží do cesty primárních dat nové oznámení, které se načte pomocí asab-print.

Příklad spouštěče notifikace:

  - notifikace:
      typ: mail
      šablona: notification.html
      to: eliska.novotna@teskalabs.com
      alert:
        !DICT
        typ: "{str:any}"
        with:
          message: "brute-force"
      event:
        !DICT
        type: "{str:any}"
        with:
          ecs.version: "1.10.0"
          event.kind: "alert"
          event.type: "brute-force"
          event.category: "attack"
          event.dataset: "correlator-webserver"

Window Correlator

Příklad

define:
  název: Příklad korelátoru oken
  description: |
    Dlouhý víceřádkový deskriptor
    To opravdu přechází do jiného linw
  typ: correlator/window
  field_alias: field_alias.default
  aggregation_count_field: cnt
  disabled: false

predikát: cnt:
  !AND
  - !EQ
    - !ITEM EVENT typ
    - UseIt
  - !INCLUDE predicate_filter

vyhodnotit:
  dimenze: [customer.name, destination.address, [destination.hostname] ]  
  by: Časové razítko
  rozlišení: # sekundy: 5 # sekundy
  minimum_growth: 10 # 10 * rozlišení je výchozí velikost segmentu (nepovinné)

analyze:
  when: event
  window: hopping
  agregace: suma
  rozpětí: 12
  test:
    !GT
    - !ARG
    - 5

spouštěč:
  - událost:
      !DICT
      typ: "{str:any}"
      with:
        category.significance: "/Compromise"

Sekce define

Tato sekce obsahuje společnou definici a metadata.

Položka name

Kratší lidsky čitelný název této deklarace.

Item type

Typ této deklarace, musí být correlator/window.

Položka field_alias

Název vyhledávače aliasů polí, který se má načíst, aby bylo možné v deklaraci použít aliasové názvy atributů událostí vedle jejich kanonických názvů.

Položka disabled

Logická hodnota, která určuje, zda je deklarace zakázána/povolena pro korelaci. Výchozí hodnota je false.

Položka description (nepovinné)

Dlouhý, případně víceřádkový, lidsky čitelný popis deklarace.

Sekce predicate (nepovinné)

Predikát filtruje příchozí události pomocí výrazu. Pokud výraz vrátí hodnotu True, vstoupí událost do sekce evaluate. Pokud výraz vrátí False, událost se přeskočí.

Ostatní vrácené hodnoty jsou nedefinované.

Včetně vnořených predikátových filtrů

Predikátové filtry jsou výrazy umístěné ve vyhrazeném souboru, které lze zahrnout do mnoha různých predikátů jako jejich části.

Pokud chcete zahrnout externí filtr predikátu, který se nachází buď ve složce include, nebo ve složce filters. (jedná se o globální složku umístěnou v nejvyšší hierarchii knihovny LogMan.io), použijte příkaz !INCLUDE:

!INCLUDE predicate_filter

kde predicate_filter je název souboru s příponou .yaml. Obsahem souboru predicate_filter.yaml je výraz, který má být zahrnut, jako např:

---
!EQ
- !ITEM EVENT category
- "MyEventCategory"

Sekce vyhodnotit

Sekce evaluate určuje primární klíč, rozlišení a další atributy, které se použijí na příchozí událost. Funkce evaluate má za úkol přidat událost do dvourozměrné struktury definované časem a prvotním klíčem.

Položka dimension

Určuje jednoduchý nebo složený primární klíč (nebo dimenzi) pro událost. Rozměr dimension je definován názvy vstupních polí události.

Příklad jednoduchého primárního klíče:

vyhodnotit:
  dimenze: Název zákazníka

Příklad složeného primárního klíče:

vyhodnotit:
  dimenze: [CustomerName, DestinationAddress, DestinationHostname]: ```: [CustomerName, DestinationAddress, DestinationHostname]

Pokud je přesně jedna dimenze jako DestinationHostname v původní události seznamem a korelace by měla proběhnout pro každou z hodnot dimenze, měla by být dimenze zabalena do [``]`:

vyhodnotit:
  dimenze: [CustomerName, DestinationAddress, [DestinationHostname]]: ```: [CustomerName, DestinationAddress, [DestinationHostname]].

Položka by

Určuje název pole vstupní události, které obsahuje informaci o datu/času, jež bude použita pro vyhodnocení.

Položka event_count (nepovinné)

Název atributu, který určuje počet pro korelaci v rámci jedné události, a tudíž ovlivňuje "součet událostí" v analýze. Výchozí hodnota je 1.

Položka resolution (nepovinné)

Určuje rozlišení časové agregace korelátoru. Jednotkou je sekunda.

vyhodnotit:
  rozlišení: # 1 hodina

Výchozí hodnota: 3600

Položka saturation (nepovinné)

Určuje dobu trvání "tichého" časového intervalu po spuštění spouštěče. Je specifický pro rozměr. Jednotkou je rozlišení.

Výchozí hodnota: 3

Sekce analyze (nepovinné)

Sekce analyze obsahuje konfiguraci časového okna, které se použije na vstupní události. Výsledek analýzy časového okna je podroben konfigurovatelnému testu. Pokud je test úspěšný (neboli vrátí True), je spuštěn trigger.

Poznámka: Sekce je nepovinná, výchozí chování je, že se trigger spustí, když je alespoň jedna událost v trumpu span rovna 2.

Položka když (nepovinné)

Určuje, kdy má dojít k analýze událostí v oknech.

Volby:

• (výchozí): Analýza proběhne poté, co přijde událost a je vyhodnocena, obvykle užitečné pro porovnávání a aritmetickou korelaci.
• periodic/...: Analýza probíhá po zadaném intervalu v sekundách, například periodic/10 (každých 10 sekund), periodic/1h (každých 3600 sekund / jednu hodinu) atd. Obvykle užitečné pro vyhodnocení UEBA.

Periodická analýza vyžaduje správné nastavení rozlišení a rozpětí časového okna, aby analýza neprobíhala příliš často.

Položka window (nepovinná)

Určuje, jaký druh časového okna se má použít.

Volby:

• tumbling: Pevné rozpětí (doba trvání), nepřekrývající se souvislé časové intervaly bez mezer.
• hopping: Pevné rozpětí (doba trvání), překrývající se souvislé časové intervaly oken

Výchozí hodnota: hopping

Položka span

Určuje šířku okna. Jednotkou je rozlišení.

Položka aggregate (nepovinné)

Určuje, jaké agregační funkce se mají použít na události v okně.

Agregátní funkce

• sum: Summation
• median: Medián
• průměr: (vážený) průměr
• median: (průměr): * median: (průměrný (průměrný) průměr): aritmetický průměr
• std: Směrodatná odchylka
• var: Rozptyl
• mean spike: Pro detekci hrotů. Základní hodnota je střední hodnota, vrací procenta.
• median spike: Pro detekci hrotů. Základní hodnotou je medián, vrací se procento.
• Unikátní počet: Pro jedinečný počet atributů události: Je třeba zadat dimension.

Výchozí hodnota: sum

Příklad jedinečného počtu:

analyzovat:
  okno: hopping
  agregace: unikátní počet
  dimenze: SourceAddress
  rozpětí: 6
  test:
    !GE
    - !ARG
    - 5

Spustí se, když je pozorováno 5 a více jedinečných zdrojových adres.

Položka test (nepovinné)

Položka test je výraz, který se použije na výstup výpočtu agregátu. Pokud výraz vrátí hodnotu True, bude spuštěn trigger, pokud dimenze ještě není nasycena. Pokud výraz vrátí hodnotu False, nebude provedena žádná akce.

Ostatní vrácené hodnoty jsou nedefinované.

Sekce trigger

Sekce trigger určuje, jaké druhy akcí se mají provést, když je trigger vyvolán pomocí test v sekci analyze. Podrobnosti viz kapitola correlator triggers.

Ended: Correlator

Konfigurace

Branding

Značku určenou zákazníkem lze nastavit v aplikaci LogMan.io WebUI.

Statický branding

Příklad:

let ConfigDefaults = {
    title: "App Title",
    brand_image: {
        full: "media/logo/header-full.svg",
        minimized: "media/logo/header-minimized.svg",
    }
};

Dynamická značka

Branding lze nakonfigurovat pomocí dynamické konfigurace.

Dynamická konfigurace je injektována pomocí ngx_http_sub_module, protože nahrazuje předdefinovaný obsah index.html (v našem případě).

Více informací o ngx_http_sub_module

Existují 3 možnosti dynamického brandingu - logo v záhlaví, nadpis a vlastní styly CSS.

Logo záhlaví

Chcete-li nahradit výchozí logo záhlaví, je třeba v konfiguraci sub_filter systému nginx dodržet pravidla pro nahrazení <meta name="header-logo-full"> a <meta name="header-logo-minimized"> s konkrétním názvem. Náhrada musí mít rekvizitu content, jinak se obsah náhrady nepropaguje. content musí obsahovat řetězec s cestou k logu.

Velikost obrázků značky naleznete zde.

Full

Příklad importu loga v plné velikosti (když není sbalen postranní panel aplikace).

sub_filter '<meta name="header-logo-full">' '<meta name="header-logo-full" content="/<location>/<path>/<to>/<custom_branding>/<logo-full>.svg">';

Minimalizováno

Příklad importu loga minimalizované velikosti (při sbaleném postranním panelu aplikace)

sub_filter '<meta name="header-logo-minimized">' '<meta name="header-logo-minimized" content="/<location>/<path>/<to>/<custom_branding>/<logo-minimized>.svg">';

Název

Příklad nahrazení názvu aplikace, konfigurace se musí řídit pravidly pro nahrazení <meta name="title"> s konkrétním name. Nahrazení musí mít rekvizitu content, jinak se obsah nahrazení nebude propagovat. content musí obsahovat řetězec s názvem aplikace.

sub_filter '<meta name="title">' '<meta name="title" content="Custom app title">';

Vlastní styly CSS

Příklad importu vlastních stylů CSS, konfigurace se musí řídit pravidly pro nahrazení <meta name="custom-css-file"> s konkrétním name. Náhrada musí mít rekvizitu content, jinak nebude obsah náhrady propagován. content musí obsahovat řetězec s cestou k souboru CSS.

sub_filter '<meta name="custom-css-file">' '<meta name="custom-css-file" content="/<location>/<path>/<to>/<custom_branding>/<custom-file>.css">';

Příklad vlastního souboru CSS

.card .card-header-login .card-header-title h2 {
    color: violet !important;
}

.text-primary {
    color: yellowgreen !important;
}

Definujte cestu nginxu k dynamickému obsahu značky

Aby bylo možné umístit dynamický (vlastní) brandingový obsah, je třeba jej definovat v nastavení nginx.

# Cesta k umístění (adresáři) s vlastním obsahem
location /<location>/<path>/<to>/<custom_branding> {
    alias /<path>/<to>/<custom_branding>;
}

Úplný příklad

Úplný příklad konfigurace nginx s vlastní značkou

...

location /<location> {
    root /<path>/<to>/<build>;
    index index.html;
    sub_filter '<meta name="header-logo-full">' '<meta name="header-logo-full" content="/<location>/<path>/<to>/<custom_branding>/<logo-full>.svg">';
    sub_filter '<meta name="header-logo-minimized">' '<meta name="header-logo-minimized" content="/<location>/<path>/<to>/<custom_branding>/<logo-minimized>.svg">';
    sub_filter '<meta name="title">' '<meta name="title" content="Custom app title">';
    sub_filter '<meta name="custom-css-file">' '<meta name="custom-css-file" content="/<location>/<path>/<to>/<custom_branding>/<custom-file>.css">';
    sub_filter_once on;
}

# Cesta k umístění (adresáři) s vlastním obsahem
location /<location>/<path>/<to>/<custom_branding> {
    alias /<path>/<to>/<custom_branding>;
}

...

Průvodce stylováním

Každý obrázek MUSÍ být ve formátu SVG (vektorový). Použití pixelových formátů (PNG, JPG, ...) se důrazně nedoporučuje. Při vytváření obrázků značky používejte plnou šířku/výšku plátna (poměr 3:1 u plné a 1:1 u minimalizované verze). Pro optimální zobrazení není vyžadováno žádné vyplňování.

Obrázky značky

formát: SVG

Plné znění: * vykreslovaný poměr: 3:1 * vykreslená velikost: 150x50 px

Minimalizováno: * vykreslený poměr: 1:1 * vykreslená velikost: 50x50 px

Branding je na velkých obrazovkách umístěn v levém horním rohu. Obrázek značky Plné velikosti se používá, když je postranní panel rozbalený, a při sbalení je nahrazen zmenšenou verzí. Na menších obrazovkách (<768px) branding v postranním panelu zmizí a zobrazí se pouze obrázek brandingu v plné velikosti v pozici nahoře uprostřed stránky.

Logo by mělo být vhodné pro použití ve světlém i tmavém režimu.

Logo na postranním panelu je vždy umístěno v dole postranního panelu. Minimalizovaná verze se objeví po sbalení postranního panelu.

Úplné: * vykreslená velikost: 90x30 px

Minimalizovaná: * vykreslená velikost: 30x30 px

Poznámka: Na úvodní obrazovce je také použit celý obrázek, 30 % šířky obrazovky.

Objevte konfiguraci

Nastavení obrazovky Discover

Obrazovka Discover slouží k zobrazení a prozkoumání dat (nejen) v ElasticSearch.

Konfiguraci obrazovky Discover lze načíst z Library nebo ze statického souboru ve složce public stejným způsobem jako v případě Dashboards.

Typ filtrovaných dat závisí na specifikaci, která musí být definována společně s datetimeField. Jedná se o klíčové hodnoty, bez kterých není filtrování možné.

Objevte konfiguraci

Konfigurace knihovny

Konfigurace knihovny je uložena v uzlu Knihovna. Musí být pouze typu JSON.

Pro získání konfigurace z Library musí být spuštěna služba asab_config s konfigurací ukazující na hlavní uzel Library. Další informace naleznete zde: http://gitlab.teskalabs.int/lmio/asab-config.

Konfigurace z Library je editovatelná

V uzlu Discover Library může být více konfiguračních souborů, v každém z nich lze nastavit pouze jednu konfigurační obrazovku Discover. Další obrazovka objevování musí být nakonfigurována v novém konfiguračním uzlu Knihovna.

Všechny konfigurační soubory z uzlu Objevování knihovny se načtou jedním voláním API.

Struktura konfigurace knihovny

Konfigurační struktura v knihovně

- hlavní uzel Knihovny
    - config
        - Objevte
            - **config**.json
    - typ
        - Discover.json
            - schema

Kde

• config je název partikulární konfigurace Discover, musí být typu json.

V knihovně vypadá cesta ke konfiguračnímu souboru takto:

/<main Library node>/config/Discover/<discoverConfig>.json

Cesta ke schématu bude vypadat následovně:

/<main Library node>/type/Discover.json.

Příklad výše popsané struktury knihovny pro případ více konfiguračních souborů Discover:

- logman
    - config
        - Discover
            - declarative.json
            - default.json
            - speed.json
    - type
        - Discover.json

DŮLEŽITÁ POZNÁMKA

Schéma (type) a konfigurační soubor (config) musí být nastaveny v knihovně, jinak se discover nenačte správně.

Všechny konfigurační soubory z uzlu Discover Library se načtou v jednom volání API.

Příklad konfigurace:

{
    "Discover:datasource": {
        "specifikace": "deklarativní*",
        "datetimeField": "@timestamp",
        "type": "elasticsearch"
    }
}

Kde

• klíč objektu slouží k pojmenování objektu. Musí být pojmenován jako Discover:datasource.
• type je typ vyhledávacího stroje.
• specification je url adresa se vzorem indexu ElasticSearch. Pokud chceme vyhledat všechna data, musí url končit hvězdičkou *. Jedná se o povinný parametr.
• datetimeField je index data položky. Je to povinný parametr, protože je potřebný pro vyhledávání/procházení pomocí ElasticSearch.

Schéma (volitelné nastavení)

Nezaměňujte se schématem Library schema.

Nastavení jména pro získání schématu z knihovny (pokud je přítomno), které se pak použije na hodnoty definované v rámci schématu. Pomocí schématu můžeme aplikovat akce na hodnoty odpovídající definovanému typu, např. pomocí komponenty ASAB-WebUI DateTime pro hodnoty času.

{
    ...

    "Discover:schema": {
        "name": "ECS"
    }

    ...
}

Příklad struktury schémat v knihovně:

- knihovna
    - Schémata
        - Discover.yaml
        - ECS.yaml
        ...

Příklad schématu v knihovně:

---

define:
  název: Elastic Common Schema
  typ: common/schema
  popis: https://www.elastic.co/guide/en/ecs/current/index.html

fields:
  '@timestamp':
    typ: datetime
    label: "Datetime"
    jednotka: sekundy
    docs: https://www.elastic.co/guide/en/ecs/current/ecs-base.html#field-timestamp

Autorizace (volitelné nastavení)

Konfigurace Discover může být omezena pro přístup pouze s konkrétním nájemcem (nájemci). To znamená, že uživatelé bez konkrétního(-ých) tenanta(-ů) nemají přístup ke konfiguraci Discover s jejím zdrojem dat. To je výhodné např. v případě, kdy chce správce omezit přístup ke konfiguraci discover s citlivými daty na určitou skupinu (skupiny) uživatelů.

Pokud se konfigurace nastavuje přímo v knihovně (a ne prostřednictvím nástroje Configuration), doporučuje se přidat sekci Authorization a klíč tenants ponechat jako prázdný řetězec (pokud není požadováno žádné omezení). To pomůže zachovat stejnou strukturu konfigurace napříč konfigurací Discover:

{
    ...

    "Authorization": {
        "tenants": ""
    }

    ...
}

Příklad nastavení Authorization v rámci konfigurace, kde je vyžadován omezený přístup:

{
    ...

    "Authorization": {
        "tenants": "tenant one, tenant two"
    }

    ...
}

Kde klíč tenants slouží k zobrazení a použití konfigurace pouze podle konkrétního nájemce (nájemců). Lze zadat více nájemců oddělených čárkou. Typ klíče tenants je string.

Nastavení #### Prompt (volitelné nastavení)

Sekce Prompt settings (Nastavení výzvy) poskytuje další možnost nastavení výzvy Discover nebo změny jejího výchozího nastavení.

Příklad sekce Discover:prompts v rámci konfigurace:

{
    ...

    "Discover:prompts": {
        "dateRangePicker:datetimeStart": "now-15m",
        "dateRangePicker:datetimeEnd": "now+15s"
        ...
    },

    ...
}

Nastavení vlastních časových úseků

Někdy je žádoucí nastavit vlastní datumové období pro zobrazování dat, protože data jsou položena např. mimo výchozí období nastavené pro Discover. Výchozí období je now-1H, které by mělo vyhledávat data v rámci now a 1 hodinu zpět. Například by to mohlo být nastaveno v Discover:prompts takto:

{
    ...

    "Discover:prompts": {
        "dateRangePicker:datetimeStart": "now-1H",
        "dateRangePicker:datetimeEnd": "now"
    },

    ...
}

Kde dateRangePicker:datetimeStart a dateRangePicker:datetimeEnd jsou období, která nastavují rozsah na počáteční období (počáteční) a na koncové období (konečné).

Možnosti nastavení pro obě období jsou:

• now-ns
• now-nm
• now-nH
• now-nd
• now-`n``w
• now-nM
• now-nY
• nyní
• now+ns
• now+nm
• now+nH
• now+nd
• now+`n``w
• now+nM
• now+nY

Kde - n je číslo, např. 2, - s označuje sekundy, - m označuje minuty, - H označuje hodiny, - d označuje dny, - w označuje týdny, - M označuje měsíce, - Y označují roky

Ostatní hodnoty budou ignorovány.

Je možné nastavit např. pouze jedno období jako v tomto příkladu, druhé období zůstane výchozí:

{
    ...

    "Discover:prompts": {
        "dateRangePicker:datetimeStart": "now-2H"
    },

    ...
}

Další příklad nastavení časového rozsahu, kde se data zobrazují 15 hodin do minulosti a hledají se 10 minut do budoucnosti:

{
    ...

    "Discover:prompts": {
        "dateRangePicker:datetimeStart": "now-15H",
        "dateRangePicker:datetimeEnd": "now+10m"
    },

    ...
}

Schéma knihovny

Pro ruční nastavení vyhledávací obrazovky v knihovně je třeba nastavit vyhledávací schéma v platném formátu JSON.

Schéma musí být zadáno a uloženo v /<main Library node>/type/<discoverType>.json.

Schéma může vypadat následovně:

{
    "$id": "Discover schema",
    "type": "object",
    "title": "Discover schema",
    "description": "Schéma Discover",
    "default": {},
    "examples": [
        {
            "Discover:datasource": {
                "specifikace": "deklarativní*",
                "datetimeField": "@timestamp",
                "type": "elasticsearch"
            }
        }
    ],
    "required": [],
    "properties": {
        "Discover:datasource": {
            "type": "string",
            "title": "Discover source",
            "description": "Specifikace dat pro obrazovku Discover",
            "default": {},
            "examples": [
                {
                    "specifikace": "deklarativní*",
                    "datetimeField": "@timestamp",
                    "type": "elasticsearch"
                }
            ],
            "required": [
                "specifikace",
                "datetimeField",
                "type"
            ],
            "properties": {
                "specifikace": {
                    "type": "string",
                    "title": "Specifikace",
                    "description": "Specifikujte zdroj dat",
                    "default": "",
                    "examples": [
                        "deklarativní*"
                    ]
                },
                "datetimeField": {
                    "type": "string",
                    "title": "Datetime",
                    "description": "Uveďte hodnotu datatime pro zdroj dat",
                    "default": "",
                    "examples": [
                        "@timestamp"
                    ]
                },
                "type": {
                    "type": "string",
                    "title": "Typ",
                    "description": "Vyberte typ zdroje",
                    "default": [
                        "elasticsearch",
                        "sentinel"
                    ],
                    "$defs": {
                        "select": {
                            "type": "select"
                        }
                    },
                    "examples": [
                        "elasticsearch*"
                    ]
                }
            }
        },
        "Discover:prompts": {
            "type": "string",
            "title": "Discover prompts",
            "description": "Aktualizace konfigurace výzvy Discover",
            "výchozí": {},
            "examples": [],
            "required": [],
            "properties": ["vlastnosti"]: {
                "dateRangePicker:datetimeStart": {
                    "type": "string",
                    "title": "Počáteční časový úsek data",
                    "description": "Nastavení časového období počátečního data výzvy",
                    "default": "now-1H",
                    "examples": [
                        "now-1H"
                    ]
                },
                "dateRangePicker:datetimeEnd": {
                    "type": "string",
                    "title": "Ending date time period",
                    "description": "Nastavení časového období koncového data výzvy",
                    "default": "now",
                    "examples": [
                        "now"
                    ]
                }
            }
        },
        "Discover:schema": {
            "type": "string",
            "title": "Discover schema name",
            "description": "Použít schéma nad hodnotami objevu",
            "default": {},
            "properties": {
                "name": {
                    "type": "string",
                    "title": "Název schématu",
                    "description": "Nastavte název schématu pro konfiguraci (bez přípony souboru)",
                    "default": ""
                }
            }
        },
        "Authorization": {
            "type": "string",
            "title": "Discover authorization",
            "description": "Omezit přístup ke konfiguraci zjišťování podle nastavení nájemce",
            "default": {},
            "examples": [],
            "required": [],
            "properties": ["vlastnosti"]: {
                "tenants": {
                    "type": "string",
                    "title": "Nájemci",
                    "description": "Zadejte nájemce (nájemce) oddělené čárkou pro omezení použití této konfigurace (nepovinné)",
                    "default": "",
                    "examples": [
                        "tenant1, tenant2"
                    ]
                }
            }
        }
    },
    "additionalProperties": false
}

Příklad předávání konfiguračních rekvizit

Příklad předání konfiguračních rekvizit do DiscoverContainer:

...

this.App.Router.addRoute({
    path: "/discover",
    exact: true,
    name: "Discover",
    component: DiscoverContainer,
    props: {
        type: "Discover":: "Discover"
    }
});

...

this.App.Navigation.addItem({
        name: "Discover",
        url: "/discover",
        icon: 'cil-compass'
    });

Používáte-li DiscoverContainer jako komponentu ve svém kontejneru, pak lze rekvizity předat následujícím způsobem:

<DiscoverContainer type="Discover" />

Konfigurační soubor statické aplikace zůstane prázdný:

module.exports = {
    app: {
    },
    webpackDevServer: {
        port: 3000,
        proxy: {
            '/api/elasticsearch': {
                cíl: "http://es-url:9200",
                pathRewrite: {'^/api/elasticsearch': ''}
            },
            '/api/asab_print': {
                target: "http://asab_print-url:8083",
                pathRewrite: {'^/api/asab_print': ''}
            },
            '/api/asab_config': {
                target: "http://asab_config-url:8082",
                pathRewrite: {'^/api/asab_config': ''}
            }
        }
    }
}

Statická konfigurace

Objevovací obrazovka nemusí být získána pouze z knihovny. Další možností je konfigurace přímo v souboru JSON a jeho uložení do složky projektů public.

Příklad statické konfigurace

V souboru index.js musí vývojář zadat:

Soubor JSON s konfigurací může být uložen kdekoli ve složce public, ale důrazně se doporučuje jej uložit do složky /public/discover/, aby se odlišil od ostatních veřejně přístupných komponent.

• Struktura konfigurace ve složce public

- public
    - objevit
        - Konfigurační soubor JSON
    - dashboards
    - locales
    - média
    - index.html
    - manifest.json

Adresa URL statického konfiguračního souboru uloženého ve složce public může vypadat takto:

https://my-project-url/discover/Discover-config.json

Příklad souboru Discover-config.json:

[
    {
        "Config name 1": {
            "Deklarativní": {
                "specifikace": "deklarativní*",
                "datetimeField": "last_inform",
                "type": "elasticsearch"
            }
        }
    },
    {
        "Název konfigurace 2": {
            "Default": {
                "specifikace": "default*",
                "datetimeField": "@timestamp",
                "type": "elasticsearch"
            }
        }
    }
]

Příklad předávání konfiguračních rekvizit

Předávání konfiguračních rekvizit do aplikace App:

this.App.Router.addRoute({
    path: "/discover",
    exact: true,
    name: "Discover",
    component: DiscoverContainer,
    props: {
        type: "https://my-project-url/discover/Discover-config.json"
    }
});

this.App.Navigation.addItem({
    name: "Discover",
    url: "/discover",
    icon: 'cil-compass'
});

Používáte-li DiscoverContainer jako komponentu ve svém kontejneru, pak lze rekvizity předat následujícím způsobem:

<DiscoverContainer type="https://my-project-url/discover/Discover-config.json" />

Konfigurační soubor statické aplikace zůstane prázdný:

module.exports = {
    app: {
    },
    webpackDevServer: {
        port: 3000,
        proxy: {
            '/api/elasticsearch': {
                cíl: "http://es-url:9200",
                pathRewrite: {'^/api/elasticsearch': ''}
            },
            '/api/asab_print': {
                target: "http://asab_print-url:8083",
                pathRewrite: {'^/api/asab_print': ''}
            },
            '/api/asab_config': {
                target: "http://asab_config-url:8082",
                pathRewrite: {'^/api/asab_config': ''}
            }
        }
    }
}

Jazykové lokalizace

Webové rozhraní LogMan.io umožňuje přizpůsobení jazykových lokalizací. Používá knihovnu i18n pro internalizaci. Podrobnosti naleznete na: https://react.i18next.com

Import a nastavení vlastní lokalizace

Webové rozhraní LogMan.io umožňuje předefinovat text komponent aplikace a zpráv pro každou sekci aplikace. Jazykové lokalizace jsou uloženy v souborech JSON s názvem translate.json.

Vlastní lokalizace lze do aplikace LogMan.io WebUI nahrát prostřednictvím konfiguračního souboru. Soubory se načítají např. z externí složky obsluhované nástrojem nginx, kam je lze uložit mezi CSS styly a další konfiguraci webu.

Příklad definice ve statickém konfiguračním souboru rozhraní LogMan.io WebUI:

module.exports = {
    app: {
        i18n: {
            fallbackLng: 'en',
            supportedLngs: ['en', 'cs'],
            debug: false,
            backend: {
                {% raw %}loadPath: 'path/to/external_folder/locales/{{lng}}/{{ns}}.json',{% endraw %}
                {% raw %}addPath: 'path/to/external_folder/locales/add/{{lng}}/{{ns}}',{% endraw %}
            }
        }
    }
}

Kde * fallbackLng je záložní jazyk * suportedLngs jsou podporované jazyky * debug, pokud je nastaveno na true, zobrazuje zprávy o ladění v konzoli prohlížeče * backend je backend plugin pro načítání zdrojů ze serveru

Path/to/external_folder/ je cesta k externí složce se složkou locales obsluhované pomocí nginx. Musí existovat 2 složky odkazující na podporované jazyky. Těmito složkami jsou en a cs, ve kterých jsou uloženy soubory translate.json, jak můžete vidět ve struktuře složek níže:

* external_folder
  * locales
    * cs
      * translation.json
    * cs
      * translation.json

Příklad vlastního souboru translate.json

en

{
    "i18n": {
        "language": {
            "cs": "English",
            "cs": "Česky"
        }
    },

    "LogConsole": {
        "Ztráta spojení": "Spojení ztraceno, bude obnoveno...",
        "Mark": "Mark",
        "Clear": "Vymazat"
    },

    ...
}

cs

{
    "i18n": {
        "language": {
            "cs": "English",
            "cs": "Česky"
        }
    },

    "LogConsole": {
        "Ztráta spojení": "Spojení ztraceno, připojuji se ...",
        "Mark": "Označit",
        "Clear": "Smazat"
    },

    ...
}

Dashboardy

Konfigurace ovládacího panelu a widgetů

Nastavení ovládacího panelu

Pro úpravu rozvržení nebo konfigurace dashboardu musí mít uživatel přiřazen prostředek dashboards:admin.

Nastavení ovládacího panelu z uživatelského rozhraní

TODO: zatím neimplementováno

Ruční nastavení ovládacího panelu z knihovny

Konfigurace knihovny

Konfigurace knihovny je uložena v uzlu Knihovna. Musí být pouze typu JSON.

Pro získání konfigurace z Library musí být spuštěna služba asab_library s konfigurací ukazující na hlavní uzel Library.

Konfiguraci z Library lze upravovat - pozici a velikost widgetů lze do Library uložit přímo z rozhraní BS-WebUI.

Nastavení ovládacího panelu s konfigurací Knihovny

• Konfigurační soubory panelů musí být uloženy v uzlu dashboard/Dashboards v Knihovně podle následujícího příkladu struktury.

• konfigurační soubor Knihovny (config), který definuje uzel Knihovny s konfigurací v uzlu Knihovny Dashboardy. Název config je zároveň názvem panelu Dashboard zobrazeného v postranním panelu aplikace. Jedná se o povinný parametr.

• DŮLEŽITÉ UPOZORNĚNÍ - konfigurační soubor MUSÍ mít příponu .json, jinak nebude možné zobrazit konfigurační soubor v modulu Knihovna, a tím spustit funkce jako Upravit nebo Zakázat.

Struktura konfigurace v knihovně

- hlavní uzel Knihovny (`library`)
    - Ovládací panely
        - **config**.json

Kde

• **hlavní uzel knihovny** obvykle by měl být pojmenován jako knihovna

• **config** je název konkrétní konfigurace Dashboardu, např. Můj Dashboard.json

V knihovně vypadá cesta ke konfiguračnímu souboru takto:

/<main Library node>/Dashboards/<dashboardConfig>.json

Podívejte se na konfiguraci dashboardu example.

Konfigurace ovládacího panelu

Zdroj dat

Slouží především k nastavení zdroje dat pro widgety. Datových zdrojů může být neomezený počet.

Příklad nastavení zdroje dat

{
    ...

     "Dashboard:datasource:elastic": {
        "type": "elasticsearch", // Zdroj dat
        "datetimeField": "@timestamp", // Typ datačasu
        "specification": "es-pattern*" // Vzor indexu nebo vzor URL
    },

    ...
}

Pokročilé nastavení Elasticsearch

{
    ...

     "Dashboard:datasource:elastic": {
        // Základní nastavení
        "type": "elasticsearch",
        "datetimeField": "@timestamp",
        "specification": "es-pattern*",


        // Pokročilé nastavení
        "sortData": "asc", // Seřadit data "asc" nebo "desc" během zpracování (nepovinné)


        // Pokročilé nastavení elasticsearch
        "size": 100, // Maximální velikost výsledků v odpovědi (výchozí 20) (nepovinné)
        "aggregateResult": true, // Pouze grafy (ne PieChart) - požádá ES o agregované hodnoty (nepovinné)
        "groupBy": "(nepovinné): // Pouze grafy - požádá ES o agregaci podle pojmu definovaného v klíči "groupBy" (nepovinné)
        "matchPhrase": "event.dataset: microsoft-office-365" // Pro výchozí zobrazení konkrétní shody zdroje dat
    },

    ...
}

Připojení datového zdroje k widgetu

Pokud není datový zdroj přiřazen k widgetu, nebudou pro zobrazení ve widgetu zpracována žádná data.

{
    ...

    "Dashboard:widget:somewidget": {
        "datasource": "Dashboard:datasource:elastic",

        ...
    },

    ...
}

Výzvy

Sekce Nastavení výzev poskytuje další možnost nastavení výzvy Dashboardu nebo změny jejího výchozího nastavení.

Použití v konfiguračním souboru:

{
    ...

    "Dashboard:prompts": {
        "dateRangePicker": true, // Povolit výzvu pro výběr rozsahu data
        "filterInput": true, // Povolit výzvu k zadání filtru
        "submitButton": true // Povolit výzvu k odeslání tlačítka
    },

    ...
}

Nastavení vlastních časových úseků

Někdy je žádoucí nastavit vlastní časové období pro zobrazování dat, protože data jsou položena např. mimo výchozí období nastavené pro Dashboard. Výchozí období je now-1H, které by mělo vyhledávat data v rámci now a 1 hodinu zpět. Například by to mohlo být nastaveno v Dashboard:prompts takto:

{
    ...

    "Dashboard:prompts": {
        ...

        "dateRangePicker": true,
        "dateRangePicker:datetimeStart": "now-1H",
        "dateRangePicker:datetimeEnd": "now",
        ...
    },

    ...
}

Kde dateRangePicker:datetimeStart a dateRangePicker:datetimeEnd jsou období, která nastavují rozsah na počáteční období (počáteční) a na koncové období (konečné).

Možnosti nastavení pro obě období jsou:

• now-ns
• now-nm
• now-nH
• now-nd
• now-`n``w
• now-nM
• now-nY
• nyní
• now+ns
• now+nm
• now+nH
• now+nd
• now+`n``w
• now+nM
• now+nY

Kde - n je číslo, např. 2, - s označuje sekundy, - m označuje minuty, - H označuje hodiny, - d označuje dny, - w označuje týdny, - M označují měsíce, - Y označují roky

Ostatní hodnoty budou ignorovány.

Je možné nastavit např. pouze jedno období jako v tomto příkladu, druhé období zůstane výchozí:

{
    ...

    "Dashobard:prompts": {
        ...

        "dateRangePicker": true,
        "dateRangePicker:datetimeStart": "now-1H",
        ...
    },

    ...
}

Další příklad nastavení časového rozsahu, kde se data zobrazují 15 hodin do minulosti a hledají se 10 minut do budoucnosti:

{
    ...

    "Dashboard:prompts": {
        ...

        "dateRangePicker": true,
        "dateRangePicker:datetimeStart": "now-15H",
        "dateRangePicker:datetimeEnd": "now+10m",
        ...
    },

    ...
}

<!-- One can specify their button title, color, path to the endpoint and formItems, which is an array of objects.

In formItems is possible to specify the type of input form (username, phone, email and password) and their titles and hint messages. On submit, filled information will be set as a JSON body of the POST request to the specified path of telco service.

widgets: [{
            component_id: "WidgetContainer",
            dataSource: "ES",
            type: "Value",
            title: "Title",
            ...
            actionButton: {
                title: 'Trigger', // Title of the button
                backgroundColor: 'primary', // Color of the button (only reactstrap and bootstrap colors, if wider range needed, configure it via external CSS)
                buttonOutline: true, // Set the outline of the button (default false)
                action:"/path/of/the/endpoint", // Url path of the endpoint (without protocol and host)
                formItems:[
                    {form:"username", title:"Username", hint: "Input username"},
                    {form:"phone", title:"Phone", hint: "Input phone"},
                    {form:"email", title:"Email", hint: "Input email"},
                    {form:"password", title:"Password", hint: "Input password"}
                ] // Forms to use in the popover
                }, // Add an aritrary button which will perform some action via triggering an endpoint defined in path
            ...
        }]
``` -->

### Mřížkový systém (volitelné nastavení)

Mřížku lze nakonfigurovat jedinečně pro různé ovládací panely. Konfiguraci mřížky lze tedy implementovat do konfigurace řídicího panelu, jak je vidět na příkladu. Pokud není v konfiguraci uveden, použije se výchozí nastavení Grid.

{ ...

"Dashboard:grid": {
    "preventCollision": false // Pokud je nastaveno na true, zabrání to kolizi widgetů na mřížce.
},
"Dashboard:grid:breakpoints": {
    "lg": 1200,
    "md": 996,
    "sm": 768,
    "xs": 480,
    "xxs": 0
},
"Dashboard:grid:cols": {
    "lg": 12,
    "md": 10,
    "sm": 6,
    "xs": 4,
    "xxs": 2
},

...

} ``` Výše uvedené nastavení je také výchozím nastavením ovládacího panelu.

Konfigurace autorizace / zakázání

Přístrojový panel lze omezit pro přístup pouze s určitým nájemcem (nájemci). To znamená, že uživatelé, kteří nemají přístup k určitému nájemci (nájemcům), nemají k přístrojovému panelu přístup. To je výhodné např. v případě, kdy chce správce omezit přístup k ovládacím panelům s citlivými údaji na určitou skupinu (skupiny) uživatelů. Chcete-li zakázat konfiguraci pro konkrétního tenanta, musíte sami přejít do sekce Knihovna aplikace a Zakázat konkrétní soubor kliknutím na přepínač v souboru. Název zakázaného souboru konkrétní konfigurace panelu se pak přidá do souboru .disabled.yaml s dotčeným(i) nájemcem(i) v uzlu Knihovna.

Zlidštit

Komponenta sloužící k převodu číselných hodnot do lidsky čitelné podoby. Převádí hodnoty do lidsky čitelné podoby, jako např: 0.000001 => 1 µ 0.00001 => 10 µ 0.0001 => 100 µ 0.001 => 1 m 0.01 => 10 m 0.1 => 100 m 1 => 1 10 => 10 100 => 100 1000 => 1 k 10000 => 10 k 100000 => 100 k 1000000 => 1 M atd. Lze jej použít pro widgety s hodnotou a více hodnotami. Chcete-li ve widgetu povolit komponentu Humanize, musíte nastavit hodnotu - "humanize": true v konfiguraci widgetu - "base": <number> definovat základnu pro přepočet, volitelný parametr, výchozí hodnota je 1000 - "decimální čísla": <number> definovat, kolik desetinných míst se má zobrazit, nepovinný parametr - "displayUnits": true zobrazí předponu (tj. µ, m, k, M, G) jednotek, nepovinný parametr, výchozí false - "units": <string> B, Hz, ...), parametr: zobrazit uživatelsky definovanou příponu jednotek (např. B, Hz, ...). displayUnits a units se ve widgetu dají dohromady a výsledek může vypadat jako MHz, kde M je předpona a Hz je uživatelem definovaná přípona. ``` { ...

"Dashboard:widget:valuewidget": {
    ...

    "humanize": true,
    "base": 1024,
    "decimální čísla": 3,
    "displayUnits": true,
    "units": "B",

    ...
},

...

} ```

Nápověda (volitelné nastavení)

Nápovědu lze přidat pro jakýkoli widget kromě widgetu Nástroje. Tímto způsobem bude nápověda vložena jako nápověda vedle názvu Widgetu. Po přidání nápovědy se v záhlaví Widgetu (vedle názvu) zobrazí informační ikona. Po najetí na ikonu se zobrazí vložená nápověda. Nápověda může být pouze typu řetězec. Příklad přidání nápovědy: ``` { ...

"Dashboard:widget:somewidget": {

    ...

    "hint": "Nějaká nápověda",

    ...
},

...

} ```

Rozložení widgetu

Velikost a pozici widgetu na mřížce lze definovat pro každý widget v konfiguraci. Pokud není nastaveno, má widget své předdefinované hodnoty pro rozvržení a pozici a bude podle toho vykreslen. Widgety lze v rámci mřížky přesouvat a měnit jejich velikost prostřednictvím Výzvy k nastavení panelu >> Upravit. Tato funkce je dostupná pro uživatele se zdrojem dashboards:admin. Příklad základního nastavení rozvržení: ``` { ...

"Dashboard:widget:somewidget": {

    ...

    // Základní nastavení
    "layout:w": 4, // Šířka widgetu v jednotkách mřížky
    "layout:h": 2, // Výška widgetu v jednotkách mřížky
    "layout:x": 0, // Poloha widgetu na ose x v jednotkách mřížky
    "layout:y": 0, // Poloha widgetu na ose y v jednotkách mřížky.


    // Vlastní nastavení (nepovinné)
    "layout:minW": 2, // Minimální šířka widgetu
    "layout:minH": 2, // Minimální výška widgetu
    "layout:maxW": 6, // Maximální šířka widgetu
    "layout:maxH": "lay": 6, // Maximální výška widgetu

    ...
},

...

} Příklad pokročilého nastavení rozvržení: { ...

"Dashboard:widget:somewidget": {

    ...

    // Pokročilé nastavení (volitelné)
    "layout:isBounded": false, // Pokud je to pravda a lze přetahovat, bude se položka přesouvat pouze v rámci mřížky
    "layout:resizeHandles": ?Array<'s' | 'w' | 'e' | 'n' | 'sw' | 'nw' | 'se' | 'ne'> = ['se'], // Ve výchozím nastavení se úchyt zobrazí pouze v pravém dolním (jihovýchodním) rohu.
    "layout:static": ?boolean = false, // Upevněte widget na statickou pozici (nelze jej přesouvat ani měnit jeho velikost). Pokud je true, rovná se `isDraggable: false, isResizable: false`.
    "layout:isDraggable": ?boolean = true, // Pokud false, nebude draggable. Přepisuje `static`
    "layout:isResizable": ?boolean = true, // Pokud false, nebude možné měnit velikost. Přepíše `static`

    ...
},

...

} ```

Widgety

Příklad widgetu v konfiguračním souboru: ``` { ...

"Dashboard:widget:somewidget": {
    "datasource": "Dashboard:datasource:elastic",
    "type": "Value",
    "field": "some.variable",
    "title": "Some title",
    "layout:w": 2,
    "layout:h": 1,
    "layout:x": 0,
    "layout:y": 1
},

...

} ```

Widget Value

Běžně se používá k zobrazení jedné hodnoty, může však také zobrazit datum a filtrovanou hodnotu widgetu najednou. ``` { ...

"Dashboard:widget:valuewidget": {
    // Základní nastavení
    "datasource": "Dashboard:datasource:elastic",
    "type": "Value", // Typ widgetu
    "field": "some.variable", // Pole (hodnota) zobrazené ve widgetu
    "title": "Some title", // Název widgetu


    // Rozšířené nastavení (nepovinné)
    "onlyDateResult": true, // Zobrazí pouze datum s časem
    "units": "GB", // Jednotky hodnoty pole
    "displayWidgetDateTime": true, // Zobrazení data a času ve widgetu pod hodnotou
    "hint": "Some hint", // Zobrazení nápovědy widgetu


    // Zlidštění hodnoty (lze použít pro převod hodnot do lidsky čitelné podoby, např. bajty na GB) (nepovinné)
    "humanize": true, // Povolit komponentu Humanize
    "base": 1024, // Základ pro přepočet hodnoty pro komponentu Humanize
    "decimals": 3, // Zaokrouhlení hodnoty na n číslic v komponentě Humanize
    "displayUnits": true, // Zobrazení předpony velikosti jednotky (jako k, M, T,...) v komponentě Humanize


    // Nastavení rozložení
    "layout:w": 2,
    "layout:h": 1,
    "layout:x": 0,
    "layout:y": 1
},

...

} ```

Widget s více hodnotami

Slouží k zobrazení více hodnot v jednom widgetu ``` { ...

"Dashboard:widget:mutliplevaluewidget": {
    // Základní nastavení
    "datasource": "Dashboard:datasource:elastic",
    "type": "MultipleValue", // Typ widgetu
    "field:1": "some.variable1", // Pole (hodnoty) zobrazené ve widgetu
    "field:2": "some.variable2", // Počet polí je neomezený.
    "field:3": "date.time",
    "title": "some title", // Název widgetu


    // Rozšířené nastavení (nepovinné)
    "units": "GB", // Jednotky hodnoty pole
    "displayWidgetDateTime": true, // Zobrazení data a času ve widgetu pod hodnotou
    "hint": "Some hint", // Zobrazení nápovědy widgetu


    // Zlidštění hodnoty (lze použít pro převod hodnot do lidsky čitelné podoby, např. bajty na GB) (nepovinné)
    "humanize": true, // Povolit komponentu Humanize
    "base": 1024, // Základ pro přepočet hodnoty pro komponentu Humanize
    "decimals": 3, // Zaokrouhlení hodnoty na n číslic v komponentě Humanize
    "displayUnits": true, // Zobrazení předpony velikosti jednotky (jako k, M, T,...) v komponentě Humanize


    // Nastavení rozložení
    "layout:w": 2,
    "layout:h": 1,
    "layout:x": 0,
    "layout:y": 1
},

...

} ```

Widget indikátoru stavu

Slouží k zobrazení hodnoty a barvy stavu na základě překročení / nepřekročení mezních hodnot. Jeho jádro je podobné widgetu Hodnota. Existují 2 typy nastavení - jeden je určen pro zobrazení barev na základě číselného rozsahu, druhý je založen na zobrazení hodnot na základě řetězce. Rozsah čísel ``` { ...

"Dashboard:widget:indicatorwidget": {
    // Základní nastavení
    "datasource": "Dashboard:datasource:elastic",
    "type": "StatusIndicator", // Typ widgetu
    "field": "some.variable", // Pole (hodnota) zobrazené ve widgetu
    "title": "Some title", // Název widgetu
    "lowerBound": 4000, // Dolní mezní hranice
    "upperBound": 5000, // Horní mezní hranice


    // Rozšířené nastavení (nepovinné)
    "lowerBoundColor": "#a9f75f", // Dolní mezní barva
    "betweenBoundColor": "#ffc433", // Midst bound color (střední barva)
    "upperBoundColor": "#C70039 ", // barva horní hranice
    "nodataBoundColor": "#cfcfcf", // Barva bez údajů
    "units": "GB", // Jednotky hodnoty pole
    "displayWidgetDateTime": true, // Zobrazení času data ve widgetu pod hodnotou
    "hint": "Some hint", // Zobrazení nápovědy widgetu


    // Nastavení rozvržení
    "layout:w": 2,
    "layout:h": 1,
    "layout:x": 0,
    "layout:y": 1
},

...

} Widget #### Table Slouží k zobrazení více hodnot ve formě tabulky. { ...

"Dashboard:widget:tablewidget": {
    // Základní nastavení
    "datasource": "Dashboard:datasource:elastic",
    "type": "Table", // Typ widgetu
    "field:1": "@timestamp", // Pole (hodnoty) zobrazené ve widgetu
    "field:2": "event.dataset", // Počet polí je neomezený.
    "field:3": "host.hostname", // Pole také označuje položky zobrazené v záhlaví tabulky
    "title": "Some title", // Název widgetu


    // Rozšířené nastavení (nepovinné)
    "dataPerPage": 5, // Počet dat na stránku
    "disablePagination": true, // Zakázat stránkování
    "units": "GB", // Jednotky hodnoty pole
    "hint": "Some hint", // Zobrazení nápovědy widgetu


    // Nastavení rozvržení
    "layout:w": 3,
    "layout:h": 3,
    "layout:x": 0,
    "layout:y": 1
},

...

} Widget #### Tools Je podobný modulu Nástroje rozhraní ASAB WebUI, ale je transformován do widgetu pro použití na ovládacím panelu. { ...

"Dashboard:widget:toolswidget": {
    // Základní nastavení
    "type": "Tools", // Typ widgetu
    "title": "BitSwan", // Název widgetu
    "redirectUrl": "http://www.teskalabs.com", // Adresa URL přesměrování
    "image": "tools/bitswan.svg", // Umístění obrázku Tools (místo cesty k umístění může být uveden i řetězec base64 obrázku).


    // Nastavení rozvržení
    "layout:w": 1,
    "layout:h": 1,
    "layout:x": 0,
    "layout:y": 0
},

...

} ```

Widget Markdown

Běžně se používá k úpravě a zobrazení psaného popisu ve formátu Markdown. Tento widget umožňuje uživateli upravit a uložit popis např. konkrétního panelu pro širší vysvětlení. Pro editaci je třeba mít k dispozici alespoň zdroj dashboards:admin. ``` { ...

"Dashboard:widget:mdwidget": {
    // Základní nastavení
    "type": "Markdown", // Typ widgetu
    "title": "Some title", // Název widgetu

    // Rozšířené nastavení (nepovinné)
    "description": "Some description", // Zobrazení popisu v markdown
    "hint": "Some hint", // Zobrazení nápovědy widgetu


    // Nastavení rozvržení
    "layout:w": 2,
    "layout:h": 1,
    "layout:x": 0,
    "layout:y": 1
},

...

} ```

Widgety grafu

Slouží k zobrazení hodnot ve formuláři grafu. Další informace o použité knihovně grafů naleznete na tomto odkazu

Přesměrování na obrazovku Discover

Widgety PieChart a BarChart nabízejí ve výchozím nastavení možnost přesměrování na obrazovku Discover. Tato funkce filtruje vybrané hodnoty v grafu a přesměruje na obrazovku Objevit. Je k dispozici pouze pro seskupená data (nastavení groupBy v nastavení datového zdroje). Lze ji vypnout nastavením "disableRedirection": true ve widgetu. Pokud je v nástroji Discover použito více konfigurací, lze ve widgetu zadat název konfigurace, který bude použit v přesměrování pro filtrování na správnou konfiguraci. Pokud se v jedné aplikaci Discover používá více konfigurací, doporučuje se zadat názvy konfigurací v rámci widgetů, aby se zabránilo přesměrování na nesprávné konfigurace a datové zdroje v aplikaci Discover. To lze nastavit pomocí rekvizity widgetu "configName": "<discover-config-name>" >>> kde <discover-config-name> je název konfiguračního souboru Discover bez přípony, např. some-config.json >>> "configName": "some-config". Poznámka: Přesměrování odstraní všechny dříve filtrované položky a upraví časový rozsah data uloženého v místním úložišti pro obrazovku Discover podle vybraného v grafu Dashboard.

Barvy widgetu grafu

Všechny grafy nabízí možnost zobrazení s jedním z předdefinovaných barevných schémat. Barevné spektrum se liší podle typu grafu. Pokud není zadána žádná barva nebo je zadána špatná barva, použije se výchozí barevné spektrum. Barva je určena proměnnou color v nastavení widgetu: "Dashboard:widget:barchartwidget": { "datasource": "Dashboard:datasource:elastic", "type": "BarChart", "title": "Some title", ... "color": "západ slunce", ... }, - PieChart - pro gradientní barevná spektra - západ slunce, druhý, bezpečný, výstraha, nebezpečí, přednastaveno - pro smíšená barevná spektra - cold, rainbow, default - BarChart a další - jednobarevná spektra - západ slunce, bezpečí, výstraha, nebezpečí, předvolené

Widget BarChart

``` { ...

"Dashboard:widget:barchartwidget": {
    // Základní nastavení
    "datasource": "Dashboard:datasource:elastic",
    "type": "BarChart", // Typ widgetu
    "title": "Some title", // Název widgetu
    "xaxis": "@timestamp", // Hodnoty zobrazené na ose x
    "yaxis": "request.bytes", // Hodnoty zobrazené na ose y

    // Rozšířené nastavení (volitelné)
    "table": true, // Umožňuje zobrazit tabulku místo grafu (po kliknutí na tlačítko).
    "xlabel": "timestamp", // popisek osy x, výchozí je datetime
    "ylabel": "bytes", // označení osy y
    "xaxisUnit": "ts", // jednotky osy x
    "yaxisUnit": "byte", // jednotky osy y
    "xaxisDomain": ["auto", "auto"], // Rozsah pro zobrazení na ose x (výchozí [0, "auto"])
    "yaxisDomain": ["auto", "auto"], // Rozsah pro zobrazení na ose y (výchozí [0, "auto"])
    "horizontal": true, // Umožňuje zobrazit graf vodorovně.
    "width": "50%", // Šířka grafu ve widgetu
    "height": "50%", // Výška grafu ve widgetu
    "convertBy": // Hodnoty grafu budou vyděleny tímto číslem. Slouží k účelu a potřebě převodu dat např. na MHz, GB atd.
    "hint": "Some hint", // Zobrazení nápovědy widgetu
    "disableRedirection": true, // Zakáže přesměrování na obrazovku Discover (pouze pro BarChart).
    "configName": "config-name", // Název konkrétní konfigurace Discover (pouze pro BarChart)
    "color": "safe", // Specifikace barvy widgetu


    // Nastavení rozvržení
    "layout:w": 6,
    "layout:h": 3,
    "layout:x": 0,
    "layout:y": 0
},

...

} Chcete-li v grafu zobrazit agregaci, musíte ji nastavit v nastavení zdroje dat: { ...

 "Dashboard:datasource:elastic": {
    // Základní nastavení
    "type": "elasticsearch",
    "datetimeField": "@timestamp",
    "specification": "es-pattern*",
    "aggregateResult": true // Pouze grafy - požádá ES o agregované hodnoty (nepovinné).
},

...

} ```

Widget ScatterChart

Nastavení tohoto widgetu je stejné jako u widgetu BarChart. ``` { ...

"Dashboard:widget:scatterchartwidget": {
    // Základní nastavení
    ...
    "type": "ScatterChart", // Typ widgetu
    ...
},

...

} ```

Widget AreaChart

Nastavení tohoto widgetu je stejné jako u widgetu BarChart. ``` { ...

"Dashboard:widget:areachartwidget": {
    // Základní nastavení
    ...
    "type": "AreaChart", // Typ widgetu
    ...
},

...

}

##### Widget LineChart

Nastavení tohoto widgetu je stejné jako u widgetu BarChart.

{ ...

"Dashboard:widget:linechartwidget": {
    // Základní nastavení
    ...
    "type": "LineChart", // Typ widgetu
    ...
},

...

}

##### Widget Stacked BarChart

**Seskupený graf**

Konfigurace zdroje dat:

{ ...

"Dashboard:datasource:elastic-stacked": {
    // Základní nastavení
    "type": "elasticsearch",
    "datetimeField": "@timestamp",
    "specification": "pattern*",
    "groupBy": [
        "sender.address",
        "recipient.address"
    ],
    "size": // Definujte maximální velikost skupiny (výchozí hodnota je 20).
    "stackSize": 100 // Definujte maximální velikost stohovaných událostí (výchozí je top 50).

    // Pokročilé nastavení
    "matchPhrase": Pro výchozí zobrazení konkrétní shody datového zdroje: "event.dataset: microsoft-office-365" // Pro výchozí zobrazení konkrétní shody datového zdroje
},
...

} Konfigurace grafu: { ...

"Dashboard:widget:stackedbarchartwidget": {
    "datasource": "Dashboard:datasource:elastic-stacked",
    "title": "Some stacked barchart title" (Nějaký název stohovaného barchartu),
    "type": "StackedBarChart",

    // Pokročilé nastavení (nepovinné)
    "table": true, // Umožňuje zobrazit tabulku místo grafu (po kliknutí na tlačítko).
    "xlabel": "Odesílatel x příjemce", // popisek osy x, výchozí je datum
    "ylabel": "Count", // označení osy y
},
...

} **Agregovaný graf na časové škále** Konfigurace datového zdroje: { ...

"Dashboard:datasource:elastic-aggregation-stacked": {
    // Základní nastavení
    "type": "elasticsearch",
    "datetimeField": "@timestamp",
    "specification": "pattern*",
    "aggregateResult": true, // Nastavte agregaci na true
    "groupBy": "o365.audit.Workload", // Hodnota pro seskupení podle
    "aggregateEvents": [
        "device.properties.OS",
        "organization.id"
    ], // Další události pro agregaci (nepovinné, ale doporučené)
    "size": 100 // Definujte maximální velikost skupiny (výchozí je top 20).

    // Pokročilé nastavení
    "matchPhrase": Pro výchozí zobrazení konkrétní shody datového zdroje: "event.dataset: microsoft-office-365" // Pro výchozí zobrazení konkrétní shody datového zdroje
},
...

} Konfigurace grafu: { ...

"Dashboard:widget:stackedbarchartwidget": {
    "datasource": "Dashboard:datasource:elastic-aggregation-stacked",
    "title": "Some stacked barchart title" (Nějaký název stohovaného barchartu),
    "type": "StackedBarChart",

    // Pokročilé nastavení (nepovinné)
    "table": true, // Umožňuje zobrazit tabulku místo grafu (po kliknutí na tlačítko).
    "xlabel": "Odesílatel x příjemce", // popisek osy x, výchozí je datum
    "ylabel": "Count", // označení osy y
},
...

} ```

Widget PieChart

Pro zobrazení hodnot v grafu je třeba v nastavení zdroje dat nastavit groupBy. groupBy požádá ES o agregaci podle termínu definovaného v klíči "groupBy": ``` { ...

 "Dashboard:datasource:elastic-groupby": {
    // Základní nastavení
    "type": "elasticsearch",
    "datetimeField": "@timestamp",
    "specification": "es-pattern*",
    "groupBy": "user.id",
    "size": 100, // Definujte maximální velikost skupiny (výchozí je top 20).

    // Pokročilé nastavení
    "matchPhrase": Pro výchozí zobrazení konkrétní shody datového zdroje: "event.dataset: microsoft-office-365" // Pro výchozí zobrazení konkrétní shody datového zdroje
},

...

}

{ ...

"Dashboard:widget:piechartwidget": {

    // Základní nastavení
    "datasource": "Dashboard:datasource:elastic-groupby",
    "type": "PieChart", // Typ widgetu
    "title": "Some title", // Název widgetu

    // Rozšířené nastavení (nepovinné)
    "table": true, // Umožňuje zobrazit tabulku místo grafu (po kliknutí na tlačítko).
    "tooltip": true, // Ve widgetu se zobrazí buď nápověda k nástroji, nebo text (ve výchozím nastavení). Alternativně lze nastavit `tooltip: "both"`, aby se zobrazily obě možnosti.
    "useGradientColors": true, // PieChart použije přednastavené gradientní barvy - ve výchozím nastavení je nastaveno na false
    "displayUnassigned": true, // Zobrazí nepřiřazené hodnoty (prázdné řetězcové klíče nebo klíče s pomlčkou) v rámci PieChart - ve výchozím nastavení nastaveno na false
    "field": "timestamp", // Pole pro zobrazení hodnot v Piechart (pokud není groupBy definováno v datovém zdroji).
    "width": "50%", // Šířka grafu ve widgetu
    "height": "50%", // Výška grafu ve widgetu
    "hint": "Some hint", // Zobrazení nápovědy widgetu
    "disableRedirection": true, // Zakázat přesměrování na obrazovku Discover
    "configName": "config-name", // Název konkrétní konfigurace Discover,
    "color": "safe", // Specifikace barvy widgetu - spektrum a názvy se mohou lišit, pokud jsou použity gradientní barvy.

    // Nastavení rozvržení
    "layout:w": 6,
    "layout:h": 3,
    "layout:x": 0,
    "layout:y": 0
},

...

}

#### Widgety vývojového diagramu

Slouží k zobrazení vývojových diagramů ve formátu svg.

##### Widget FlowChart

Widget Flowchart je založen na vývojových diagramech mermaid.js. Více informací najdete na tomto [odkazu](https://mermaid-js.github.io){:target="_blank"}.

{ ...

"Dashboard:widget:flowchart": {
    // Základní nastavení
    "type": "FlowChart", // Typ widgetu
    "title": "Gantt chart", // Název widgetu
    "content": "gantt\ntitle Ganttův diagram\ndateFormat YYYY-MM-DD\nsection Section\nA task:a1, 2014-01-01, 30d\nAnother task:after a1,20d\nsection Another\nTask in sec:2014-01-12,12d\nanother task: 24d", // Obsah vývojového diagramu

    // Rozšířené nastavení (nepovinné)
    "hint": "Some hint", // Zobrazení nápovědy widgetu

    // Nastavení rozvržení
    "layout:w": 6,
    "layout:h": 3,
    "layout:x": 0,
    "layout:y": 0
},

...

} **Obsah vývojového diagramu** Obsah vývojového diagramu musí být typu řetězec. Jelikož je součástí JSON, musí být nové řádky **odděleny znakem `\n`. <!-- TODO: remove this comment when obtaining of the flowchart from URL or API will be implemented --> V příštích iteracích se plánuje implementace získávání obsahu vývojového diagramu z rozhraní API nebo adresy URL. Příklad převodu řetězcového vývojového diagramu mermomocí tak, aby byl kompatibilní s nastavením JSON v knihovně **Původní řetězec:** gantt název Ganttův diagram dateFormat RRRR-MM-DD section Sekce A task :a1, 2014-01-01, 30d Další úkol :po a1 , 20d sekce Jiný Úkol v sekci :2014-01-12 , 12d Další úkol : 24d **Změněný řetězec** gantt\ntitle Ganttův diagram\ndateFormat RRRR-MM-DD\oddíl Sekce\nÚkol:a1, 2014-01-01, 30d\nDalší úkol:po a1,20d\oddíl Další\nÚkol v sekci:2014-01-12,12d\další úkol: 24d ```

Příklad konfigurace ovládacího panelu

Příklad:

{
    "Dashboard:datasource:elastic": {
        "type": "elasticsearch",
        "datetimeField": "@timestamp",
        "specifikace": "default-events*"
    },
    "Dashboard:datasource:elastic-aggregation": {
        "type": "elasticsearch",
        "datetimeField": "@timestamp",
        "specifikace": "default-events*",
        "aggregateResult": true
    },
    "Dashboard:datasource:elastic-size100": {
        "type": "elasticsearch",
        "datetimeField": "@timestamp",
        "specifikace": "default-events*",
        "size": 100
    },
    "Dashboard:datasource:elastic-stacked": {
        "type": "elasticsearch",
        "datetimeField": "@timestamp",
        "specifikace": "default-events*",
        "groupBy": [
            "sender.address",
            "recipient.address"
        ],
        "matchPhrase": "event.dataset:microsoft-office-365",
        "size": 50,
        "stackSize": 100
    },
    "Dashboard:grid": {
        "preventCollision": false
    },
    "Dashboard:grid:breakpoints": {
        "lg": 1200,
        "md": 996,
        "sm": 768,
        "xs": 480,
        "xxs": 0
    },
    "Dashboard:grid:cols": {
        "lg": 12,
        "md": 10,
        "sm": 6,
        "xs": 4,
        "xxs": 2
    },
    "Dashboard:prompts": {
        "dateRangePicker": true,
        "dateRangePicker:datetimeStart": "now-15H",
        "dateRangePicker:datetimeEnd": "now+10s",
        "filterInput": true,
        "submitButton": true
    },
    "Dashboard:widget:table": {
        "datasource": "Dashboard:datasource:elastic-size100",
        "field:1": "@timestamp",
        "field:2": "event.dataset",
        "field:3": "host.hostname",
        "title": "Table": "Table",
        "type": "Table",
        "layout:w": 6,
        "layout:h": 4,
        "layout:x": 0,
        "layout:y": 9,
        "layout:minW": 2,
        "layout:minH": 3
    },
    "Dashboard:widget:hostname": {
        "datasource": "Dashboard:datasource:elastic",
        "field": "host.hostname",
        "title": "Hostname",
        "type": "Value",
        "layout:w": 2,
        "layout:h": 1,
        "layout:x": 10,
        "layout:y": 12
    },
    "Dashboard:widget:lastboot": {
        "datasource": "Dashboard:datasource:elastic",
        "field": "@timestamp",
        "units": "ts",
        "title": "Last boot",
        "type": "Value",
        "layout:w": 2,
        "layout:h": 1,
        "layout:x": 8,
        "layout:y": 12,
        "layout:minH": 1
    },
    "Dashboard:widget:justdate": {
        "datasource": "Dashboard:datasource:elastic",
        "field": "@timestamp",
        "onlyDateResult": true,
        "title": "Just date",
        "type": "Value",
        "layout:w": 4,
        "layout:h": 2,
        "layout:x": 8,
        "layout:y": 9
    },
    "Dashboard:widget:displaytenant": {
        "datasource": "Dashboard:datasource:elastic",
        "field": "tenant",
        "title": "Tenant",
        "type": "Value",
        "layout:w": 2,
        "layout:h": 2,
        "layout:x": 6,
        "layout:y": 9
    },
    "Dashboard:widget:baraggregationchart": {
        "datasource": "Dashboard:datasource:elastic-aggregation",
        "title": "Request body bytes aggregation",
        "type": "BarChart",
        "xaxis": "@timestamp",
        "yaxis": "http.request.body.bytes",
        "yaxisDomain": [
            "auto",
            0
        ],
        "ylabel": "bytes",
        "layout:w": 6,
        "layout:h": 3,
        "layout:x": 0,
        "layout:y": 6,
        "layout:minW": 4,
        "layout:minH": 3,
        "layout:isBounded": true
    },
    "Dashboard:widget:barchart": {
        "datasource": "Dashboard:datasource:elastic",
        "title": "Request body bytes",
        "type": "BarChart",
        "hint": "Some hint",
        "width": "95%",
        "xaxis": "@timestamp",
        "yaxis": "http.request.body.bytes",
        "ylabel": "bytes",
        "layout:w": 6,
        "layout:h": 3,
        "layout:x": 6,
        "layout:y": 6
    },
    "Dashboard:widget:scatterchart": {
        "datasource": "Dashboard:datasource:elastic-size100",
        "title": "Request body bytes scatter size 100",
        "type": "ScatterChart",
        "xaxis": "@timestamp",
        "xlabel": "datetime",
        "yaxis": "http.request.body.bytes",
        "ylabel": "http.request.body.bytes",
        "layout:w": 6,
        "layout:h": 3,
        "layout:x": 6,
        "layout:y": 0,
        "layout:minH": 2,
        "layout:maxH": 6
    },
    "Dashboard:widget:scatteraggregationchart": {
        "datasource": "Dashboard:datasource:elastic-aggregation",
        "title": "Request body bytes scatter aggregation",
        "type": "ScatterChart",
        "xaxis": "@timestamp",
        "yaxis": "http.request.body.bytes",
        "xlabel": "datetime",
        "ylabel": "count",
        "layout:w": 6,
        "layout:h": 3,
        "layout:x": 0,
        "layout:y": 0
    },
    "Dashboard:widget:areachart": {
        "datasource": "Dashboard:datasource:elastic",
        "height": "100%",
        "title": "Request body bytes area",
        "type": "AreaChart",
        "width": "95%",
        "xaxis": "@timestamp",
        "yaxis": "http.request.body.bytes",
        "ylabel": "area bytes",
        "layout:w": 6,
        "layout:h": 3,
        "layout:x": 6,
        "layout:y": 3,
        "layout:minH": 2,
        "layout:maxH": 6,
        "layout:resizeHandles": [
            "sw"
        ]
    },
    "Dashboard:widget:areaaggregationchart": {
        "datasource": "Dashboard:datasource:elastic-aggregation",
        "title": "Request body bytes area aggregation",
        "type": "AreaChart",
        "xaxis": "@timestamp",
        "xlabel": "datetime",
        "yaxis": "http.request.body.bytes",
        "ylabel": "count",
        "layout:w": 6,
        "layout:h": 3,
        "layout:x": 0,
        "layout:y": 3
    },
    "Dashboard:widget:multiplevalwidget": {
        "datasource": "Dashboard:datasource:elastic",
        "type": "MultipleValue",
        "title": "Multiple values",
        "field:1": "event.dataset",
        "field:2": "http.response.status_code",
        "field:3": "url.orignal",
        "layout:w": 2,
        "layout:h": 2,
        "layout:x": 6,
        "layout:y": 11
    },
    "Dashboard:widget:statusindicatorwidget": {
        "datasource": "Dashboard:datasource:elastic",
        "type": "StatusIndicator",
        "title": "Bytes exceedance",
        "field": "http.request.body.bytes",
        "units": "bytes",
        "lowerBound": 20000,
        "upperBound": 40000,
        "lowerBoundColor": "#a9f75f",
        "betweenBoundColor": "#ffc433",
        "upperBoundColor": "#C70039 ",
        "nodataBoundColor": "#cfcfcf",
        "layout:w": 2,
        "layout:h": 1,
        "layout:x": 10,
        "layout:y": 11
    },
    "Dashboard:widget:toolswidget": {
        "type": "Tools",
        "title": "Grafana",
        "redirectUrl": "http://www.grafana.com",
        "image": "tools/grafana.svg",
        "layout:w": 2,
        "layout:h": 1,
        "layout:x": 8,
        "layout:y": 11
    },
    "Dashboard:widget:flowchart": {
        "title": "Ganttův diagram",
        "type": "FlowChart",
        "content": "gantt\název Ganttův diagram\datový formát RRRR-MM-DD\oddíl Sekce\nÚkol:a1, 2014-01-01, 30d\nDalší úkol:po a1,20d\oddíl Další\nÚkol v sekci:2014-01-12,12d\další úkol: 24d",
        "layout:w": 12,
        "layout:h": 2,
        "layout:x": 0,
        "layout:y": 13
    },
    "Dashboard:widget:markdown": {
        "title": "Markdown description",
        "type": "Markdown",
        "description": "## Markdown content",
        "layout:w": 12,
        "layout:h": 2,
        "layout:x": 0,
        "layout:y": 15
    },
    "Dashboard:widget:barchart-stacked": {
        "datasource": "Dashboard:datasource:elastic-stacked",
        "title": "Seskupená adresa odesílatele X příjemce",
        "type": "StackedBarChart",
        "xlabel": "Odesílatel x příjemce",
        "ylabel": "Count",
        "layout:w": 12,
        "layout:h": 4,
        "layout:x": 0,
        "layout:y": 17
    }
}

Přístrojový panel Office 365

Příklad:

{
    "Dashboard:prompts": {
        "dateRangePicker": true,
        "filterInput": true,
        "submitButton": true
    },
    "Dashboard:datasource:elastic-office365-userid": {
        "datetimeField": "@timestamp",
        "groupBy": "user.id",
        "matchPhrase": "event.dataset:microsoft-office-365",
        "specification": "lmio-default-events*",
        "type": "elasticsearch",
        "size": 100
    },
    "Dashboard:datasource:elastic-office365-clientip": {
        "datetimeField": "@timestamp",
        "groupBy": "client.ip",
        "matchPhrase": "event.dataset:microsoft-office-365",
        "specification": "lmio-default-events*",
        "type": "elasticsearch",
        "size": 100
    },
    "Dashboard:datasource:elastic-office365-activity": {
        "datetimeField": "@timestamp",
        "groupBy": "o365.audit.Workload",
        "matchPhrase": "event.dataset:microsoft-office-365",
        "specification": "lmio-default-events*",
        "type": "elasticsearch",
        "size": 100
    },
    "Dashboard:datasource:elastic-office365-actions": {
        "datetimeField": "@timestamp",
        "groupBy": "event.action",
        "matchPhrase": "event.dataset:microsoft-office-365",
        "specification": "lmio-default-events*",
        "type": "elasticsearch",
        "size": 50
    },
    "Dashboard:widget:piechart": {
        "datasource": "Dashboard:datasource:elastic-office365-clientip",
        "title": "Client IP",
        "type": "PieChart",
        "table": true,
        "layout:w": 6,
        "layout:h": 4,
        "layout:x": 6,
        "layout:y": 0
    },
    "Dashboard:widget:piechart2": {
        "datasource": "Dashboard:datasource:elastic-office365-userid",
        "title": "ID uživatele",
        "type": "PieChart",
        "useGradientColors": true,
        "table": true,
        "tooltip": true,
        "layout:w": 6,
        "layout:h": 4,
        "layout:x": 0,
        "layout:y": 0
    },
    "Dashboard:widget:piechart3": {
        "datasource": "Dashboard:datasource:elastic-office365-activity",
        "title": "Aktivita podle aplikací",
        "type": "PieChart",
        "table": true,
        "tooltip": true,
        "layout:w": 6,
        "layout:h": 4,
        "layout:x": 6,
        "layout:y": 4
    },
    "Dashboard:widget:barchart": {
        "datasource": "Dashboard:datasource:elastic-office365-actions",
        "title": "Actions",
        "type": "BarChart",
        "table": true,
        "xaxis": "event.action",
        "xlabel": "Actions",
        "ylabel": "Count",
        "layout:w": 6,
        "layout:h": 4,
        "layout:x": 0,
        "layout:y": 4
    }
}

Katalog widgetů

Bližší pohled na nastavení widgetu.

Nastavení ovládacího panelu a widgetu naleznete zde.

Hodnotové widgety

Hodnotové widgety se používají, pokud je třeba zobrazit data v textové podobě.

Widget s jednou hodnotou

Slouží k zobrazení pouze jedné hodnoty.

Hodnota může být typu: string, boolean, number.

Single value může v případě potřeby zobrazovat pouze datum (převést např. unixové časové razítko na lidsky čitelné datum).

Widget s více hodnotami

Slouží k zobrazení n hodnot v jednom widgetu.

Kromě zobrazení n hodnot v jednom widgetu má widget více hodnot stejné funkce jako widget jedné hodnoty.

Hodnoty mohou být typu: string, boolean, number.

Widget stavového indikátoru

Widget indikátoru stavu zobrazuje číselnou hodnotu a barevnou indikaci na základě definovaných hranic.

Hodnota může být typu: číslo.

Widget tabulky

Widget tabulky může zobrazovat více hodnot ve formě tabulky.

Hodnoty mohou být typu: string, boolean, number.

Widgety nástrojů

Widgety nástrojů slouží jako "tlačítko" - po kliknutí na něj se v prohlížeči otevře nová karta s odkazem (adresou URL) zadaným v konfiguraci widgetu. Obrázky pro widget nástroje lze načíst přímo do složky public aplikace nebo je načíst jako obrázek ve formě řetězce base64.

Widgety grafů

Widgety grafu se používají, pokud je potřeba zobrazit data v grafické podobě.

Recharts se používají jako knihovna pro vykreslení dat v podobě grafu.

Widget BarChart

Widget BarChart má 4 typy zobrazování dat:

Widget BarChart s ukázkou dat

Zobrazení dat na základě nějakého klíče na časové ose.

Widget BarChart s agregovanými daty

Zobrazení počtu dat na základě nějakého klíče na časové ose.

Widget BarChart se seskupenými daty

Zobrazení dat na základě klíče podle celkového počtu.

Widget BarChart s tabulkou dat

Zobrazení dat grafu v tabulce. Tuto funkci lze povolit v nastavení grafu a aktivovat kliknutím na tlačítko v pravém horním rohu widgetu.

Widget AreaChart

Obsahuje stejné funkce jako widget BarChart, ale zobrazuje data ve widgetu ve formě oblasti.

Widget ScatterChart

Obsahuje stejné funkce jako widget BarChart, ale zobrazuje data ve widgetu ve formě rozptylu.

Widget PieChart

PieChart zobrazuje pouze seskupená data ve formě koláčového grafu a tabulky.

PieChart s gradientními barvami

V tomto příkladu je pro zobrazení podrobných informací o dané části použit tooltip (na tomto obrázku není zobrazen).

PieChart s více barvami

V tomto příkladu je tooltip nahrazen indikací aktivní části v levém horním rohu widgetu.

Widget FlowChart

Mermaid se používá jako knihovna pro vykreslování vývojových diagramů.

Hřiště Mermaid najdete zde.

Ended: Dashboardy

Ended: Konfigurace

Autorizace a ověřování

TeskaLabs LogMan.io používá komponentu TeskaLabs SeaCat Auth, která se zabývá autorizací uživatelů, autentizací, řízením přístupu, rolemi, nájemci, vícefaktorovou autentizací, integrací s jinými poskytovateli identit atd.

SP-TeskaLabs SeaCat Auth má svou vyhrazenou stránku dokumentace.

LogMan.io Commander

LogMan.io Commander umožňuje spouštět následující pomocné příkazy prostřednictvím příkazového řádku nebo API.

Příkaz encpwd

Hesla používaná v konfiguracích lze chránit šifrováním.

Příkaz Encrypt Password zašifruje heslo(a) do formátu hesla LogMan.io pomocí šifry AES.

Hesla jsou pak použita v deklarativní konfiguraci LogMan.io Collector. v následujícím formátu:

!encpwd "<LMIO_PASSWORD>"

Konfigurace

Výchozí cestu ke klíči AES lze nakonfigurovat následujícím způsobem:

[pwdencryptor]
key=/data/aes.key

Použití

Kontejner Docker

Příkazový řádek

docker exec -it lmio-commander lmiocmd encpwd MyPassword

API

LogMan.io Commander slouží také jako koncový bod API, takže příkaz encpwd lze dosáhnout prostřednictvím volání HTTP:

curl -X POST -d "MyPassword" http://lmio-commander:8989/encpwd

---

Příkaz library

Příkaz Library slouží k vložení adresářové struktury knihovny se všemi deklaracemi YAML do ZooKeeperu, kde se nacházejí další komponenty jako jsou LogMan.io Parser a Correlator, mohou dynamicky stahovat z.

Struktura složek může být umístěna v souborovém systému (připojeném ke kontejneru Docker) nebo na url GIT.

Takto se zahájí načítání knihovny do clusteru ZooKeeper:

Konfigurace

Je nutné správně nakonfigurovat zdrojovou složku a výstup ZooKeeper.

[zdroj]
path=/library

[destination]
urls=zookeeper:12181
path=/lmio

Zdrojovou cestou může být cesta k úložišti GIT s předponou git://:

[source]
path=git://<username>:<deploy_token>@<git_url_path>.git

Tímto způsobem bude knihovna automaticky naklonována z GIT do adresáře dočasné složky, nahraje se do ZooKeeper a poté se dočasná složka odstraní.

Použití

Kontejner Docker

Příkazový řádek

docker exec -it lmio-commander lmiocmd library load

Použití explicitně definované konfigurace:

docker exec -it lmio-commander lmiocmd -c /data/lmio-commander.conf library load

API

LogMan.io Commander také obsluhuje koncový bod API, takže příkaz library lze dosáhnout prostřednictvím volání HTTP:

curl -X PUT http://lmio-commander:8989/library/load

Viz část Docker Compose níže.

---

Příkaz iplookup

Příkaz iplookup zpracovává databáze IP rozsahů a generuje IP vyhledávací soubory připravené pro použití s lmio-parser IP Enricher. Má dva dílčí příkazy: iplookup from-csv pro zpracování obecných souborů CSV a iplookup from-ip2location pro zpracování souborů CSV IP2LOCATION.

Konfigurace ####

Zdrojový a cílový adresář lze nastavit v konfiguračním souboru

[iplookup]
source_path=/data
destination_path=/data

iplookup from-csv

Načte obecný soubor CSV a vytvoří soubor IP Enricher lookup. Očekává se, že první řádek souboru bude záhlaví obsahující názvy sloupců. První dva sloupce musí být ip_from a ip_to.

Rozhraní příkazového řádku

lmiocmd.py iplookup from-csv [-h] [--separator SEPARATOR] [--zone-name ZONE_NAME] [--gzip] [--include-ip-range] file_name

Poziční argumenty:

• file_name: Vstupní soubor CSV

Nepovinné argumenty:

• -h, --help: ``: zobrazí tuto nápovědu a ukončí ji.
• -g, --gzip: Komprimuje výstupní soubor pomocí gzip.
• -i INPUT_IP_FORMAT, --input-ip-format INPUT_IP_FORMAT: Formát vstupních IP adres. Výchozí hodnota je 'ipv6'. Možné hodnoty:
• ipv6: IPv6 adresa reprezentovaná jako řetězec, např. ::ffff:c000:02eb,
• ipv4: standardní řetězec adresy IPv4 se čtyřmi tečkami, např. 192.0.2.235,
• ipv6-int: IPv6 adresa jako 128bitové celé desítkové číslo, např. 281473902969579,
• ipv4-int: IPv4 adresa jako 32bitové desítkové celé číslo, např. 3221226219.
• -s SEPARATOR, --separator SEPARATOR: Oddělovač sloupců CSV.
• -o LOOKUP_NAME, ---název LOOKUP_NAME: Název výstupního vyhledávání. Používá se jako název vyhledávací zóny. Ve výchozím nastavení je odvozen od názvu vstupního souboru.
• --include-ip-range: Zahrnuje pole ip_from a ip_to do hodnot vyhledávání.
• --force-ipv4: Zabrání mapování adres IPv4 na IPv6. To je nekompatibilní se vstupními formáty IPv6.

Příklad použití

lmiocmd iplookup from-csv \
--input-ip-format ipv6 \
--lookup-name ip2country \
--gzip \
my-ipv6-zones.CSV

iplookup from-ip2location

Tento příkaz je podobný výše uvedenému příkazu iplookup from-csv, ale je přizpůsoben speciálně pro zpracování IP2Location™ CSV databází. V případě databází IP2LOCATION LITE dokáže příkaz odvodit vstupní formát IP a názvy sloupců z názvu souboru. Názvy sloupců je však možné zadat explicitně

Rozhraní příkazového řádku

lmiocmd.py iplookup from-csv [-h] [--separator SEPARATOR] [--zone-name ZONE_NAME] [--gzip] [--include-ip-range] file_name

Poziční argumenty:

• file_name: Vstupní soubor CSV

Nepovinné argumenty:

• -h, --help: ``: zobrazí tuto nápovědu a ukončí ji.
• -g, --gzip: Komprimuje výstupní soubor pomocí gzip.
• -s SEPARATOR, --separator SEPARATOR: Oddělovač sloupců CSV. Výchozí hodnota je ','.
• -c COLUMN_NAMES, --column-names COLUMN_NAMES: Seznam názvů sloupců oddělených mezerami, které se mají použít. Ve výchozím nastavení je odvozen z názvu souboru IP2LOCATION.
• -i INPUT_IP_FORMAT, --input-ip-format INPUT_IP_FORMAT: Formát vstupních IP adres. Ve výchozím nastavení je odvozen z názvu souboru IP2LOCATION. Možné hodnoty:
• ipv6-int: IPv6 adresa jako 128bitové desítkové celé číslo, např. 281473902969579,
• ipv4-int: IPv4 adresa jako 32bitové desítkové celé číslo, např. 3221226219.
• -o LOOKUP_NAME, --lookup-name LOOKUP_NAME: Název výstupního vyhledávání. Používá se jako název vyhledávací zóny. Ve výchozím nastavení je odvozen od názvu vstupního souboru.
• -e, --keep-empty-rows: Nevylučovat řádky s prázdnými hodnotami (označené '-').
• --include-ip-range: Zahrnout pole ip_from a ip_to do hodnot vyhledávání.
• --force-ipv4: Zabrání mapování adres IPv4 na IPv6.

Příklad použití

S automatickými názvy sloupců a vstupním formátem IP:

lmiocmd iplookup from-ip2location \
--lookup-name ip2country \
--gzip \
IP2LOCATION-LITE-DB1.IPV6.CSV

S explicitními názvy sloupců a vstupním formátem IP (výsledek bude odpovídat výše uvedenému příkladu):

lmiocmd iplookup from-ip2location \
--lookup-name ip2country \
--gzip \
--column names "ip_from ip_to country_code country_name" \
--input-ip-format ipv6-int
IP2LOCATION-LITE-DB1.IPV6.CSV

Docker Compose

Soubor

Následující soubor docker-compose.yml stahuje LogMan.io Commander z registru Docker společnosti TeskaLabs a očekává konfigurační soubor ve složce ./lmio-commander.

verze: '3'
services:
  lmio-commander:
    image: docker.teskalabs.com/lmio/lmio-commander
    container_name: lmio-commander
    volumes:
      - ./lmio-commander:/data
      - /opt/lmio-library:/library
    ports:
      - "8989:8080"

Cesta /opt/lmio-library vede do úložiště knihovny LogMan.io.

Spusťte kontejner

docker-compose pull
docker-compose up -d

Deklarativní jazyk SP-Lang

TeskaLabs LogMan.io používá SP-Lang jako deklarativní jazyk pro psaní pravidel parserů, enricherů, korelátorů a dalších komponent.

Jazyk SP-Lang má svou vyhrazenou stránku documentation site.

Integrační služba TeskaLabs LogMan.io

LogMan.io Integ umožňuje integraci TeskaLabs LogMan.io se službou podporovanými externími systémy prostřednictvím očekávaného formátu zpráv a výstupního/vstupního protokolu.

LogMan.io Integ využívá deklarativní transformátory specifikované v souborech YAML a uložené ve skupině (jako integ atd.). v knihovně LogMan.io.

Konfigurace

Propojení LogMan.io s externím systémem, jako je ArcSight, nakonfigurujte instanci LogMan.io Integ, a zároveň zadejte skupinu transformátorů, Kafka vstup a Kafka nebo TCP výstup(y) ve vlastních sekcích jako MyTCPOutput:

# Nastavit transformátory

[deklarace]
library=/library
groups=integ
include_search_path=filters/*

# Nastavit vstup

[connection:KafkaConnection]
bootstrap_servers=lm1:19092,lm2:29092,lm3:39092

[pipeline:TransformersPipeline:KafkaSource]
topic=lmio-events

# Nastavit výstup(y) - vybírají je jednotlivé transformátory

[MyTCPOutput]
address=lm1:9999

[MyKafkaOutput]
topic=lmio-output

Transformátory

Transformátory jsou deklarativní procesory, které vytvářejí vlastní vyhrazenou pipeline s KafkaSource. a výstupním sinkem.

Příklad

---
define:
  název: ArcSight Transformer for Correlations
  typ: transformer/default
   format: string

output:
  - typ: kafka/tcp/unix-stream/null
    config: MyTCPOutput
    formát: string/json
    latch: 0

predikát:
  !EQ
  - !ITEM EVENT typ
  - Korelace

transformovat:
  !JOIN
  oddělovač: ""
  items:
  - !JOIN
    delimiter: "|"
    items:
    - CEF:0
    - TeskaLabs
    - LogMan.io
    - 1.2.3
    - !ITEM EVENT name
  - !DICT.FORMAT
    co: !EVENT
    typ: cef

Sekce define

Tato sekce obsahuje společnou definici a metadata.

Položka name

Kratší lidsky čitelný název této deklarace.

Item type

Typ této deklarace, musí být transformer/default.

Položka description (nepovinné)

Dlouhý, případně víceřádkový, lidsky čitelný popis deklarace.

Položka field_alias (nepovinné)

Název vyhledávače aliasů polí, který se má načíst, aby bylo možné v deklaraci použít aliasové názvy atributů událostí vedle jejich kanonických názvů.

Sekce output

Sekce output určuje seznamy výstupů.

Položka type

Typ výstupu, např. kafka, unix-stream, tcp, null.

Položka format

Formát události vytvořené transformátorem, buď string, nebo json (výchozí: string).

Položka config

Konfigurační část pro daný výstup uložená v souboru .conf, například MyKafkaOutput nebo MyTCPOutput (viz konfigurační část výše).

Zadejte topic pro výstup Kafka a address pro TCP/Unix Stream.

Položka latch

Pokud je nastaveno, výstupní události se ukládají do fronty latch, aby byly přístupné prostřednictvím pravidelného volání API na /latch. Počet uložených událostí se předává prostřednictvím hodnoty, f. e. latch: 30 bude uchovávat posledních 30 událostí pro každý transformátor. Výchozí hodnota: !!null.

Sekce predikát (nepovinné)

Predikát filtruje příchozí události pomocí výrazu. Pokud výraz vrátí hodnotu True, vstoupí událost do sekce transform. Pokud výraz vrátí False, událost se přeskočí.

Ostatní vrácené hodnoty jsou nedefinované.

Tuto sekci lze použít k urychlení integrace přeskočením řádků se zjevně nerelevantním obsahem.

Včetně vnořených predikátových filtrů

Predikátové filtry jsou výrazy umístěné ve vyhrazeném souboru, které lze zahrnout do mnoha různých predikátů jako jejich části.

Pokud chcete zahrnout externí filtr predikátu, který se nachází buď ve složce include, nebo ve složce filters. (jedná se o globální složku umístěnou v nejvyšší hierarchii knihovny LogMan.io), použijte příkaz !INCLUDE:

!INCLUDE predicate_filter

kde predicate_filter je název souboru s příponou .yaml. Obsahem souboru predicate_filter.yaml je výraz, který má být zahrnut, jako např:

---
!EQ
- !ITEM EVENT category
- "MyEventCategory"

Sekce transform

Tato sekce určuje vlastní transformační mechanismus. Očekává, že bude vrácen slovník nebo None, což znamená, že transformace nebyla úspěšná.

Kafka Topics

Výchozí témata LogMan.io

Následující témata jsou výchozí témata LogMan.io, která se používají k předávání zpracovaných událostí (řádků protokolu) mezi jednotlivými komponentami, jako je LogMan.io Ingestor, LogMan.io Parser atd. Viz následující tabulka:

Kafka	Popis	Kafka consumer groups	Producer pipelines	Consumer pipelines
lmio-lookups	Ukládá události vyhledávání, například informace o aktualizaci položky vyhledávání atd.	lmio-parser-x, lmio-correlator-x, lmio-watcher	parser/LookupModificationPipeline, correlator/LookupModificationPipeline, watcher/LookupChangeStreamPipeline, parser/ParsersPipeline	parser/LookupChangeStreamPipeline correlator/LookupChangeStreamPipeline watcher/LookupModificationPipeline parser/ParsersPipeline
lmio-output	Ukládá parsované výstupní korelace/alarty i události vyhledávání.	lmio-integ, lmio-watcher-output	correlator/OutputPipeline, parser/ParsersPipeline	integ/ArcSightPipeline watcher/OutputToInputPipeline
lmio-events	Ukládá analyzované události protokolu.	lmio-dispatcher, lmio_correlator-x	parser/EnrichersPipeline, watcher/OutputToInputPipeline, watcher/LookupLogPipeline, dispatcher/ToEventsPipeline	dispatcher/EventsPipeline
lmio-others	Ukládá neparsované události protokolu a chyby parsování.	lmio-dispatcher	parser/ErrorPipeline, dispatcher/ToOthersPipeline	dispatcher/OthersPipeline

Výchozí témata jsou přítomna při každém nasazení LogMan.io a lze je nastavit pomocí inicializátoru témat Kafka v LogMan.io Parseru.

Témata LogMan.io pro shromážděné události

Témata pro sbírané události jsou specifická pro každý typ datového zdroje a nájemce (zákazníka). Standard pro pojmenování takových témat Kafka je následující:

collected-<tenant>-<type>

kde tenant je název tenantu psaný malými písmeny a typ je typ zdroje dat. Mezi příklady patří např:

collected-railway-syslog
collected-ministry-files
collected-johnandson-databases

Souhrn je uveden v následující tabulce:

Kafka topic	Description	Kafka consumer groups	Producer pipelines	Consumer pipelines
collected-tenant-type	Ukládá surové shromážděné protokoly pro tenant v datovém typu type.	lmio-parser-*	ingestor/WebSocketPipeline	parser/ParsersPipeline

Knihovna TeskaLabs LogMan.io

Knihovna deklarací je složka v souborovém systému, která obsahuje deklarace pro parsery, obohacovače, korelátory a další prvky YAML, jako jsou soubory !INCLUDE.

Knihovna má předepsanou strukturu:

knihovna/
    <parser group 1>/
        p01_<parser>.yaml
        p02_<parser>.yaml
        e01_<enricher>.yaml
        e02_<enricher>.yaml
        include/
            head_parser.yaml
            spec_parser.yaml
            ...
        test/
            test01.yaml
            ...
    <parser group 2>/
    <parser group 2>/

    <correlator group 1>/
    <correlator group 2>/

    ...
    include/

Skupina parserů je sada deklarací parserů a obohacovačů, která je provozována v rámci stejného typu parseru.

Vzor pojmenování

Vzor pojmenování např. p01_<...>.yaml se doporučuje, protože poskytuje kontrolu nad pořadím provádění a vizuální rozlišení mezi parsery a obohacovači. Pořadí souborů načítaných do pipeline je abecední, bude tedy načten parser s názvem p01_<...>.yaml. do pipeline před parserem p02_<...>.yaml.

Zahrnutí deklarací do knihovny

Deklarace, jako jsou deklarace parserů, mohou zahrnovat další deklarace z adresářů include knihovny pomocí výrazu !INCLUDE.

Adresáře include se zadávají v konfigurační volbě include_search_path pro LogMan.io Parser, Correlator atd.:

[deklarace]
include_search_path=filters;filters/firewall;filters/common;filters/authentication

Uvedením hvězdičky * za lomítkem budou rekurzivně zahrnuty všechny podadresáře, takže uživatel nemusí zadávat každý z nich ve volbě include_search_path:

[deklarace]
include_search_path=filters/*

Ve výchozím nastavení jsou vždy implicitně zahrnuty i následující include search path:

V tomto případě je implicitní vyhledávací cesta pro soubory YAML `!INCLUDE`, které se používají v rámci skupiny parserů. `library/include` je umístění souborů `!INCLUDE` YAML používaných globálně. Deklaraci s názvem `predicate_filter.yaml` umístěnou v jednom z adresářů vyhledávací cesty include pak lze začlenit následujícím způsobem:

predikát:
  !AND
  - !EQ
    - !ITEM EVENT Typ
    - UseIt
  - !INCLUDE predicate_filter

Další informace naleznete v částech Kaskádový parser a Window Correlator. ## Jednotkové testy `library/<* group/test` je umístění unit testu pro danou skupinu, viz `lmio-parser` a `lmio-correlator` pro více informací o tom, jak přistupovat k unit testům knihovny. Knihovna je navržena tak, aby ji bylo možné snadno spravovat pomocí systémů pro správu verzí, jako je Git nebo Subversion.

Vyhledávání

LogMan.io Lookups jsou obvykle dynamické seznamy uložené v ElasticSearch a aktualizovány prostřednictvím Kafky z libovolné komponenty LogMan.io, jako je např. Parser nebo Correlator, nebo prostřednictvím uživatelského rozhraní LogMan.io.

Dynamické vyhledávání

Lookups umožňují ukládat informace, jako jsou například neúspěšné pokusy o přihlášení uživatele, blokované IP adresy, přístupy k serverům prostřednictvím brány firewall atd. V těchto případech, se vyhledávání vytváří prostřednictvím uživatelského rozhraní LogMan.io a přidávají se nové položky. když dojde ke spuštění v korelátoru LogMan.io.

Přístup k vyhledávání

Korelace nebo parsery mohou reagovat na aktualizovaný lookup pomocí výrazů !LOOKUP.GET a !LOOKUP.CONTAINS. a podle toho upravit rozbor události nebo její vyhodnocení.

Obrovské statické vyhledávání

Speciální vyhledávání, například IPEnricher s velkým množstvím sdílených dat. se načítají ze souborů nebo ze ZooKeeperu a obvykle nejsou dynamicky aktualizovány.

Data pro vyhledávání IPEnricher se načítají z binárního souboru vytvořeného nástrojem LogMan.io Commander z textového souboru CSV.

Další informace naleznete v částech Události vyhledávání a Parsování vyhledávání.

Metriky

TeskaLabs LogMan.io nabízí paletu metrik ze všech svých mikroslužeb včetně LogMan.io Parser, LogMan.io Dispatcher, LogMan.io Correlator atd.

Metriky jsou uloženy v InfluxDB a aktualizovány každou spuštěnou mikroslužbou přibližně jednou za minutu. Metriky jsou vizualizovány v aplikaci Grafana pomocí poskytnutých/vypůjčených nebo vlastních ovládacích panelů.

V následujících částech jsou uvedeny dostupné metriky (nebo měření z pohledu InfluxDB) spolu s jejich hodnotami a značkami:

Metriky paměti

Každá mikroslužba obsahuje měřidlo s názvem os.stat, které shromažďuje informace o využití paměti. Vypočítávají se následující hodnoty:

• VmPeak: Maximální velikost virtuální paměti
• VmLck: Velikost zamčené paměti
• VmPin: Pinned memory size
• VmHWM: Maximální velikost rezidentní sady ("high water mark")
• VmRSS: Velikost rezidentní sady
• VmData, VmStk, VmExe: Velikost datových, zásobníkových a textových segmentů
• VmLib: Velikost kódu sdílené knihovny
• VmPTE: Velikost záznamů v tabulce stránek
• VmPMD: Velikost tabulek stránek druhé úrovně
• VmSwap: Velikost vyměněné virtuální paměti anonymními privátními stránkami; využití swapu shmem není zahrnuto

Obecné metriky pipeline

Následující metriky jsou vytvářeny každou pipeline, takže jsou specifické pro každou mikroslužbu, která čte, transformuje a výstupuje data jako LogMan.io Ingestor, LogMan.io Parser, LogMan.io Dispatcher, LogMan.io Correlator atd.

Tagy jsou pipeline (ID pipeline) a host (název hostitele mikroslužby).

bspump.pipeline

Metrika čítače s následujícími hodnotami:

• event.in: počet událostí vstupujících do pipeline v zadaném časovém intervalu (jednou za minutu).
• event.drop: počet událostí, které byly během zpracování v potrubí vyřazeny, v zadaném časovém intervalu (jednou za minutu).
• event.out: počet událostí, které úspěšně opustily potrubí v zadaném časovém intervalu (jednou za minutu).
• warning: počet varování vytvořených v potrubí v zadaném časovém intervalu (jednou za minutu)
• warning: počet chyb vytvořených v potrubí v zadaném časovém intervalu (jednou za minutu)

bspump.pipeline.eps

Metrika čítače s následujícími hodnotami:

• eps.in: události za sekundu vstupující do pipeline
• eps.drop: události za sekundu, které v potrubí odpadly
• eps.out: události za sekundu úspěšně opouštějící potrubí
• warning: počet varování vytvořených v potrubí v zadaném časovém intervalu (jednou za minutu)
• warning: počet chyb vytvořených v potrubí v zadaném časovém intervalu (jednou za minutu)

bspump.pipeline.gauge

Metrika měřidla (hodnota se vypočítá jednou) s následujícími hodnotami:

• warning.ratio: poměr varování na úspěšně provedené události.
• error.ratio: poměr chyb na úspěšné události

bspump.pipeline.dutycycle

Metrika dutycycle, která počítá procento zpožděného zpracování (způsobeného obvykle následující službou, jako je ElasticSearch) na nezpožděné zpracování.

• ready: hodnota true/false, která udává, zda nebyla pipeline zpožděna.

timedrift

Volitelná metrika pipeline, která je povolena v každé mikroslužbě LogMan.io.

Vypočítává rozdíl mezi aktuálním časem a časem vzniku dané události, který je obvykle označen atributem @timestamp. Následující hodnoty se počítají pro zadaný časový interval (jednou za minutu):

• avg
• median
• stddev
• min
• max

Metriky nájemce

Tenant metriky jsou specifické pro mikroslužby LogMan.io Parser, LogMan.io Dispatcher, LogMan.io Correlator a LogMan.io Watcher.

Tagy jsou pipeline (ID pipeline), host (název hostitele mikroslužby) a tenant (název tenanta psaný malými písmeny).

bspump.pipeline.tenant.eps

Metrika čítače s následujícími hodnotami:

• eps.in: události nájemce za sekundu, které vstupují do potrubí.
• eps.aggr: agregované události nájemce (počet je vynásoben atributem cnt v událostech) za sekundu vstupující do potrubí
• eps.drop: události nájemce za sekundu, které byly vypuštěny v potrubí
• eps.out: události nájemce za sekundu, které úspěšně opustily potrubí
• warning: počet varování nájemce vytvořených v potrubí v zadaném časovém intervalu (jednou za minutu)
• warning: počet chyb nájemce vytvořených v potrubí v zadaném časovém intervalu (jednou za minutu).

V LogMan.io Parseru pocházejí nejdůležitější metriky z ParsersPipeline (když data poprvé vstoupí do Parseru a jsou analyzována prostřednictvím preprocesorů a parserů) a EnrichersPipeline, zatímco v LogMan.io Dispatcheru z EventsPipeline a OthersPipeline.

bspump.pipeline.tenant.load

Metrika čítače s následujícími hodnotami:

• load.in: velikost bajtů nájemce všech událostí vstupujících do pipeline v zadaném časovém intervalu (jednou za miutu).
• load.out: velikost bajtů všech událostí nájemce opouštějících potrubí v zadaném časovém intervalu (jednou za minutu).

Metriky korelátoru

Následující metriky jsou specifické pro korelátor LogMan.io.

Jejich značky jsou correlator (název korelátoru) a host (název hostitele mikroslužby).

correlator.predicate

Metrika čítače, která počítá, kolik událostí prošlo predikátem.

• in: počet událostí vstupujících do predikátu v časovém intervalu (jednou za minutu).
• hit: počet událostí úspěšně vyhovujících predikátu v časovém intervalu (jednou za minutu).
• miss: počet událostí, které v časovém intervalu neprošly predikátem (jednou za minutu) a opustily tak korelátor.
• error: počet chyb v predikátu v časovém intervalu (jednou za minutu)

correlator.trigger

Metrika čítače, která počítá, kolik událostí prošlo spouštěcí sekcí korelátoru.

• in: počet událostí vstupujících do spouštěče v časovém intervalu (jednou za minutu).
• out: počet událostí opouštějících spouštěč v časovém intervalu (jednou za minutu).
• error: počet chyb ve spouštěči v časovém intervalu (jednou za minutu), měl by se rovnat in - out.

Pojmenovací standardy

Úložiště produktů

Úložiště produktů obsahují zdrojové kódy všech komponent LogMan.io (datová čerpadla, služby, uživatelské rozhraní atd.).

Názvy úložišť produktů,které vždy vyvíjí a spravuje společnost TeskaLabs, vždy začínají předponou lmio-.

Úložiště produktů nesmí být upravována zákazníky ani partnery.

Úložiště konfigurace webu

Úložiště konfigurace webu obsahují konfigurace každého nasazeného webu. LogMan.io, základní technologie a také soubor(y) Docker Compose. pro dané nasazení na daném serveru.

Úložiště konfigurace webu může spravovat také partner nebo zákazník. Jejich názvy vždy začínají předponou site-.

Úložiště partnerů

Úložiště spravovaná partnerem nebo zákazníkem vždy obsahují jejich název malými písmeny za předponou, oddělený pomlčkami.

Proto pro úložiště webu vypadá formát takto:

site-<partner_name>-<location>

Kde location je místo nasazení (název společnosti, která spravuje server). Umístění, pokud je obecně známé, lze popsat i jiným explicitním způsobem, např. jako build-env pro označení prostředí sestavení.

Poznámky

Klíčové slovo environment se vždy zkracuje na env.

Klíčové slovo encrypt se vždy zkracuje na enc.

Multitenancy

TesksLabs LogMan.io je produkt založený na multitenanci, který vyžaduje zadat identifikaci nájemce (zákazníka) v každé události protokolu, což lze provést automaticky pomocí nástroje LogMan.io Collector.

Každá instance LogMan.io Parser je specifická pro nájemce, stejně jako indexy uloženy v systému ElasticSearch. Do systému se tak dostanou pouze logy patřící k danému nájemci. se zobrazí danému tenantu v uživatelském rozhraní Kibana nebo LogMan.io.

Také metriky monitorování toků v Grafana jsou založeny na tenantech a umožňují tak sledovat tok logů pro každého jednotlivého zákazníka.

Standard pojmenování

Vzhledem k technologickému základu TeskaLabs LogMan.io jsou všechny identifikace nájemců musí být malá písmena bez speciálních znaků (jako #, * atd.).

Nástroje

Seznam OpenSource nástrojů třetích stran, které lze integrovat s TeskaLabs LogMan.io. Po povolení jsou k dispozici v sekci "Tools" v LogMan.io.

Kybernetická bezpečnost

Kibana

Kibana je otevřený software pro vizualizaci příchozích logů. Je to jeden z nástrojů Elastic. Týmy kybernetické bezpečnosti používají Kibanu především pro analytické úlohy.

Více informací naleznete na adrese Kibana Guide.

TheHive

TheHive je platforma pro reakci na bezpečnostní incidenty.

Více informací na thehive-project.org

MISP

MISP je otevřený software pro korelaci, ukládání a sdílení indikátorů kybernetické bezpečnosti, analýzu malwaru atd.

Více informací na misp-project.org

Datová věda

Jupyter Notebook

JupyterLab je webové interaktivní vývojové prostředí pro zápisníky, kód a data. Jeho flexibilní rozhraní umožňuje uživatelům konfigurovat a uspořádat pracovní postupy v oblasti datové vědy, vědeckých výpočtů, počítačové žurnalistiky a strojového učení. Modulární design vybízí k rozšířením, která rozšiřují a obohacují funkce.

Více informací na adrese Jupyter Notebook

Technická podpora

ZooNavigator

Prohlížeč a editor ZooKeeper.

https://github.com/elkozmon/zoonavigator

Grafana

Platforma pro pozorovatelnost a vizualizaci dat. Pro vizualizaci metrik.

https://github.com/grafana/grafana

KafDrop

Webové uživatelské rozhraní Kafka

https://github.com/obsidiandynamics/kafdrop

Taxonomie výstrah

TeskaLabs LogMan.io poskytuje taxonomii pro organizaci a správu různých artefaktů generovaných v rámci systému, což analytikům kybernetické bezpečnosti usnadňuje stanovení priorit a efektivní reakci na bezpečnostní hrozby.

Taxonomie je uspořádána do následujícího stromu:

• Událost
  • Protokol
  • Komplexní
• Ticket
  • Upozornění
  • Incident

Zde je vysvětlení jednotlivých kategorií a jejich podkategorií.

Událost

Události jsou záznamy o činnostech, ke kterým dochází v síti, systémech nebo aplikacích organizace.

Lze je dále rozdělit na:

Log

Protokoly jsou základní záznamy generované různými zařízeními, systémy nebo aplikacemi, které uchovávají informace o jejich činnosti. Příkladem jsou protokoly brány firewall, protokoly serverů nebo aplikací. Tyto protokoly pomáhají analytikům pochopit, co se děje v prostředí organizace, a lze je použít pro odhalování bezpečnostních hrozeb a anomálií.

Komplexní

Komplexní události označují korelované nebo agregované události, které mohou indikovat bezpečnostní incident nebo vyžadovat další analýzu. Generují je korelátory, hlídače a jiné detektory, které shromažďují události z různých zdrojů, analyzují je a vytvářejí výstrahy na základě předem definovaných pravidel nebo algoritmů strojového učení.

Ticket

Tikety vytvářejí analytici kybernetické bezpečnosti nebo automatizované korelátory, hlídače a detektory za účelem sledování a správy bezpečnostních událostí, které vyžadují pozornost. Tiket se může týkat nuly, jedné nebo více událostí.

Lze je dále rozdělit na:

Upozornění

Výstrahy jsou generovány, když je zjištěna určitá událost, série událostí nebo anomálie, která může znamenat potenciální bezpečnostní hrozbu. Výstrahy obvykle vyžadují okamžitou pozornost analytiků kybernetické bezpečnosti, kteří je třídí, vyšetřují a určují, zda se jedná o skutečný bezpečnostní incident.

Incident

Incidenty jsou potvrzené bezpečnostní události, které byly prošetřeny a klasifikovány jako skutečné hrozby. Představují vyšší úroveň závažnosti než výstrahy a často vyžadují koordinovanou reakci více týmů, například týmů pro reakci na incidenty nebo správu sítě, s cílem hrozbu omezit, napravit a zotavit se z ní.

Ended: Referenční příručka