Table of Contents
Úvod
Dokumentace k TeskaLabs LogMan.io¶
Vítejte v dokumentaci TeskaLabs LogMan.io.
TeskaLabs LogMan.io¶
TeskaLabs LogMan.io™️ je softwarový produkt pro sběr logů, agregaci logů, ukládání a retenci logů, analýzu logů v reálném čase a rychlou reakci na incidenty v IT infrastruktuře, souhrnně známé jako správa logů.
TeskaLabs LogMan.io se skládá z centrální infrastruktury a sběračů logů, které se nacházejí na monitorovaných systémech, jako jsou servery nebo síťová zařízení. Sběrače logů shromažďují různé logy (operační systém, aplikace, databáze) a systémové metriky, jako je využití CPU, využití paměti, volné místo na disku atd. Shromážděné události jsou v reálném čase odesílány do centrální infrastruktury pro konsolidaci, orchestraci a uložení. Díky své povaze v reálném čase poskytuje LogMan.io alerty pro anomální situace z pohledu provozu systému (např. je místo na disku nedostatečné?), dostupnosti (např. běží aplikace?), byznysu (např. je počet transakcí pod normálem?) nebo bezpečnosti (např. nějaký neobvyklý přístup k serverům?).
TeskaLabs SIEM¶
TeskaLabs SIEM je real-time nástroj pro Security Information and Event Management. TeskaLabs SIEM poskytuje analýzu a korelaci bezpečnostních událostí a alertů v reálném čase zpracovávaných TeskaLabs LogMan.io. Návrh TeskaLabs SIEM je zaměřen na zlepšení kybernetické bezpečnosti a dosažení souladu s předpisy.
Více komponent
TeskaLabs SIEM a TeskaLabs LogMan.io jsou samostatné produkty. Díky své modulární architektuře tyto produkty zahrnují také další technologie TeskaLabs:
- TeskaLabs SeaCat Auth pro autentizaci a autorizaci včetně uživatelských rolí a jemně zrnitého řízení přístupu.
- TeskaLabs SP-Lang je výrazový jazyk používaný na mnoha místech v produktu.
Vytvořeno s ❤️ TeskaLabs
TeskaLabs LogMan.io™️ je produkt TeskaLabs.
Funkce¶
TeskaLabs LogMan.io je real-time SIEM s log managementem.
- Multitenance: jedna instance TeskaLabs LogMan.io může sloužit více tenantům (zákazníkům, oddělením).
- Multiuser: TeskaLabs LogMan.io může být používán neomezeným počtem uživatelů současně.
Technologie¶
Kryptografie¶
- Transportní vrstva: TLS 1.2, TLS 1.3 a lepší
- Symetrická kryptografie: AES-128, AES-256, AES-512
- Asymetrická kryptografie: RSA, ECC
- Hash metody: SHA-256, SHA-384, SHA-512
- MAC funkce: HMAC
- HSM: PKCS#11 rozhraní
Poznámka
TeskaLabs LogMan.io používá pouze silnou kryptografii, což znamená, že používáme pouze tyto šifry, hashovací funkce a další algoritmy, které jsou uznávány jako bezpečné kryptografickou komunitou a organizacemi jako ENISA nebo NIST.
Podporované zdroje logů¶
TeskaLabs LogMan.io podporuje různé technologie, které jsou uvedeny níže.
Formáty¶
- Syslog RFC 5424 (IEFT)
- Syslog RFC 3164 (BSD)
- Syslog RFC 3195 (BEEP profil)
- Syslog RFC 6587 (Rámce přes TCP)
- Reliable Event Logging Protocol (RELP), včetně SSL
- Windows Event Log
- SNMP
- ArcSight CEF
- LEEF
- JSON
- XML
- YAML
- Avro
- Vlastní/surový formát logu
A mnoho dalších.
Info
Syslog protokoly mohou být přenášeny přes TCP, UDP a TLS/SSL.
Prodejci a produkty¶
Cisco¶
- Cisco Firepower Threat Defense (FTD)
- Cisco Adaptive Security Appliance (ASA)
- Cisco Identity Services Engine (ISE)
- Cisco Meraki (MX, MS, MR zařízení)
- Cisco Catalyst Switches
- Cisco IOS
- Cisco WLC
- Cisco ACS
- Cisco SMB
- Cisco UCS
- Cisco IronPort
- Cisco Nexus
- Cisco Routers
- Cisco VPN
- Cisco Umbrella
Palo Alto Networks¶
- Palo Alto Next-Generation Firewalls
- Palo Alto Panorama (Centrální správa)
- Palo Alto Traps (Ochrana koncových bodů)
Fortinet¶
- FortiGate (Next-Generation Firewalls)
- FortiSwitch (Přepínače)
- FortiAnalyzer (Log Analytics)
- FortiMail (Bezpečnost emailů)
- FortiWeb (Web Application Firewall)
- FortiADC
- FortiDDos
- FortiSandbox
Juniper Networks¶
- Juniper SRX Series (Firewally)
- Juniper MX Series (Routery)
- Juniper EX Series (Přepínače)
Check Point Software Technologies¶
- Check Point Security Gateways
- Check Point SandBlast (Prevence hrozeb)
- Check Point CloudGuard (Cloudová bezpečnost)
Microsoft¶
- Microsoft Windows (Operační systém)
- Microsoft Azure (Cloudová platforma)
- Microsoft SQL Server (Databáze)
- Microsoft IIS (Web server)
- Microsoft Office 365
- Microsoft Exchange
- Microsoft Sharepoint
Linux¶
- Ubuntu (Distribuce)
- CentOS (Distribuce)
- Debian (Distribuce)
- Red Hat Enterprise Linux (Distribuce)
- IPTables
- nftables
- Bash
- Cron
- Kernel (dmesg)
Oracle¶
- Oracle Database
- Oracle WebLogic Server (Aplikační server)
- Oracle Cloud
Amazon Web Services (AWS)¶
- Amazon EC2 (Virtuální servery)
- Amazon RDS (Databázová služba)
- AWS Lambda (Serverless Computing)
- Amazon S3 (Služba úložiště)
VMware¶
- VMware ESXi (Hypervisor)
- VMware vCenter Server (Správní platforma)
F5 Networks¶
- F5 BIG-IP (Aplikační datové řadiče)
- F5 Advanced Web Application Firewall (WAF)
Barracuda Networks¶
- Barracuda CloudGen Firewall
- 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)¶
- Aruba Switches
- Aruba Wireless Access Points
- Aruba ClearPass (Kontrola 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 (Prevence průniků)
- Trend Micro Endpoint Protection Manager
- Trend Micro Apex One
Fidelis¶
- Fidelis Elevate
Zscaler¶
- Zscaler Internet Access (Secure Web Gateway)
- Zscaler Private Access (Vzdálený přístup)
Akamai¶
- Akamai (Content Delivery Network a Bezpečnost)
- 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 Next-Generation Firewalls
- SonicWall Email Security
- SonicWall Secure Mobile Access
WatchGuard Technologies¶
- WatchGuard Firebox (Firewally)
- WatchGuard XTM (Unified Threat Management)
- WatchGuard Dimension (Viditelnost bezpečnosti sítě)
Apple¶
- macOS (Operační systém)
Apache¶
- Apache Cassandra (Databáze)
- Apache HTTP Server
- Apache Kafka
- Apache Tomcat
- Apache Zookeeper
NGINX¶
- NGINX (Web server a reverzní proxy server)
Docker¶
- Docker (Platforma pro kontejnery)
Kubernetes¶
- Kubernetes (Orchestrace kontejnerů)
Atlassian¶
- Jira (Správa issues a projektů)
- Confluence (Kolaborační software)
- Bitbucket (Kolaborace na kódu a verzování)
Cloudflare¶
- Cloudflare (Content Delivery Network a Bezpečnost)
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 (Continuous Integration and Continuous Delivery)
- rsyslog
- GenieACS
- Haproxy
- SpamAssassin
- 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¶
- Brocade Switches
Google¶
- Google Cloud
- Pub/Sub & BigQuery
Elastic¶
- Logstash
- Filebeat
- Winlogbeat
- Auditbeat
- Metricbeat
- Packetbeat
- Heartbeat
- ... a beats z komunitního seznamu
- 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ě)
- Dell PowerConnect Switches
- Dell W-Series (Přístupové body)
- Dell iDRAC
- Dell Force10 Switches
FlowMon¶
- Flowmon Collector
- Flowmon Probe
- Flowmon ADS
- Flowmon FPI
- Flowmon APM
GreyCortex¶
- GreyCortex Mendel
Huawei¶
- Huawei Routers
- Huawei Switches
- Huawei Unified Security Gateway (USG)
Synology¶
- Synology NAS
- Synology SAN
- Synology NVR
- Synology Wi-Fi routers
Ubiquity¶
- UniFi
Avast¶
- Avast Antivirus
Kaspersky¶
- Kaspersky Endpoint Security
- Kaspersky 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¶
- Mikrotik Routers
- Mikrotik Switches
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
Stapro¶
- Stapro FONS Akord
Tento seznam není vyčerpávající, protože existuje mnoho dalších prodejců a produktů, které mohou posílat logy do TeskaLabs LogMan.io pomocí standardních protokolů, jako je Syslog. Kontaktujte nás, pokud hledáte specifickou technologii k integraci.
Extrakce logů z SQL¶
TeskaLabs LogMan.io může extrahovat logy z různých SQL databází pomocí ODBC (Open Database Connectivity).
Mezi podporované databáze patří:
- PostgreSQL
- Oracle Database
- IBM Db2
- MySQL
- SQLite
- MariaDB
- SAP HANA
- Sybase ASE
- Informix
- Teradata
- Amazon RDS (Relational Database Service)
- Google Cloud SQL
- Azure SQL Database
- Snowflake
Ochranné známky
Všechny ochranné známky nebo obchodní názvy zmíněné nebo použité jsou majetkem jejich příslušných vlastníků.
Architektura TeskaLabs LogMan.io¶
lmio-collector¶
LogMan.io Collector slouží k přijímání logových řádků z různých zdrojů, jako jsou SysLog NG, soubory, Windows Event Forwarding, databáze přes ODBC konektory a podobně. Logové řádky mohou být dále zpracovávány deklarativním procesorem a poslány do LogMan.io Ingestoru přes WebSocket.
lmio-ingestor¶
LogMan.io Ingestor přijímá události přes WebSocket, transformuje je do formátu čitelného pro Kafka a
pokládá je do Kafka collected-
topicu. Existuje několik ingestorů pro různé
formáty událostí, jako jsou SysLog, databáze, XML a další.
lmio-parser¶
LogMan.io Parser běží v několika instancích, aby přijímal různé formáty příchozích událostí (různé Kafka topicy) a/nebo stejné události (instance pak běží ve stejné Kafka skupině, aby rozdělovaly události mezi sebou). LogMan.io Parser načítá LogMan.io Library přes ZooKeeper nebo ze souborů k načítání deklarativních parserů a obohacovačů z nakonfigurovaných parserových skupin.
Pokud byly události parsovány načteným parserem, jsou položeny do Kafka topicu lmio-events
, jinak
vstupují do Kafka topicu lmio-others
.
lmio-dispatcher¶
LogMan.io Dispatcher načítá události z Kafka topicu lmio-events
a posílá je jak do všech
přihlášených (přes ZooKeeper) LogMan.io Correlator instancí, tak do ElasticSearch v
příslušném indexu, kde mohou být všechny události dotazovány a vizualizovány pomocí Kibana.
LogMan.io Dispatcher běží také v několika instancích.
lmio-correlator¶
LogMan.io Correlator používá ZooKeeper k přihlášení ke všem LogMan.io Dispatcher instancím, aby přijímal parsované události (logové řádky apod.). Poté LogMan.io Correlator načítá LogMan.io Library přes ZooKeeper nebo ze souborů k vytváření korelátorů na základě deklarativní konfigurace. Události produkované korelátory (Window Correlator, Match Correlator) jsou následně předávány LogMan.io Dispatcherovi a LogMan.io Watcherovi přes Kafka.
lmio-watcher¶
LogMan.io Watcher sleduje změny v lookupech používaných v instancích LogMan.io Parserů a LogMan.io Correlatorů.
Když dojde ke změně, všechny běžící komponenty, které používají LogMan.io Library, jsou informovány
přes Kafka topic lmio-lookups
o změně a lookup je aktualizován v ElasticSearch,
který slouží jako trvalé úložiště pro všechny lookupy.
lmio-integ¶
LogMan.io Integ umožňuje integraci LogMan.io s podporovanými externími systémy přes očekávaný formát zpráv a výstupní/vstupní protokol.
Podpora¶
Online pomoc¶
Náš tým je dostupný na našem online kanálu podpory na Slack. Můžete posílat zprávy našim interním expertům přímo, konzultovat své plány, problémy a výzvy a dokonce získat online pomoc přes sdílení obrazovky, takže se nemusíte obávat hlavních aktualizací a podobně. Přístup je poskytován zákazníkům s aktivním podpůrným plánem.
E-mailová podpora¶
Kontaktujte nás na: support@teskalabs.com
Pracovní doba podpory¶
Úroveň podpory 5/8 je dostupná ve všední dny podle českého kalendáře, 09-18 hodin středoevropského času (Evropa/Praha).
Úroveň podpory 24/7 je také k dispozici, záleží na vašem aktivním podpůrném plánu.
Uživatelský manuál
Vítejte¶
Co najdete v uživatelské příručce?
Zde se můžete dozvědět, jak používat aplikaci TeskaLabs LogMan.io. Pro informace o instalaci, konfiguraci a údržbě navštivte Administrátorskou příručku nebo Referenční příručku. Pokud nemůžete najít potřebnou pomoc, kontaktujte Podporu.
Rychlý start¶
Přejít na:
- Získat přehled o všech událostech ve vašem systému (Domů)
- Číst příchozí logy a filtrovat logy podle pole a času (Průzkumník)
- Zobrazit a filtrovat data ve formě grafů a diagramů (Dashboardy)
- Zobrazit a tisknout reporty (Reporty)
- Spustit, stáhnout a spravovat exporty (Export)
- Změnit obecná nebo uživatelská nastavení
Některé funkce jsou viditelné pouze pro administrátory, takže nemusíte vidět všechny funkce, které jsou zahrnuty v Uživatelské příručce ve vaší vlastní verzi TeskaLabs LogMan.io.
Rychlý start pro administrátory¶
Jste administrátor? Přejít na:
- Přidávat nebo upravovat soubory ve knihovně, jako například dashboardy, reporty a exporty (Knihovna)
- Přidávat nebo upravovat lookupy (Lookupy)
- Přistupovat k externím komponentům, které pracují s TeskaLabs LogMan.io (Nástroje)
- Změnit konfiguraci vašeho rozhraní (Konfigurace)
- Zobrazit mikroslužby (Služby)
- Spravovat uživatelská oprávnění (Auth)
Nastavení¶
Použijte tyto ovládací prvky v pravém horním rohu obrazovky pro změnu nastavení:
Tenanti¶
Tenant je jedním subjektem shromažďujícím data ze skupiny zdrojů. Když používáte program, můžete vidět pouze data patřící vybranému tenantovi. Data daného tenanta jsou zcela oddělena od dat ostatních tenantů v TeskaLabs LogMan.io (další informace o multitenanci). Vaše společnost může mít pouze jednoho tenanta, nebo také více tenantů (například pro různé oddělení). Pokud distribuujete nebo spravujete TeskaLabs LogMan.io pro jiné klienty, máte více tenantů, minimálně jednoho pro každého klienta.
Tenanti mohou být přístupní více uživateli a uživatelé mohou mít přístup k více tenantům. Více o tenantech se dozvíte zde.
Tipy¶
Pokud jste noví ve sběru logů, klikněte na tipové boxy, abyste se dozvěděli, proč byste mohli chtít použít určitou funkci.
Proč používat TeskaLabs LogMan.io?
TeskaLabs LogMan.io sbírá logy, což jsou záznamy o každé jednotlivé události v síťovém systému. Tyto informace vám mohou pomoci:
- Pochopit, co se děje ve vaší síti
- Řešit problémy sítě
- Vyšetřovat bezpečnostní incidenty
Správa vašeho účtu¶
Název vašeho účtu se nachází v pravém horním rohu obrazovky:
Změna hesla¶
- Klikněte na název vašeho účtu.
- Klikněte na Změnit heslo.
- Zadejte své aktuální heslo a nové heslo.
- Klikněte na Nastavit heslo.
Měli byste vidět potvrzení o změně hesla. Chcete-li se vrátit na stránku, na které jste byli před změnou hesla, klikněte na Vrátit se zpět.
Změna informací o účtu¶
- Klikněte na název vašeho účtu.
- Klikněte na Spravovat.
- Zde můžete:
- Změnit své heslo
- Změnit svou emailovou adresu
- Změnit nebo přidat své telefonní číslo
- Odhlásit se
- Klikněte na to, co chcete udělat, a proveďte změny. Změny nebudou okamžitě viditelné - budou viditelné po odhlášení a opětovném přihlášení.
Zobrazení oprávnění přístupu¶
- Klikněte na název vašeho účtu.
- Klikněte na Kontrola přístupu, kde uvidíte, jaká oprávnění máte.
Odhlášení¶
- Klikněte na název vašeho účtu.
- Klikněte na Odhlásit se.
Můžete se také odhlásit z obrazovky Spravovat.
Odhlášení ze všech zařízení¶
- Klikněte na název vašeho účtu.
- Klikněte na Spravovat.
- Klikněte na Odhlásit se ze všech zařízení.
Po odhlášení budete automaticky přesměrováni na přihlašovací obrazovku.
Používání domovské stránky¶
Domovská stránka vám poskytuje přehled vašich datových zdrojů a kritických příchozích událostí. Po přihlášení budete automaticky na domovské stránce, ale na domovskou stránku se můžete také dostat z tlačítek vlevo.
Možnosti zobrazení¶
Zobrazení grafu a seznamu¶
Pro přepínání mezi zobrazením grafu a seznamu klikněte na tlačítko seznamu.
Získání dalších podrobností¶
Kliknutím na jakoukoli část grafu přejdete do Průzkumníku, kde se zobrazí seznam logů, které tvoří tuto část grafu. Odtud můžete zkoumat a filtrovat tyto logy.
Zde můžete vidět, že Průzkumník automaticky filtruje události z vybraného datasetu (z grafu na domovské stránce), event.dataset:devolutions
.
Použití Průzkumníka¶
Průzkumník vám poskytuje přehled o všech logech, které jsou sbírány v reálném čase. Zde můžete filtrovat data podle času a pole.
Navigace Průzkumníkem¶
Termíny¶
Celkový počet: Celkový počet logů v zobrazeném časovém rozmezí.
Agregováno podle: V sloupcovém grafu každý sloupec reprezentuje počet logů sebraných během časového intervalu. Použijte Agregováno podle pro volbu časového intervalu. Například Agregováno podle: 30m znamená, že každý sloupec v grafu zobrazuje počet všech logů sebraných během 30 minutového časového intervalu. Pokud změníte na Agregováno podle: hodina, pak každý sloupec reprezentuje jednu hodinu logů. Dostupné možnosti se mění v závislosti na celkovém časovém rámci, který zobrazuje Průzkumník.
Filtrování dat¶
Změňte časový rámec, ze kterého se logy zobrazují, a filtrovejte logy podle pole.
Tip: Proč filtrovat data?
Logy obsahují mnoho informací, více než potřebujete k dokončení většiny úkolů. Když filtrujete data, vybíráte, které informace chcete vidět. To vám může pomoci lépe pochopit vaši síť, identifikovat trendy a dokonce lovit hrozby.
Příklady:
- Chcete vidět údaje o přihlášení od jednoho uživatele, takže filtrujete data, aby se zobrazovaly logy obsahující jeho uživatelské jméno.
- Večer ve středu došlo k bezpečnostnímu incidentu a chcete se dozvědět více, takže filtrujete data, aby se zobrazovaly logy z tohoto časového období.
- Všimnete si, že nevidíte žádná data od jednoho z vašich síťových zařízení. Můžete filtrovat data, aby se zobrazovaly všechny logy pouze z tohoto zařízení. Nyní můžete zjistit, kdy data přestala přicházet a jaká událost mohla způsobit problém.
Změna časového rámce¶
Můžete zobrazit logy z určeného časového rámce. Nastavte časový rámec výběrem počátečního a koncového bodu pomocí tohoto nástroje:
Pamatujte: Po změně časového rámce stiskněte modré tlačítko pro obnovení, aby se stránka aktualizovala.
Použití nástroje pro nastavení času¶
Nastavení relativního počátečního/koncového bodu¶
Pro nastavení počátečního nebo koncového bodu v relativním čase od teď použijte záložku Relativní.
Rychlé nastavení času
Použijte rychlé možnosti now- ("teď mínus") pro nastavení časového rámce na přednastavenou hodnotu jedním kliknutím. Výběr jedné z těchto možností ovlivňuje oba počáteční a koncový bod. Například, pokud zvolíte now-1 týden, počáteční bod bude před týdnem a koncový bod bude "teď." Výběr možnosti now- z koncového bodu udělá to samé jako výběr možnosti now- z počátečního bodu. (Nemůžete použít možnosti now- k nastavení koncového bodu na cokoliv jiného než "teď.")
Možnosti rozbalovacího seznamu
Pro nastavení relativního času (například před 15 minutami) pro počáteční nebo koncový bod použijte možnosti relativního času pod rychlým nastavením. Vyberte jednotku času z rozbalovacího seznamu a napište nebo klikněte na požadované číslo.
Pro potvrzení výběru klikněte na Nastavit relativní čas a zobrazte logy kliknutím na tlačítko pro obnovení.
Příklad ukázaný: Tento výběr zobrazí logy sebrané od jednoho dne zpátky až do nynějška.
Nastavení přesného počátečního/koncového bodu¶
Pro výběr přesného dne a času pro počáteční nebo koncový bod použijte záložku Absolutní a vyberte datum a čas v kalendáři.
Pro potvrzení výběru klikněte na Nastavit datum.
Příklad ukázaný: Tento výběr zobrazí logy sebrané od 7. června 2023 v 6:00 až do nynějška.
Automatické obnovení¶
Pro automatické aktualizace zobrazení v nastaveném časovém intervalu zvolte obnovovací frekvenci:
Obnovení¶
Pro znovunačtení zobrazení s vašimi změnami klikněte na modré tlačítko pro obnovení.
Poznámka: Nevybírejte "Teď" jako počáteční bod. Protože program nemůže zobrazit data novější než "teď," není to platné a zobrazí se chybová zpráva.
Použití voliče času¶
Pro výběr konkrétnějšího časového období v rámci aktuálního časového rámce klikněte a přetáhněte na grafu.
Filtrování podle pole¶
V Průzkumníku můžete filtrovat data podle jakéhokoliv pole několika způsoby.
Použití seznamu polí¶
Použijte vyhledávací lištu pro nalezení požadovaného pole nebo procházejte seznam.
Izolace pole¶
Pro výběr, která pole chcete vidět v seznamu logů, klikněte na symbol + vedle názvu pole. Můžete vybrat více polí.
Zobrazení všech hodnot v jednom poli¶
Pro zobrazení procentuálního rozložení všech hodnot z jednoho pole klikněte na lupu vedle názvu pole (lupa se zobrazí při přejetí myší přes název pole).
Tip: Co to znamená?
Tento seznam hodnot z pole http.response.status_code porovnává, jak často uživatelé dostávají určité http odpovědní kódy. 51.4 % času uživatelé dostávají kód 404, což znamená, že stránka nebyla nalezena. 43.3 % času uživatelé dostávají kód 200, což znamená, že požadavek byl úspěšný. Vysoké procento "nenalezených" odpovědních kódů může informovat administrátora webu, že jeden nebo více často klikaných odkazů je rozbitý.
Zobrazení a filtrování detailů logů¶
Pro zobrazení detailů jednotlivých logů jako tabulku nebo v JSON, klikněte na šipku vedle časové značky. Filtry můžete aplikovat pomocí názvů polí v zobrazení tabulky.
Filtrování z rozšířeného tabulkového zobrazení¶
Můžete použít ovládací prvky v tabulkovém zobrazení pro filtrování logů:
Filtr pro logy obsahující stejnou hodnotu ve vybraném poli (update_item
v action
v příkladu)
Filtr pro logy, které NEobsahují stejnou hodnotu ve vybraném poli (update_item
v action
v příkladu)
Zobrazit procentuální rozložení hodnot v tomto poli (stejná funkce jako lupa v seznamu polí vlevo)
Přidat do seznamu zobrazených polí pro všechny viditelné logy (stejná funkce jako v seznamu polí vlevo)
Dotazovací lišta¶
Můžete filtrovat pole (ne čas) pomocí dotazovací lišty. Dotazovací lišta vám řekne, jaký dotazovací jazyk použít. Dotazovací jazyk závisí na vašem zdroji dat. Použijte Lucene Query Syntax pro data uložená pomocí ElasticSearch.
Po napsání dotazu nastavte časový rámec a klikněte na tlačítko pro obnovení. Vaše filtry budou aplikovány na viditelné příchozí logy.
Vyšetřování IP adres¶
Můžete vyšetřit IP adresy pomocí externích analyzačních nástrojů. Například můžete chtít toto udělat, pokud vidíte více podezřelých přihlášení z jedné IP adresy.
Použití externích nástrojů pro analýzu IP
1. Klikněte na IP adresu, kterou chcete analyzovat.
2. Klikněte na nástroj, který chcete použít. Budete přesměrováni na webovou stránku nástroje, kde můžete vidět výsledky analýzy IP adresy.
Použití Dashboardů¶
Dashboard je sada grafů a diagramů, které reprezentují data z vašeho systému. Dashboardy vám umožňují rychle získat přehled o tom, co se děje ve vaší síti.
Váš administrátor nastavuje dashboardy na základě zdrojů dat a polí, která jsou pro vás nejvíce užitečná. Například můžete mít dashboard, který zobrazuje grafy týkající se pouze e-mailové aktivity nebo pouze pokusů o přihlášení. Můžete mít mnoho dashboardů pro různé účely.
Můžete filtrovat data tak, aby se změnila data, která dashboard zobrazuje v rámci svých přednastavených omezení.
Jak mi mohou dashboardy pomoci?
Usnadněním určitých dat do grafu, tabulky nebo diagramu můžete získat vizuální přehled o aktivitách ve vašem systému a identifikovat trendy.
V tomto příkladu můžete vidět, že 19. června bylo odesláno a přijato velké množství e-mailů.
Navigace v Dashboardech¶
Otevření dashboardu¶
Chcete-li otevřít dashboard, klikněte na jeho název.
Ovládací prvky dashboardu¶
Nastavení časového rámce¶
Můžete změnit časový rámec, který dashboard reprezentuje. Najděte průvodce nastavením času zde. Aby se dashboard aktualizoval s novým časovým rámcem, klikněte na tlačítko obnovit.
Poznámka: Dashboardy nemají automatickou obnovovací frekvenci.
Filtrování dat dashboardu¶
Pro filtrovaní dat, která dashboard zobrazuje, použijte query bar. Query language, který musíte použít, závisí na vašem zdroji dat. Query bar vám sdělí, který query language použít. Použijte Lucene Query Syntax pro data uložená pomocí ElasticSearch.
Přesouvání widgetů¶
Můžete přemisťovat a měnit velikost jednotlivých widgetů. Pro přesunutí widgetů klikněte na tlačítko menu dashboardu a vyberte Edit.
Pro přesunutí widgetu klikněte kdekoliv na widget a tahem přesuňte. Pro změnu velikosti widgetu klikněte na pravý dolní roh widgetu a tahem změňte velikost.
Pro uložení změn klikněte na zelené tlačítko pro uložení. Pro zrušení změn klikněte na červené tlačítko pro zrušení.
Tisk dashboardů¶
Pro tisk dashboardu klikněte na tlačítko menu dashboardu a vyberte Print. Váš prohlížeč otevře nové okno, kde si můžete zvolit nastavení tisku.
Zprávy¶
Zprávy jsou vizuální reprezentace vašich dat vhodné pro tisk, podobně jako tisknutelné nástěnky. Váš administrátor vybírá, jaké informace se do vašich zpráv dostanou, na základě vašich potřeb.
Najděte a vytiskněte zprávu¶
- Vyberte zprávu ze svého seznamu nebo použijte vyhledávací lištu, abyste zprávu našli.
- Klikněte na Tisk. Váš prohlížeč otevře okno pro tisk, kde můžete upravit nastavení tisku.
Použití Exportu¶
Převádějte sady logů na stahovatelné a odesílatelné soubory pomocí Exportu. Tyto soubory můžete mít na svém počítači, prohlížet v jiném programu nebo je posílat emailem.
Co je export?
Export není soubor, ale proces, který vytváří soubor. Export obsahuje a následuje vaše instrukce pro to, jaká data do souboru zahrnout, jaký typ souboru vytvořit a co s ním udělat. Když export spustíte, vytvoříte soubor.
Proč bych měl exportovat logy?
Možnost vidět skupinu logů v jednom souboru vám může pomoci data důkladněji prozkoumat. Několik důvodů, proč byste chtěli exportovat logy:
- Pro vyšetření události nebo útoku
- Pro zaslání dat analytikovi
- Pro prozkoumání dat v programu mimo TeskaLabs LogMan.io
Navigace Exportu¶
Seznam exportů
Seznam exportů vám ukazuje všechny již provedené exporty.
Na stránce seznamu můžete:
- Zobrazit detaily exportu kliknutím na název exportu
- Stáhnout export kliknutím na ikonu cloudu vedle jeho názvu
- Smazat export kliknutím na ikonu koše vedle jeho názvu
- Hledat exporty pomocí vyhledávacího pole
Status exportu je barevně odlišen:
- Zelená: Dokončeno
- Žlutá: Probíhá
- Modrá: Naplánováno
- Červená: Selhalo
Přeskočit na:¶
Spustit export¶
Spuštění exportu přidá export na váš Seznam exportů, ale automaticky ho nestáhne. Viz Stáhnout export pro instrukce.
Spustit export na základě přednastavení¶
1. Klikněte na Nový na stránce Seznam exportů. Nyní můžete vidět přednastavené exporty:
2. Pro spuštění přednastaveného exportu, klikněte na tlačítko spuštění vedle názvu exportu.
NEBO
2. Pro editaci exportu před spuštěním, klikněte na tlačítko editace vedle názvu exportu. Proveďte změny a poté klikněte na Start. (Použijte tento průvodce pro naučení se provádět změny.)
Jakmile spustíte export, budete automaticky přesměrováni zpět na seznam exportů a váš export se objeví na vrcholu seznamu.
Poznámka
Přednastavené exporty jsou vytvořeny administrátory.
Spustit export na základě exportu, který jste již dříve spustili¶
Můžete znovu spustit export. Znovu spuštění exportu nepřepíše původní export.
1. Na stránce Seznam exportů klikněte na název exportu, který chcete znovu spustit.
2. Klikněte na Restart.
3. Zde můžete provést změny (viz tento průvodce) nebo spustit export tak, jak je.
4. Klikněte na Start.
Jakmile spustíte export, budete automaticky přesměrováni zpět na seznam exportů a váš nový export se objeví na vrcholu seznamu.
Vytvořit nový export¶
Vytvořit export z prázdného formuláře¶
1. V Seznamu exportů klikněte na Nový, poté klikněte na Vlastní.
2. Vyplňte pole.
Poznámka
Možnosti v rozbalovacích menu se mohou změnit na základě vašich výběrů.
Název
Pojmenujte export.
Zdroj dat
Vyberte zdroj dat z rozbalovacího seznamu.
Výstup
Zvolte typ souboru pro vaše data. Může to být:
- Raw: Pokud chcete stáhnout export a importovat logy do jiného software, zvolte raw. Pokud je zdroj dat Elasticsearch, formát raw souborů je .json.
- .csv: Hodnoty oddělené čárkou
- .xlsx: Formát Microsoft Excel
Kompresní formát
Zvolte, zda chcete soubor s exportem zkomprimovat (zip), nebo nechat nekomprimovaný. Zkomprimovaný soubor je menší a snadněji se posílá, a také zabírá méně místa na disku.
Cíl
Zvolte cíl pro váš soubor. Může to být:
- Stáhnout: Soubor, který můžete stáhnout do svého počítače.
- Email: Vyplňte emailová pole. Když export spustíte, email bude odeslán. Soubor s daty můžete kdykoli stáhnout na stránce Seznam exportů.
- Jupyter: Uloží soubor do Jupyter notebooku, přístupného přes stránku Nástroje. K přístupu do Jupyter notebooku potřebujete administrátorská oprávnění, takže zvolte Jupyter jako cíl pouze pokud jste administrátor.
Oddělovač
Pokud zvolíte .csv jako váš výstup, vyberte znak, který bude označovat oddělení mezi jednotlivými hodnotami v každém logu. I když CSV znamená hodnoty oddělené čárkou, můžete zvolit jiný oddělovač, jako je středník nebo mezera.
Plánování (volitelně)¶
Pro naplánování exportu místo jeho okamžitého spuštění, klikněte na Přidat plán.
-
Naplánovat jednorázově:
- Pro jednorázové spuštění exportu v budoucnu zadejte požadovaný datum a čas ve formátu
YYYY-MM-DD HH:mm
, například2023-12-31 23:59
(31. prosince 2023, 23:59).
- Pro jednorázové spuštění exportu v budoucnu zadejte požadovaný datum a čas ve formátu
-
Naplánovat opakovaný export:
-
Pro nastavení exportu ke spuštění automaticky v pravidelném intervalu použijte
cron
syntaxi. Více ocron
se můžete dozvědět na Wikipedii a použít tento nástroj a tato příklady od Cronitoru pro pomoc při psanícron
výrazů. -
Pole Plán podporuje také náhodné použití
R
a Vixie cron-style@
klíčové výrazy.
-
Dotaz
Zadejte dotaz pro filtrování určitých dat. Dotaz určuje, která data se budou exportovat, včetně časového rámce logů.
Varování
Musíte zahrnout dotaz do každého exportu. Pokud spustíte export bez dotazu, všechna data uložená ve vašem programu budou exportována bez filtru pro čas nebo obsah. To může vytvořit extrémně velký soubor a způsobit zátěž na komponenty pro ukládání dat, a soubor pravděpodobně nebude užitečný pro vás ani pro analytiky.
Pokud náhodou spustíte export bez dotazu, můžete export smazat, zatímco stále běží, na stránce Seznam exportů kliknutím na ikonu koše.
TeskaLabs LogMan.io používá Elasticsearch Query DSL (Domain Specific Language).
Zde je kompletní průvodce Elasticsearch Query DSL.
Příklad dotazu:
{
"bool": {
"filter": [
{
"range": {
"@timestamp": {
"gte": "now-1d/d",
"lt": "now/d"
}
}
},
{
"prefix": {
"event.dataset": {
"value": "microsoft-office-365"
}
}
}
]
}
}
Rozbor dotazu:
bool
: To nám říká, že celý dotaz je Boolean dotaz, který kombinuje několik podmínek, jako jsou "must," "should," a "must not." Zde se používá filter
pro nalezení vlastností, které data musí mít, aby byla zahrnuta do exportu. filter
může mít více podmínek.
range
je první podmínka filtru. Jelikož se vztahuje k poli pod ním, což je @timestamp
, bude filtrovat logy na základě rozsahu hodnot v poli timestamp.
@timestamp
nám říká, že dotaz filtruje čas, takže exportuje logy z určitého časového rámce.
gte
: To znamená "větší nebo rovno," což je nastavena na hodnotu now-1d/d
, což znamená, že nejstarší timestamp (první log) bude přesně jeden den starý v době spuštění exportu.
lt
znamená "menší než," a je nastaveno na now/d
, takže nejnovější timestamp (poslední log) bude ten nejnovější v době spuštění exportu ("now").
prefix
je druhá filtrační podmínka. Hledá logy, kde hodnota pole, v tomto případě event.dataset
, začíná na microsoft-office-365
.
Takže, co tento dotaz znamená?
Tento export zobrazí všechny logy z Microsoft Office 365 za posledních 24 hodin.
3. Přidat sloupce
Pro .csv a .xlsx soubory je třeba specifikovat, jaké sloupce chcete mít ve vašem dokumentu. Každý sloupec reprezentuje datové pole. Pokud nespecifikujete žádné sloupce, výsledná tabulka bude mít všechny možné sloupce, takže tabulka může být mnohem větší, než očekáváte nebo potřebujete.
Můžete vidět seznam všech dostupných datových polí v Průzkumník. Chcete-li zjistit, která pole jsou relevantní pro logy, které exportujete, prozkoumejte jednotlivý log v Průzkumník.
- Pro přidání sloupce klikněte na Přidat. Zadejte název sloupce.
- Pro smazání sloupce klikněte na -.
- Pro změnu pořadí sloupců klikněte a přetáhněte šipky.
Varování
Stisknutí enter po zadání názvu sloupce spustí export.
Tento příklad byl stažen z exportu uvedeného výše jako .csv soubor, poté oddělen do sloupců pomocí Microsoft Excel Převést text na sloupce čaroděj. Můžete vidět, že sloupce zde odpovídají sloupcům specifikovaným v exportu.
4. Spustit export stisknutím Start.
Jakmile spustíte export, budete automaticky přesměrováni zpět na seznam exportů a váš export se objeví na vrcholu seznamu.
Stáhnout export¶
1. Na stránce Seznam exportů klikněte na ikonu cloudu pro stažení.
NEBO
1. Na stránce Seznam exportů klikněte na název exportu.
2. Klikněte na Stáhnout.
Váš prohlížeč by měl automaticky zahájit stahování.
Smazat export¶
1. Na stránce Seznam exportů klikněte na ikonu koše.
NEBO
1. Na stránce Seznam exportů klikněte na název exportu.
2. Klikněte na Odstranit.
Export by měl zmizet ze seznamu.
Přidat export do knihovny¶
Poznámka
Tato funkce je dostupná pouze pro administrátory.
Pokud se vám líbí export, který jste vytvořili nebo upravili, můžete jej uložit do knihovny jako přednastavení pro budoucí použití.
1. Na stránce Seznam exportů klikněte na název exportu.
2. Klikněte na Uložit do Knihovny.
Když kliknete na Nový na stránce Seznam exportů, vaše nové přednastavení exportu by mělo být v seznamu.
Přehled vlasností
Domovská stránka¶
Domovská stránka vám poskytuje přehled o vašich zdrojích dat a kritických příchozích událostech.
Možnosti zobrazení¶
Graf a seznam¶
Pro přepnutí mezi grafem a seznamem klikněte na tlačítko seznamu.
Získání dalších podrobností¶
Kliknutím na kteroukoli část grafu se dostanete do Průzkumníka, kde uvidíte seznam logů, které tvoří tuto část grafu. Odtud můžete tyto logy prozkoumat a filtrovat.
Zde můžete vidět, že Průzkumník automaticky filtruje události z vybrané datové sady (z grafu na domovské stránce), event.dataset:devolutions
.
Průzkumník¶
Průzkumník vám poskytuje přehled o všech logách, které se sbírají v reálném čase. Zde můžete filtrovat data podle času a pole.
Navigace v Průzkumníku¶
Pojmy¶
Celkový počet: Celkový počet logů ve zvoleném časovém období.
Agregováno podle: V sloupcovém grafu každý sloupec představuje počet logů, které byly shromážděny v časovém intervalu. Pomocí Agregováno podle můžete zvolit časový interval. Například Agregováno podle: 30m znamená, že každý sloupec v grafu zobrazuje počet všech logů shromážděných během 30 minutového období. Pokud změníte na Agregováno podle: hodina, pak každý sloupec představuje jednu hodinu logů. Dostupné možnosti se mění na základě celkového časového intervalu, který prohlížíte v Průzkumníku.
Filtrování dat¶
Změňte časové období, ze kterého se zobrazují logy, a filtrujte logy podle pole.
Tip: Proč filtrovat data?
Logy obsahují mnoho informací, více než je potřeba k většině úkolů. Při filtrování dat si vybíráte, které informace vidíte. To vám může pomoci lépe pochopit vaši síť, identifikovat trendy a dokonce lovit hrozby.
Příklady:
- Chcete vidět data o přihlášení pouze jednoho uživatele, takže filtrujete data tak, aby zobrazovala logy obsahující jeho uživatelské jméno.
- Měli jste bezpečnostní událost ve středu večer a chcete se o ní dozvědět více, takže filtrujete data pro zobrazení logů z této doby.
- Všimli jste si, že nevidíte žádná data z jednoho vašeho síťového zařízení. Můžete filtrovat data tak, aby zobrazovala všechny logy pouze z tohoto zařízení. Nyní můžete vidět, kdy data přestala přicházet a co byla poslední událost, která mohla způsobit problém.
Změna časového období¶
Můžete prohlížet logy z určeného časového období. Nastavte časové období výběrem počátečního a koncového bodu pomocí tohoto nástroje:
Pamatujte: Jakmile změníte časové období, stiskněte modré tlačítko obnovy, aby se aktualizovala vaše stránka.
Použití nástroje pro nastavení času¶
Nastavení relativního počátečního/konečného bodu¶
Chcete-li nastavit počáteční nebo koncový bod na čas relativní k aktuálnímu času, použijte kartu Relativní.
Rychlá nastavení času
Použijte rychlé možnosti nyní- ("nyní mínus") k nastavení časového období na přednastavené hodnoty jedním kliknutím. Výběr jedné z těchto možností ovlivňuje oba počáteční i koncový bod. Například pokud zvolíte nyní-1 týden, počáteční bod bude před týdnem a koncový bod bude "nyní". Výběr možnosti nyní- z koncového bodu udělá totéž jako výběr možnosti nyní- z počátečního bodu. (Není možné použít možnosti nyní- k nastavení koncového bodu na cokoliv jiného než "nyní.")
Rozbalovací možnosti
Chcete-li nastavit relativní čas (například před 15 minutami) pro počáteční nebo koncový bod, použijte relativní časové možnosti pod rychlými nastaveními. Vyberte jednotku času z rozbalovacího seznamu a zadejte nebo klikněte na požadované číslo.
Chcete-li volbu potvrdit, klikněte na Nastavit relativní čas a zobrazte logy kliknutím na tlačítko obnovy.
Příklad zobrazen: Tato volba zobrazí logy shromážděné od jednoho dne zpět až do současnosti.
Nastavení přesného počátečního/konečného bodu¶
Chcete-li zvolit přesné datum a čas pro počáteční nebo koncový bod, použijte kartu Absolutní a vyberte datum a čas v kalendáři.
Chcete-li volbu potvrdit, klikněte na Nastavit datum.
Příklad zobrazen: Tato volba zobrazí logy shromážděné od 7. června 2023, 6:00 až do současnosti.
Automatické obnovení¶
Chcete-li aktualizovat zobrazení automaticky ve stanoveném časovém intervalu, vyberte frekvenci obnovení:
Obnovení¶
Chcete-li načíst zobrazení s vašimi změnami, klikněte na modré tlačítko obnovy.
Poznámka: Nevybírejte "Nyní" jako počáteční bod. Program nemůže zobrazit data novější než "nyní," takže to není platné a zobrazí se chybová zpráva.
Použití výběru času¶
Chcete-li vybrat konkrétnější časové období v rámci aktuálního časového období, klikněte a přetáhněte na grafu.
Filtrování podle pole¶
V Průzkumníku můžete filtrovat data podle jakéhokoli pole několika způsoby.
Použití seznamu polí¶
Použijte vyhledávací pole k vyhledání požadovaného pole nebo projděte seznam.
Izolování polí¶
Chcete-li zvolit, která pole se zobrazují v seznamu logů, klikněte na symbol + vedle názvu pole. Můžete vybrat více polí.
Zobrazení všech hodnot v jednom poli¶
Chcete-li zobrazit procentuální rozložení všech hodnot z jednoho pole, klikněte na lupu vedle názvu pole (lupa se zobrazí po najetí myší na název pole).
Tip: Co to znamená?
Tento seznam hodnot z pole http.response.status_code porovnává, jak často uživatelé dostávají určité http odpovědní kódy. 51,4 % času uživatelé dostávají kód 404, což znamená, že stránka nebyla nalezena. 43,3 % času uživatelé dostávají kód 200, což znamená, že požadavek byl úspěšný. Vysoké procento odpovědí "stránka nenalezena" může informovat administrátora webu, že jeden nebo více jeho často kliknutých odkazů je nefunkční.
Zobrazení a filtrování detailů logů¶
Chcete-li zobrazit detaily jednotlivých logů jako tabulku nebo v JSON, klikněte na šipku vedle časové značky. Můžete použít pole v zobrazení tabulky pro aplikaci filtrů.
Filtrování z rozšířeného pohledu tabulky¶
Můžete použít ovládací prvky v zobrazení tabulky pro filtrování logů:
Filtrovat logy, které obsahují stejnou hodnotu ve vybraném poli (update_item
v action
v příkladě)
Filtrovat logy, které NEobsahují stejnou hodnotu ve vybraném poli (update_item
v action
v příkladě)
Zobrazit procentuální rozložení hodnot v tomto poli (stejná funkce jako lupa v seznamu polí vlevo)
Přidat do seznamu zobrazovaných polí pro všechny viditelné logy (stejná funkce jako v seznamu polí vlevo)
Hledací lišta¶
Můžete filtrovat pole (ne čas) pomocí hledací lišty. Hledací lišta vám řekne, který dotazovací jazyk používat. Dotazovací jazyk závisí na vašem zdroji dat. Použijte Lucene Query Syntax pro data uložená pomocí ElasticSearch.
Po zadání dotazu nastavte časový rámec a klikněte na tlačítko obnovy. Vaše filtry se uplatní na viditelné příchozí logy.
Vyšetřování IP adres¶
Můžete vyšetřovat IP adresy pomocí externích nástrojů pro analýzu. Můžete to například chtít udělat, když vidíte více podezřelých přihlášení z jedné IP adresy.
Použití externích nástrojů pro analýzu IP
1. Klikněte na IP adresu, kterou chcete analyzovat.
2. Klikněte na nástroj, který chcete použít. Budete přesměrováni na webovou stránku nástroje, kde můžete vidět výsledky analýzy IP adresy.
Dashboardy¶
Dashboard je sada grafů a diagramů, které představují data z vašeho systému. Dashboardy vám umožňují rychle získat přehled o tom, co se děje ve vaší síti.
Váš administrátor nastaví dashboardy na základě datových zdrojů a polí, která jsou pro vás nejvíce užitečná. Například můžete mít dashboard, který zobrazuje grafy týkající se pouze e-mailové aktivity, nebo pouze pokusů o přihlášení. Můžete mít mnoho dashboardů pro různé účely.
Data můžete filtrovat tak, aby se změnily údaje, které dashboard zobrazuje v rámci svých předem nastavených omezení.
Jak mi mohou dashboardy pomoci?
Když máte určitá data uspořádána do grafu, tabulky nebo diagramu, můžete získat vizuální přehled o aktivitě ve vašem systému a identifikovat trendy.
V tomto příkladu můžete vidět, že velký objem e-mailů byl odeslán a přijat 19. června.
Navigace v dashboardech¶
Otevření dashboardu¶
Chcete-li otevřít dashboard, klikněte na jeho název.
Ovládání dashboardu¶
Nastavení časového rámce¶
Můžete změnit časový rámec, který dashboard představuje. Najděte návod k nastavení času zde. Pro obnovení dashboardu s novým časovým rámcem klikněte na tlačítko obnovit.
Poznámka: V Dashboardech není žádná automatická obnova.
Filtrování dat na dashboardu¶
Chcete-li filtrovat data, která dashboard zobrazuje, použijte dotazovací lištu. Dotazovací jazyk, který potřebujete použít, závisí na vašem datovém zdroji. Dotazovací lišta vám sdělí, jaký dotazovací jazyk použít. Použijte Lucene Query Syntax pro data uložená pomocí ElasticSearch.
Příklad výše používá Lucene Query Syntax.
Přesunování widgetů¶
Můžete přemístit a změnit velikost jednotlivých widgetů. Chcete-li přesouvat widgety, klikněte na tlačítko menu dashboardu a vyberte Upravit.
Chcete-li přesunout widget, klikněte na kterékoli místo na widgetu a táhněte. Chcete-li změnit velikost widgetu, klikněte na pravý dolní roh widgetu a táhněte.
Pro uložení změn klikněte na zelené tlačítko uložit. Pro zrušení změn klikněte na červené tlačítko zrušit.
Tisk dashboardů¶
Chcete-li vytisknout dashboard, klikněte na tlačítko menu dashboardu a vyberte Tisk. Váš prohlížeč otevře okno, kde si můžete vybrat nastavení tisku.
Reporty¶
Reporty jsou pro tisk optimalizované vizuální reprezentace vašich dat, podobně jako tisknutelné řídicí panely. Váš administrátor volí, jaké informace budou v reportech obsaženy na základě vašich potřeb.
Najděte a vytiskněte report¶
- Vyberte report ze svého seznamu, nebo použijte vyhledávací lištu k nalezení vašeho reportu.
- Klikněte na Tisk. Váš prohlížeč otevře okno pro tisk, ve kterém můžete zvolit nastavení tisku.
Export¶
Převádějte sady logů do stahovatelných, zasílatelných souborů v Exportu. Tyto soubory můžete uchovávat na svém počítači, zkoumat je v jiném programu nebo je posílat e-mailem.
Co je export?
Export není soubor, ale proces, který vytváří soubor. Export obsahuje a následuje vaše pokyny, které data umístit do souboru, jaký typ souboru vytvořit a co s ním udělat. Když spustíte export, vytvoříte soubor.
Proč bych měl exportovat logy?
Pohled na skupinu logů v jednom souboru vám může pomoci lépe prozkoumat data. Několik důvodů, proč byste mohli chtít exportovat logy, jsou:
- K prozkoumání události nebo útoku
- K odeslání dat analytikovi
- K prozkoumání dat v programu mimo TeskaLabs LogMan.io
Navigace v exportu¶
Seznam exportů
Seznam exportů vám zobrazuje všechny exporty, které byly spuštěny.
Na stránce se seznamem můžete:
- Vidět podrobnosti exportu kliknutím na název exportu
- Stáhnout export kliknutím na ikonu cloudu vedle jeho názvu
- Smazat export kliknutím na ikonu koše vedle jeho názvu
- Vyhledávat exporty pomocí vyhledávací lišty
Stav exportu je kódován barvami:
- Zelená: Dokončeno
- Žlutá: Probíhá
- Modrá: Naplánováno
- Červená: Selhalo
Přeskočit na:¶
Spustit export¶
Spuštění exportu přidá export do vašeho Seznamu exportů, ale automaticky export nestáhne. Pokyny k tomu naleznete v části Stáhnout export.
Spustit export na základě přednastavených šablon¶
1. Na stránce Seznam exportů klikněte na Nový. Nyní vidíte přednastavené šablony exportů:
2. Chcete-li spustit přednastavený export, klikněte na tlačítko spuštění vedle názvu exportu.
NEBO
2. Chcete-li před spuštěním upravit export, klikněte na tlačítko úprav vedle názvu exportu. Proveďte změny a poté klikněte na Spustit. (Použijte tento návod, abyste se dozvěděli více o provádění změn.)
Jakmile spustíte export, budete automaticky přesměrováni zpět na seznam exportů a váš export se objeví na vrcholu seznamu.
Note
Předvolby vytvářejí administrátoři.
Spustit export na základě již dříve spuštěného exportu¶
Můžete znovu spustit již dříve spuštěný export. Opětovné spuštění exportu nepřepíše původní export.
1. Na stránce Seznam exportů klikněte na název exportu, který chcete znovu spustit.
2. Klikněte na Restartovat.
3. Můžete zde provést změny (viz tento návod) nebo export spustit tak, jak je.
4. Klikněte na Spustit.
Jakmile spustíte export, budete automaticky přesměrováni zpět na seznam exportů a váš nový export se objeví na vrcholu seznamu.
Vytvořit nový export¶
Vytvořit export z prázdného formuláře¶
1. V Seznamu exportů klikněte na Nový, poté klikněte na Vlastní.
2. Vyplňte pole.
Poznámka
Volby v rozbalovacích nabídkách se mohou měnit na základě provedených výběrů.
Název
Pojmenujte export.
Zdroj dat
Vyberte zdroj dat z rozbalovací nabídky.
Výstup
Vyberte typ souboru pro svá data. Může být:
- Surový: Pokud si přejete stáhnout export a importovat logy do jiného softwaru, zvolte surový. Pokud je zdroj dat Elasticsearch, formát surového souboru je .json.
- .csv: Hodnoty oddělené čárkou
- .xlsx: Formát Microsoft Excel
Kompresie
Zvolte, zda chcete exportní soubor zabalit, nebo jej nechat nekomprimovaný. Zabalený soubor je komprimovaný, a tudíž menší, což usnadňuje jeho odeslání a zabírá méně místa na vašem počítači.
Cíl
Vyberte cíl pro váš soubor. Může to být:
- Stáhnout: Soubor, který můžete stáhnout do svého počítače.
- E-mail: Vyplňte e-mailová pole. Když spustíte export, e-mail se odešle. Data si stále můžete kdykoliv stáhnout v Seznamu exportů.
- Jupyter: Uloží soubor do Jupyter notebooku, který můžete získat přístup na stránce Nástroje. K přístupu do Jupyter notebooku potřebujete mít administrativní oprávnění, takže si jako cíl vyberte Jupyter, pouze pokud jste administrátor.
Oddělovač
Pokud vyberete jako výstup .csv, zvolte, jaký znak bude označovat oddělení mezi jednotlivými hodnotami v každém logu. I když CSV znamená hodnoty oddělené čárkou, můžete použít jiný oddělovač, například středník nebo mezera.
Plán (volitelný)¶
Chcete-li plánovat export místo jeho okamžitého spuštění, klikněte na Přidat plán.
-
Jednorázový plán:
- Chcete-li export spustit jednorázově v budoucnu, zadejte požadované datum a čas ve formátu
YYYY-MM-DD HH:mm
, například2023-12-31 23:59
(31. prosince 2023, ve 23:59).
- Chcete-li export spustit jednorázově v budoucnu, zadejte požadované datum a čas ve formátu
-
Pravidelný export:
-
Chcete-li nastavit export, který se automaticky spustí v pravidelném intervalu, použijte syntaxi
cron
. Více o cron se můžete dozvědět na Wikipedii a použijte tento nástroj a tyto příklady od Cronitoru k psaní cron výrazů. -
Pole Plán také podporuje náhodné použití
R
a výrazy klíčových slov ve stylu Vixie cron@
.
-
Dotaz
Zadejte dotaz pro filtrování určitých dat. Dotaz určuje, která data se mají exportovat, včetně časového rámce logů.
Warning
V každém exportu musíte použít dotaz. Pokud spustíte export bez dotazu, veškerá data uložená ve vašem programu budou exportována bez filtru pro čas nebo obsah. To by mohlo vytvořit extrémně velký soubor a zatížit komponenty pro ukládání dat a soubor pravděpodobně nebude užitečný ani pro vás, ani pro analytiky.
Pokud omylem spustíte export bez dotazu, můžete export smazat, zatímco stále běží v Seznamu exportů kliknutím na tlačítko koše.
TeskaLabs LogMan.io používá Elasticsearch Query DSL (Domain Specific Language).
Zde je kompletní příručka Elasticsearch Query DSL.
Příklad dotazu:
{
"bool": {
"filter": [
{
"range": {
"@timestamp": {
"gte": "now-1d/d",
"lt": "now/d"
}
}
},
{
"prefix": {
"event.dataset": {
"value": "microsoft-office-365"
}
}
}
]
}
}
Rozbor dotazu:
bool
: To nám říká, že celý dotaz je binární, což kombinuje více podmínek jako "musí", "měl by" a "nesmí". Zde se používá filter
k nalezení charakteristik, které data musí mít, aby se dostala do exportu. filter
může mít více podmínek.
range
je první podmínka filtru. Jelikož se odkazuje na pole pod sebou, což je @timestamp
, bude filtrovat logy na základě rozsahu hodnot v poli timestamp.
@timestamp
nám říká, že dotaz filtruje čas, takže bude exportovat logy z určitého časového období.
gte
: To znamená "větší než nebo rovno", což je nastaveno na hodnotu now-1d/d
, což znamená, že nejstarší časové razítko (první log) bude z přesně jednoho dne zpět v okamžiku, kdy spustíte export.
lt
znamená "méně než" a je nastaveno na now/d
, takže nejnovější časové razítko (poslední log) bude nejnovější v okamžiku spuštění exportu ("teď").
prefix
je druhá podmínka filtru. Hledá logy, kde hodnota pole, v tomto případě event.dataset
, začíná na microsoft-office-365
.
Co tento dotaz znamená?
Tento export zobrazí všechny logy z Microsoft Office 365 za posledních 24 hodin.
3. Přidejte sloupce
Pro soubory .csv a .xlsx musíte specifikovat, jaké sloupce chcete mít ve svém dokumentu. Každý sloupec představuje datové pole. Pokud nespecifikujete žádné sloupce, výsledná tabulka bude mít všechny možné sloupce, takže tabulka může být mnohem větší, než očekáváte nebo potřebujete.
Seznam všech dostupných datových polí naleznete v Průzkumníku. Chcete-li zjistit, jaká pole jsou relevantní pro logy, které exportujete, prozkoumejte jednotlivé logy v Průzkumníku.
- Chcete-li přidat sloupec, klikněte na Přidat. Zadejte název sloupce.
- Chcete-li sloupec odebrat, klikněte na -.
- Chcete-li sloupce přeuspořádat, klikněte a přetáhněte šipky.
Varování
Stisknutí enter po zadání názvu sloupce spustí export.
Tento příklad byl stažen z výše uvedeného exportu jako .csv soubor a poté oddělen do sloupců pomocí Průvodce převodem textu na sloupce Microsoft Excel. Můžete vidět, že sloupce zde odpovídají sloupcům specifikovaným v exportu.
4. Spusťte export stisknutím Start.
Jakmile spustíte export, budete automaticky přesměrováni zpět na seznam exportů a váš export se objeví na vrcholu seznamu.
Stáhnout export¶
1. Na stránce Seznam exportů klikněte na tlačítko cloudu ke stažení.
NEBO
1. Na stránce Seznam exportů klikněte na název exportu.
2. Klikněte na Stáhnout.
Váš prohlížeč by měl automaticky zahájit stahování.
Smazat export¶
1. Na stránce Seznam exportů klikněte na tlačítko koše.
NEBO
1. Na stránce Seznam exportů klikněte na název exportu.
2. Klikněte na Odstranit.
Export by měl zmizet ze seznamu.
Přidat export do knihovny¶
Note
Tato funkce je k dispozici pouze administrátorům.
Pokud se vám líbí export, který jste vytvořili nebo upravili, můžete jej uložit do své knihovny jako přednastavenou šablonu pro budoucí použití.
1. Na stránce Seznam exportů klikněte na název exportu.
2. Klikněte na Uložit do knihovny.
Když na stránce Seznam exportů kliknete na Nový, měl by se váš nový přednastavený export objevit v seznamu.
Knihovna¶
Funkce pro administrátory
Knihovna je funkce pro administrátory. Knihovna má významný dopad na to, jak TeskaLabs LogMan.io funguje. Někteří uživatelé nemají k Knihovně přístup.
Knihovna uchovává položky (soubory), které určují, co vidíte při používání TeskaLabs LogMan.io. Položky v Knihovně určují například vaši domovskou stránku, dashboardy, reporty, exporty a některé funkce SIEM.
Když obdržíte TeskaLabs LogMan.io, Knihovna již obsahuje soubory. Tyto soubory můžete přizpůsobit vašim potřebám.
Knihovna podporuje tyto typy souborů:
- .html
- .json
- .md
- .txt
- .yaml
- .yml
Warning
Změna položek v Knihovně má vliv na to, jak TeskaLabs LogMan.io a TeskaLabs SIEM fungují. Pokud si nejste jisti změnami v Knihovně, kontaktujte Podporu.
Navigace v Knihovně¶
Některé položky mají další možnosti v pravém horním rohu obrazovky:
Vyhledávání položek¶
Pro nalezení položky použijte vyhledávací pole, nebo procházejte složky.
Pokud přejdete do složky v Knihovně a chcete se vrátit k vyhledávacímu poli, klikněte znovu na Knihovna.
Přidávání položek do Knihovny¶
Warning
Nepokoušejte se přidávat jednotlivé položky do knihovny pomocí funkce Obnovit. Obnovit je určeno pouze pro importování celé knihovny.
Vytváření položek ve složce¶
Položku můžete vytvořit přímo v určitých složkách. Pokud je možné přidat položku, zobrazí se tlačítko Vytvořit novou položku ve složce (složka) při kliknutí na složku.
- Pro přidání položky klikněte na Vytvořit novou položku ve složce (složka).
- Pojmenujte položku, vyberte příponu souboru z rozbalovací nabídky a klikněte na Vytvořit.
- Pokud se položka neobjeví okamžitě, aktualizujte stránku, a vaše položka by se měla objevit v Knihovně.
Přidání položky zkopírováním existující položky¶
- Klikněte na položku, kterou chcete zkopírovat.
- Klikněte na tlačítko ... v horní části.
- Klikněte na Kopírovat.
- Přejmenujte položku, vyberte příponu souboru z rozbalovací nabídky, a klikněte na Kopírovat.
- Pokud se položka neobjeví okamžitě, aktualizujte stránku, a vaše položka by se měla objevit v Knihovně.
Úprava položky v Knihovně¶
- Klikněte na položku, kterou chcete upravit.
- Pro úpravu položky klikněte na Upravit.
- Pro uložení změn klikněte na Uložit, nebo ukončete editor bez uložení kliknutím na Zrušit.
- Pokud se vaše úpravy neprojeví okamžitě, aktualizujte stránku, a vaše změny by měly být uloženy.
Odstranění položky z Knihovny¶
- Klikněte na položku, kterou chcete odstranit.
- Klikněte na tlačítko ... v horní části.
- Klikněte na Odstranit a potvrďte Ano, pokud vás váš prohlížeč vyzve.
- Pokud se položka neodstraní okamžitě, aktualizujte stránku, a odstraněná položka by měla zmizet.
Deaktivace položek¶
Můžete dočasně deaktivovat položku. Zůstane ve vaší knihovně, ale její dopad na váš systém bude pozastaven.
Pro deaktivaci položky klikněte na položku a klikněte na Deaktivovat.
Položku můžete kdykoliv znovu aktivovat kliknutím na Aktivovat.
Note
Nemůžete číst obsah položky, když je deaktivovaná.
Zálohování Knihovny¶
Svoji celou Knihovnu můžete zálohovat na svůj počítač nebo jiná externí úložiště exportováním Knihovny.
Pro export a stažení obsahu Knihovny klikněte na Akce, poté klikněte na Zálohovat. Váš prohlížeč zahájí stahování.
Obnovení knihovny ze záložního souboru¶
Warning
Použití Obnovit znamená importované celé knihovny z vašeho počítače. Obnovit je určeno k obnově knihovny z verze zálohy, takže přepíše (smaže) stávající obsah vaší Knihovny v TeskaLabs LogMan.io. Knihovnu obnovujte POUZE, pokud plánujete nahradit veškerý obsah Knihovny soubory, které importujete.
Obnovení¶
- Klikněte na Akce.
- Klikněte na Obnovit.
- Vyberte soubor z vašeho počítače. Můžete importovat pouze soubory tar.gz.
- Klikněte na Importovat.
Pamatujte, že použití Obnovit a Importovat přepíše celou vaši knihovnu.
Vyhledávání¶
Administrátorská funkce
Vyhledávání je administrátorská funkce. Někteří uživatelé nemají přístup k Vyhledáváním.
Můžete použít vyhledávání k získání a uložení dalších informací z externích zdrojů. Další informace obohatí vaše data a přidají relevantní kontext. Díky tomu jsou vaše data hodnotnější, protože můžete data analyzovat hlouběji. Například můžete uložit uživatelská jména, aktivní uživatele, aktivní VPNky a podezřelé IP adresy.
Tip
Můžete si přečíst více o Vyhledávání zde v Referenční příručce.
Navigace Vyhledáváním¶
Vytvoření nového vyhledávání¶
Pro vytvoření nového vyhledávání:
- Klikněte na Vytvořit vyhledávání.
- Vyplňte pole: Název, Krátký popis, Podrobný popis a Klíč(e).
- Pro přidání dalšího klíče klikněte na +.
- Zvolte, zda chcete přidat nebo nepřidat expiraci.
- Klikněte na Uložit.
Vyhledání vyhledávání¶
Použijte vyhledávací lištu pro nalezení konkrétního vyhledávání. Použití vyhledávací lišty neprohledává obsah vyhledávání, pouze názvy vyhledávání. Pro zobrazení všech vyhledávání znovu po použití vyhledávací lišty vymažte vyhledávací lištu a stiskněte Enter
nebo Return
.
Zobrazení a úprava detailů vyhledávání¶
Zobrazení klíčů/položek vyhledávání¶
Pro zobrazení klíčů a hodnot, nebo položek, vyhledávání klikněte na tlačítko ..., a klikněte na Položky.
Úprava klíčů/položek vyhledávání¶
Z Seznamu vyhledávání klikněte na tlačítko ... a klikněte na Položky. To vás vezme na stránku individuálního vyhledávání.
Přidání: Pro přidání položky klikněte na Přidat položku.
Úprava: Pro úpravu stávající položky klikněte na tlačítko ... na řádku položky a klikněte na Upravit.
Smazání: Pro smazání položky klikněte na tlačítko ... na řádku položky a klikněte na Smazat.
Nezapomeňte kliknout na Uložit po provedení změn.
Zobrazení popisu vyhledávání¶
Pro zobrazení podrobného popisu vyhledávání klikněte na tlačítko ... na stránce Seznam vyhledávání a klikněte na Informace.
Úprava popisu vyhledávání¶
- Klikněte na tlačítko ... na stránce Seznam vyhledávání a klikněte na Informace. To vás vezme na stránku informací vyhledávání.
- Klikněte na Upravit vyhledávání ve spodní části.
- Po provedení změn klikněte na Uložit, nebo klikněte na Zrušit pro ukončení režimu úprav.
Smazání vyhledávání¶
Pro smazání vyhledávání:
-
Klikněte na tlačítko ... na stránce Seznam vyhledávání a klikněte na Informace. To vás vezme na stránku informací vyhledávání.
-
Klikněte na Smazat vyhledávání.
Nástroje¶
Funkce administrátora
Nástroje jsou funkcí pro administrátora. Změny, které provedete při návštěvě externích nástrojů, mohou mít významný dopad na fungování TeskaLabs LogMan.io. Někteří uživatelé nemají přístup na stránku Nástroje.
Stránka Nástroje poskytuje rychlý přístup k externím programům, které spolupracují nebo mohou být použity společně s TeskaLabs LogMan.io.
Používání externích nástrojů¶
Pro automatické zabezpečené přihlášení k nástroji klikněte na ikonu nástroje.
Upozornění
- I když jsou data tenantů v TeskaLabs LogMan.io UI oddělena, data tenantů nejsou oddělena v rámci těchto nástrojů.
- Změny, které provedete v Zookeeper, Kafka a Kibana, by mohly poškodit vaše nasazení TeskaLabs LogMan.io.
Údržba¶
Funkce administrátora
Údržba je funkcí administrátora. To, co v rámci Údržby provádíte, má významný dopad na způsob, jakým TeskaLabs LogMan.io funguje. Někteří uživatelé nemají přístup k Údržbě.
Sekce Údržby zahrnuje Konfiguraci a Služby.
Konfigurace¶
Konfigurace obsahuje soubory JSON, které určují některé komponenty, které můžete vidět a používat v TeskaLabs LogMan.io. Například Konfigurace zahrnuje:
- Stránku Průzkumníka
- Postranní panel
- Tenants
- Stránku Nástrojů
Upozornění
Konfigurační soubory mají významný dopad na způsob, jakým TeskaLabs LogMan.io funguje. Pokud potřebujete pomoc s konfigurací uživatelského rozhraní, kontaktujte Podporu.
Základní a Pokročilý režim¶
Můžete přepínat mezi Základním a Pokročilým režimem pro konfigurační soubory.
Základní má vyplňovací pole. Pokročilý zobrazuje soubor ve formátu JSON. Chcete-li zvolit režim, klikněte na Základní nebo Pokročilý v pravém horním rohu.
Úprava konfiguračního souboru¶
Chcete-li konfigurační soubor upravit, klikněte na název souboru, zvolte preferovaný režim a proveďte změny. Soubor je vždy editovatelný - nemusíte na nic klikat, aby bylo možné začít upravovat. Nezapomeňte kliknout na Uložit, až budete hotovi.
Služby¶
Služby vám ukazují všechny služby a mikroservices ("mini programy"), které tvoří infrastrukturu TeskaLabs LogMan.io.
Upozornění
Vzhledem k tomu, že TeskaLabs LogMan.io je tvořen mikroservices, zásah do mikroservices může mít významný dopad na výkon programu. Pokud potřebujete pomoc s mikroservices, kontaktujte Podporu.
Zobrazení detailů služby¶
Chcete-li zobrazit detaily služby, klikněte na šipku vlevo od názvu služby.
Auth: Kontrola přístupu uživatelů¶
Funkce pro administrátory
Auth je funkce pro administrátory. Má významný dopad na lidi používající TeskaLabs LogMan.io. Někteří uživatelé nemají přístup na stránky Auth.
Sekce Auth (autorizace) zahrnuje všechny ovládací prvky, které administrátoři potřebují k řízení uživatelů a tenantů.
Přihlašovací údaje¶
Přihlašovací údaje jsou uživatelé. Z obrazovky Přihlašovací údaje můžete vidět:
- Jméno: Uživatelské jméno, které někdo používá k přihlášení
- Tenanti: Tenanti, ke kterým má tento uživatel přístup (viz Tenanti)
- Role: Soubor oprávnění, které tento uživatel má (viz Role)
Vytvoření nových přihlašovacích údajů¶
1. Pro vytvoření nového uživatele klikněte na Vytvořit nové přihlašovací údaje.
2. Na kartě Vytvořit zadejte uživatelské jméno. Pokud chcete osobě poslat e-mail s pozvánkou k nastavení nového hesla, zadejte její e-mailovou adresu a zaškrtněte políčko Poslat pokyny k nastavení hesla.
3. Klikněte na Vytvořit přihlašovací údaje.
Nové přihlašovací údaje se objeví v seznamu Přihlašovací údaje. Pokud jste zaškrtli políčko Poslat pokyny k nastavení hesla, nový uživatel by měl obdržet e-mail.
Úprava přihlašovacích údajů¶
Pro úpravu přihlašovacího údaje klikněte na uživatelské jméno a poté klikněte na Upravit v sekci, kterou chcete změnit. Nezapomeňte kliknout na Uložit pro uložení změn nebo klikněte na Zrušit pro ukončení editoru.
Tenanti¶
Tenant je entita, která shromažďuje data z několika zdrojů. Každý tenant má izolovaný prostor pro shromažďování a správu svých dat. (Data každého tenanta jsou v UI zcela oddělena od dat ostatních tenantů.) Jedno nasazení TeskaLabs LogMan.io může zvládnout mnoho tenantů (multitenance).
Jako uživatel může být vaše společnost jen jeden tenant, nebo můžete mít různé tenanty pro různé oddělení. Pokud jste distributor, každý z vašich klientů má alespoň jednoho tenant.
Jeden tenant může být přístupný několika uživateli a uživatelé mohou mít přístup k více tenantům. Můžete kontrolovat, kteří uživatelé mají přístup k jakým tenantům, přiřazením přihlašovacích údajů k tenantům nebo naopak.
Zdroje¶
Zdroje jsou nejzákladnější jednotkou autorizace. Jsou to jednotlivá a specifická přístupová oprávnění.
Příklady:
- Možnost přístupu k dashboardům z určitého datového zdroje
- Možnost mazat tenanty
- Možnost provádět změny v Knihovně
Role¶
Role je kontejnerem pro zdroje. Můžete vytvořit roli, která zahrnuje libovolnou kombinaci zdrojů, takže role je soubor oprávnění.
Klienti¶
Klienti jsou další aplikace, které přistupují k TeskaLabs LogMan.io pro podporu jeho fungování.
Varování
Odebrání klienta může přerušit základní funkce programu.
Sezení¶
Sezení jsou aktivní přihlašovací období aktuálně probíhající.
Způsoby, jak ukončit sezení:
- Klikněte na červené X na řádku sezení na stránce Sezení.
- Klikněte na název sezení, poté klikněte na Ukončit sezení.
- Pro ukončení všech sezení (odhlášení všech uživatelů) klikněte na Ukončit vše na stránce Sezení.
Tip
Modul Auth využívá TeskaLabs SeaCat Auth. Pro více informací si můžete přečíst jeho dokumentaci nebo se podívat na jeho repozitář na GitHubu.
Tabulky dat¶
Některé funkce LogMan.io používají tabulky dat k zobrazení seznamů.
Nepřetržitě pracujeme na rozšíření možností tabulek dat v celém produktu.
Stránky funkcí, které používají tabulky dat, zahrnují Exporty, Základní linie, Upozornění, Vyhledávání, Údržbu služeb, Sběrače a moduly Autentizace, jako jsou Přihlašovací údaje, Nájemci atd.
Řazení¶
Řazení podle jednoho sloupce¶
Data můžete řadit podle jakéhokoli sloupce, vedle názvu sloupce se zobrazuje ikona pro řazení.
Pro alfanumerické řazení podle sloupce klikněte na ikonu se dvěma šipkami vedle názvu sloupce.
Šipka směřující dolů označuje řazení v alfanumerickém pořadí, sestupně.
Šipka směřující nahoru označuje, že data jsou seřazena v alfanumerickém pořadí, vzestupně.
Řazení podle více sloupců¶
Pro alfanumerické řazení podle více sloupců držte shift
, zatímco klikáte na ikony pro řazení.
Položky na stránku¶
Chcete-li změnit počet položek zobrazených na stránce:
- Klikněte na číslo vedle Položek na stránku v dolní části obrazovky.
- Vyberte číslo. Stránka se automaticky znovu načte.
Alternativně můžete přizpůsobit počet položek na stránku pomocí URL.
URL obsahuje i=
následované číslem.
Chcete-li změnit počet položek na stránku, změňte toto číslo a stiskněte enter
nebo return
.
Například i=7
zobrazuje 7 položek na stránku.
Specializované filtrování¶
Některé funkce, jako například Upozornění, umožňují specializované filtrování.
Zde můžete například filtrovat podle konkrétních hodnot z polí Typ, Závažnost a Stav.
Analytikův manuál
Manuál analytika¶
Manuál analytika
Odborníci na kybernetickou bezpečnost a datoví analytici používají Manuál analytika k:
- Dotazování se na data
- Vytváření kybernetických detekcí
- Vytváření vizualizací dat
- Používání a vytváření dalších analytických nástrojů
Chcete-li se naučit používat webovou aplikaci TeskaLabs LogMan.io, navštivte Uživatelský manuál. Pro informace o nastavení a instalaci se podívejte na Administrátorský manuál a Referenční příručku.
Rychlý start¶
- Dotazy: Psaní dotazů pro vyhledávání a filtrování dat
- Dashboardy: Navrhování vizualizací pro souhrny a vzory dat
- Detekce: Vytváření vlastních detekcí pro aktivity a vzory
- Notifikace: Odesílání zpráv prostřednictvím e-mailu z detekcí nebo alertů
Použití Lucene Query Syntax¶
Pokud ukládáte data do Elasticsearch, musíte pro dotazování dat v TeskaLabs LogMan.io používat Lucene Query Syntax.
Zde jsou některé rychlé tipy pro použití Lucene Query Syntax, ale můžete také vidět úplnou dokumentaci na webové stránce Elasticsearch nebo navštívit tento tutoriál.
Lucene Query Syntax můžete použít při tvorbě dashboardů, filtrování dat v dashboardech a při hledání logů v Průzkumník.
Základní dotazové výrazy¶
Hledání pole message
s jakoukoli hodnotou:
message:*
Hledání hodnoty delivered
v poli message
:
message:delivered
Hledání fráze not delivered
v poli message
:
message:"not delivered"
Hledání jakékoli hodnoty v poli message
, ale NE hodnoty delivered
:
message:* -message:delivered
Hledání textu delivered
kdekoli ve hodnotě v poli message
:
message:delivered*
message:delivered
message:not delivered
message:delivered with delay
Note
Tento dotaz by nevrátil stejné výsledky, kdyby byl specifikovaný text (delivered
v tomto příkladu) pouze část slova nebo čísla, neoddělený mezerami nebo tečkami. Proto by dotaz message:eliv
například nevrátil tyto výsledky.
Hledání rozsahu hodnot od 1 do 1000 v poli user.id
:
user.id:[1 TO 1000]
Hledání otevřeného rozsahu hodnot od 1 a vyšší v poli user.id
:
user.id:[1 TO *]
Kombinování dotazových výrazů¶
Použijte booleovské operátory pro kombinování výrazů:
AND
- kombinuje kritéria
OR
- alespoň jedno z kritérií musí být splněno
Použití závorek
Použijte závorky, když je třeba seskupit více položek dohromady, aby vytvořily výraz.
Příklady seskupených výrazů:
Hledání logů z datasetu security
, buď s IP adresou obsahující 123.456
a message
jako failed login
, nebo s akcí události deny
a delay
větší než 10
:
event.dataset:security AND (ip.address:123.456* AND message:"failed login") OR
(event.action:deny AND delay:[10 TO *])
Hledání knihy v databázi knihovny napsané buď Karelem Čapkem nebo Lucií Lukačovičovou, která byla přeložena do angličtiny, nebo knihy v angličtině, která má alespoň 300 stran a žánr vědeckofantastický:
language:English AND (author:"Karel Čapek" OR author:"Lucie Lukačovičová") OR
(page.count:[300 TO *] AND genre:"science fiction")
Log data dashboards
vytvoření widgetu koláčového grafu zkopírujte a vložte tuto šablonu do panelového souboru v Knihovně a vyplňte hodnoty. Doporučené hodnoty a hodnoty specifikující datový zdroj Elasticsearch jsou již vyplněny.
"datasource:Název datového zdroje": {
"datetimeField": "@timestamp",
"groupBy": " ",
"matchPhrase": " ",
"specification": "lmio-{{ tenant }}-events*",
"type": "elasticsearch",
"size": 20
},
"widget:Název widgetu": {
"datasource": "datasource:Název datového zdroje",
"title": "Název widgetu",
"type": "PieChart",
"tooltip": true,
"table": true,
"layout:w": 6,
"layout:h": 4,
"layout:x": 0,
"layout:y": 0,
"layout:moved": false,
"layout:static": true,
"layout:isResizable": false
},
Tabulky¶
Tabulka zobrazuje textové a číselné hodnoty z datových polí, která specifikujete.
Příklad widgetu tabulky
"datasource:office365-email-failed-or-quarantined": { #(1)
"type": "elasticsearch", #(2)
"datetimeField": "@timestamp", #(3)
"specification": "lmio-{{ tenant }}-events*", #(4)
"size": 100, #(5)
"matchPhrase": "event.dataset:microsoft-office-365 AND event.action:MessageTrace AND o365.message.status:(Failed OR Quarantined)" #(6)
},
"widget:office365-email-failed-or-quarantined": { #(7)
"datasource": "datasource:office365-email-failed-or-quarantined", #(8)
"field:1": "@timestamp", #(9)
"field:2": "o365.message.status",
"field:3": "sender.address",
"field:4": "recipient.address",
"field:5": "o365.message.subject",
"title": "Neúspěšné nebo karanténní e-maily", #(10)
"type": "Table", #(11)
"dataPerPage": 9, #(12)
"layout:w": 12, #(13)
"layout:h": 4,
"layout:x": 0,
"layout:y": 0,
"layout:moved": false,
"layout:static": true,
"layout:isResizable": false
}
datasource
označuje začátek sekce datového zdroje a také název datového zdroje. Název neovlivňuje funkci panelu, ale je potřeba na něj správně odkázat v sekci widgetu.- Typ datového zdroje. Pokud používáte Elasticsearch, hodnota je
"elasticsearch"
- Indikuje, které pole v logech je polem s datem a časem. Například v Elasticsearch logách, které jsou parsovány Elastic Common Schema (ECS), je pole s datem a časem
@timestamp
. - Odkazuje na index, ze kterého se načítají data v Elasticsearch. Hodnota
lmio-{{ tenant}}-events*
odpovídá našim názvovým konvencím indexů v Elasticsearch a{{ tenant }}
je místo upravitelného tenanta. Hvězdička*
umožňuje neupřesněné další znaky v názvu indexu zaevents
. Výsledek: Widget zobrazuje data z aktivního tenanta. - Kolik hodnot chcete zobrazit. Tato tabulka bude mít maximálně 100 řádků. Počet řádků na stránku můžete nastavit v
dataPerPage
níže. - Dotaz, který filtruje konkrétní logy pomocí Lucene syntaxe dotazů. V tomto případě widget zobrazuje data pouze z logů z datasetu Microsoft Office 365 s hodnotou
MessageTrace
v polievent.action
a stavem zprávyFailed
neboQuarantined
. widget
označuje začátek sekce widgetu a také název widgetu. Název neovlivňuje funkci panelu.- Odkazuje na sekci datového zdroje výše, která ji naplňuje. Ujistěte se, že hodnota zde přesně odpovídá názvu příslušného datového zdroje. (Tímto se widget dozví, odkud získá data.)
- Každé pole je sloupec, který se zobrazí v tabulce v panelu. V tomto příkladu tabulky neúspěšných nebo karanténních e-mailů by tabulka zobrazovala časové razítko, stav zprávy, adresu odesílatele, adresu příjemce a předmět e-mailu pro každý log (což představuje každý e-mail). Použijte tolik polí, kolik chcete.
- Název widgetu, který se bude zobrazovat v panelu
- Typ widgetu
- Počet položek zobrazených na stránce (najednou) v tabulce
- Viz poznámku výše o umístění widgetů pro informace o rozvrhových řádcích.
Widget tabulky vykreslený:
Šablona widgetu tabulky:
Pro vytvoření widgetu tabulky zkopírujte a vložte tuto šablonu do panelového souboru v Knihovně a vyplňte hodnoty. Doporučené hodnoty a hodnoty specifikující datový zdroj Elasticsearch jsou již vyplněny.
"datasource:Název datového zdroje": {
"type": "elasticsearch",
"datetimeField": "@timestamp",
"specification": "lmio-{{ tenant }}-events*",
"size": 100,
"matchPhrase": " "
},
"widget:Název widgetu": {
"datasource": "Název datového zdroje",
"field:1": "@timestamp",
"field:2": " ",
"field:3": " ",
"field:4": " ",
"field:5": " ",
"title": "Název widgetu",
"type": "Table",
"dataPerPage": 9,
"layout:w": 12,
"layout:h": 4,
"layout:x": 0,
"layout:y": 0,
"layout:moved": false,
"layout:static": true,
"layout:isResizable": false
}
Jednotlivé hodnoty¶
Widget hodnoty zobrazuje nejnovější jednotlivou hodnotu z datového pole, které specifikujete.
"datasource:microsoft-exchange1": { #(1)
"datetimeField": "@timestamp", #(2)
"matchPhrase": "event.dataset:microsoft-exchange AND email.from.address:* AND email.to.address:*", #(3)
"specification": "lmio-{{ tenant }}-events*", #(4)
"type": "elasticsearch", #(5)
"size": 1 #(6)
},
"widget:fortigate1": { #(7)
"datasource": "datasource:microsoft-exchange1", #(8)
"field": "email.from.address", #(9)
"title": "Poslední aktivní uživatel", #(10)
"type": "Value", #(11)
"layout:w": 4, #(12)
"layout:h": 1,
"layout:x": 0,
"layout:y": 0,
"layout:moved": false,
"layout:static": true,
"layout:isResizable": false
}
datasource
označuje začátek sekce datového zdroje a také název datového zdroje. Název neovlivňuje funkci panelu, ale je potřeba na něj správně odkázat v sekci widgetu.- Indikuje, které pole v logech je polem s datem a časem. Například v Elasticsearch logách, které jsou parsovány Elastic Common Schema (ECS), je pole s datem a časem
@timestamp
. - Dotaz, který filtruje konkrétní logy pomocí Lucene syntaxe dotazů. V tomto případě widget zobrazuje data pouze z logů z datasetu Microsoft Exchange s jakoukoli hodnotou (
*
) v políchemail.from.address
aemail.to.address
. - Odkazuje na index, ze kterého se načítají data v Elasticsearch. Hodnota
lmio-{{ tenant}}-events*
odpovídá našim názvovým konvencím indexů v Elasticsearch a{{ tenant }}
je místo upravitelného tenanta. Hvězdička*
umožňuje neupřesněné další znaky v názvu indexu zaevents
. Výsledek: Widget zobrazuje data z aktivního tenanta. - Typ datového zdroje. Pokud používáte Elasticsearch, hodnota je
"elasticsearch"
- Kolik hodnot chcete zobrazit. Protože widget hodnoty zobrazuje pouze jednu hodnotu,
size
je 1. widget
označuje začátek sekce widgetu a také název widgetu. Název neovlivňuje funkci panelu.- Odkazuje na sekci datového zdroje výše, která ji naplňuje. Ujistěte se, že hodnota zde přesně odpovídá názvu příslušného datového zdroje. (Tímto se widget dozví, odkud získá data.)
- Odkazuje na pole (z nejnovějšího logu), ze kterého bude hodnota zobrazena.
- Název widgetu, který se bude zobrazovat v panelu
- Typ widgetu. Typ hodnoty zobrazuje jednotlivou hodnotu.
- Viz poznámku výše o umístění widgetů pro informace o rozvrhových řádcích.
Widget hodnoty vykreslený:
Šablona widgetu hodnoty:
Pro vytvoření widgetu hodnoty zkopírujte a vložte tuto šablonu do panelového souboru v Knihovně a vyplňte hodnoty. Doporučené hodnoty a hodnoty specifikující datový zdroj Elasticsearch jsou již vyplněny.
"datasource:Název datového zdroje": {
"datetimeField": "@timestamp",
"matchPhrase": " ",
"specification": "lmio-{{ tenant }}-events*",
"type": "elasticsearch",
"size": 1
},
"widget:Název widgetu": {
"datasource": "datasource:Název datového zdroje",
"field": " ",
"title": "Název widgetu",
"type": "Value",
"layout:w": 4,
"layout:h": 1,
"layout:x": 0,
"layout:y": 0,
"layout:moved": false,
"layout:static": true,
"layout:isResizable": false
}
Příklad panelu¶
Tento příklad je správně strukturován:
{
"Prompts": {
"dateRangePicker": true,
"filterInput": true,
"submitButton": true
},
"datasource:access-log-combined HTTP Response": {
"type": "elasticsearch",
"datetimeField": "@timestamp",
"specification": "lmio-default-events*",
"size": 20,
"groupBy": "http.response.status_code",
"matchPhrase": "event.dataset: access-log-combined AND http.response.status_code:*"
},
"widget:access-log-combined HTTP Response": {
"datasource": "datasource:access-log-combined HTTP Response",
"title": "HTTP status codes",
"type": "PieChart",
"color": "warning",
"useGradientColors": true,
"table": true,
"tooltip": true,
"layout:w": 6,
"layout:h": 5,
"layout:x": 6,
"layout:y": 0,
"layout:moved": false,
"layout:static": true,
"layout:isResizable": false
},
"datasource:access-log-combined Activity": {
"type": "elasticsearch",
"datetimeField": "@timestamp",
"specification": "lmio-default-events*",
"matchPhrase": "event.dataset:access-log-combined AND http.response.status_code:*",
"aggregateResult": true
},
"widget:access-log-combined Activity": {
"datasource": "datasource:access-log-combined Activity",
"title": "Aktivita",
"type": "BarChart",
"table": true,
"xaxis": "@timestamp",
"ylabel": "HTTP požadavky",
"yaxis": "http.response.status_code",
"color": "sunset",
"layout:w": 6,
"layout:h": 4,
"layout:x": 0,
"layout:y": 1,
"layout:moved": false,
"layout:static": true,
"layout:isResizable": false
},
"datasource:Access-log-combined Last_http": {
"datetimeField": "@timestamp",
"matchPhrase": "event.dataset:access-log-combined AND http.response.status_code:*",
"specification": "lmio-default-events*",
"type": "elasticsearch",
"size": 1000
},
"widget:Access-log-combined Last_http": {
"datasource": "datasource:Access-log-combined Last_http",
"field": "http.response.status_code",
"title": "Poslední HTTP status kód",
"type": "Value",
"layout:w": 6,
"layout:h": 1,
"layout:x": 0,
"layout:y": 0,
"layout:moved": false,
"layout:static": true,
"layout:isResizable": false
}
}
Poznámka: Data jsou libovolná. Tento příklad má pouze pomoci správně naformátovat vaše panely.
Panel vykreslený:
Parsování
Parsování¶
Parsování je proces analýzy původního logu (který je obvykle ve formátu jednoho/nebo více řádkových řetězců, JSON nebo XML) a jeho transformace na seznam klíč-hodnota párů, které popisují data logu (například kdy se původní událost stala, priorita a závažnost logu, informace o procesu, který log vytvořil, atd).
Každý log, který vstupuje do vašeho systému TeskaLabs LogMan.io, musí být analyzován. Mikroservis LogMan.io Parsec je zodpovědný za parsování logů. Parsec potřebuje parsery, což jsou sady deklarací (YAML soubory), aby věděl, jak analyzovat každý typ logu. LogMan.io přichází s LogMan.io Common Library, která obsahuje mnoho parserů již vytvořených pro mnoho běžných typů logů. Pokud však potřebujete vytvořit vlastní parsery, pochopení parsování klíčových pojmů, znalost deklarací, a použití parsing tutorialu vám může pomoci.
Základní příklad parsování
Parsování vezme surový log, jako je tento:
<30>2023:12:04-15:33:59 hostname3 ulogd[1620]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth2.3009" outitf="eth6" srcmac="e0:63:da:73:bb:3e" dstmac="7c:5a:1c:4c:da:0a" srcip="172.60.91.60" dstip="192.168.99.121" proto="17" length="168" tos="0x00" prec="0x00" ttl="63" srcport="47100" dstport="12017"
@timestamp: 2023-12-04 15:33:59.033
destination.ip: 192.168.99.121
destination.mac: 7c:5a:1c:4c:da:0a
destination.port: 12017
device.model.identifier: SG230
dns.answers.ttl 63
event.action: Packet dropped
event.created: 2023-12-04 15:33:59.033
event.dataset: sophos
event.id: 2001
event.ingested: 2023-12-04 15:39:10.039
event.original: <30>2023:12:04-15:33:59 hostname3 ulogd[1620]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth2.3009" outitf="eth6" srcmac="e0:63:da:73:bb:3e" dstmac="7c:5a:1c:4c:da:0a" srcip="172.60.91.60" dstip="192.168.99.121" proto="17" length="168" tos="0x00" prec="0x00" ttl="63" srcport="47100" dstport="12017"
host.hostname: hostname3
lmio.event.source.id: hostname3
lmio.parsing: parsec
lmio.source: mirage
log.syslog.facility.code: 3
log.syslog.facility.name: daemon
log.syslog.priority: 30
log.syslog.severity.code: 6
log.syslog.severity.name: information
message id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth2.3009" outitf="eth6" srcmac="e0:63:da:73:bb:3e" dstmac="7c:5a:1c:4c:da:0a" srcip="172.60.91.60" dstip="192.168.99.121" proto="17" length="168" tos="0x00" prec="0x00" ttl="63" srcport="47100" dstport="12017"
observer.egress.interface.name: eth6
observer.ingress.interface.name: eth2.3009
process.name: ulogd
process.pid: 1620
sophos.action: drop
sophos.fw.rule.id: 60002
sophos.prec: 0x00
sophos.protocol: 17
sophos.sub: packetfilter
sophos.sys: SecureNet
sophos.tos: 0x00
source.bytes: 168
source.ip: 172.60.91.60
source.mac: e0:63:da:73:bb:3e
source.port: 47100
tags: lmio-parsec:v23.47
tenant: default
_id: e1a92529bab1f20e43ac8d6caf90aff49c782b3d6585e6f63ea7c9346c85a6f7
_prev_id: 10cc320c9796d024e8a6c7e90fd3ccaf31c661cf893b6633cb2868774c743e69
_s: DKNA
Analýza klíčových termínů¶
Důležité termíny relevantní pro LogMan.io Parsec a proces analýzy.
Událost¶
Jednotka dat, která prochází procesem analýzy, se nazývá událost. Původní událost přichází do LogMan.io Parsec jako vstup a je následně analyzována procesory. Pokud analýza uspěje, vytvoří analyzovanou událost, a pokud analýza selže, vytvoří chybu události.
Původní událost¶
Původní událost je vstup, který LogMan.io Parsec přijímá - jinými slovy neanalyzovaný log. Může být reprezentován surovým (možná kódovaným) řetězcem nebo strukturou ve formátu JSON nebo XML.
Analyzovaná událost¶
Analyzovaná událost je výstup úspěšné analýzy, formátovaný jako neuspořádaný seznam klíč-hodnota serializovaný do struktury JSON. Analyzovaná událost vždy obsahuje unikátní ID, původní událost, a typicky informace o tom, kdy byla událost vytvořena zdrojem a přijata Apache Kafka.
Chyba události¶
Chyba události je výstup neúspěšné analýzy, formátovaný jako neuspořádaný seznam klíč-hodnota serializovaný do struktury JSON. Vytvoří se, když selže analýza, mapování nebo obohacování, nebo když dojde k jiné výjimce v LogMan.io Parsec. Vždy obsahuje původní událost, informace o tom, kdy byla událost neúspěšně analyzována, a chybová zpráva popisující důvod, proč analýza selhala. Navzdory neúspěšné analýze bude chyba události vždy ve formátu JSON, klíč-hodnota.
Knihovna¶
Vaše TeskaLabs LogMan.io Knihovna obsahuje všechny vaše deklarace (jakož i mnoho dalších typů souborů). Své soubory deklarací můžete upravovat ve své Knihovně přes Zookeeper.
Deklarace¶
Deklarace popisují, jak bude událost transformována. Deklarace jsou soubory ve formátu YAML, které může LogMan.io Parsec interpretovat k vytvoření deklarativních procesorů. V LogMan.io Parsec existují tři typy deklarací: parsery, obohacovače a mapování. Viz Deklarace pro více informací.
Parser¶
Parser je druh deklarace, který bere původní událost nebo konkrétní pole částečně analyzované události jako vstup, analyzuje její jednotlivé části, a poté je ukládá jako klíč-hodnota do události.
Mapování¶
Deklarace mapování je druh deklarace, který bere částečně analyzovanou událost jako vstup, přejmenuje názvy polí a případně převede datové typy. Pracuje společně se schématem (ECS, CEF). Také funguje jako filtr, který vynechá data, která nejsou potřeba v konečné analyzované události.
Obohacovač¶
Obohacovač je druh deklarace, který doplňuje částečně analyzovanou událost o další data.
Deklarace
Deklarace¶
Deklarace popisují, jak by měl být event parsován. Jsou uložené jako YAML soubory v Knihovně. LogMan.io Parsec interpretuje tyto deklarace a vytváří parsing procesory.
Existují tři typy deklarací:
- Parser deklarace: Parser přijímá původní event nebo specifické pole částečně parsovaného eventu jako vstup, analyzuje jeho jednotlivé části a ukládá je jako páry klíč-hodnota do eventu.
- Mapping deklarace: Mapping přijímá částečně parsovaný event jako vstup, přejmenovává názvy polí a případně převádí datové typy. Pracuje společně se schématem (ECS, CEF).
- Enricher deklarace: Enricher doplňuje částečně parsovaný event o další data.
Tok dat¶
Typický, doporučený sekvenční řetězec parsování je řetězec deklarací:
- První hlavní parser deklarace začíná řetězec, a další parsery (nazývané sub-parsery) extrahují detailnější data z polí vytvořených předchozím parserem.
- Pak následuje (jedna jediná) mapping deklarace, která přejmenuje klíče parsovaných polí podle schématu a filtruje pole, která nejsou potřeba.
- Nakonec enricher deklarace doplňuje event o další data. Ačkoliv je možné použít více enriových souborů, doporučuje se použít jen jeden.
Pojmenování deklarací¶
Důležité: Konvence pojmenování
LogMan.io Parsec načítá deklarace abecedně a vytváří příslušné procesory ve stejném pořadí. Proto vytvořte seznam souborů deklarací podle těchto pravidel:
-
Začněte všechny názvy souborů deklarací číselným prefixem:
10_parser.yaml
,20_parser_message.yaml
, ...,90_enricher.yaml
.Doporučuje se "nechat si místo" v číslování pro budoucí deklarace, pokud budete chtít přidat novou deklaraci mezi dvě existující (např.
25_new_parser.yaml
). -
Zahrňte typ deklarace do názvů souborů:
20_parser_message.yaml
spíše než10_message.yaml
. - Zahrňte typ schématu použitého v mapping názvech souborů:
40_mapping_ECS.yaml
spíše než40_mapping.yaml
.
Příklad:
/Parsers/MyParser/:
- 10_parser.yaml
- 20_parser_username.yaml
- 30_parser_message.yaml
- 40_mapping_ECS.yaml
- 50_enricher_lookup.yaml
- 60_enricher.yaml
Deklarace parserů¶
Deklarace parseru bere jako vstup původní událost nebo konkrétní pole částečně zpracované události, analyzuje jeho jednotlivé části a ukládá je jako páry klíč-hodnota do události.
LogMan.io Parsec aktuálně podporuje tři typy deklarací parserů:
- JSON parser
- Parser Windows událostí
- Parsec parser
Struktura deklarace¶
Aby bylo možné určit typ deklarace, je třeba specifikovat sekci define
.
define:
type: <declaration_type>
Pro deklaraci parseru specifikujte type
jako parser
.
JSON parser¶
JSON parser se používá pro zpracování událostí se strukturou JSON.
define:
name: JSON parser
type: parser/json
Toto je kompletní JSON parser a bude analyzovat události ze struktury JSON, odděluje pole na páry klíč-hodnota.
Varování
Zatím LogMan.io Parsec nepodporuje zpracování událostí s vnořenou strukturou JSON. Například událost níže nelze analyzovat pomocí JSON parseru:
{
"key": {
"foo": 1,
"bar": 2
}
}
Parser Windows událostí¶
Parser Windows událostí se používá pro zpracování událostí, které jsou vytvářeny Microsoft Windows. Tyto události jsou ve formátu XML.
define:
name: Windows Events Parser
type: parser/windows-event
Toto je kompletní parser Windows událostí a bude analyzovat události z Microsoft Windows, odděluje pole na páry klíč-hodnota.
Parsec parser¶
Parsec parser se používá pro zpracování událostí ve formátu prostého textu. Je založen na výrazech SP-Lang Parsec.
Pro zpracování původních událostí použijte následující deklaraci:
define:
name: My Parser
type: parser/parsec
parse:
!PARSE.KVLIST
- ...
- ...
- ...
define:
name: My Parser
type: parser/parsec
field: <custom_field>
parse:
!PARSE.KVLIST
- ...
- ...
- ...
Když je specifikováno field
, parsování se aplikuje na toto pole, jinak se aplikuje na původní událost. Proto musí být přítomno v každém sub-parseru.
Příklady deklarací Parsec parseru¶
Příklad 1: Jednoduchý příklad
Pro účely příkladu předpokládejme, že chceme zpracovat kolekci jednoduchých událostí:
Hello Miroslav from Prague!
Hi Kristýna from Pilsen.
{
"name": "Miroslav",
"city": "Prague"
}
{
"name": "Kristýna",
"city": "Pilsen"
}
define:
type: parser/parsec
parse:
!PARSE.KVLIST
- !PARSE.UNTIL " "
- name: !PARSE.UNTIL " "
- !PARSE.EXACTLY "from "
- city: !PARSE.LETTERS
Příklad 2: Složitější příklad
Pro účely tohoto příkladu předpokládejme, že chceme zpracovat kolekci jednoduchých událostí:
Process cleaning[123] finished with code 0.
Process log-rotation finished with code 1.
Process cleaning[657] started.
A chceme výstup v následujícím formátu:
{
"process.name": "cleaning",
"process.pid": 123,
"event.action": "process-finished",
"return.code": 0
}
{
"process.name": "log-rotation",
"event.action": "process-finished",
"return.code": 1
}
{
"process.name": "cleaning",
"process.pid": 657,
"event.action": "process-started",
}
Deklarace bude následující:
define:
type: parser/parsec
parse:
!PARSE.KVLIST
- !PARSE.UNTIL " "
- !TRY
- !PARSE.KVLIST
- process.name: !PARSE.UNTIL "["
- process.pid: !PARSE.UNTIL "]"
- !PARSE.SPACE
- !PARSE.KVLIST
- process.name: !PARSE.UNTIL " "
- !TRY
- !PARSE.KVLIST
- !PARSE.EXACTLY "started."
- event.action: "process-started"
- !PARSE.KVLIST
- !PARSE.EXACTLY "finished with code "
- event.action: "process-finished"
- return.code: !PARSE.DIGITS
Příklad 3: Zpracování syslog událostí
Pro účely příkladu předpokládejme, že chceme zpracovat jednoduchou událost ve formátu syslog:
<189> Sep 22 10:31:39 server-abc server-check[1234]: User "harry potter" logged in from 198.20.65.68
Chceme výstup v následujícím formátu:
{
"PRI": 189,
"timestamp": 1695421899,
"server": "server-abc",
"process.name": "server-check",
"process.pid": 1234,
"user": "harry potter",
"action": "log-in",
"ip": "198.20.65.68"
}
Vytvoříme dva parsry. První parser bude zpracovávat hlavičku syslogu a druhý bude zpracovávat zprávu.
define:
name: Syslog parser
type: parser/parsec
parse:
!PARSE.KVLIST
- !PARSE.EXACTLY "<"
- PRI: !PARSE.DIGITS
- !PARSE.EXACTLY ">"
- timestamp: ...
- server: !PARSE.UNTIL " "
- process.name: !PARSE.UNTIL "["
- process.pid: !PARSE.UNTIL "]"
- !PARSE.EXACTLY ":"
- message: !PARSE.CHARS
Tento parser
define:
type: parser/parsec
field: message
drop: yes
parse:
!PARSE.KVLIST
- !PARSE.UNTIL " "
- user: !PARSE.BETWEEN { what: '"' }
- !PARSE.EXACTLY " "
- !PARSE.UNTIL " "
- !PARSE.UNTIL " "
- !PARSE.UNTIL " "
- ip: !PARSE.CHARS
Deklarace mapování¶
Poté, co jsou všechna deklarovaná pole získána z parserů, pole obvykle musí být přejmenována podle určitého schématu (ECS, CEF) v procesu nazývaném mapování.
Proč je mapování nezbytné?
Pro uložení dat o událostech v Elasticsearch je nezbytné, aby názvy polí v logách odpovídaly Elastic Common Schema (ECS), standardizované, open-source kolekci názvů polí, která jsou kompatibilní s Elasticsearch. Proces mapování přejmenuje pole v parsovaných logách podle tohoto schématu. Mapování zajišťuje, že logy z různých zdrojů mají jednotné, konzistentní názvy polí, což umožňuje Elasticsearch je správně interpretovat.
Důležité
Po defaultu funguje mapování jako filtr. Ujistěte se, že v deklaraci mapování zahrnete všechna pole, která chcete mít v parsovaném výstupu. Jakékoliv pole neuvedené v mapování bude z události odstraněno.
Psaní deklarace mapování¶
Deklarace mapování pište v YAML. (Deklarace mapování nepoužívají výrazy SP-Lang.)
define:
type: parser/mapping
schema: /Schemas/ECS.yaml
mapping:
<original_key>: <new_key>
<original_key>: <new_key>
...
Ve sekci define
specifikujte parser/mapping
jako type
. V poli schema
specifikujte cestu k souboru schématu, které používáte. Pokud používáte Elasticsearch, použijte Elastic Common Schema (ECS).
Pro přejmenování klíče a změnu datového typu hodnoty:
mapping:
<original_key>:
field: <new_key>
type: <new_type>
Dostupné datové typy najdete zde.
Pro přejmenování klíče bez změny datového typu hodnoty:
mapping:
<original_key>: <new_key>
Příklad¶
Example
Pro účely příkladu, řekněme, že chceme parsovat jednoduchou událost ve formátu JSON:
{
"act": "user login",
"ip": "178.2.1.20",
"usr": "harry_potter",
"id": "6514-abb6-a5f2"
}
a chtěli bychom, aby konečný výstup vypadal takto:
{
"event.action": "user login",
"source.ip": "178.2.1.20",
"user.name": "harry_potter"
}
Všimněte si, že názvy klíčů v původní události se liší od názvů klíčů v požadovaném výstupu.
Pro počáteční deklaraci parseru v tomto případě můžeme použít jednoduchý JSON parser:
define:
type: parser/json
Tento parser vytvoří seznam klíč-hodnota párů, které jsou přesně stejné jako původní.
Pro změnu názvů jednotlivých polí vytvoříme tento soubor deklarace mapování, 20_mapping_ECS.yaml
, ve kterém popisujeme, jaká pole mapovat a jak:
---
define:
type: parser/mapping # určuje typ deklarace
schema: /Schemas/ECS.yaml # které schéma je aplikováno
mapping:
act: 'event.action'
ip: 'source.ip'
usr: 'user.name'
Tato deklarace vytvoří požadovaný výstup. (Datové typy nebyly změněny.)
Deklarace Enricherů¶
Enricher doplňují parsované události o dodatečná data.
Enricher může:
- Vytvořit nové pole v události.
- Transformovat hodnoty polí nějakým způsobem (změna velikosti písmen, provádění výpočtů, atd.).
Enrichery jsou nejčastěji používány k:
- Určení datasetu, kde budou logy uloženy v ElasticSearch (přidání pole
event.dataset
). - Získání facility a severity z pole syslog priority.
define:
type: parsec/enricher
enrich:
event.dataset: <dataset_name>
new.field: <expression>
...
- Enrichery zapisujte v YAML.
- Specifikujte
parsec/enricher
v polidefine
.
Example
Následující příklad je enricher používaný pro události ve formátu syslog. Předpokládejme, že máte parser pro události ve tvaru:
<14>1 2023-05-03 15:06:12 server pid: Uživatelské jméno 'HarryPotter' přihlášeno.
{
"log.syslog.priority": 14,
"user.name": "HarryPotter"
}
Chcete získat závažnost (severity) a lokální zařízení (facility) z protokolu syslog, které jsou vypočítány standardním způsobem:
(facility * 8) + severity = priority
Také byste chtěli změnit jméno HarryPotter
na harrypotter
, aby bylo sjednoceno napříč různými logovacími zdroji.
Proto vytvoříte enricher:
define:
type: parsec/enricher
enrich:
event.dataset: 'dataset_name'
user.id: !LOWER { what: !GET {from: !ARG EVENT, what: user.name} }
# Facility a severity jsou vypočteny z 'syslog.pri' standardním způsobem
log.syslog.facility.code: !SHR
what: !GET { from: !ARG EVENT, what: log.syslog.priority }
by: 3
log.syslog.severity.code: !AND [ !GET {from: !ARG EVENT, what: log.syslog.priority}, 7 ]
Parsing tutorial
---
title: Návod na analýzu
---
# Návod na analýzu
Kompletní proces analýzy vyžaduje deklarace analyzátoru, mapování a obohacovače. Tento návod rozděluje tvorbu deklarací krok za krokem. Pro více informací o microservisu Parsec navštivte [dokumentaci LogMan.io Parsec](../../parsec/index.md).
!!! poznámka "Než začnete"
**SP-Lang**
Deklarace analýzy jsou psány v TeskaLabs SP-Lang. Pro více podrobností o analytických výrazech navštivte [dokumentaci SP-Lang](/sp-lang/expressions/parsec/).
**Deklarace**
Pro více informací o specifických typech deklarací, viz:
* [O deklaracích](./declarations/index.md)
* [Deklarace analyzátoru](./declarations/parser-declarations.md)
* [Deklarace mapování](./declarations/mapping-declarations.md)
* [Deklarace obohacovače](./declarations/enricher-declarations.md)
## Vzorové logy
Tento příklad používá tuto sadu logů sesbíraných z různých zařízení Sophos SG230:
<38>2023:01:12-13:09:09 asgmtx sshd[17112]: Failed password for root from 218.92.0.190 port 56745 ssh2
<38>2023:01:12-13:09:20 asgmtx sshd[16281]: Did not receive identification string from 218.92.0.190
<38>2023:01:12-13:09:20 asgmtx aua[2350]: id="3005" severity="warn" sys="System" sub="auth" name="Authentication failed" srcip="43.139.111.88" host="" user="login" caller="sshd" reason="DENIED"
Tyto logy používají formát syslog popsaný v [RFC 5424](https://datatracker.ietf.org/doc/html/rfc5424).
Logy mohou být obvykle rozděleny do dvou částí: hlavička a tělo. **Hlavička** je vše před prvním dvojtečkou po časovém razítku. **Tělo** je zbytek logu.


## Strategie analýzy
Parsec interpretuje každou deklaraci abecedně podle názvu, takže pořadí pojmenování je důležité. V rámci každé deklarace, proces analýzy následuje pořadí, ve kterém jste zapsali výrazy jako kroky.
Sekvence analýzy může zahrnovat více deklarací analyzátoru, a také vyžaduje deklaraci mapování a deklaraci obohacovače. V tomto případě vytvořte tyto deklarace:
1. **První deklarace analyzátoru**: Analyzujte hlavičky syslog
2. **Druhá deklarace analyzátoru**: Analyzujte tělo logů jako **zprávu**.
3. **Deklarace mapování**: Přejmenujte pole
4. **Deklarace obohacovače**: Přidejte metadata (například název datové sady) a vypočítejte syslog facility a seriousness z priority
Dle [naming conventions](./declarations/index.md#naming-declarations), nazvěte tyto soubory:
- 10_parser_header.yaml
- 20_parser_message.yaml
- 30_mapping_ECS.yaml
- 40_enricher.yaml
Pamatujte, že deklarace jsou interpretovány v abecedním pořadí, v tomto případě rostoucím číselným prefixem. Používejte prefixy jako 10, 20, 30, atd., aby bylo možné přidat novou deklaraci mezi existující později bez přejmenování všech souborů.
## 1. Analýza hlavičky
Toto je první deklarace analyzátoru. Následující sekce rozebírají a vysvětlují každou část deklarace.
```yaml title="10_parser_header.yaml"
---
define:
type: parser/parsec
parse:
!PARSE.KVLIST
# Část PRI
- '<'
- PRI: !PARSE.DIGITS
- '>'
# Časové razítko
- TIMESTAMP: !PARSE.DATETIME
- year: !PARSE.DIGITS # year: 2023
- ':'
- month: !PARSE.MONTH { what: 'number' } # month: 01
- ':'
- day: !PARSE.DIGITS # day: 12
- '-'
- hour: !PARSE.DIGITS # hour: 13
- ':'
- minute: !PARSE.DIGITS # minute: 08
- ':'
- second: !PARSE.DIGITS # second: 45
- !PARSE.UNTIL ' '
# Hostname a proces
- HOSTNAME: !PARSE.UNTIL ' ' # asgmtx
- PROCESS: !PARSE.UNTIL ':'
# Zpráva
- !PARSE.SPACES
- MESSAGE: !PARSE.CHARS
Hlavičky logu¶
Hlavička syslog je ve formátu:
<PRI>TIMESTAMP HOSTNAME PROCESS.NAME[PROCESS.PID]:


Důležité: Variabilita logů
Všimněte si, že PROCESS.PID
ve čtvercových závorkách není přítomen v hlavičce prvního logu. Aby parser mohl zvládnout tuto rozdílnost, bude zapotřebí způsob, jak zvládnout možnost, že PROCESS.PID
může být přítomen nebo nepřítomen. Tento problém bude řešen později v návodu.
Analýza PRI¶
Nejprve analyzujte PRI, což je uzavřeno mezi znaky <
a >
, bez mezery mezi nimi.
Jak analyzovat <PRI>
, jak je uvedeno v první deklaraci analyzátoru:
!PARSE.KVLIST
- !PARSE.EXACTLY { what: '<' }
- PRI: !PARSE.DIGITS
- !PARSE.EXACTLY { what: '>' }
Použité výrazy:
!PARSE.EXACTLY
: Analýza znaků<
a>
!PARSE.DIGITS
: Analýza čísel (čísel) PRI
!PARSE.EXACTLY
zkratka
Výraz !PARSE.EXACTLY
má syntaktickou zkratku, protože se často používá. Místo zahrnutí celého výrazu, PARSE.EXACTLY { what: '(znak)' }
může být zkráceno na '(znak')
.
Takže výše uvedená deklarace analyzátoru může být zkrácena na:
!PARSE.KVLIST
- '<'
- PRI: !PARSE.DIGITS
- '>'
Analýza časového razítka¶
Neanalyzovaný formát časového razítka je:
yyyy:mm:dd-HH:MM:SS
2023:01:12-13:08:45
Analyzujte časové razítko pomocí výrazu !PARSE.DATETIME
.
Jak je to uvedeno v první deklaraci analyzátoru:
# 2023:01:12-13:08:45
- TIMESTAMP: !PARSE.DATETIME
- year: !PARSE.DIGITS # year: 2023
- ':'
- month: !PARSE.MONTH { what: 'number' } # month: 01
- ':'
- day: !PARSE.DIGITS # day: 12
- '-'
- hour: !PARSE.DIGITS # hour: 13
- ':'
- minute: !PARSE.DIGITS # minute: 08
- ':'
- second: !PARSE.DIGITS # second: 45
- !PARSE.UNTIL { what: ' ', stop: after }
Analýza měsíce:
Výraz !PARSE.MONTH
vyžaduje, abyste specifikovali formát měsíce v parametru what
. Možnosti jsou:
'number'
(použit v tomto případě) přijímá čísla 01-12'short'
pro zkrácené názvy měsíců (JAN, FEB, atd.)'full'
pro plné názvy měsíců (JANUARY, FEBRUARY, atd.)
Analýza mezery:
Mezera na konci časového razítka také musí být analyzována. Použitím výrazu !PARSE.UNTIL
se analyzuje vše až do znaku mezery (' '
), zastavuje se po mezeře, jak je definováno (stop: after
).
!PARSE.UNTIL
zkratky a alternativy
!PARSE.UNTIL
má syntaktickou zkratku:
- !PARSE.UNTIL ' '
- !PARSE.UNTIL { what: ' ', stop: after }
Alternativně, můžete zvolit výraz, který specificky analyzuje jednu nebo více mezer, respektive:
- !PARSE.SPACE
nebo
- !PARSE.SPACES
V tomto bodě je analyzována sekvence znaků <181>2023:01:12-13:08:45
(včetně mezery na konci).
Analýza hostname a procesu¶
Dále analyzujte hostname a proces: asgmtx sshd[17112]:
.
Pamatujte, že hlavička prvního logu se liší od ostatních. Pro řešení, které zohledňuje tuto rozdílnost, vytvořte deklaraci analyzátoru a poddeklaraci analyzátoru.
Jak je to uvedeno v první deklaraci analyzátoru:
# Hostname a proces
- HOSTNAME: !PARSE.UNTIL ' ' # asgmtx
- PROCESS: !PARSE.UNTIL ':'
# Zpráva
- !PARSE.SPACES
- MESSAGE: !PARSE.CHARS
- Analyzujte hostname: Pro analýzu hostname, použijte výraz
!PARSE.UNTIL
k analýze všeho až po zadaný znak uvnitř' '
, což je v tomto případě mezera, a zastavuje po tomto znaku, aniž by tento znak zahrnul do výstupu. - Analyzujte proces: Použijte
!PARSE.UNTIL
znovu pro analýzu do:
. Po dvojtečce ('
), je hlavička analyzována. - Analyzujte zprávu: V této deklaraci použijte
!PARSE.SPACES
k analýze všech mezer mezi hlavičkou a zprávou. Poté ukládejte zbytek události do poleMESSAGE
pomocí výrazu!PARSE.CHARS
, který v tomto případě analyzuje všechny zbylé znaky v logu. Použijte další deklarace k analýze částí zprávy.
1.5. Analýza pro variabilitu logu¶
Pro řešení problému, že první log nemá process PID, potřebujete druhou deklaraci analyzátoru, poddeklaraci. V ostatních logách je process PID uzavřen do čtvercových závorek ([ ]
).
Vytvořte deklaraci nazvanou 15_parser_process.yaml
. Abyste zohlednili rozdíly v logách, vytvořte dva "cesty" nebo "větve", které může parser použít. První větev bude analyzovat PROCESS.NAME
, PROCESS.PID
a :
. Druhá větev bude analyzovat pouze PROCESS.NAME
.
Proč potřebujeme dvě větve?
U tří logů je process PID uzavřen ve čtvercových závorkách ([ ]
). Proto analýza, která izoluje PID, začíná analyzací znaku ve čtvercové závorce [
. Nicméně, v prvním logu pole PID není přítomno. Pokud se pokusíte analyzovat první log pomocí stejného výrazu, parser se pokusí najít čtvercovou závorku v tomto logu a bude pokračovat v hledání, i když znak [
není přítomen v hlavičce.
Výsledkem by bylo, že cokoliv uvnitř čtvercových závorek je analyzováno jako PID
, což by v tomto případě nemělo smysl a narušilo by zbytek procesu analýzy pro tento log.
Druhá deklarace:
---
define:
type: parser/parsec
field: PROCESS
error: continue
parse:
!PARSE.KVLIST
- !TRY
- !PARSE.KVLIST
- PROCESS.NAME: !PARSE.UNTIL '['
- PROCESS.PID: !PARSE.UNTIL ']'
- !PARSE.KVLIST
- PROCESS.NAME: !PARSE.CHARS
K dosažení tohoto účelu, vytvořte dva malé parsovací bloky pod kombinátorem !PARSE.KVLIST
pomocí výrazu !TRY
.
Výraz !TRY
Výraz !TRY
umožňuje vnořit seznam výrazů pod něj. !TRY
začíná pokusem použít první výraz a pokud tento první výraz není použitelný pro log, proces pokračuje s dalším vnořeným výrazem, a tak dále, dokud nějaký výraz neuspěje.
Pod výrazem !TRY
:
První větev:
1. Výraz analyzuje PROCESS.NAME
a PROCESS.PID
, očekává čtvercové závorky [
a ]
přítomné v události. Po analyzování těchto znaků, také analyzuje znak :
.
2. Pokud log neobsahuje znak [
, výraz !PARSE.UNTIL '['
selže, a v tom případě celý výraz !PARSE.KVLIST
v první větvi selže.
Druhá větev:
3. Výraz !TRY
bude pokračovat s dalším parserem, který nevyžaduje, aby znak [
byl přítomen v události. Jednoduše analyzuje všechno před :
a zastaví se po něm.
4. Pokud tento druhý výraz selže, log přechází do OTHERS.
2. Analýza zprávy¶
Zvažte znovu události:
``` <181>2023:01:12-13:08:45 asgmtx httpd: 212.158.149.81 - - [12/Jan/2023:13:08:45 +0100] "POST /webadmin.plx HTTP/1.1" 200 2000 <38>202
Detekce
LogMan.io Correlator¶
TeskaLabs LogMan.io Correlator je výkonná, rychlá a škálovatelná součást LogMan.io a TeskaLabs SIEM. Correlator je klíčovým prvkem pro efektivní kyberbezpečnost díky své schopnosti detekovat hrozby.
Correlator identifikuje specifické aktivity, vzorce, anomálie a hrozby v reálném čase podle pravidel detekce. Correlator pracuje v datovém proudu vašeho systému namísto diskového úložiště, což z něj činí rychlý a jedinečně škálovatelný bezpečnostní mechanismus.
Co Correlator dělá?¶
Correlator sleduje události a jejich časovou souvislost ve vztahu k širšímu vzorci či aktivitě.
- Nejprve identifikujete vzorec, hrozbu nebo anomálii, kterou chcete, aby Correlator monitoroval. Napíšete detekci, která definuje aktivitu, včetně toho, jaké typy událostí (logů) jsou relevantní a kolikrát se musí událost vyskytnout v definovaném časovém rámci, aby byla vyvolána reakce.
-
Correlator identifikuje relevantní příchozí události a organizuje je nejprve podle určitého atributu v události (dimenze), jako je zdrojová IP adresa nebo uživatelské ID, a poté třídí události do krátkých časových intervalů, takže může analyzovat počet událostí. Časové intervaly jsou také definovány pravidlem detekce.
Poznámka: Nejčastěji se v Correlatoru používá funkce sum pro počítání událostí, které se vyskytly ve specifikovaném časovém rámci. Correlator může také analyzovat za použití dalších matematických funkcí.
-
Correlator analyzuje tyto dimenze a časové intervaly, aby zjistil, zda se relevantní události vyskytly ve stanoveném časovém rámci. Když Correlator detekuje aktivitu, vyvolá reakci specifikovanou v detekci.
Jinak řečeno, tento mikroslužba sdílí stav událostí v časových intervalech a používá klouzavé okno pro analýzu.
Co je klouzavé analýzové okno?
Použití klouzavého okna analýzy znamená, že Correlator může kontinuálně analyzovat více časových intervalů. Například při analýze období 30 sekund Correlator posouvá své 30 sekundové okno analýzy tak, aby překrýval předchozí analýzy, jak čas postupuje.
Tento obrázek představuje jedinou dimenzi, například analýzu událostí se stejnou zdrojovou IP adresou. Ve skutečném pravidle detekce byste měli několik řad této tabulky, jedna řada pro každou IP adresu. Více v příkladu níže.
Klouzavé okno umožňuje analyzovat překrývající se 30 sekundové časové rámce 0:00-0:30
, 0:10-0:40
, 0:20-0:50
a 0:30-0:60
namísto pouze 0:00-0:30
a 0:30-0:60
.
Příklad¶
Příklad scénáře: Vytvoříte detekci, která vás upozorní, když je učiněno 20 pokusů o přihlášení ke stejnému uživatelskému účtu během 30 sekund. Protože tato rychlost zadávání hesel je vyšší, než by většina lidí mohla dosáhnout sami, může tato aktivita naznačovat útok hrubou silou.
Aby Correlator mohl detekovat tuto bezpečnostní hrozbu, potřebuje vědět dvě věci:
- Které události jsou relevantní. V tomto případě to znamená neúspěšné pokusy o přihlášení ke stejnému uživatelskému účtu.
- Kdy se tyto události (pokusy o přihlášení) staly ve vztahu k sobě navzájem.
Poznámka: Následující logy a obrázky jsou závažně zjednodušeny pro lepší ilustraci myšlenek.
1. Tyto logy se vyskytují v systému:
Co tyto logy znamenají?
Každá tabulka, kterou vidíte výše, je log pro událost jednoho neúspěšného pokusu o přihlášení uživatele.
log.ID
: Unikátní identifikátor logu, jak je vidět v tabulce nížetimestamp
: Čas, kdy se událost odehrálausername
: Correlator bude analyzovat skupiny logů od stejných uživatelů, protože by nebylo efektivní analyzovat pokusy o přihlášení napříč všemi uživateli dohromady.event.message
: Correlator hledá pouze neúspěšné přihlášení, jak by bylo definováno pravidlem detekce.
2. Correlator začíná sledovat události v řádcích a sloupcích:
- Uživatelské jméno je dimenze, jak je definováno pravidlem detekce, takže každý uživatel má svůj vlastní řádek.
- Log ID (A, B, C, atd.) je zde v tabulce, aby bylo vidět, které logy jsou počítány.
- Číslo v každé buňce je kolik událostí se v daném časovém intervalu pro daného uživatele (dimenze) vyskytlo.
3. Correlator pokračuje ve sledování událostí:
Vidíte, že jeden účet nyní zažívá vyšší objem neúspěšných pokusů o přihlášení.
4. Zároveň Correlator analyzuje 30-sekundové časové rámce pomocí analýzového okna:
Analýzové okno se pohybuje přes časové intervaly a počítá celkový počet událostí v 30-sekundových časových rámcích. Vidíte, že když analýzové okno dosáhne časového rámce 01:20-01:50
pro uživatelské jméno anna.s.ample
, spočítá více než 20 událostí. To by vyvolalo reakci z Correlatoru, jak je definováno v detekci (více o triggerech zde).
Gif pro ilustraci pohybu analýzového okna
30-sekundové analýzové okno "klouže" nebo "roluje" podél časových intervalů a počítá, kolik událostí se stalo. Když najde 20 nebo více událostí v jedné analýze, akce z pravidla detekce je spuštěna.
Paměť a úložiště¶
Correlator funguje v datovém proudu, ne v databázi. To znamená, že Correlator sleduje události a provádí analýzu v reálném čase, jakmile se události stávají, namísto tahání minulých sbíraných událostí z databáze k provedení analýzy.
Aby mohl fungovat v datovém proudu, Correlator používá mapování paměti, což mu umožňuje fungovat v rychle přístupné paměti systému (RAM) spíše než spoléhat na diskové úložiště.
Mapování paměti poskytuje významné výhody:
- Detekce v reálném čase: Data v RAM jsou rychlejší na přístup než data z diskového úložiště. To činí Correlator velmi rychlým, což vám umožňuje detekovat hrozby okamžitě.
- Simultánní zpracování: Větší kapacita zpracování umožňuje Correlatoru provozovat mnoho paralelních detekcí najednou.
- Škálovatelnost: Objem dat v systému pro shromažďování logů pravděpodobně vzroste, jak vaše organizace poroste. Correlator může držet krok. Alokace další RAM je rychlejší a jednodušší než zvětšování diskového úložiště.
- Perzistence: Pokud se systém neočekávaně vypne, Correlator neztrácí data. Historie Correlatoru je často zálohována na disk (SSD), takže data jsou dostupná, když se systém znovu spustí.
Pro více technických informací navštivte naše referenční dokumentaci Correlatoru.
Co je detekce?¶
Detekce (někdy nazývaná korelační pravidlo) definuje a nachází vzorce a specifické události ve vašich datech. Velký objem událostních logů prochází vaším systémem a detekce pomáhají identifikovat události a kombinace událostí, které mohou být výsledkem bezpečnostního narušení nebo systémové chyby.
Důležité
- Možnosti vašich detekcí závisí na vaší Konfiguraci korelátoru.
- Všechny detekce jsou psány v TeskaLabs SP-Lang. K dispozici je rychlý průvodce SP-Lang v příkladu korelace okna a další pokyny pro detekci.
Co mohou detekce dělat?¶
Můžete napsat detekce, které popisují a nacházejí nekonečnou kombinaci událostí a vzorců, ale toto jsou běžné aktivity k monitorování:
- Více neúspěšných pokusů o přihlášení: Četné neúspěšné pokusy o přihlášení během krátké doby, často ze stejné IP adresy, kvůli zachycení brute-force nebo útoků pomocí posypávání hesel.
- Neobvyklý přenos nebo exfiltrace dat: Abnormální nebo velký přenos dat z vnitřní sítě na externí místa.
- Skenování portů: Pokusy o identifikaci otevřených portů na síťových zařízeních, které mohou být předzvěstí útoku.
- Neobvyklé hodiny aktivity: Aktivita uživatelů nebo systému během nepracovních hodin, což by mohlo naznačovat kompromitovaný účet nebo vnitřní hrozbu.
- Geografické anomálie: Přihlášení nebo aktivity pocházející z neočekávaných geografických míst na základě typického chování uživatele.
- Přístup k citlivým zdrojům: Neoprávněné nebo neobvyklé pokusy o přístup k důležitým nebo citlivým souborům, databázím nebo službám.
- Změny kritických systémových souborů: Neočekávané změny systémových a konfiguračních souborů.
- Podozrivá e-mailová aktivita: Phishingové e-maily, přílohy s malwarem nebo jiné typy škodlivého obsahu v e-mailech.
- Eskalatace privilegií: Pokusy o eskalaci privilegií, například když se běžný uživatel snaží získat přístup na úrovni administrátora.
Začínáme¶
Pečlivě plánujte své korelační pravidlo, abyste se vyhli chybějícím důležitým událostem nebo přitahování pozornosti k irelevantním událostem. Odpovězte na otázky:
- Jakou aktivitu (události nebo vzorce) chcete detekovat?
- Které logy jsou relevantní pro tuto aktivitu?
- Co chcete, aby se stalo, pokud bude aktivita detekována?
Pro začátek psaní detekce si prohlédněte tento příklad korelace okna a postupujte podle těchto dalších pokynů.
Psaní detekčního pravidla typu korelace okna¶
Pravidlo pro korelaci okna je velmi všestranný typ detekce, který může identifikovat kombinace událostí v čase. Tento příklad ukazuje některé techniky, které můžete použít při psaní pravidel pro korelaci okna, ale existuje mnoho dalších možností, takže tato stránka vám poskytne další vedení.
Než budete moci napsat nové detekční pravidlo, musíte:
- Rozhodnout, jakou aktivitu hledáte, a rozhodnout časový rámec, ve kterém je tato aktivita významná.
- Identifikovat, který zdroj dat produkuje logy, které by mohly spustit pozitivní detekci, a zjistit, jaké informace tyto logy obsahují.
- Rozhodnout, co chcete, aby se stalo, když je aktivita detekována.
Použijte TeskaLabs SP-Lang pro psaní korelačních pravidel.
Sekce korelačního pravidla¶
Zahrňte následující sekce do vašeho pravidla:
- Define: Informace, které popisují vaše pravidlo.
- Predicate: Sekce
predicate
je filtr, který identifikuje, které logy vyhodnotit, a které logy ignorovat. - Evaluate: Sekce
evaluate
třídí nebo organizuje data k analýze. - Analyze: Sekce
analyze
definuje a hledá požadovaný vzorec v datech setříděných sekcíevaluate
. - Trigger: Sekce
trigger
definuje, co se stane, pokud dojde k pozitivní detekci.
K lepšímu pochopení struktury korelačního pravidla okna konzultujte tento příklad.
Komentáře
Zahrňte komentáře do vašich detekčních pravidel, aby vy a ostatní pochopili, co každá položka v detekčním pravidle dělá. Přidávejte komentáře na samostatných řádcích od kódu a začínejte komentáře mřížkami #
.
Závorky
Slova v závorkách ()
jsou zástupné symboly, které ukazují, že by v této části obvykle byla hodnota. Korelační pravidla nepoužívají závorky.
Define¶
Vždy zahrňte do define
:
Položka v pravidlu | Jak zahrnout |
---|---|
|
Pojmenujte pravidlo. I když název nemá žádný vliv na funkčnost pravidla, měl by být jasný a snadno pochopitelný pro vás i ostatní. |
|
Popište pravidlo stručně a přesně. Popis také nemá vliv na funkčnost pravidla, ale může pomoct vám i ostatním pochopit, k čemu pravidlo slouží. |
|
Zahrňte tento řádek tak, jak je. type ovlivňuje funkčnost pravidla. Pravidlo používá correlator/window k fungování jako korelátor oken.
|
Predicate¶
Sekce predicate
je filtr. Při psaní predicate
používáte SP-Lang výrazy ke struktuře podmínek filtru pro "povolení" pouze logů, které jsou relevantní k aktivitě nebo vzorci, který pravidlo detekuje.
Pokud log splňuje podmínky predikátu, je analyzován v dalších krocích detekčního pravidla spolu s dalšími souvisejícími logy. Pokud log nesplňuje podmínky predikátu, detekční pravidlo log ignoruje.
Viz tato příručka, abyste se dozvěděli více o psaní predikátů.
Evaluate¶
Jakýkoli log, který projde filtrem v predicate
, je hodnocen v evaluate
. Sekce evaluate
organizuje data, aby mohla být analyzována. Obvykle nelze odhalit bezpečnostní hrozbu (nebo jiné významné vzorce) pouze na základě jedné události (například jednoho neúspěšného pokusu o přihlášení), proto je potřeba psát detekční pravidla k seskupení událostí dohromady, aby se našly vzorce, které ukazují na bezpečnostní nebo provozní problémy.
Sekce evaluate
vytváří neviditelné hodnotící okno - můžete si okno představit jako tabulku. Tabulku používá sekce analyze
k detekci aktivity, kterou hledá detekční pravidlo.
Můžete vidět příklad sekcí evaluate
a analyze
spolupracujících zde.
Položka v evaluate |
Jak zahrnout |
---|---|
|
dimension vytváří řádky v tabulce. V tabulce jsou hodnoty specifikovaných polí seskupeny do jednoho řádku (viz tabulka níže).
|
|
by vytváří sloupce v tabulce. Ve většině případů je @timestamp správnou volbou, protože pravidla korelace oken jsou založena na čase. Takže každý sloupec v tabulce je interval času, který specifikuje resolution .
|
|
Jednotka resolution je sekundy. Každý časový interval bude počet sekund, které určíte.
|
|
Pole saturation nastavuje, kolikrát může být spouštěč aktivován, než pravidlo přestane počítat události v jedné buňce, které způsobily spuštění (viz tabulka níže). S doporučeným nasycením 1 přestanou být relevantní události, které se stanou v rámci stejného určeného časového rámce (resolution ), počítány po jednom spuštění. Nastavení saturace na 1 zabraňuje dalšímu spouštění pro totožné chování ve stejném časovém rámci.
|
Analyze¶
analyze
používá tabulku vytvořenou sekcí evaluate
, aby zjistil, zda se stala aktivita, kterou hledá detekční pravidlo.
Můžete vidět příklad sekcí evaluate
a analyze
spolupracujících zde.
Položka v analyze |
Jak zahrnout |
---|---|
|
Okno analyzuje specifikovaný počet buněk v tabulce vytvořené sekcí evaluate , z nichž každá představuje logy v určeném časovém rámci. Hoppingové okno: Okno bude počítat hodnoty v buňkách, testující všechny přilehlé kombinace buněk, aby pokryla stanovené časové období, s přesahem. Hoppingové okno je doporučeno. Tumblingové okno: Okno počítá hodnoty v buňkách, testující všechny přilehlé kombinace buněk, aby pokryla stanovené časové období, BEZ přesahu. Viz poznámka níže pro další informace o hoppingových a tumblingových oknech. |
|
aggregate závisí na dimension . Použijte unique count , abyste zajistili, že pravidlo nebude počítat stejnou hodnotu vašeho specifikovaného pole v dimension více než jednou.
|
|
Span nastavuje počet buněk v tabulce, které budou analyzovány najednou. span vynásobený resolution je časový rámec, ve kterém korelační pravidlo hledá vzorec nebo chování. (Například 2*60 je 2 minutový časový rámec.)
|
|
Výraz !GE znamená "větší než nebo rovno" a !ARG VALUE odkazuje na výstupní hodnotu funkce aggregate . Hodnota uvedená pod !ARG VALUE je počet unikátních výskytů hodnoty v jednom analyzačním okně, které spustí korelační pravidlo.
|
Hoppingová vs. tumblingová okna
Tato stránka o tumblingových a hoppingových oknech vám může pomoci pochopit různé typy analyzačních oken.
Trigger¶
Po identifikaci podezřelé aktivity, kterou jste specifikovali, pravidlo může:
- Odeslat detekci do Elasticsearch jako dokument. Poté můžete vidět detekci jako log v TeskaLabs LogMan.io. Můžete vytvořit svůj vlastní dashboard pro zobrazení detekcí korelačních pravidel, nebo najít logy v Průzkumník.
- Poslat notifikaci emailem
Navštivte stránku spouštěčů, abyste se dozvěděli o nastavení spouštěčů pro vytváření událostí, a jděte na stránku notifikací, abyste se dozvěděli o odesílání zpráv z detekcí.
Příklad detekčního pravidla pro korelaci oken¶
Pravidlo pro korelaci oken je typ detekce, které může identifikovat kombinace událostí v průběhu času. Než použijete tento příklad pro napsání svého vlastního pravidla, navštivte tyto pokyny, abyste lépe porozuměli jednotlivým částem pravidla.
Jako všechna detekční pravidla, i pravidla pro korelaci oken píšeme v TeskaLabs SP-Lang.
Přejít na: Definovat | Predikát | Vyhodnotit | Analyzovat | Spustit
Toto detekční pravidlo hledá jednu externí IP adresu, která se snaží přistupovat ke 25 nebo více unikátním interním IP adresám během 2 minut. Tato aktivita může naznačovat pokus útočníka prohledávat síťovou infrastrukturu kvůli zranitelnosti.
Poznámka
Jakýkoli řádek začínající hashtag (#) je komentář, není součástí detekčního pravidla. Přidávejte poznámky do svých detekčních pravidel, aby ostatní lépe pochopili účel a funkci pravidel.
Kompletní detekční pravidlo pomocí korelace oken:
define:
name: "Network T1046 Network Service Discovery"
description: "Externí IP přistupující k 25+ interním IP adresám během 2 minut"
type: correlator/window
predicate:
!AND
- !OR
- !EQ
- !ITEM EVENT event.dataset
- "fortigate"
- !EQ
- !ITEM EVENT event.dataset
- "sophos"
- !OR
- !EQ
- !ITEM EVENT event.action
- "deny"
- !EQ
- !ITEM EVENT event.action
- "drop"
- !IN
what: source.ip
where: !EVENT
- !NOT
what:
!STARTSWITH
what: !ITEM EVENT source.ip
prefix: "193.145"
- !NE
- !ITEM EVENT source.ip
- "8.8.8.8"
- !IN
what: destination.ip
where: !EVENT
evaluate:
dimension: [tenant, source.ip]
by: "@timestamp"
resolution: 60
saturation: 1
analyze:
window: hopping
aggregate: unique count
dimension: destination.ip
span: 2
test:
!GE
- !ARG VALUE
- 25
trigger:
- event:
!DICT
type: "{str:any}"
with:
ecs.version: "1.10.0"
lmio.correlation.depth: 1
lmio.correlation.name: "Network T1046 Network Service Discovery"
# Události
events: !ARG EVENTS
# Popis hrozby
# https://www.elastic.co/guide/en/ecs/master/ecs-threat.html
threat.framework: "MITRE ATT&CK"
threat.software.platforms: "Network"
threat.indicator.sightings: !ARG ANALYZE_RESULT
threat.indicator.confidence: "Medium"
threat.indicator.ip: !ITEM EVENT source.ip
threat.indicator.port: !ITEM EVENT source.port
threat.indicator.type: "ipv4-addr"
threat.tactic.id: "TA0007"
threat.tactic.name: "Discovery"
threat.tactic.reference: "https://attack.mitre.org/tactics/TA0007/"
threat.technique.id: "T1046"
threat.technique.name: "Network Service Discovery"
threat.technique.reference: "https://attack.mitre.org/techniques/T1046/"
# Identifikace
event.kind: "alert"
event.dataset: "correlation"
source.ip: !ITEM EVENT source.ip
Definovat¶
define:
name: "Network T1046 Network Service Discovery"
description: "Externí IP přistupující k 25+ interním IP adresám během 2 minut"
type: correlator/window
Položka v pravidle | Co to znamená? |
---|---|
|
To je název pravidla. Název je pro uživatele a nemá žádný dopad na samotné pravidlo. |
|
Popis je také pro uživatele. Popisuje, co pravidlo dělá, ale nemá žádný dopad na samotné pravidlo. |
|
Typ má dopad na pravidlo. Pravidlo používá correlator/window k fungování jako okno korelace.
|
Predikát¶
predicate
je filtr, který kontroluje, zda příchozí log může souviset s událostí, kterou detekční pravidlo hledá.
Predikát je složen z výrazů SP-Lang. Výrazy vytvářejí podmínky. Pokud je výraz "pravdivý", je podmínka splněna. Filtr kontroluje příchozí log, aby zjistil, zda log činí výrazy predikátu "pravdivými" a tedy splňuje podmínky.
Pokud log splňuje podmínky predikátu, je analyzován dalším krokem detekčního pravidla spolu s dalšími souvisejícími logy. Pokud log nesplňuje podmínky predikátu, detekční pravidlo log ignoruje.
Kompletní dokumentaci k SP-Lang najdete zde.
Výrazy SP-Lang, v pořadí, ve kterém se objevují v predikátu
Výraz | Význam |
---|---|
!AND |
VŠECHNY kritéria vnořené pod !AND musí být splněny, aby !AND bylo pravdivé |
!OR |
Alespoň JEDNO z kritérií vnořených pod !OR musí být splněno, aby !OR bylo pravdivé |
!EQ |
"Rovná se". Musí se rovnat, nebo odpovídat hodnotě, aby bylo pravdivé |
!ITEM EVENT |
Získává informace z obsahu příchozích logů (přistupuje k polím a hodnotám v příchozích logech) |
!IN |
Hledá hodnotu v rozsahu hodnot (co v kde ) |
!NOT |
Hledá opak výrazu vnořeného pod !NOT (následující co ) |
!STARTSWITH |
Hodnota pole (co ) musí začínat na specifikovaný text (prefix ), aby byla pravdivá |
!NE |
"Nerovná se". Musí se NEROVNAT (nesmí odpovídat hodnotě), aby byla pravdivá |
Je vidět, že pod !AND
je několik výrazů. Log musí splňovat VŠECHNY podmínky vnořené pod !AND
, aby prošel přes filtr.
Jak je vidno v pravidle | Co to znamená? |
---|---|
|
To je první !OR výraz a má vnořeny dva !EQ výrazy, takže alespoň JEDNA !EQ podmínka vnořená pod toto !OR musí být pravdivá. Pamatujte, !ITEM EVENT získává hodnotu pole, které specifikuje. Pokud má příchozí log v poli event.dataset "fortigate" NEBO "sophos", pak log splňuje podmínku !OR .
Tento filtr přijímá události pouze ze zdrojů dat FortiGate a Sophos. FortiGate a Sophos poskytují bezpečnostní nástroje jako jsou firewally, takže toto pravidlo hledá události generované bezpečnostními nástroji, které možná již zachycují podezřelou aktivitu. |
|
Tato podmínka je strukturována stejně jako předchozí. Pokud má příchozí log hodnotu "deny" NEBO "drop" v poli event.action , pak log splňuje tuto podmínku !OR .
Hodnoty "deny" a "drop" v logu signalizují, že bezpečnostní zařízení, jako například firewall, zablokovalo pokus o přístup na základě autorizačních nebo bezpečnostních politik. |
|
Pokud pole source.ip existuje v příchozím logu (!EVENT ), pak log splňuje tuto podmínku !IN .
Pole source.ip je IP adresa, která se snaží získat přístup k jiné IP adrese. Protože toto pravidlo se specificky týká IP adres, log musí obsahovat zdrojovou IP adresu, aby byl relevantní.
|
|
Pokud hodnota pole source.ip NEZAČÍNÁ na "193.145", pak je tento výraz !NOT pravdivý. 193.145 je začátek interních IP adres této sítě, takže výraz !NOT filtruje interní IP adresy. To proto, že interní IP adresy přistupující k mnoha jiným interním IP adresám v krátkém časovém období by nebyly podezřelé. Pokud by nebyly interní IP adresy vyfiltrovány, pravidlo by vracelo falešně pozitivní výsledky.
|
|
Pokud příchozí log NEMÁ hodnotu "8.8.8.8" v poli source.ip , pak log splňuje tuto podmínku !NE .
Pravidlo filtruje 8.8.8.8 jako zdrojovou IP adresu, protože je to známý a důvěryhodný DNS resolver provozovaný společností Google. 8.8.8.8 obecně není spojována s podezřelou aktivitou, takže pokud bychom ji nevyloučili, pravidlo by vyvolalo falešně pozitivní výsledky. |
|
Pokud pole destination.ip existuje v příchozím logu, pak log splňuje tuto podmínku !IN .
Pole destination.ip je IP adresa, ke které je přistupováno. Protože toto pravidlo se specificky týká IP adres, log musí obsahovat cílovou IP adresu, aby byl relevantní.
|
Pokud příchozí log splní VŠECHNY podmínky uvedené výše (vnořené pod !AND
), pak je log vyhodnocován a analyzován v dalších částech detekčního pravidla.
Vyhodnotit¶
Každý log, který projde filtrem v predicate
, je vyhodnocen v evaluate
. Sekce evaluate
organizuje data tak, aby mohla být analyzována. Obvykle není možné rozpoznat bezpečnostní hrozbu (nebo jiné významné vzory) pouze na základě jedné události (např. jednoho neúspěšného pokusu o přihlášení), takže detekční pravidlo skupinuje události, aby našlo vzory, které ukazují na bezpečnostní nebo provozní problémy.
Sekce evaluate
vytváří neviditelné hodnotící okno - můžete si ho představit jako tabulku. Tuto tabulku používá sekce analyze
k detekci události, kterou detekční pravidlo hledá.
evaluate:
dimension: [tenant, source.ip]
by: "@timestamp"
resolution: 60
saturation: 1
Jak je vidno v rámci pravidla | Co to znamená? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
dimension vytváří řádky v tabulce. Řádky jsou tenant a source.ip . V konečné tabulce jsou hodnoty tenant a source.ip seskupeny do jednoho řádku (viz tabulka níže).
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
by vytváří sloupce v tabulce. Odkazuje na pole @timestamp , protože hodnoty z tohoto pole umožňují pravidlu porovnávat události v průběhu času. Takže každý sloupec je interval času, který specifikuje resolution .
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Jednotkou resolution jsou sekundy, takže hodnota zde je 60 sekund. Každý časový interval bude dlouhý 60 sekund.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Pole saturation nastavuje, kolikrát může být spouštěč aktivován, než pravidlo přestane počítat události v jedné buňce, která způsobila spouštěč (viz tabulka níže). Protože saturace je 1, znamená to, že relevantní události, které se stanou během jedné minuty, přestanou být počítány po jedné aktivaci spouštěče. Nastavení saturace na 1 zabraňuje dalším aktivacím spouštěče pro stejné chování ve stejném časovém rozmezí. V tomto příkladu by byl spouštěč aktivován pouze jednou, pokud by se externí IP adresa pokusila přistoupit k jakémukoli počtu unikátních internPredikáty¶
Jak psát predikáty¶Než můžete vytvořit filtr, musíte znát možné pole a hodnoty logů, které hledáte. Abyste zjistili, jaká pole a hodnoty mají vaše logy, přejděte do Průzkumníka ve webové aplikaci TeskaLabs LogMan.io. SP-Lang výrazy¶Sestavte podmínky pro filtr pomocí SP-Lang výrazů. Filtr kontroluje příchozí log, aby zjistil, zda log splňuje podmínky tím, že činí výrazy "pravdivými". Kompletní dokumentaci k SP-Lang najdete zde. Běžné SP-Lang výrazy:
Podmínky¶Použijte tento průvodce ke správnému strukturování jednotlivých podmínek. Závorky Slova v závorkách
Příklad¶Abyste pochopili, co jednotlivé výrazy znamenají v kontextu tohoto příkladu, klikněte na ikony .
Tento filtr hledá logy, které:
Pro další nápady a tipy na formátování si prohlédněte tento příklad v kontextu detekčního pravidla včetně podrobností o sekci Triggery¶Trigger, v alertu nebo detekci, provádí akci. Například v detekci může sekce Trigger může:
Spuštění události¶Můžete spustit událost. Konečným výsledkem je, že trigger vytvoří log události, kterou můžete vidět v TeskaLabs LogMan.io.
Následující
Pokud používáte Elasticsearch a tedy Elastic Common Schema (ECS), můžete si přečíst o standardních polích v ECS reference guide. Spuštění oznámení¶Oznámení odesílají zprávy. V současné době můžete použít oznámení k odesílání e-mailů. Více informací o psaní oznámení a vytváření e-mailových šablon. NotifikaceNotifikace¶Notifikace odesílají zprávy. Můžete přidat sekci TeskaLabs LogMan.io používá TeskaLabs ASAB Iris, TeskaLabs mikroservisu, k odesílání zpráv. Warning Aby nedošlo k zahlcení notifikacemi, používejte notifikace pouze pro vysoce naléhavá a dobře otestovaná detekční pravidla. Některé detekce jsou více vhodné k odesílání jako události přes Elasticsearch a prohlížení v webové aplikaci LogMan.io. Typy notifikací¶Aktuálně můžete odesílat zprávy přes email. Odesílání upozornění prostřednictvím e-mailu¶Upozornění pište v TeskaLabs SP-Lang. Pokud píšete upozornění na detekci, napište e-mailové upozornění v sekci Důležité Pro upozornění, která odesílají e-maily, musíte vytvořit e-mailovou šablonu v Knihovně, se kterou se propojíte. Tato šablona obsahuje skutečný text, který příjemce uvidí, s prázdnými poli, která se mění podle toho, co bylo detekováno (používá se Jinja templating), včetně logů zapojených do detekce a jakýchkoli dalších informací dle vašeho výběru. Sekce upozornění v pravidle detekce vyplňuje prázdná pole v e-mailové šabloně. Jednu e-mailovou šablonu můžete použít pro více pravidel detekce. Příklad: Použijte tento příklad jako vodítko. Klikněte na ikony , abyste zjistili, co znamená každý řádek.
Vyplňování e-mailové šablony
Pole Pole Odkazujte se na naše pokyny pro vytváření e-mailových šablon, abyste mohli psát šablony, které správně fungují jako upozornění. Vytvoření emailových šablon¶Emailová šablona je dokument, který spolupracuje s Emailová šablona poskytuje text, který příjemce vidí, když obdrží email z notifikace. Emailové šablony najdete ve své Knihovně ve složce Templates. Když píšete emailovou šablonu ke spojení s notifikací, ujistěte se, že šablonová pole v každé položce odpovídají. Jak spolu notifikace a emailová šablona spolupracují?TeskaLabs ASAB Iris je mikroslužba pro zasílání zpráv, která spojuje notifikaci a emailovou šablonu a odesílá emaily s vyplněnými zástupnými poli. Vytvoření emailové šablony¶Vytvoření nové prázdné emailové šablony
Kopírování existující emailové šablony
Chcete-li opustit režim úprav, uložte kliknutím na Save nebo zrušte kliknutím na Cancel. Psaní emailové šablony¶Emailové šablony můžete psát v Markdown nebo v HTML. Markdown je méně složité, ale HTML vám dává více možností formátování. Když píšete text, ujistěte se, že příjemci vyjasníte:
Jednoduchý příklad šablony pomocí Markdown:
Slova ve dvou složených závorkách (jako Testování emailové šablony¶Emailovou šablonu můžete otestovat pomocí funkce Test template. Testování emailové šablony znamená odeslání skutečného emailu, aby se zjistilo, zda se formát a pole zobrazují správně. Tento test žádným způsobem neinteraguje s detekčním pravidlem. Vyplňte pole From, To, CC, BCC a Subject stejným způsobem jako u jakéhokoli emailu (ale je nejlepší praxí poslat email sami sobě). Vždy musíte vyplnit minimálně pole From a To. Testovací parametry¶Můžete naplnit Jinja šablonová pole pro testovací účely pomocí nástroje Parameters. Napište parametry v JSON. JSON používá páry klíč-hodnota. Klíče jsou pole v šabloně a hodnoty jsou to, co naplní pole. V tomto příkladu jsou klíče a hodnoty zvýrazněny, aby ukázaly, že klíče v Parameters musí odpovídat polím v šabloně a hodnoty naplní pole ve výsledném emailu: Parameters má dva režimy úprav: textový editor a klikací JSON editor. Chcete-li přepínat mezi režimy, klikněte na ikonu <···> nebo vedle Parameters. Můžete přepínat mezi režimy bez ztráty své práce. Klikací editor¶Chcete-li přepnout na klikací JSON editor, klikněte na ikonu <···> vedle Parameters. Klikací editor formátuje vaše parametry za vás a říká vám typ hodnoty pro každou položku. Jak používat klikací editor: V klikacím editoru, editujte, smažte a přidejte ikony, které se zobrazují při najetí myší nad řádky a položky. 1. Přidejte klíč: Když najedete myší nad horní řádek (říká počet klíčů, které máte, například 0 items), objeví se ikona . Chcete-li přidat parametr, klikněte na ikonu . Výzva vás požádá o název klíče. Zadejte název klíče (název pole, které chcete testovat) a klikněte na ikonu , aby se uložil. Nepoužívejte uvozovky - editor je přidá za vás. Název klíče se objeví vedle hodnoty 2. Přidejte hodnotu: Chcete-li upravit hodnotu, klikněte na ikonu , která se objeví, když najedete myší vedle hodnoty 3. Chcete-li přidat další páry klíč-hodnota, klikněte na ikonu , která se objeví, když najedete myší nad horní řádek. 4. Chcete-li položku smazat, klikněte na ikonu , která se objeví, když najedete myší nad položku. Chcete-li položku upravit, klikněte na ikonu , která se objeví, když najedete myší nad položku. Textový editor¶Chcete-li přepnout do textového editoru, klikněte na ikonu vedle Parameters. Příklad formátování parametrů:
Rychlé tipy pro JSON
Testovací okno vám řekne, pokud parametry nejsou v platném formátu JSON. Přepínání režimů¶Můžete přepínat režimy a pokračovat v úpravách svých parametrů. Nástroj Parameters automaticky převede vaši práci na nový režim. Poznámka o polích Pole je seznam více hodnot. Chcete-li upravit hodnotu pole v klikacím editoru, musíte nejprve ručně napsat alespoň dvě hodnoty ve správném formátu pole v textovém editoru (viz Rychlé tipy pro JSON výše). Poté můžete přepnout do klikacího editoru a přidat další položky do pole. Odeslání testovacího emailu¶Když budete připraveni testovat email, klikněte na Send. Obdržíte email do schránky adresáta v poli To:, kde můžete zkontrolovat formátování šablony. Pokud email nevidíte, zkontrolujte svou složku se spamem. Jinja šablonování¶Sekce Formát¶Formátujte všechna Jinja šablonová pole dvěma složenými závorkami na každé straně názvu pole, jak v Markdown, tak v HTML emailových šablonách. Můžete, ale nemusíte, použít mezeru na každé straně názvu pole.
Pro podrobnější vysvětlení šablonování pomocí Jinja navštivte tento návod.
|
Mount | Velikost | FS | Part. | RAID / Part. | VG / LV |
---|---|---|---|---|---|
/boot/efi |
1G | fat32 | 1 | ||
SWAP | 64G | 2 | |||
/boot |
2G | ext4 | 3 | md0 / 1 |
|
/ |
50G | ext4 | 3 | md0 / 2 |
systemvg / rootlv |
/var/log |
50G | ext4 | 3 | md0 / 2 |
systemvg / loglv |
Nepoužité | >100G | 3 | md0 / 2 |
systemvg |
Legenda:
- FS: Souborový systém
- Part.: GUID oddíl
- RAID / Part.: MD RAID svazek a oddíl na daném RAID svazku
- VG: LVM Skupina svazků
- LV: LVM Logický svazek
Note
Nepoužitý prostor bude později použit během instalace např. pro Docker kontejnery.
10) Identifikujte dva systémové úložné disky
Dva systémové úložné disky jsou strukturovány symetricky pro zajištění redundancy v případě selhání jednoho systémového disku.
Note
Rychlé a pomalé úložiště není zde konfigurováno během instalace OS, ale později z nainstalovaného OS.
11) Nastavte první systémový disk jako primární bootovací zařízení
Tento krok vytvoří první GPT oddíl s UEFI, který je namontován na /boot/efi
.
Velikost tohoto oddílu je přibližně 1 GB.
12) Nastavte druhý systémový disk jako sekundární bootovací zařízení
Další UEFI oddíl je vytvořen na druhém systémovém disku.
13) Vytvořte SWAP oddíly na obou systémových discích
Na každém z dvou disků přidejte GPT oddíl o velikosti 64G a formát swap
.
Vyberte „volný prostor“ na příslušném systémovém disku a poté „Přidat GPT oddíl“
Výsledné uspořádání je následující:
14) Vytvořte GPT oddíl pro RAID1 na obou systémových discích
Na každém z dvou disků přidejte GPT oddíl se vším zbývajícím volným prostorem. Formát je „Neformátovat“, protože tento oddíl bude přidán do RAID1 pole. Můžete nechat „Velikost“ prázdnou, abyste použili veškerý zbývající prostor na zařízení.
Výsledkem je „oddíl“ místo „volného prostoru“ na příslušných discích.
15) Vytvořte softwarový RAID1
Vyberte „Vytvořit softwarový RAID (md)“.
Název pole je md0
(výchozí).
RAID úroveň je „1 (zrcadlené)“.
Vyberte dva oddíly z výše uvedeného kroku, nechte je označené jako „aktivní“ a stiskněte „Vytvořit“.
Uspořádání systémových disků je následující:
16) Vytvořte BOOT oddíl RAID1
Přidejte GPT oddíl na md0
RAID1 z výše uvedeného kroku.
Velikost je 2G, formát je ext4
a mount je /boot
.
17) Nastavte LVM oddíl na RAID1
Zbývající prostor na RAID1 bude spravován pomocí LVM.
Přidejte GPT oddíl na md0
RAID1, pomocí „volného prostoru“ pod zařízením md0
.
Použijte maximální dostupný prostor a nastavte formát na „Neformátovat“. Můžete nechat „Velikost“ prázdnou, abyste použili veškerý zbývající prostor na zařízení.
18) Nastavte LVM skupinu svazků systému
Vyberte „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řte logický svazek root
Přidejte logický svazek s názvem rootlv
na systemvg
(v „volném prostoru“), velikost je 50G, formát je ext4
a mount je /
.
20) Přidejte dedikovaný logický svazek pro systémové logy
Přidejte logický svazek s názvem loglv
na systemvg
, velikost je 50G, formát je ext4
a mount je „Jiné“ a /var/log
.
21) Potvrďte uspořádání systémových disků
Stiskněte „Hotovo“ na spodní části obrazovky a nakonec „Pokračovat“, abyste potvrdili aplikaci akcí na systémových discích.
22) Nastavení profilu
Vaše jméno: TeskaLabs Admin
Název vašeho serveru: lm01
(například)
Vyberte uživatelské jméno: tladmin
Vyberte dočasné heslo, které bude odstraněno na konci instalace.
23) Nastavení SSH
Vyberte „Nainstalovat OpenSSH server“
24) Přeskočte serverové snapy
Stiskněte „Hotovo“, žádné serverové snapy nebudou nainstalovány z této obrazovky.
25) Počkejte, až bude server nainstalován
Trvá to přibližně 10 minut.
Když je instalace dokončena, včetně bezpečnostních aktualizací, vyberte „Restartovat nyní“.
26) Když budete vyzváni, odpojte USB flash disk ze serveru
Stiskněte „Enter“, abyste pokračovali v procesu restartování.
Note
Tento krok můžete přeskočit, pokud instalujete přes IPMI.
27) Spusťte server do nainstalovaného OS
Vyberte „Ubuntu“ na obrazovce GRUB nebo prostě 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) Nakonfigurujte pomalé úložiště dat
Pomalé úložiště dat (HDD) je namontováno na /data/hdd
.
Předpokládáme, ž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é RAID5 pole na /dev/md1
s ext4
souborovým systémem, namontovaný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 RAID6 pole použijte --level=6
.
Vytvořte EXT4 souborový systém a mount point:
sudo mkfs.ext4 -L data-hdd /dev/md1
sudo mkdir -p /data/hdd
Zadejte následující řádek do /etc/fstab
:
/dev/disk/by-label/data-hdd /data/hdd ext4 defaults,noatime 0 1
Danger
Příznak noatime
je důležitý pro optimální výkon úložiště.
Namontujte disk:
sudo mount /data/hdd
Note
Konstrukce RAID pole může trvat značnou dobu. Můžete sledovat průběh pomocí cat /proc/mdstat
. Restartování serveru je během konstrukce RAID pole bezpečné.
Můžete urychlit konstrukci zvýšením rychlostních limitů:
sudo sysctl -w dev.raid.speed_limit_min=5000000
sudo sysctl -w dev.raid.speed_limit_max=50000000
Tato nastavení rychlostních limitů vydrží až do dalšího restartu.
31) Nakonfigurujte rychlé úložiště dat
Rychlé úložiště dat (SSD) je namontováno na /data/ssd
.
Předpokládáme, že server poskytuje následující disková zařízení /dev/nvme0n1
a /dev/nvme1n1
.
Vytvořte softwarové RAID1 pole na /dev/md2
s ext4
souborovým systémem, namontovaným na /data/ssd
.
sudo mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1
sudo mkfs.ext4 -L data-ssd /dev/md2
sudo mkdir -p /data/ssd
Zadejte následující řádek do /etc/fstab
:
/dev/disk/by-label/data-ssd /data/ssd ext4 defaults,noatime 0 1
Danger
Příznak noatime
je důležitý pro optimální výkon úložiště.
Namontujte disk:
sudo mount /data/ssd
32) Uložte konfiguraci RAID pole
Spusťte:
sudo mdadm --detail --scan > /etc/mdadm/mdadm.conf
sudo echo "MAILADDR root" >> /etc/mdadm/mdadm.conf
Aktualizujte init ramdisk:
sudo update-initramfs -u
33) Deaktivujte periodickou kontrolu RAID
sudo systemctl disable mdcheck_continue
sudo systemctl disable mdcheck_start
34) Nainstalujte základní nástroje
sudo apt install cron dnsutils iputils-ping tcpdump netcat
sudo apt autoremove
35) Instalace OS je dokončena
Restartujte server, abyste ověřili správnost instalace OS.
sudo reboot
Zde je video, které shrnuje instalační proces:
Od operačního systému k Dockeru¶
V této fázi nejen nainstalujete Docker, ale také celkově připravíte stroj na instalaci TeskaLabs LogMan.io.
Pokud jste přeskočili instalaci na holém hardwaru a provedli instalaci na virtuálním serveru, věnujte pozornost požadavkům.
Požadavky¶
- Běžící server s nainstalovaným operačním systémem.
- Přístup na server přes SSH, uživatel je
tladmin
s oprávněním vykonávatsudo
. - Pomalé úložiště připojené na
/data/hdd
. - Rychlé úložiště připojené na
/data/ssd
.
Časové pásmo UTC
Časové pásmo operačního systému pro TeskaLabs LogMan.io MUSÍ být nastaveno na UTC.
Kroky¶
1) Přihlaste se na server přes SSH jako uživatel tladmin
ssh tladmin@<ip-of-the-server>
2) Nakonfigurujte přístup přes SSH
Nainstalujte veřejný SSH klíč pro uživatele tladmin
:
cat > /home/tladmin/.ssh/authorized_keys
Omezení přístupu:
sudo vi /etc/ssh/sshd_config
Změny v /etc/ssh/sshd_config
:
PermitRootLogin
nano
PubkeyAuthentication
nayes
PasswordAuthentication
nano
3) Nakonfigurujte parametry jádra Linuxu
Zapište tento obsah do souboru /etc/sysctl.d/01-logman-io.conf
vm.max_map_count=262144
net.ipv4.ip_unprivileged_port_start=80
fs.inotify.max_user_instances=1024
fs.inotify.max_user_watches=1048576
fs.inotify.max_queued_events=16384
Parametr vm.max_map_count
zvyšuje maximální počet mmaps v subsystému virtuální paměti Linuxu.
Je to potřeba pro Elasticsearch.
Parametr net.ipv4.ip_unprivileged_port_start
umožňuje neprivilegovaným procesům naslouchat na portu 80 (a více).
To je potřeba, aby NGINX mohl naslouchat na tomto portu a nevyžadoval zvýšená oprávnění.
4) Nainstalujte Docker
Docker je nezbytný pro nasazení všech mikroservis LogMan.io v kontejnerech, konkrétně Apache Kafka, Elasticsearch, NGINX a jednotlivé streamingové pumpy atd.
Vytvořte logický svazek dockerlv
s EXT4 souborovým systémem:
sudo lvcreate -L100G -n dockerlv systemvg
sudo mkfs.ext4 -L docker-ssd /dev/systemvg/dockerlv
sudo mkdir /var/lib/docker
Zadejte následující řádek do /etc/fstab
:
/dev/disk/by-label/docker-ssd /var/lib/docker ext4 defaults,noatime 0 1
Připojte svazek:
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
sudo chmod a+r /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 na server, aby se projevila změna skupiny.
5) Deaktivujte Docker bridge síť
Docker vytváří bridge síť (docker0
) ve výchozím nastavení, která není potřebná pro TeskaLabs LogMan.io.
Toto je způsob, jak deaktivovat výchozí bridge síť Dockeru.
Vytvořte soubor /etc/docker/daemon.json
s následujícím obsahem:
{
"bridge": "none"
}
6) Nainstalujte Wireguard
Wireguard je rychlá a nejbezpečnější VPN technologie. TeskaLabs LogMan.io využívá Wireguard pro interní komunikaci v rámci clusteru.
Rozsah IP adres Wireguard sítě je 172.17.10.0/24
.
Každý uzel clusteru získá jednu IP adresu z tohoto rozsahu, první uzel dostane 172.17.10.1
, druhý 172.17.10.2
a tak dále.
sudo apt install wireguard
sudo su -
cd /etc/wireguard/
umask 077
wg genkey > wg0.key
wg pubkey < wg0.key > wg0.pub
Vytvořte /etc/wireguard/wg0.conf
s následujícím obsahem.
Upravte sekce [Peer]
, aby odrážely rozložení vašeho clusteru.
Pokud instalujete variantu s jedním uzlem, bude přítomna pouze jedna sekce [Peer]
.
[Interface]
PrivateKey = <obsah souboru wg0.key>
ListenPort = 41194
Address = 172.17.10.1/24
MTU = 1412
[Peer]
# První uzel
PublicKey = <obsah souboru wg0.pub>
Endpoint = <IP adresa prvního uzlu>:41194
AllowedIPs = 172.17.10.1/32
PersistentKeepalive = 60
[Peer]
# Druhý uzel
PublicKey = <obsah souboru wg0.pub ze uzlu lmb2>
Endpoint = <IP adresa druhého uzlu>:41194
AllowedIPs = 172.17.10.2/32
PersistentKeepalive = 60
sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0.service
7) Nakonfigurujte rozlišení názvů hostitelů (volitelně)
Cluster TeskaLabs LogMan.io vyžaduje, aby každý uzel mohl rozlišit IP adresu jakéhokoli jiného uzlu clusteru podle jeho názvu.
Pokud nakonfigurovaný DNS server tuto schopnost neposkytuje, názvy uzlů a jejich IP adresy musí být vloženy do /etc/hosts
.
sudo vi /etc/hosts
Příklad /etc/hosts
172.17.10.1 lma1
172.17.10.2 lmb1
172.17.10.3 lmx1
Všimněte si, že IP adresy jsou převzaty z rozsahu Wireguard.
8) Restartujte server
sudo reboot
Je důležité aplikovat všechny výše uvedené parametry.
Instalace TeskaLabs LogMan.io¶
Požadavky¶
- Správné nastavení disků a logických svazků podle předchozích fází.
- Konfigurace v
/etc/sysctl.d/01-logman-io.conf
je aplikována. - Docker běží a uživatel
tladmin
je ve skupinědocker
. - Ujistěte se, že adresář
/opt/site
je prázdný.
Info
Data budou uložena v adresářích /data/hdd
a /data/ssd
.
Ujistěte se, že tyto složky neobsahují žádný obsah, který by mohl interferovat s instalací.
Note
Můžete použít skript pro kontrolu požadavků pro rychlou kontrolu vašeho systému.
# Stáhněte skript
curl -O https://libsreg.z6.web.core.windows.net/prerequisites/prerequisites.sh -o /tmp/prerequisites.sh
# Stáhněte odpovídající SHA-256 kontrolní součet
curl -O https://libsreg.z6.web.core.windows.net/prerequisites/prerequisites.sh.sha256 -o /tmp/prerequisites.sh.sha256
# Ověřte integritu skriptu
(cd /tmp && sha256sum -c prerequisites.sh.sha256)
# Umožněte skriptu být spustitelným a spusťte ho
chmod +x /tmp/prerequisites.sh
(cd /tmp && ./prerequisites.sh)
rm /tmp/prerequisites.sh /tmp/prerequisites.sh.sha256
První uzel nebo jediný uzel¶
1) Stáhněte instalační skript
curl -s https://lmio.blob.core.windows.net/library/lmio/install-ubuntu2204.sh -o /tmp/install-lmio.sh
2) Spusťte instalaci
sudo bash /tmp/install-lmio.sh
Vyberte "První jádrový uzel"
Stiskněte < Pokračovat >
Zadejte přihlašovací údaje do registru Docker TeskaLabs
Stiskněte < Přihlásit se >
pro pokračování.
Note
Přihlašovací údaje poskytuje podpora TeskaLabs. Prosím, kontaktujte nás, pokud je nemáte.
Vyplňte ID uzlu a IP adresu
ID uzlu je název hostitele a MUSÍ být rozpoznatelný.
IP adresa musí být dosažitelná z ostatních uzlů clusteru přes interní síť. Pro instalaci jediného uzlu použijte IP adresu stroje v síti Froting.
Jakmile zadáte všechny potřebné informace a potvrdíte stisknutím tlačítka, instalace pokračuje. To může trvat od několika minut až po půl hodiny. Buďte trpěliví a nezastavujte proces.
Sledování instalace
Pro sledování Docker kontejnerů, které se registrují, otevřete druhý terminál a zadejte watch docker ps -a
.
3) Otevřete webové uživatelské rozhraní
Webová aplikace TeskaLabs LogMan.io bude přístupná na portu 443 s použitím názvu hostitele jako doménového jména.
V příkladu, https://lmio-test/
.
4) První uzel je nainstalován
LogMan.io může běžet jak jako instalace jediného uzlu, tak v clusteru. Pokud běžíte LogMan.io pouze na jednom stroji, vaše instalace je dokončena. Pokračujte k nastavení vaší instalace TeskaLabs LogMan.io pro sběr logů.
Druhý a třetí uzel¶
Ujistěte se, že druhý a třetí jádrový uzel clusteru splňuje požadavky uvedené na začátku této stránky. Také se ujistěte, že můžete dosáhnout prvního uzlu clusteru přes síť.
Pokud jste připraveni, použijte tento příkaz pro zahájení instalace. Ujistěte se, že specifikujete verzi ASAB Maestro. Použijte stejnou verzi jako na prvním uzlu clusteru.
docker run -it --rm --pull always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /opt/site:/opt/site \
-v /opt/site/docker/conf:/root/.docker/ \
-v /data:/data \
-e NODE_ID=`hostname -s` \
-e ASAB_MAESTRO_VERSION=<specifikujte verzi> \ #(1)
--network=host \
pcr.teskalabs.com/asab/asab-governator:stable \
python3 -m governator.bootstrap
- Ujistěte se, že specifikujete verzi ASAB Maestro. Použijte stejnou verzi jako na prvním uzlu clusteru.
Když se GUI otevře, vyberte instalaci druhého/třetího jádrového uzlu.
Na další obrazovce zadejte IP adresu prvního uzlu clusteru, ke kterému se chcete připojit.
Další obrazovka zobrazuje aktuální stav clusteru Zookeeper a umožňuje vám zkontrolovat název hostitele a IP adresu.
Zkontrolujte nebo opravte název hostitele a IP adresu a stiskněte "Vytvořit nový uzel clusteru"
Čekejte, až proces skončí.
Zbytek lze nastavit z webové aplikace LogMan.io. Takže, přihlaste se.
Na novém uzlu clusteru (lmio-test2
) běží nové instance. Zkontrolujte to na obrazovce Služby.
Instalace arbitra/quorum uzlu
Pokračujte s těmito nastaveními pouze pokud neplánujete zpracovávat data na uzlu clusteru.
Upravte záznam uzlu v Zookeeperu. Ručně mu přiřaďte roli "arbitra".
Prostřednictvím nabídky Nástroje otevřete Zoonavigator a přejděte do adresáře /asab/nodes
. Najděte uzel, který chcete označit jako arbitra a přidejte mu roli:
ip:
- XX.XX.XX.XX
roles:
- arbiter
Uložte soubor.
Nastavení clusteru¶
Ujistěte se, že technologie clusteru jsou nainstalovány. Zookeeper je již nainstalován.
Přidejte k novému uzlu instanci pro každou službu:
- mongo
- elasticsearch-master
- telegraf
- lmio-collector-system
Přejděte do Knihovny a otevřete model.yaml
umístěný ve složce Site.
Hledejte výše uvedené služby v modelu a přidejte instanci každé na nově nainstalovaném uzlu.
Na tomto snímku obrazovky můžete vidět soubor model.yaml
uvnitř Knihovny, který je upravován na řádku 9. Přidejte ID uzlu nově nainstalovaného uzlu (lmio-test2
) do seznamu instancí služby mongo
. Pokračujte podobně pro všechny výše uvedené služby. Specifikujte instanci elasticsearch master explicitně, podobně jako master-1. Až budete hotovi, stiskněte Uložit a aplikujte změny na dotčený uzel.
Vyberte nový uzel (lmio-test2
) a stiskněte tlačítko Aplikovat.
Když je instalace dokončena, vyberte jeden po druhém zbývající uzly a stiskněte Aplikovat. Aktuální změny musí být aplikovány na všechny uzly clusteru.
Instalace datového uzlu¶
Pokud je tento uzel určen pro sběr logů a zpracování dat, nainstalujte instance následujících služeb podobným způsobem:
- nginx
- kafka
- lmio-receiver
- lmio-depositor
- elasticsearch-hot
- elasticsearch-warm
- elasticsearch-cold
- lmio-lookupbuilder
- lmio-ipaddrproc
Round-Robin DNS vyvažování
Vyvažování sběru logů se provádí prostřednictvím DNS vyvažování. Ujistěte se, že váš DNS server může rozpoznat všechny uzly, kde očekáváte sběr logů.
Instalace bez ASAB Maestro
Instalace bez orchestrace Maestro vyžaduje následující kroky:
1) Vytvořte strukturu složek
sudo apt install git
2) Vytvořte strukturu 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ěňte vlastnictví na složku dat elasticsearch:
sudo chown -R 1000:0 /data/ssd/elasticsearch
sudo chown -R 1000:0 /data/hdd/elasticsearch
3) Klonujte konfigurační soubory webu do složky /opt
:
cd /opt
git clone https://gitlab.com/TeskaLabs/<PARTNER_GROUP>/<MY_CONFIG_REPO_PATH>
4) Přihlaste se do docker.teskalabs.com.
cd <MY_CONFIG_REPO_PATH>
docker login docker.teskalabs.com
5) Vstupte do repozitáře a nasazujte server specifický Docker Compose soubor
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
6) Zkontrolujte, že všechny kontejnery běží
docker ps
Nastavení TeskaLabs LogMan.io¶
Váš TeskaLabs LogMan.io je čerstvě nainstalován a připraven. Pojďme ho nastavit pro sběr logů!
Webové uživatelské rozhraní¶
TeskaLabs LogMan.io je přístupný přes HTTPS na prvním uzlu clusteru.
V tomto příkladu je URL https://lmio-test/
, zadejte ji do svého webového prohlížeče.
Certifikáty SSL podepsané sami sebou
Po výchozím nastavení je TeskaLabs LogMan.io dodáván s certifikáty SSL podepsanými sami sebou. Váš prohlížeč vás upozorní na potenciální bezpečnostní riziko. Nemůže ověřit certifikát SSL. Ale je to vaše instalace, do které vstupujete. Takže přijměte riziko bez obav a pokračujte na webovou stránku.
Vždy můžete nahradit certifikáty podepsané sami sebou vlastními certifikáty.
Budete přesměrováni na přihlašovací obrazovku. Kontaktujte podporu TeskaLabs pro výchozí přihlašovací údaje.
Vytvoření vašich přihlašovacích údajů a pozastavení výchozího administrátora¶
Počáteční nastavení LogMan.io obsahuje system
tenant, který se používá pro administraci a analýzu systémových logů, a výchozí přihlašovací údaje admin
.
Aby bylo zajištěno bezpečné přihlášení, vytvořte nové přihlašovací údaje s rolí superuser
.
Pokud jste ještě nenakonfigurovali SMTP server, vyzvedněte si pokyny pro resetování hesla z logů služby autentizace seacat na serveru.
Ujistěte se, že se můžete úspěšně přihlásit do TeskaLabs LogMan.io s novými přihlašovacími údaji.
Poté pozastavte výchozí přihlašovací údaje admin
.
Zajištění systémových sběračů pro systémový tenant¶
Aby bylo možné začít sbírat logy ze systémových sběračů, zajistěte každý dostupný systémový sběrač do systémového tenantu.
Přizpůsobení instalace¶
SMTP¶
Jak nakonfigurovat SMTP server
Doménové jméno¶
Nastavte parametr PUBLIC_URL
v modelu a klikněte na Použít.
SSL certifikáty¶
Jak přidat vlastní SSL certifikát
Vytvoření prvního tenantu¶
system
tenant je určen pouze pro sběr logů z LogMan.io samotného.
Aby bylo možné začít sbírat logy z vaší IT infrastruktury, vytvořte nový tenant.
V sekci Auth & Roles vyberte Tenants a klikněte na Nový tenant v pravém horním rohu.
Vytvořte konfiguraci pro nový tenant. Název konfigurace MUSÍ být stejný jako název tenantu. Vyberte schéma (ECS je výchozí) a časové pásmo (např. Europe/Prague)
Zajištění sběrače¶
Aby bylo možné povolit sběr logů, musí být nainstalován sběrač TeskaLabs LogMan.io.
Existuje několik způsobů, jak nainstalovat sběrač, vyberte ten, který nejlépe vyhovuje požadavkům vaší infrastruktury.
Pokračujte na Sběrač logů a dozvíte se více.
Jakmile bude sběrač nainstalován a nakonfigurován pro připojení k vaší instanci LogMan.io, uvidíte ho na obrazovce Sběrače. Zajistěte sběrač do nově vytvořeného tenantu.
Postupujte podle dokumentace, jak nakonfigurovat sběrač pro sběr logů z běžných zdrojů.
How to
Jak dělat věci v LogMan.io¶
Toto je soubor rychlých příruček k běžným tématům pro každého administrátora.
Tyto příručky jsou platné pouze v automatizovaných instalacích "Maestro". Prosím, kontaktujte podporu TeskaLabs v jiných případech.
Jak nakonfigurovat SMTP server¶
Pro umožnění e-mailových oznámení je vyžadováno připojení k SMTP serveru.
Postupujte podle navigace Údržba >> Konfigurace v aplikaci LogMan.io. Vyberte sekci SMTP, poskytněte konfiguraci a klikněte na tlačítko Uložit.
Konfigurace SMTP je uložena, ale není aktivní. Musí být aplikována na všechny komponenty.
Klikněte na tlačítko Použít, které je přístupné ve složce /Site
Knihovny, nebo použijte příkazovou řádku.
Na hostitelském serveru, v adresáři /opt/site
, použijte příkaz:
./gov.sh up
Aplikujte změny na všechny komponenty, tj. na všechny uzly clusteru.
Jak aktualizovat certifikát Nginx¶
kompatibilitní poznámka: (dostupné v instalaci Maestro od verze v24.38)
Instalace TeskaLabs LogMan.io přichází s výchozími samopodepsanými SSL certifikáty. Můžete chtít tyto certifikáty změnit na vlastní SSL certifikáty, které je také potřeba čas od času obnovit.
Podívejte se na jak vygenerovat CSR pro vaši certifikační autoritu.
Certifikát Nginx je uložen ve Vaultu jako nginx_certificate
. Soukromý klíč je uložen ve Vaultu jako nginx_private_key
.
Nastavit SSL certifikát¶
Pro nahrazení výchozích samopodepsaných certifikátů poskytněte jak soukromý klíč, tak certifikát. Nejprve umístěte oba soubory na server. Poté je odešlete prostřednictvím API do Vaultu. Použijte tyto příkazy na libovolném uzlu clusteru s běžícím ASAB Remote Control:
curl -X PUT localhost:8891/vault/nginx_private_key --data-binary '@/absolute/path/to/private_key.pem'
curl -X PUT localhost:8891/vault/nginx_certificate --data-binary '@/absolute/path/to/certificate.pem'
Pro aplikaci nového certifikátu stiskněte tlačítko "Apply" (nebo spusťte ./gov.sh up
v /opt/site
) pro každý uzel se službou nginx
.
Obnovit SSL certifikát¶
Pokud máte certifikát uložený, spusťte tento příkaz na libovolném uzlu clusteru s běžícím ASAB Remote Control:
curl -X PUT localhost:8891/vault/nginx_certificate --data-binary '@/absolute/path/to/certificate.pem'
Pro aplikaci nového certifikátu stiskněte tlačítko "Apply" (nebo spusťte ./gov.sh up
v /opt/site
) pro každý uzel se službou nginx
.
Řešení problémů¶
Můj certifikát nefunguje. Chci zpět výchozí.¶
Může se stát, že po nahrání vlastního SSL certifikátu Nginx nenastartuje kvůli problémům s certifikáty a ztratíte přístup k GUI. Vždy můžete nechat Maestro regenerovat samopodepsaný certifikát.
Nejprve odstraňte svůj vlastní certifikát a klíč z Vaultu:
curl -X DELETE localhost:8891/vault/nginx_private_key
curl -X DELETE localhost:8891/vault/nginx_certificate
Stiskněte tlačítko "Apply" (nebo spusťte ./gov.sh up
v /opt/site
) pro každý uzel se službou nginx
.
Když Maestro nemůže tyto položky ve Vaultu najít, vygeneruje je a můžete Nginx znovu spustit.
Jak nastavit verzi¶
Jak nastavit verzi LogMan.io¶
Produkt TeskaLabs LogMan.io se skládá ze dvou aplikací, LogMan.io a ASAB Maestro.
Pro spuštění LogMan.io musíte v modelu specifikovat obě aplikace a jejich verze.
define:
type: rc/model
services:
...
applications:
- name: "ASAB Maestro"
version: v24.30.01
- name: "LogMan.io"
version: v24.30.01
Verze a soubory verzí
Verze se vztahuje na konkrétní soubor verze v Knihovně.
Verze v24.30.01 aplikace ASAB Maestro se vztahuje na soubor verze /Site/ASAB Maestro/Versions/v24.30.01.yaml
.
Verze v24.30.01 aplikace LogMan.io se vztahuje na soubor verze /Site/LogMan.io/Versions/v24.30.01.yaml
.
define:
type: rc/version
product: LogMan.io
version: v24.30.01
asab_maestro_library: v24.29
versions:
lmio-collector: v24.25
lmio-receiver: v24.19.01
lmio-parsec: v24.30
lmio-depositor: v24.30
lmio-alerts: v24.24
lmio-elman: v24.22-beta3
lmio-lookupbuilder: v24.30
lmio-ipaddrproc: v24.30
lmio-watcher: v24.22
system-collector: v24.25
lmio-baseliner: v24.30
lmio-correlator: v24.30.01
library lmio-common-library: v24.30.01
Chcete-li změnit verzi LogMan.io, jednoduše přepište verze aplikací v modelu, uložte model a aplikujte změny.
Vyberte existující verze a zajistěte kompatibilitu
Vyberte pouze soubory verzí, které skutečně existují v Knihovně.
Zajistěte, aby verze aplikací ASAB Maestro a LogMan.io byly kompatibilní.
Vlastní verze¶
Vyhněte se vlastním verzím
LogMan.io se skládá z několika služeb a testujeme jejich kompatibilitu před každým vydáním. Verze distribuované TeskaLabs jsou testovány a silně doporučovány.
Nemůžeme zaručit kompatibilitu služeb, pokud jsou použity kombinace JINÉ než ty v oficiálních souborech verzí.
Pro pokročilé uživatele, kteří ignorovali varování, zde jsou tipy, jak přizpůsobit verze:
Vytvoření nového souboru verze¶
V Knihovně vytvořte nový YAML soubor ve složce /Site/<application>/Versions/
. Dodržujte požadovanou strukturu souboru verze a specifikujte verze služeb. Pokud není pro službu specifikována žádná verze, bude použita verze latest
jako výchozí. Nastavte název nového souboru jako verzi aplikace v modelu.
Vlastní verze
Předpokládejme, že nový vlastní soubor verze aplikace LogMan.io se jmenuje custom.yaml
a je umístěn v /Site/LogMan.io/Versions/custom.yaml
v Knihovně.
Aby bylo možné použít nový soubor verze, propojte ho v modelu a stiskněte tlačítko "Použít".
define:
type: rc/model
services:
...
applications:
- name: "ASAB Maestro"
version: v24.30.01
- name: "LogMan.io"
version: custom
Přepsání verze v modelu¶
Chcete-li přepsat soubor verze z modelu, použijte klíč "version" v deklaraci služby.
V tomto příkladu bude verze instance asab-iris-1
nastavena na v24.36
. Verze v souboru verze /Site/ASAB Maestro/Versions/v24.30.01.yaml
bude ignorována.
define:
type: rc/model
services:
...
asab-iris:
instances:
- node1
version: v24.36
applications:
- name: "ASAB Maestro"
version: v24.30.01
- name: "LogMan.io"
version: v24.30.01
Nastavení verze pro každou instanci se nedoporučuje
Je možné nastavit odlišnou verzi pro každou instanci. Tento přístup však nedoporučujeme. Spuštění více instancí s odlišnými verzemi vede k vážným chybám ve většině služeb.
define:
type: rc/model
services:
...
asab-iris:
instances:
1:
node: node1
version: v24.36
2:
node: node1
version: v24.25
applications:
- name: "ASAB Maestro"
version: v24.30.01
- name: "LogMan.io"
version: v24.30.01
Jak se připojit k LDAP serveru¶
LDAP server nebo Active Directory lze použít k tomu, aby se uživatelé mohli bezproblémově přihlásit do TeskaLabs LogMan.io.
Specifikujte připojení k LDAP konfigurací TeskaLabs SeaCat Auth (autorizovaný server v rámci TeskaLabs LogMan.io) v modelu.
Najděte službu seacat-auth
v modelu a postupujte podle tohoto příkladu. Než provedete změny v modelu, bezpečně nahrajte tajný klíč (v tomto případě LDAP_USER_PASSWORD
) do Vaultu. Teprve poté bude tajný klíč dostupný, když budou změny aplikovány na konfiguraci SeaCat Auth.
model.yaml
define:
type: rc/model
services:
...
seacat-auth:
instances:
- node1 # Seznam uzlů s instancí seacat-auth
asab:
config:
"seacatauth:credentials:ldap:external":
uri: ldap://ad.company.cz # URI k vašemu LDAP serveru
username: "CN=user,OU=Users_System,DC=company,DC=cz" # Celé jméno uživatele v Active Directory
attrusername: sAMAccountName
password: "{{LDAP_USER_PASSWORD}}"
base: DC=company,DC=cz
filter: "(&(objectClass=user)(|(sAMAccountName=novakjan)(sAMAccountName=novotnypavel)))"
attributes: "mail mobile"
secrets:
LDAP_USER_PASSWORD: {}
Pro uložení tajného klíče do Vaultu použijte tento příkaz na hostitelském serveru LogMan.io. Ujistěte se, že nahradíte klíč a hodnotu hesla podle svých potřeb.
curl -X PUT localhost:8891/vault/LDAP_USER_PASSWORD --data 'supersecret'
Stiskněte tlačítko Použít, které je přístupné ve složce /Site
knihovny, nebo použijte příkazovou řádku.
Na hostitelském serveru, ve složce /opt/site
, použijte příkaz:
./gov.sh up
Odstraňování problémů ASAB Maestro¶
Aplikace změn z příkazového řádku¶
Ve složce /opt/site
na každém uzlu se nachází skript ./gov.sh
.
Použijte ho k aplikaci změn na jakémkoli uzlu.
Tento příkaz aplikuje změny v modelu na aktuální uzel:
$ cd /opt/site
$ ./gov.sh up
Aplikujte nejnovější změny na jiném uzlu. (Nahraďte <node_id>
skutečným ID uzlu.)
$ ./gov.sh up <node_id>
Ruční interakce s Dockerem nebo Podmanem¶
Skript ./gov.sh
funguje přesně stejně jako příkaz docker
, ale ve správném nastavení clusteru.
To zahrnuje i část docker compose
.
To je užitečné, když komponenty ASAB Maestro nefungují podle očekávání a jejich UI nebo API není k dispozici.
Příklad:
$ cd /opt/site
$ ./gov.sh compose up -d
[+] Spuštění 6/6
✔ Kontejner asab-config-1 Spuštěno 0.1s
✔ Kontejner asab-remote-control-1 Spuštěno 0.1s
✔ Kontejner zookeeper-1 Spuštěno 0.1s
✔ Kontejner zoonavigator-1 Spuštěno 0.1s
✔ Kontejner asab-library-1 Spuštěno 0.1s
✔ Kontejner asab-governator-1 Spuštěno 0.1s
$
Ruční aktualizace na nedávný ASAB Governator¶
Pokud potřebujete ručně aktualizovat asab-governator
na konkrétním uzlu, zde je správný postup:
$ cd /opt/site
$ ./gov.sh image pull docker.teskalabs.com/asab/asab-governator:stable
$ ./gov.sh compose up -d asab-governator-1
Nahraďte asab-governator-1
správným instance_id
na asab-governator
na daném uzlu.
Použijte ./gov.sh ps -a
k identifikaci instance_id
.
Nginx se nemůže připojit na port 80¶
Nginx log
nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)
Řešení
$ sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80
Elasticsearch se nespouští kvůli alokaci virtuální paměti¶
Řešení
$ sudo sysctl vm.max_map_count=262144
Hardware pro TeskaLabs LogMan.io¶
Toto jsou hardwarové specifikace navržené pro vertikální škálovatelnost. Jsou optimalizované pro ty, kteří plánují postavit počáteční TeskaLabs LogMan.io cluster s co nejnižšími náklady, avšak s možností postupně přidávat více hardwaru, jak cluster roste. 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¶
- Šasi: 2U
- Přední HDD zásobníky: 12 pozic pro disky, 3,5", pro data HDD, hot-swap
- Zadní HDD zásobníky: 2 pozice pro disky, 2,5", pro OS HDD, hot-swap
- CPU: 1x AMD EPYC 32 jader
- RAM: 256GB DDR4 3200, pomocí 64GB modulů
- Datová SSD: 2x 4TB SSD NVMe, PCIe 3.0+
- Řadič datových SSD: NVMe PCIe 3.0+ stoupačka, bez RAID; nebo použijte NVMe sloty na základní desce
- Datová HDD: 3x 20TB SATA 2/3+ nebo SAS 1/2/3+, 6+ Gb/s, 7200 ot./min.
- Řadič datových HDD: karta HBA nebo IT mód, SATA nebo SAS, JBOD, bez RAID, hot-swap
- OS HDD: 2x 256GB+ SSD SATA 2/3+, HBA, bez RAID, přímo připojeno k SATA na základní desce
- Síťová karta: 2x (duální) 1Gbps Ethernet NIC; nebo 1x dvouportový
- Napájecí zdroj: redundantní 920W
- IPMI nebo ekvivalentní
Poznámka
RAID je implementován v softwaru, respektive v operačním systému.
Vertikální škálovatelnost¶
- Přidejte další CPU (celkem 2 CPU), pro tuto volbu je vyžadována základní deska s 2 sloty pro CPU
- Přidejte RAM až do 512GB
- Přidejte až 9 dalších data HDD, maximální prostor 220 TB pomocí 12x 20 TB HDD v RAID5
- Vyměňte síťovou kartu za duální 10Gbps Ethernet NIC (nebo lepší)
Poznámka
K dispozici jsou také varianty 3U a 4U s 16 respektive 24 pozicemi pro disky.
Poslední aktualizace: srpen 2024
Úložiště dat¶
TeskaLabs LogMan.io pracuje s několika různými úrovněmi úložiště, aby poskytlo optimální izolaci dat, výkon a náklady.
Struktura úložiště dat¶
Schéma: Doporučená struktura úložiště dat.
Rychlé úložiště dat¶
Rychlé úložiště dat (také známé jako "hot" úroveň) obsahuje nejnovější logy a další události přijaté do TeskaLabs LogMan.io. Doporučujeme použít nejrychlejší možnou třídu úložiště pro nejlepší propustnost a výkon při vyhledávání. Komponenta v reálném čase (Apache Kafka) také používá rychlé úložiště dat pro perzistenci proudu.
- Doporučené časové období: jeden den až jeden týden
- Doporučená velikost: 2TB - 4TB
- Doporučená redundance: RAID 1, další redundanci poskytuje aplikační vrstva
- Doporučený hardware: NVMe SSD PCIe 4.0 a lepší
- Fyzická zařízení pro rychlé úložiště dat MUSÍ být spravována pomocí mdadm
- Montovací bod:
/data/ssd
- Souborový systém: EXT4, doporučuje se nastavit příznak
noatime
pro optimální výkon
Strategie zálohování¶
Příchozí události (logy) 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 "přehrát" události do TeskaLabs LogMan.io v případě potřeby. Data jsou také replikována na další uzly klastru okamžitě po jejich příjezdu do klastru. Z tohoto důvodu se nedoporučuje tradiční zálohování, ale je možné.
Obnovení je řešeno komponenty klastru replikací dat z dalších uzlů klastru.
Příklad
/data/ssd/kafka-1
/data/ssd/elasticsearch/es-master
/data/ssd/elasticsearch/es-hot1
/data/ssd/zookeeper-1
/data/ssd/influxdb-2
...
Pomalu úložiště dat¶
Pomalu úložiště obsahuje data, která není třeba rychle přistupovat, a obvykle obsahují starší logy a události, jako jsou teplé a studené indexy pro ElasticSearch.
- Doporučená redundance: softwarový RAID 6 nebo RAID 5; RAID 0 pro virtualizované/cloud instance s podkladovou redundancí úložiště
- Doporučený hardware: cenově efektivní pevné disky, SATA 2/3+, SAS 1/2/3+
- Typická velikost: desítky TB, např. 18TB
- Karta řadiče: SATA nebo HBA SAS (IT Mode)
- Fyzická zařízení pro pomalu úložiště MUSÍ být spravována softwarovým RAID (mdadm)
- Montovací bod:
/data/hdd
- Souborový systém: EXT4, doporučuje se nastavit příznak
noatime
pro optimální výkon
Výpočet kapacity klastru¶
Toto je vzorec pro výpočet celkové dostupné kapacity klastru na pomalu úložišti.
total = (disks-raid) * capacity * servers / replica
disks
je počet disků pomalu úložiště na serverraid
je náklad na RAID, 1 pro RAID5 a 2 pro RAID6capacity
je kapacita disku pomalu úložištěservers
je počet serverůreplica
je replikační faktor v ElasticSearch
Příklad
(6[disks]-2[raid6]) * 18TB[capacity] * 3[servers] / 2[replica] = 108TB
Strategie zálohování¶
Data uložená na pomalu úložišti jsou VŽDY replikována na další uzly klastru a také uložena v archivu. Z tohoto důvodu se nedoporučuje tradiční zálohování, ale je možné (uvážíme-li obrovskou velikost pomalu úložiště).
Obnovení je řešeno komponenty klastru replikací dat z dalších uzlů klastru.
Příklad
/data/hdd/elasticsearch/es-warm01
/data/hdd/elasticsearch/es-warm02
/data/hdd/elasticsearch/es-cold01
/data/hdd/mongo-2
/data/hdd/nginx-1
...
Strategie velkého pomalu úložiště¶
Pokud vaše pomalu úložiště bude větší než 50 TB, doporučujeme používat HBA SAS řadiče, SAS expandéry a JBOD jako optimální strategii pro škálování pomalu úložiště. SAS úložiště lze řetězit, aby bylo možné připojit velký počet disků. Externí JBOD skříně lze také připojit pomocí SAS pro uložení dalších disků.
RAID 6 vs RAID 5¶
RAID 6 i RAID 5 jsou typy RAID (redundantní pole nezávislých disků), které využívají stripování dat a paritu pro zajištění redundance dat a zvýšení výkonu.
RAID 5 používá stripování přes více disků, s jedním paritním blokem vypočítaným přes všechny disky. Pokud selže jeden disk, data lze stále obnovit pomocí paritních informací. Nicméně, data jsou ztracena, pokud druhý disk selže před výměnou prvního.
RAID 6 na druhou stranu používá stripování a dva nezávislé paritní bloky, které jsou uloženy na samostatných discích. Pokud selžou dva disky, data lze stále obnovit pomocí paritních informací. RAID 6 poskytuje vyšší úroveň ochrany dat ve srovnání s RAID 5. Nicméně, RAID 6 také zvyšuje náklady a snižuje kapacitu úložiště kvůli dvěma paritním blokům.
Co se týče pomalu úložiště, RAID 5 je obecně považován za méně bezpečný než RAID 6, protože logová data jsou obvykle zásadní a dva selhané disky by mohly způsobit ztrátu dat. RAID 6 je v tomto scénáři nejlepší, protože může přežít dva selhané disky a poskytuje více ochrany dat.
V RAID 5 je počet požadovaných disků (N-1) disků, kde N je počet disků v poli. To je proto, že jeden z disků je využitý pro paritní informace, které jsou použité pro obnovu dat v případě selhání jednoho disku. Například, pokud chcete vytvořit pole RAID 5 s kapacitou 54 TB, potřebujete alespoň čtyři (4) disky s kapacitou alespoň 18 TB každý.
V RAID 6 je počet požadovaných disků (N-2) disků. To je proto, že používá dva soubory paritních informací, které jsou uloženy na samostatných discích. V důsledku toho může RAID 6 přežít selhaní až dvou disků před ztrátou dat. Například, pokud chcete vytvořit pole RAID 6 s kapacitou 54 TB, potřebujete alespoň pět (5) disků s kapacitou alespoň 18 TB každý.
Je důležité poznamenat, že 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 další disky ve srovnání s RAID 5. Nicméně, RAID 6 poskytuje vyšší ochranu a může přežít dvě selhání disku.
Je třeba také zmínit, že data v pomalu úložišti jsou duplikována napříč clusterem (pokud je to relevantní) pro zajištění další ochrany dat.
Tip
Použijte Online RAID Calculator pro výpočet požadavků na úložiště.
Systémové úložiště¶
Systémové úložiště je vyhrazeno pro operační systém, instalace softwaru a konfigurace. Žádná provozní data nejsou uložena na systémovém úložišti. Instalace na virtualizačních platformách často používají dostupný místně redundantní diskový prostor.
- Doporučená velikost: 250 GB a více
- Doporučený hardware: dva (2) lokální SSD disky v softwarovém RAID 1 (zrcadlení), SATA 2/3+, SAS 1/2/3+
Pokud je to relevantní, doporučuje se následující rozdělení úložiště:
- EFI oddíl, montážní bod
/boot/efi
, velikost 1 GB - Swap oddíl, 64 GB
- Softwarový RAID1 (mdadm) přes zbytek místa
- Boot oddíl na RAID1, montážní bod
/boot
, velikost 512 MB, souborový systém ext4 - LVM oddíl na RAID1, zbytek dostupného místa s objemovou skupinou
systemvg
- LVM logický oddíl
rootlv
, montážní bod/
, velikost 50 GB, souborový systém ext4 - LVM logický oddíl
loglv
, montážní bod/var/log
, velikost 50 GB, souborový systém ext4 - LVM logický oddíl
dockerlv
, montážní bod/var/lib/docker
, velikost 100 GB, souborový systém ext4 (pokud je to relevantní)
Strategie zálohování pro systémové úložiště¶
Doporučuje se pravidelně zálohovat všechny souborové systémy na systémovém úložišti, aby mohly být použity pro obnovení instalace v případě potřeby. Strategie zálohování je kompatibilní s většinou běžných zálohovacích technologií na trhu.
- Recovery Point Objective (RPO): plná záloha jednou týdně nebo po větších údržbových pracích, inkrementální záloha jednou denně.
- Recovery Time Objective (RTO): 12 hodin.
Poznámka
RPO a RTO jsou doporučené, vzhledem k vysoce dostupné konfiguraci klastru LogMan.io. To znamená tři a více uzlů, aby úplné odstávky jednoho uzlu neovlivnily dostupnost služby.
Archivní úložiště dat¶
Archivní úložiště dat je doporučené, ale nepovinné. Slouží pro velmi dlouhé období uchovávání dat a účely redundance. Také představuje ekonomický způsob dlouhodobého uložení dat. Data nejsou dostupná online v klastru, musí být obnovena zpět při potřebě, což je spojeno s určitou dobou "time-to-data".
Data jsou komprimována při kopírování do archivu, typický kompresní poměr je v rozpětí od 1:10 do 1:2, v závislosti na povaze logů.
Data jsou replikována do úložiště po počáteční konsolidaci na rychlém úložišti dat, prakticky okamžitě po ingestování do klastru.
- Doporučené technologie: SAN / NAS / Cloud cold storage (AWS S3, MS Azure Storage)
- Montovací bod:
/data/archive
(pokud je relevantní)
Poznámka
Veřejné cloudy mohou být použity jako archivní úložiště dat. V takovém případě musí být povoleno šifrování dat pro ochranu dat 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 HBA SAS konektivitu a úložiště orientované OS distribuce jako Unraid nebo TrueNAS.
Co NEPROVÁDĚT při správě úložiště dat¶
- NEdoporučujeme použití NAS / SAN úložiště pro úložiště dat
- NEdoporučujeme použití hardwarových RAID řadičů atd. pro úložiště dat
Správa úložiště¶
Tato kapitola poskytuje praktický příklad konfigurace úložiště pro TeskaLabs LogMan.io. Nemusíte konfigurovat nebo spravovat úložiště LogMan.io, pokud k tomu nemáte konkrétní důvod, LogMan.io je dodáván v plně nakonfigurovaném stavu.
Předpokládáme následující konfiguraci hardwaru:
- SSD disky pro rychlé úložiště dat:
/dev/nvme0n1
,/dev/nvme1n1
- HDD disky pro pomalu úložiště dat:
/dev/sde
,/dev/sdf
,/dev/sdg
Tip
Použijte příkaz lsblk
pro sledování aktuálního stavu úložných zařízení.
Vytvoření softwarového RAID1 pro rychlé úložiště dat¶
mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1
mkfs.ext4 /dev/md2
mkdir -p /data/ssd
Přidejte montovací body do /etc/fstab
:
/dev/md2 /data/ssd ext4 defaults,noatime 0 2
Připojte souborové systémy úložiště dat:
mount /data/ssd
Tip
Použijte cat /proc/mdstat
pro kontrolu stavu softwarového RAID.
Vytvoření softwarového RAID5 pro pomalu úložiště dat¶
mdadm --create /dev/md1 --level=5 --raid-devices=3 /dev/sde /dev/sdf /dev/sdg
mkfs.ext4 /dev/md1
mkdir -p /data/hdd
Poznámka
Pro RAID6 použijte --level=6
.
Přidejte montovací body do /etc/fstab
:
/dev/md1 /data/hdd ext4 defaults,noatime 0 2
Připojte souborové systémy úložiště dat:
mount /data/hdd
Rozšíření velikosti úložiště dat¶
S neustále rostoucími objemy dat je vysoce pravděpodobné, že budete potřebovat rozšířit (neboli zvětšit) úložiště dat, a to buď na rychlém úložišti dat, nebo na pomalu úložišti dat. To se provádí přidáním nového datového svazku (např. fyzický disk nebo virtuální svazek) do stroje - nebo na některých virtualizovaných řešeních - zvětšením existujícího svazku.
Poznámka
Úložiště dat může být rozšířeno bez jakéhokoli výpadku.
Příklad rozšíření pomalu úložiště dat¶
Předpokládáme, že chcete přidat nový disk /dev/sdh
do pomalu úložiště /dev/md1
:
mdadm --add /dev/md1 /dev/sdh
Nový disk je přidán 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í.
Pro zvětšení RAID na náhradní zařízení:
mdadm --grow --raid-devices=4 /dev/md1
Číslo 4
musí být upraveno tak, aby odpovídalo aktuálnímu nastavení RAID.
Zvětšete souborový systém:
resize2fs /dev/md1
Síťování¶
Tato dokumentační sekce je navržena tak, aby vás provedla procesem nastavení a řízení síťování TeskaLabs LogMan.io. Aby byla zajištěna bezproblémová funkčnost, je důležité dodržovat předepsané síťové konfigurace popsané níže.
Schéma: Přehled sítě clusteru LogMan.io.
Fronting network¶
Fronting network je soukromý L2 nebo L3 segment, který slouží pro sběr logů. Z toho důvodu musí být přístupný ze všech zdrojů logů.
Každý uzel (server) má vyhrazenou IPv4 adresu v fronting network. IPv6 je také podporováno.
Fronting network musí být dostupný na všech místech clusteru LogMan.io.
Uživatelská síť¶
Uživatelská síť je soukromý L2 nebo L3 segment, který slouží pro přístup uživatelů k webovému uživatelskému rozhraní. Z tohoto důvodu musí být přístupná pro všechny uživatele.
Každý uzel (server) má vyhrazenou IPv4 adresu v uživatelské síti. IPv6 je také podporováno.
Uživatelská síť musí být dostupná na všech místech clusteru LogMan.io.
Interní síť¶
Interní síť je soukromý L2 nebo L3 segment, který se používá pro soukromou komunikaci mezi uzly clusteru. MUSÍ BÝT vyhrazena pro TeskaLabs LogMan.io bez externího přístupu k zachování bezpečnosti clusteru. Interní síť musí poskytovat šifrování, pokud je provozována ve sdíleném prostředí (např. jako VLAN). Toto je kritický požadavek pro bezpečnost clusteru.
Každý uzel (server) má vyhrazenou IPv4 adresu v interní síti. IPv6 je také podporováno.
Dále může být IPMI hardwarových uzlů vystaveno na této síti, na dodatečné IP adrese (jak IPv4, tak IPv6).
Interní síť musí být dostupná na všech místech clusteru LogMan.io.
Kontejnery běžící na uzlu používají "síťový režim" nastavený na "host" v interní síti. To znamená, že síťový stack kontejneru není izolován od uzlu (hostitele) a kontejner nezískává vlastní IP adresu.
Administrátoři MOHOU přistupovat k interní síti pomocí VPN.
Konektivita¶
Každý uzel (aka server) má následující požadavky na konektivitu:
Fronting network¶
- Minimální: 1Gbit NIC
- Doporučeno: 2x bonded 10Gbit NIC
Uživatelská síť¶
- Minimální: sdíleno s fronting network
- Doporučeno: 1Gbit NIC
Interní síť¶
- Minimální: Žádná NIC, interní pouze pro instalace s jedním uzlem, 1Gbit
- Doporučeno: 2x bonded 10Gbit NIC
- IPMI pokud je dostupné na úrovni serveru
Internetová konektivita (NAT, firewalled, za proxy serverem) pomocí Fronting network NEBO Interní sítě.
Komunikace¶
Fronting network¶
Zdroj | Cíl | Protokol | Port | Poznámka |
---|---|---|---|---|
Uzel LogMan.io | DNS servery | udp | 53 | Na základě konfigurace |
Uzel LogMan.io | DNS servery | tcp | 53 | Na základě konfigurace |
Uzel LogMan.io | NTP servery | udp | 123 | Na základě konfigurace |
Uzel LogMan.io | SMTP server | tcp | 25 | Nešifrovaný (plain text) provoz, nedoporučuje se |
Uzel LogMan.io | SMTP server | tcp | 465 | Šifrováno pomocí STARTTLS |
Uzel LogMan.io | SMTP server | tcp | 587 | Šifrováno pomocí SMTPS |
Uzel LogMan.io | LDAP server | tcp | 389 | Nešifrovaný (plain text) provoz, nedoporučuje se |
Uzel LogMan.io | LDAP server | tcp | 686 | Šifrováno pomocí LDAPS |
Uzel LogMan.io | LDAP server | tcp | 3268 | Nešifrovaný (plain text) provoz, nedoporučuje se |
Uzel LogMan.io | LDAP server | tcp | 3269 | Šifrováno pomocí LDAPS |
Sběrač logů | Uzel LogMan.io | tcp | 443 | Šifrováno pomocí Mutual TLS 1.2 |
Sběrač logů | Uzel LogMan.io | udp | 41194 | VPN (volitelně) |
Uzel LogMan.io | Slack servery | tcp | 443 | Notifikace (volitelně) |
Uzel LogMan.io | MS Teams servery | tcp | 443 | Notifikace (volitelně) |
Uzel LogMan.io | Sentry.io | tcp | 443 | Systémová telemetrie (volitelně) |
Uzel LogMan.io | Uptime Robot | tcp | 443 | Dostupnost systému (volitelně) |
Uzel LogMan.io | Aktualizace softwaru | tcp | 443 | docker.teskalabs.com , pcr.teskalabs.com , rcr.teskalabs.com , registry-1.docker.io , auth.docker.io , production.cloudflare.docker.com , asabwebui.z16.web.core.windows.net , webappsreg.z6.web.core.windows.net , webappsreg-secondary.z6.web.core.windows.net |
Uzel LogMan.io | Aktualizace obsahu | tcp | 443 | libsreg.z6.web.core.windows.net , libsreg-secondary.z6.web.core.windows.net , lmio.blob.core.windows.net |
Uzel LogMan.io | Aktualizace OS | tcp | 443, 80 | archive.ubuntu.com , security.ubuntu.com , cz.archive.ubuntu.com |
Tip
Každá odchozí HTTPS komunikace může používat proxy server. Nakonfigurujte svůj proxy server, aby povoloval provoz na určené doménové názvy.
Uživatelská síť¶
Zdroj | Cíl | Protokol | Port | Poznámka |
---|---|---|---|---|
Uživatelé | Uzel LogMan.io | tcp | 443 | |
Uživatelé | Uzel LogMan.io | tcp | 80 | Pouze pro přesměrování na HTTPS (volitelně) |
Tip
Přístup uživatelů je vyvážen pomocí Round-robin DNS.
Interní síť¶
Zdroj | Cíl | Protokol | Port | Poznámka |
---|---|---|---|---|
Uzel LogMan.io | Uzel LogMan.io | udp | 41194 | VPN |
Administrátoři | Uzel LogMan.io | tcp | 22 | SSH (volitelně) |
Administrátoři | IPMI | tcp | 443 | Na vyhrazeném ethernetovém portu / IP adrese (volitelně) |
Sběrač logů¶
Zdroj | Cíl | Protokol | Port | Poznámka |
---|---|---|---|---|
Sběrač logů | DNS servery | udp | 53 | |
Sběrač logů | DNS servery | tcp | 53 | |
Sběrač logů | NTP servery | udp | 123 | |
Sběrač logů | Uzel LogMan.io | tcp | 443 | Šifrováno pomocí Mutual TLS 1.2 |
Sběrač logů | Uzel LogMan.io | udp | 41194 | VPN (volitelně) |
Administrátoři | Sběrač logů | tcp | 22 | SSH přístup administrátorů (volitelně) |
Sběrač logů | Aktualizace softwaru | tcp | 443 | docker.teskalabs.com , pcr.teskalabs.com , rcr.teskalabs.com , registry-1.docker.io , auth.docker.io , production.cloudflare.docker.com (volitelně) |
Sběrač logů | Aktualizace OS | tcp | 443 | archive.ubuntu.com , security.ubuntu.com (volitelně) |
Syslog¶
Zdroj | Cíl | Protokol | Port | Poznámka |
---|---|---|---|---|
Zdroj logů | Sběrač logů | tcp | 514 | Syslog |
Zdroj logů | Sběrač logů | udp | 514 | Syslog |
Zdroj logů | Sběrač logů | tcp | 1514 | Syslog |
Zdroj logů | Sběrač logů | udp | 1514 | Syslog |
Zdroj logů | Sběrač logů | tcp | 6514 | Syslog s SSL / TLS (autodetekce, může být použit také jako plain TCP) |
Zdroj logů | Sběrač logů | udp | 6514 | Syslog s DTLS |
Zdroj logů | Sběrač logů | udp | 20514 | REPL |
Zdroj logů | Sběrač logů | tcp | 10000…14099 | Vlastní rozsah portů zdroje logů (volitelně) |
Zdroj logů | Sběrač logů | udp | 10000…14099 | Vlastní rozsah portů zdroje logů (volitelně) |
Microsoft¶
Zdroj | Cíl | Protokol | Port | Poznámka |
---|---|---|---|---|
MS Windows | Sběrač logů | tcp | 5986 | Sběr logů z Microsoft Windows pomocí WEF, HTTPS (volitelně) |
MS Windows | Sběrač logů | tcp | 5985 | Sběr logů z Microsoft Windows pomocí WEF, Kerberos (volitelně) |
MS Windows | Sběrač logů | tcp | 88 | Kerberos autorizace verze 5 pro WEF (volitelně) |
MS Windows | Sběrač logů | udp | 88 | Kerberos autorizace verze 5 pro WEF (volitelně) |
Sběrač logů | KDC, MS AD | tcp | 88 | Kerberos autorizace verze 5 pro WEF (volitelně) |
Sběrač logů | KDC, MS AD | udp | 88 | Kerberos autorizace verze 5 pro WEF (volitelně) |
Sběrač logů | Microsoft 365 | tcp | 443 | Sběr logů z Microsoft 365 (volitelně) |
ODBC¶
Pro sběr logů z databázových systémů se používá ODBC.
Zdroj | Cíl | Protokol | Port | Poznámka |
---|---|---|---|---|
Sběrač logů | Oracle Database | tcp | 1521 | |
Sběrač logů | Microsoft SQL | tcp | 1433 | |
Sběrač logů | Microsoft SQL | udp | 1434 | |
Sběrač logů | MySQL | tcp | 3306 | |
Sběrač logů | PostgreSQL | tcp | 5432 |
SNMP¶
Zdroj | Cíl | Protokol | Port | Poznámka |
---|---|---|---|---|
SNMP trap zdroje | Sběrač logů | udp | 161 | SNMP |
SSL serverový certifikát¶
Fronting network a uživatelská síť vystavují webová rozhraní přes HTTPS na portu TCP/443. Z tohoto důvodu potřebuje LogMan.io SSL serverový certifikát.
Může jít buď o:
- self-signed SSL serverový certifikát
- SSL serverový certifikát vydaný certifikační autoritou provozovanou interně uživatelem
- SSL serverový certifikát vydaný veřejnou (komerční) certifikační autoritou
Tip
Můžete použít nástroj XCA pro generování nebo ověřování vašich SSL certifikátů.
Self-signed certifikát¶
Tato možnost je vhodná pro velmi malé nasazení.
Uživatelé obdrží varování od svých prohlížečů při přístupu k webovému rozhraní LogMan.io.
Rovněž je potřeba použít insecure
vlajky v kolektorech.
Vytvoření self-signed SSL certifikátu pomocí příkazového řádku OpenSSL
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:secp384p1 \
-keyout key.pem -out cert.pem -sha256 -days 3650 -nodes \
-subj "/CN=logman.int"
Tento příkaz vytvoří key.pem
(soukromý klíč) a cert.pem
(certifikát) pro interní doménové jméno logman.int
.
Certifikát od certifikační autority¶
Parametry pro SSL serverový certifikát:
- Soukromý klíč: EC 384 bit, křivka secp384p1 (minimálně), alternativně RSA 2048 (minimálně)
- Subjekt Common Name
CN
: Plně kvalifikované doménové jméno uživatele Web UI LogMan.io - X509v3 Subject Alternative Name: Plně kvalifikované doménové jméno uživatele Web UI LogMan.io nastavené na "DNS"
- Typ: End Entity, kritické
- X509v3 Subject Key Identifier nastaveno
- X509v3 Authority Key Identifier nastaveno
- X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment, Key Agreement
- X509v3 Extended Key Usage: TLS Web Server Authentication
Příklad SSL serverového certifikátu pro http://logman.example.com/
``` Certifikát: Data: Verze: 3 (0x2) Sériové číslo: 6227131463912672678 (0x566b3712dc2c4da6) Algoritmus pro podpis: ecdsa-with-SHA256 Vydavatel: CN = logman.example.com
Cluster¶
TeskaLabs LogMan.io může být nasazeno na jednom serveru (tzv. "node") nebo v clusterovém nastavení. TeskaLabs LogMan.io také podporuje geo-clustering.
Geo-clustering¶
Geo-clustering je technika používaná k zajištění redundance proti selháním replikací dat a služeb v různých geografických lokalitách. Tento přístup se snaží minimalizovat dopad jakýchkoliv nepředvídaných selhání, katastrof nebo přerušení, která mohou nastat v jedné lokalitě, tím, že zajišťuje, že systém může pokračovat v provozu bez přerušení z jiné lokality.
Geo-clustering zahrnuje nasazení několika instancí LogMan.io v různých geografických regionech nebo datových centrech a jejich konfiguraci tak, aby pracovaly jako jeden logický celek. Tyto instance jsou propojeny pomocí dedikované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ím. V případě selhání na jednom místě zbylé instance systému přebírají a pokračují v provozu bez přerušení. To nejenže pomáhá zajistit vysokou dostupnost (HA) a uptime, ale také snižuje riziko ztráty dat a prostojů.
Další výhodou geo-clusteringu je, že může poskytovat lepší výkon a škálovatelnost umožněním vyvažování zátěže a sdílení zdrojů mezi několika lokalitami. To znamená, že zdroje mohou být dynamicky přidělovány a upravovány dle měnících se požadavků, čímž se zajišťuje, že systém je vždy optimalizován pro výkon a efektivitu.
Celkově je geo-clustering silnou technikou, která pomáhá zajišťovat vysokou dostupnost, odolnost a škálovatelnost jejich kritických aplikací a služeb. Replikací zdrojů v několika geografických lokalitách mohou organizace minimalizovat dopad selhání a přerušení, a zároveň zlepšit výkon a efektivitu.
Lokality¶
Lokalita "A"¶
Lokalita "A" je první lokalita, která se má postavit. V nastavení s jedním node je také jedinou lokalitou.
Node lma1
je první server, který se postaví v clusteru.
Nody v této lokalitě jsou pojmenovány "Node lmaX
". X
je sekvenční číslo serveru (např. 1, 2, 3, 4 a tak dále).
Pokud vám dojdou čísla, pokračujte malými písmeny (např. a, b, c a tak dále).
Podrobnosti o nodech naleznete v doporučené hardwarové specifikaci.
Lokalita B, C, D a tak dále¶
Lokalita B (a C, D atd.) jsou další lokality v clusteru.
Nody v těchto lokalitách jsou pojmenovány "Node lmLX
".
L
je malé písmeno, které představuje lokalitu v abecedním pořadí (např. a, b, c).
X
je sekvenční číslo serveru (např. 1, 2, 3, 4 a tak dále).
Pokud vám dojdou čísla, pokračujte malými písmeny (např. a, b, c a tak dále).
Podrobnosti o nodech naleznete v doporučené hardwarové specifikaci.
Koordinační lokalita "X"¶
Cluster MUSÍ mít lichý počet lokalit, aby se předešlo Split-brain problému.
Z tohoto důvodu doporučujeme postavit malou, koordinační lokalitu s jedním nodem (Node lmx1
).
Doporučujeme použít virtualizační platformu pro "Node x1
", ne fyzické hardware.
V této lokalitě nejsou uchovávána žádná data (logy, události).
Typy nodů¶
Core node¶
První tři nody v clusteru se nazývají core node. Core nody tvoří konsenzus v rámci clusteru, zajišťují konzistenci a koordinují činnosti v clusteru.
Peripheral nodes¶
Peripheral nody jsou ty nody, které se neúčastní konsenzu v clusteru.
Rozvržení clusteru¶
Schéma: Příklad rozvržení clusteru.
Single node "cluster"¶
Node: lma1
(Lokalita a, Server 1).
Dva velké a jeden malý node¶
Nody: lma1
, lmb1
a lmx1
.
Tři nody, tři lokality¶
Nody: lma1
, lmb1
a lmc1
.
Čtyři velké a jeden malý node¶
Nody: lma1
, lma2
, lmb1
, lmb2
a lmx1
.
Šest nodů, tři lokality¶
Nody: lma1
, lma2
, lmb1
, lmb2
, lmc1
a lmc2
.
Větší clustery¶
Větší clustery typicky zavádějí specializaci nodů.
Kolektor logů
TeskaLabs LogMan.io Kolektor¶
Toto je administrátorská příručka pro TeskaLabs LogMan.io Kolektor. Popisuje, jak nainstalovat kolektor.
Pro více podrobností o tom, jak sbírat logy, pokračujte do referenční příručky.
Instalace TeskaLabs LogMan.io Collector¶
Tento krátký návod vysvětluje, jak připojit nový log collector běžící jako virtuální stroj.
Tip
Pokud používáte hardware TeskaLabs LogMan.io Collector, připojte monitor přes HDMI a přejděte přímo na krok 5.
-
Stáhněte si obraz virtuálního stroje.
Zvolte odkaz ke stažení na základě vaší virtualizační technologie:
-
Importujte stažený obraz do vaší virtualizační platformy.
-
Konfigurujte síťová nastavení nového virtuálního stroje
Požadavky:
- Virtuální stroj musí mít přístup k instalaci TeskaLabs LogMan.io.
- Virtuální stroj musí být dosažitelný z zařízení, která budou posílat logy do TeskaLabs LogMan.io.
-
Spusťte virtuální stroj.
-
Určete identitu TeskaLabs LogMan.io Collector.
Identita se skládá z 16 písmen a číslic. Uložte si ji pro následující kroky.
-
Otevřete webovou aplikaci LogMan.io ve svém prohlížeči.
Postupujte podle tohoto odkazu nebo přejděte na "Collectors" a klikněte na tlačítko "Provisioning".
-
Zadejte identitu collectoru z kroku 4 do pole.
Poté klikněte na Provision pro připojení collectoru a zahájení sběru logů.
-
TeskaLabs LogMan.io Collector je úspěšně připojen a sbírá logy.
Tip
Zelený kruh vlevo označuje, že log collector je online. Modrá linie označuje, kolik logů collector přijal za posledních 24 hodin.
Administrace uvnitř VM¶
Administrativní akce ve virtuálním stroji TeskaLabs LogMan.io Collector jsou dostupné v menu. Stiskněte "M" pro přístup do menu. Použijte šipkové klávesy a Enter pro navigaci a výběr akcí.
Dostupné možnosti jsou:
- Vypnout
- Restartovat
- Konfigurace sítě
Tip
Doporučujeme použít funkci Vypnout
pro bezpečné vypnutí virtuálního stroje collectoru.
Další poznámky¶
Můžete připojit neomezený počet log collectorů, např. pro sběr z různých zdrojů nebo pro sběr různých typů logů.
Podporované virtualizační technologie¶
TeskaLabs LogMan.io Collector podporuje následující virtualizační technologie:
- VMWare
- Oracle VirtualBox
- Microsoft Hyper-V
- Qemu
Virtuální stroj¶
TeskaLabs LogMan.io collector je poskytován jako předinstalovaný obraz virtuálního stroje (OVA soubor).
Minimální specifikace¶
- 2 vCPU
- RAM: 2 GB
- Úložiště dat OS: 16 GB, thick provisioning
- Úložiště bufferu: 20 - 500 GB (závisí na příchozím EPS), thin provisioning
- 1x NIC, nejlépe 1Gbps
- OS: Linux
Poznámka
Pro prostředí s vyšším zatížením by měl být virtuální stroj odpovídajícím způsobem zvětšen.
Síť¶
Collector musí být schopen se připojit k instalaci TeskaLabs LogMan.io přes HTTPS (WebSocket) pomocí jeho URL.
Doporučujeme přidělit statickou IP adresu virtuálnímu stroji, protože bude použit v mnoha konfiguracích zdrojů logů.
Vlastní instalace¶
TeskaLabs LogMan.io collector může být také nainstalován do nového virtuálního stroje pomocí instalačního skriptu.
Podporované OS:
- Ubuntu Server 22.04.4 LTS
- RedHat/CentOS 7
Pokročilá správa¶
Tato sekce popisuje správu předinstalované virtuální mašiny sběrače TeskaLabs LogMan.io, prováděnou z příkazového řádku.
Spuštění a zastavení sběrače¶
Pro spuštění zastaveného sběrače zadejte:
# service lmio-collector start
Pro zastavení sběrače zadejte:
# service lmio-collector stop
Upgrade na novou stabilní verzi¶
# docker pull pcr.teskalabs.com/lmio/lmio-collector:stable
# service lmio-collector restart
# docker stop lmio-collector-cntrl
Note
Upgrade sběrače se spouští automaticky každou noc.
Povolení SSH přístupu¶
service ssh start
Přístup: ssh tladmin@<collector-ip>
Tip
Ujistěte se, že je heslo nastaveno pro uživatele tladmin
.
Spuštění sběrače na popředí¶
# service lmio-collector stop
# docker run \
--rm \
--name lmio-collector \
-v /conf:/conf \
-v /data:/data \
--net=host\
pcr.teskalabs.com/lmio/lmio-collector:stable
Stiskněte Ctrl-C pro ukončení sběrače.
Pro spuštění sběrače na pozadí proveďte:
# service lmio-collector start
Event Lanes
Úvod do event lanes¶
Event lanes definují tok dat v TeskaLabs LogMan.io, od sběru logů po jejich uložení do databáze Elasticsearch. Specifikují pravidla pro analýzu, povolený obsah a klasifikaci dat.
Tok dat v TeskaLabs LogMan.io¶
Následující příklad ilustruje standardní tok logů (nebo událostí) v TeskaLabs LogMan.io.
- Sběr surových událostí: Logy (události) jsou sbírány LogMan.io Collector a odesílány do centrálního LogMan.io clusteru.
- Archivace surových událostí: LogMan.io Receiver ukládá surové události do Archivu. Archiv je neměnná databáze pro dlouhodobé ukládání příchozích logů. Surové logy lze odtud vyzvednout a použít pro další analýzu.
- Analýza událostí: Surové logy jsou odebírány z Archivu a odesílány k analýze. Nejprve přicházejí do Kafka
received
tématu. LogMan.io Parsec odebírá surové logy zreceived
Kafka tématu a aplikuje vybraná pravidla pro analýzu.- Úspěšně analyzované události pokračují do Kafka
events
tématu. LogMan.io Depositor odebírá analyzované události z Kafka a ukládá je do Elasticsearchevents
indexu. - Když analýza selže, události se stávají neanalyzovanými a pokračují do Kafka
others
tématu. LogMan.io Depositor odebírá neanalyzované události z Kafka a ukládá je do Elasticsearchothers
indexu.
- Úspěšně analyzované události pokračují do Kafka
Event lanes¶
Když je připojen nový zdroj logů a je mu přiřazen nový datový tok, TeskaLabs LogMan.io automaticky vytvoří novou event lane pro něj. Event lane popisuje:
- jaká pravidla analýzy budou aplikována na datový tok
- jaké dashboardy, reporty a další obsah v Knihovně budou povoleny pro nájemce, který vlastní datový tok
- klasifikaci datového toku (dodavatel, produkt, kategorie atd.)
- zdroj dat používaný na obrazovce Discover
- jaká Kafka témata a Elasticsearch indexy budou použity pro tento datový tok
Každá event lane patří pouze jednomu nájemci. Dva nájemci nemohou sdílet stejnou event lane.
Vytváření nových event lane¶
Zde se můžete naučit, jak vytvořit novou event lane a vybrat pro ni správná pravidla parsování.
Event lane a její vlastnosti (pravidla parsování, obsah, kategorizace logů atd.) jsou založeny na datových tocích. TeskaLabs LogMan.io automaticky přiřazuje event lane na základě názvu datového toku a šablon event lane.
Existují dva případy pro připojení nového logového zdroje:
-
Když připojíte logový zdroj, pro který je obsah již k dispozici v Knihovně, event lane je vytvořena na základě příslušné šablony event lane a názvu datového toku, který poskytnete.
-
Když připojíte logový zdroj, pro který obsah není poskytnut, event lane je vytvořena, ale neposkytuje žádný obsah, kategorizaci ani pravidla parsování. Tyto musí být vytvořeny a specifikovány v deklaraci event lane.
Datové toky¶
Data v TeskaLabs LogMan.io jsou organizována do datových toků. Datový tok je sbírka logů (událostí) z logového zdroje, které sdílejí stejný typ a strukturu.
Logy v jednom datovém toku nemusí být nutně spojeny s jedním logovým zařízením. Může existovat mnoho logových zařízení, která produkují logy stejného typu.
Například můžete mít pět různých logových zařízení, která produkují data ve stejném (nebo podobném) formátu (např. Linux servery):
<123> Dec 12 12:20:00 host-1 proces: ...
<123> Dec 12 12:20:00 host-2 proces: ...
<123> Dec 12 12:20:00 host-3 proces: ...
<123> Dec 12 12:20:00 host-4 proces: ...
<123> Dec 12 12:20:00 host-5 proces: ...
V tomto případě můžete vybrat jeden datový tok pro tato logová zařízení a považovat všechna logová zařízení za jeden logový zdroj. Avšak když jedno z logových zařízení produkuje logy jiného typu:
<123>1 2024-12-12T12:20:00.000001 host-x proces tag: ...
měli byste to považovat za jiný logový zdroj a vytvořit pro něj samostatný datový tok, aby mohla být aplikována různá pravidla parsování.
Jak pojmenovat datový tok? (1/2)
Názvy toků jsou používány jako reference pro LogMan.io k výběru správné event lane. Proto je výběr správného názvu toku zásadní!
Název toku se obvykle skládá z názvu dodavatele, technologie a číselné identifikace. Zde je několik příkladů názvů toků:
cisco-asa-1
cisco-asa-2
linux-rsyslog-1
microsoft-365-1
synology-nas-1
Přečtěte si více o tom, jak vybrat správný název toku níže.
Obecný datový tok¶
Po instalaci LogMan.io Collector a připojení logových zdrojů jsou všechna data shromážděna do jednoho obecného toku. Jsou uložena v Archivu a Elasticsearch. Na události v obecném toku se neuplatňují žádná specifická pravidla parsování.
Pro aplikaci specifických pravidel parsování a kategorizaci událostí vytvořte nové datové toky.
Jak vytvořit nový datový tok¶
V tomto příkladu vás provedeme, jak vytvořit nový datový tok.
Předpokládejme, že chcete vytvořit datový tok pro logy přicházející z IP adresy 127.0.0.1
.
-
Otevřete webovou aplikaci TeskaLabs LogMan.io. Přejděte na Archiv.
-
Vyberte obecný tok. Uvidíte seznam surových logů z různých IP adres.
- Shromážděno: Čas, kdy byl log shromážděn LogMan.io Collector
- Přijato: Čas, kdy byl log přijat LogMan.io Receiver.
- Zdroj: Informace o původu logu, složené z IP adresy, portu a protokolu.
Hodnoty protokolu mohou být následující:
- S: Tok / TCP protokol
- D: Datagram / UDP protokol
- T: TLS / SSL protokol
-
Otevřete Logové zdroje >> Collectors. Najděte kolektor podle jeho štítku nebo identity.
-
Otevřete kartu Vlastní. Zde můžete vybrat datové toky na základě IP adres, portů a protokolů. Sledujte tento odkaz pro podrobnosti o konfiguraci LogMan.io Collector. Všimněte si, že název toku je důležitý.
Příklad konfigurace LogMan.io Collectorclassification: syslog-1514: &syslog-1514 # Názvy toků my-stream-1: - { ip: 127.0.0.1 } input:SmartDatagram:smart-udp-1514: address: '1514' output: smart smart: *syslog-1514 input:SmartStream:smart-tcp-1514: address: '1514' output: smart smart: *syslog-1514 output:CommLink:smart: {}
Klikněte na Použít.
-
Od nynějška jsou logy přicházející z IP adresy
127.0.0.1
odesílány do datového tokumy-stream-1
. Otevřete Archiv. Najděte tokmy-stream-1
. Uvidíte přicházející logy z toku.Info
Jakmile je log uložen v Archivu, nemůže být přesunut do jiného datového toku (Archiv je neměnná databáze).
Jak vytvořit event lane¶
Event lane jsou vytvářeny ze šablon event lane. Šablona event lane popisuje vlastnosti datového toku, které budou aplikovány na event lane. Má svou deklaraci v Knihovně:
---
define:
type: lmio/event-lane-template
name: Linux Rsyslog # Čitelný název datového toku
stream: linux-rsyslog-* # Reference na název toku
# Kategorizace logového zdroje
logsource:
product:
- linux
service:
- syslog
# Pravidla parsování, která se mají aplikovat na event lane
parsec:
name: /Parsers/Linux/Common/
# Obsah, který se má povolit při vytváření event lane
content:
dashboards: /Dashboards/Linux/Common/
Po nalezení nového datového toku je spárován s jednou z šablon event lane. Nová event lane bude vytvořena a zdědí vlastnosti této šablony. Nová deklarace pro event lane bude vytvořena v Knihovně:
---
define:
type: lmio/event-lane-template
name: Linux Rsyslog (1)
template: /Templates/EventLanes/Linux/linux-rsyslog.yaml
logsource:
product:
- linux
service:
- syslog
parsec:
name: /Parsers/Linux/Common/
instances: 2
content:
dashboards: /Dashboards/Linux/Common/
kafka:
received:
topic: received.company.linux-rsyslog-1
events:
topic: events.company.linux-rsyslog-1
others:
topic: others.company.linux-rsyslog-1
elasticsearch:
events:
index: lmio-company-events-linux-rsyslog-1
others:
index: lmio-company-others
Deklarace event lane kopíruje vlastnosti datového toku z jeho šablony a přidává informace o:
- jaké Kafka témata a Elasticsearch indexy budou použity
- kolik instancí mikroservisu LogMan.io Parsec poběží uvnitř clusteru LogMan.io
Jak pojmenovat datový tok? (2/2)
Když vyberete název toku, který odpovídá jedné z šablon event lane, odpovídající event lane zdědí její vlastnosti (pravidla parsování, obsah Knihovny, kategorizaci atd.).
Předpokládejme, že chcete připojit logový zdroj typu Linux Rsyslog. Můžete najít vhodnou technologii v šablonách event lane:
---
define:
type: lmio/event-lane-template
name: Linux Rsyslog # Čitelný název datového toku
stream: linux-rsyslog-* # Reference na název toku
Hvězdička *
na konci možnosti stream
odpovídá libovolnému číslu. Proto můžete pojmenovat svůj datový tok linux-rsyslog-1
, linux-rsyslog-2
atd.
Odpovídající event lane pak zdědí název toku:
---
define:
type: lmio/event-lane
name: Linux Rsyslog (1)
template: /Templates/EventLanes/Linux/linux-rsyslog.yaml
Pravidla parsování a další vlastnosti event lane mohou být změněny ručně, takže není žádné riziko při výběru nesprávného názvu toku při prvním pokusu.
Obecné šablony
Když není nalezena žádná šablona event lane pro daný název datového toku, je event lane pro odpovídající datový tok vytvořena ze šablony Obecné event lane. Obecná šablona aplikuje pouze nejzákladnější pravidla parsování na datový tok a neposkytuje žádné konkrétní informace o logovém zdroji.
Když připojíte logový zdroj neznámého typu nebo typu, který neexistuje v šablonách event lane, event lane bude odvozena z obecné šablony. Vlastnosti této event lane můžete později upravit.
Správa událostních pruhů¶
Uživatelský účet může upravovat a mazat událostní pruhy.
Úprava událostních pruhů¶
Událostní pruhy lze upravit v deklaraci Knihovny /EventLanes/tenant/eventlane.yaml
. Například lze vybrat různé pravidla pro analýzu pro tento datový tok, nebo mu lze poskytnout novou sadu dashboardů.
Přečtěte si více o deklaracích událostních pruhů zde.
Deaktivace a mazání událostních pruhů¶
Událostní pruhy lze deaktivovat a mazat.
Deaktivace událostního pruhu¶
Chcete-li deaktivovat událostní pruh, postupujte podle těchto kroků:
-
Zastavte všechny instance LogMan.io Parsec nastavením počtu instancí v deklaraci událostního pruhu na nulu:
parsec: instances: 0
-
Ujistěte se, že všechny instance LogMan.io Parsec jsou zastaveny a odstraněny v sekci Údržba > Služby.
-
Deaktivujte událostní pruh změnou možnosti
define/type
v deklaraci událostního pruhu:define: type: lmio/event-lane-inactive
-
Zastavte instanci LogMan.io Elman, aby se zabránilo vytvoření nového událostního pruhu. Zastavte také všechny instance LogMan.io Receiver.
docker stop lmio-receiver-1 docker stop lmio-elman-1
-
Vstupte do Docker kontejneru Kafka. Ručně odstraňte témata
received
aevents
událostního pruhu, který chcete odstranit.docker exec -it kafka-1 bash /bin/kafka-topics --bootstrap-server localhost:9092 --delete --topic received.tenant.stream /bin/kafka-topics --bootstrap-server localhost:9092 --delete --topic events.tenant.stream
-
Restartujte LogMan.io Elman.
docker restart lmio-elman-1
-
Proveďte rollover v Elasticsearch pro index událostního pruhu.
POST /lmio-tenant-events-stream/_rollover
-
Odstraňte datový zdroj Discover pro událostní pruh v Konfigurace >> Discover >> lmio-tenant-events-stream.
-
Pokud chcete pouze deaktivovat událostní pruh, ale ponechat jeho data, restartujte všechny instance LogMan.io Receiver. Pokud chcete událostní pruh a jeho data smazat, pokračujte dále.
(node-1) $ docker restart lmio-receiver-1 (node-2) $ docker restart lmio-receiver-2 (node-3) $ docker restart lmio-receiver-3
Mazání neaktivního událostního pruhu¶
-
Zastavte všechny instance LogMan.io Receiver. Přejděte do Zoonavigator, otevřete
lmio/receiver/db
a odstraňte záznam datového toku. -
Ujistěte se, že témata Kafka
received
aevents
jsou odstraněna. Odstraňte deklaraci událostního pruhu v Knihovně/EventLanes/tenant/stream.yaml
. -
Pokud chcete smazat data událostního pruhu, čtěte dále. Pokud ne, restartujte všechny instance LogMan.io Receiver.
Warning
Po smazání událostního pruhu nejsou žádná data smazána z Archivu nebo databáze Elasticsearch, ale nelze k nim přistupovat z webové aplikace TeskaLabs LogMan.io.
Mazání dat událostního pruhu¶
Danger
Mazání dat z TeskaLabs LogMan.io je možné, ale důrazně se nedoporučuje.
-
Otevřete Kibana >> Správa stacku >> Správa indexů. Odstraňte všechny indexy začínající na
lmio-tenant-events-stream
. -
Otevřete Kibana >> Správa stacku >> Správa indexů >> Šablony indexů. Odstraňte šablonu indexu začínající na
lmio-tenant-events-stream
. -
Otevřete Kibana >> Správa stacku >> Politiky životního cyklu indexu. Odstraňte ILM začínající na
lmio-tenant-events-stream
. -
Ujistěte se, že všechny instance LogMan.io Receiver jsou zastaveny. Odstraňte všechna data streamu z horké, studené a teplé fáze na všech uzlech clusteru.
rm -rfv /data/ssd/lmio-receiver-x/hot/<stream> rm -rfv /data/hdd/lmio-receiver-x/warm/<stream> rm -rfv /data/hdd/lmio-receiver-x/cold/<stream>
-
Restartujte všechny instance LogMan.io Receiver.
Životní cyklus dat
Životní cyklus dat v TeskaLabs LogMan.io zahrnuje několik fází navržených tak, aby efektivně spravovaly logová data během jejich cesty. Od počátečního ingestování, archivace a analýzy, indexování až po konečné smazání, je každá fáze pečlivě nakonfigurována pro optimalizaci výkonu, uchovávání dat a potřeby souladu. I když naše výchozí konfigurace poskytují rozumná nastavení pro většinu případů použití, což umožňuje plynulý provoz od prvního dne, pochopení fází životního cyklu může pomoci zpřesnit a přizpůsobit systém, jak se vaše požadavky vyvíjejí. Tato kapitola nabízí přehled těchto fází a zapojených databází, čímž klade základy pro pokročilou správu dat.
Data (např. logy, události, metriky) jsou uložena v několika fázích dostupnosti, v podstatě v chronologickém pořadí.
Existuje několik zastávek v toku dat, kde lze přizpůsobit životní cyklus nebo uchovávání dat:
- Archiv - Prvním komponentem, který shromažďuje data, je LMIO Receiver, který poskytuje Archiv. Data v Archivu jsou spravována prostřednictvím politiky životního cyklu nastavené pro každý stream.
Správa životního cyklu dat v Archivu
- Kafka - LMIO Receiver odesílá data do tématu
received.<tenant>.<stream>
. Jakmile jsou data analyzována, dosahují tématuevents.<tenant>.<stream>
neboothers.<tenant>
, pokud analýza selže.
Nastavení politiky uchovávání v Kafce
- Elasticsearch - Analyzovaná data jsou uložena a indexována v Elasticsearch s jeho správou životního cyklu dat.
Správa životního cyklu indexu v Elasticsearch
Pro připomenutí toku dat prostřednictvím TeskaLabs LogMan.io si prosím prohlédněte Architektonický diagram.
Nastavení retenční politiky Kafka¶
TeskaLabs LogMan.io zajišťuje, že nastavení Kafka témat jsou udržována v určitých mezích.
- Témata event lane jsou automaticky spravována LogMan.io Event Lane Manager. Jejich retenční doba může být nastavena globálně.
- Retenci jakéhokoli Kafka tématu lze změnit ručně v Kafce.
Témata event lane¶
LogMan.io Event Lane Manager automaticky nastavuje retenční politiku pro témata event lane received.<tenant>.<stream>
, events.<tenant>.<stream>
a others.<tenant>
. Je možné nastavit retenci globálně (pro všechna témata) v konfiguraci:
services:
lmio-elman:
asab:
config:
kafka:
retention.ms_optimal: ... # výchozí: 3 dny
retention.ms_max: ... # výchozí: 7 dní
retention.ms_min: ... # výchozí: 1 den (24 hodin)
[kafka]
retention.ms_optimal=... ; výchozí: 3 dny
retention.ms_max=... ; výchozí: 7 dní
retention.ms_min=... ; výchozí: 1 den (24 hodin)
Když je vytvořeno nové téma event lane, jeho retence je nastavena na retention.ms_optimal
. Poté může být retence každého tématu event lane změněna ručně, ale musí být vyšší než retention.ms_min
a nižší než retention.ms_max
, jinak se automaticky vrátí na retention.ms_optimal
.
Kontrola sanity¶
Warning
Následující řádky jsou relevantní pro neautomatizované nasazení TeskaLabs LogMan.io bez LMIO Event Lane Manager.
Pro instalace, kde není spuštěn LMIO Event Lane Manager, existuje podpůrný mechanismus, který nastavuje retenci pro témata event lane.
LMIO Receiver kontroluje všechna Kafka témata received.<tenant>.<stream>
a zajišťuje, že jejich retence je mezi nakonfigurovanými minimem a maximem.
Výchozí minimální retence je 12 hodin a výchozí maximum je 7 dní.
Pokud je retence menší, je nastavena na nakonfigurovanou minimální hodnotu. Pokud je retence větší, je nastavena na nakonfigurovanou maximální hodnotu.
Můžete změnit konfiguraci v konfiguračním souboru LMIO Receiver. Použijte čas v milisekundách:
[kafka:sanity]
min.retention.ms=... # výchozí: 12 hodin
max.retention.ms=... # výchozí: 7 dní
LMIO Depositor implementuje stejnou logiku, používající stejnou konfiguraci, ovlivňující témata events.<tenant>.<stream>
a others.<tenant>
a poskytující stejné výchozí hodnoty.
Mějte na paměti, že retenci lze řídit na základě jak stáří logů v frontě, tak velikosti tématu (v bajtech). Komponenty LogMan.io nekontrolují konfiguraci retence na základě velikosti indexu.
Nastavení retenční doby v Kafce¶
Retenci každého Kafka tématu lze změnit v Kafce.
Každý Docker kontejner Kafka je vybaven nástroji pro příkazový řádek Kafka, které lze použít.
-
Vstupte do shellu Docker kontejneru Kafka:
docker exec -it kafka-1 bash
-
Zkontrolujte, že téma existuje a je dostupné:
/usr/bin/kafka-topics --bootstrap-server localhost:9092 --list | grep "<topic>"
(Nahraďte
<topic>
názvem vašeho tématu.) -
Nastavte retenci pro jednotlivé téma pomocí příkazu:
/usr/bin/kafka-configs --bootstrap-server localhost:9092 \ --entity-type topics --entity-name "<topic>" \ --alter --add-config retention.ms=86400000
(Nahraďte
<topic>
názvem vašeho tématu aretention.ms
vaší hodnotou.)
Proč milisekundy?
Možná se ptáte, proč používáme milisekundy všude, kde konfigurujeme retenci Kafky. Proč prostě nepoužít hodiny nebo dny?
Ve skutečnosti existují konfigurační možnosti pro nastavení retence pomocí hodin nebo dní.
Ale volba retention.ms
má vždy nejvyšší prioritu před všemi ostatními možnostmi.
Abychom předešli možným konfliktům s jinými službami, rozhodli jsme se používat milisekundy, což je také doporučeno společností Confluent.
Správa životního cyklu indexu Elasticsearch¶
Správa životního cyklu indexu (ILM) v Elasticsearch slouží k automatickému uzavření nebo odstranění starých indexů (tj. s daty staršími než tři měsíce), aby byla zachována výkonnost vyhledávání a úložiště dat bylo schopno uchovávat aktuální data.
TeskaLabs LogMan.io poskytuje výchozí politiku ILM pro každý index.
Výchozí politika ILM je zdokumentována zde. Můžete ji změnit pro každý index Elasticsearch v příslušném prohlášení Event Lane. Přečtěte si více o tom zde.
Architektura Hot-Warm-Cold (HWC)¶
HWC je rozšíření standardní rotace indexů poskytované ILM Elasticsearch a je dobrým nástrojem pro správu dat časových řad. Architektura HWC nám umožňuje přiřadit specifické uzly k jedné z fází. Při správném použití, spolu s architekturou clusteru, to umožní maximální výkon, využívající dostupný hardware na maximum.
Horká fáze¶
Obvykle existuje nějaké časové období (týden, měsíc atd.), kdy chceme intenzivně dotazovat indexy, zaměřujeme se na rychlost, spíše než na úsporu paměti (a dalších zdrojů). To je místo, kde přichází "Horká" fáze, která nám umožňuje mít index s více replikami, rozloženými a dostupnými na více uzlech pro optimální uživatelský zážitek.
Horké uzly¶
Horké uzly by měly využívat rychlé části dostupného hardwaru, využívající většinu CPU a rychlejší IO.
Teplá fáze¶
Jakmile toto období skončí a indexy již nejsou dotazovány tak často, budeme mít prospěch z jejich přesunu do "Teplé" fáze, která nám umožňuje snížit počet uzlů (nebo se přesunout na uzly s méně dostupnými zdroji) a replik indexů, čímž se sníží zátěž na hardware, přičemž stále zachováváme možnost vyhledávat data přiměřeně rychle.
Teplé uzly¶
Teplé uzly, jak název napovídá, stojí na křižovatce, mezi tím, aby byly výhradně pro účely ukládání, a přitom si zachovaly nějakou CPU sílu pro občasné dotazy.
Studená fáze¶
Někdy existují důvody pro uchovávání dat po delší dobu (diktované zákonem nebo nějakým interním pravidlem). Data se neočekávají, že budou dotazována, ale zároveň je nelze zatím smazat.
Studené uzly¶
Tady přicházejí do hry studené uzly, může jich být málo, s pouze malými CPU zdroji, nemají potřebu používat SSD disky, což je naprosto v pořádku s pomalejším (a volitelně větším) úložištěm.
Zálohování a obnovení Elasticsearch¶
Snapshoty¶
Nachází se pod Stack Management -> Snapshot and Restore
. Snapshoty jsou uloženy na místě repozitáře. Struktura je následující. Samotný snapshot 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 vytvoříte snapshot každý den, starší indexy jsou v snapshotu pouze znovu odkazovány, zatímco pouze nové indexy jsou skutečně zkopírovány do záložního adresáře.
Repozitáře¶
Nejprve je třeba nastavit repozitář snapshotů. Určete umístění, kde se repozitář snapshotů nachází, například /backup/elasticsearch
. Tato cesta musí být přístupná ze všech uzlů v clusteru. Pokud je Elasticsearch spuštěn v dockeru, zahrnuje to namontování prostoru uvnitř dockerových kontejnerů a jejich restartování.
Politiky¶
Aby bylo možné začít pořizovat snapshoty, je třeba vytvořit politiku. Politika určuje předponu názvu snapshotů, které vytváří, specifikuje repozitář, který bude používat pro vytváření snapshotů, a vyžaduje nastavení plánu, indexy (definované pomocí vzorů nebo konkrétních názvů indexů - například lmio-<tenant>-events-*
).
Dále může politika specifikovat, zda ignorovat nedostupné indexy, povolit částečné indexy a zahrnout globální stav. Použití těchto závisí na konkrétním případě, ve kterém bude politika snapshotu použita, a není doporučeno jako výchozí. K dispozici je také nastavení pro automatické mazání snapshotů a definování expirace. Tyto také závisí na konkrétní politice, samotné snapshoty jsou však velmi malé (co se paměti týče), pokud neobsahují globální stav, což je očekávané, protože jsou to pouze ukazatele na jiné místo, kde jsou uložena skutečná data indexu.
Obnovení snapshotu¶
Pro obnovení snapshotu jednoduše vyberte snapshot obsahující index nebo indexy, které chcete obnovit, a vyberte "Obnovit". Poté musíte specifikovat, zda chcete obnovit všechny indexy obsažené v snapshotu, nebo pouze část. Můžete přejmenovat obnovené indexy, můžete také obnovit částečné snapshot indexy a upravit nastavení indexu při jejich obnovování. Nebo je resetovat na výchozí hodnoty. Indexy jsou poté obnoveny podle specifikací zpět do clusteru.
Upozornění¶
Při mazání snapshotů mějte na paměti, že musíte mít zálohované indexy pokryté snapshotem, abyste je mohli obnovit. To znamená, že pokud například vyčistíte některé indexy z clusteru a poté odstraníte snapshot, který obsahoval odkaz na tyto indexy, nebudete je moci obnovit.
Sledování systému
Systémové monitorování¶
Následující nástroje a techniky vám mohou pomoci pochopit, jak si váš systém TeskaLabs LogMan.io vede a prozkoumat jakékoliv vzniklé problémy.
Přednastavené dashboardy¶
LogMan.io zahrnuje přednastavené diagnostické dashboardy, které vám poskytnou přehled o výkonu vašeho systému. To je nejlepší místo, kde začít s monitorováním.
Příklad přednastaveného dashboardu
Preventivní kontroly¶
Preventivní kontroly jsou preventivní prohlídky vaší aplikace LogMan.io a výkonu systému. Navštivte náš manuál pro preventivní kontroly a naučte se, jak pravidelně provádět preventivní kontroly.
Metriky¶
Metriky jsou měření týkající se výkonu systému. Vyšetřování metrik může být užitečné, pokud již víte, kterou oblast svého systému potřebujete prozkoumat, což můžete zjistit analýzou přednastavených dashboardů nebo provedením preventivní kontroly.
Dashboardy Grafana pro diagnostiku systému¶
Prostřednictvím TeskaLabs LogMan.io můžete přistupovat k dashboardům v Grafana, které monitorují vaše datové pipelines. Tyto dashboardy používejte pro diagnostické účely.
Prvních několik měsíců nasazení TeskaLabs LogMan.io je stabilizační období, během kterého můžete vidět extrémní hodnoty produkované těmito metrikami. Tyto dashboardy jsou obzvlášť užitečné během stabilizace a mohou pomoci s optimalizací systému. Jakmile je váš systém stabilní, extrémní hodnoty obecně indikují problém.
Pro přístup k dashboardům:
- V LogMan.io, přejděte na Nástroje.
-
Klikněte na Grafana. Nyní jste bezpečně přihlášeni do Grafana pomocí vašich uživatelských přihlašovacích údajů pro LogMan.io.
-
Vyberte dashboard, který si chcete prohlédnout.
Tipy
- Přejeďte myší nad jakýkoli graf, abyste viděli detaily v konkrétních časových bodech.
- Můžete změnit časový rámec jakéhokoli dashboardu pomocí nástrojů pro změnu časového rámce v pravém horním rohu obrazovky.
Dashboard LogMan.io¶
Dashboard LogMan.io monitoruje všechny datové pipelines ve vaší instalaci TeskaLabs LogMan.io. Tento dashboard vám může pomoci zjistit, pokud například vidíte méně logů, než očekáváte v LogMan.io. Viz Metiky pipeline pro hlubší vysvětlení.
Zahrnuté metriky:
-
Event In/Out: Objem událostí procházejících každou datovou pipeline měřený v operacích vstup/výstup za sekundu (io/s). Pokud pipeline běží hladce, množství In a Out je stejné a linie Drop je nula. To znamená, že stejný počet událostí vstupuje a opouští pipeline a žádná není ztracena. Pokud graf ukazuje, že množství In je větší než množství Out a linie Drop je větší než nula, znamená to, že některé události byly ztraceny a může být problém.
-
Duty cycle: Zobrazuje procento zpracovávaných dat ve srovnání s daty čekajícími na zpracování. Pokud pipeline pracuje podle očekávání, duty cycle je 100%. Pokud je duty cycle nižší než 100%, znamená to, že někde v pipeline je zpoždění nebo překážka, která způsobuje frontu událostí.
-
Time drift: Ukazuje zpoždění nebo lag v zpracování událostí, což znamená, jak dlouho po doručení události je skutečně zpracována. Významné nebo zvýšené zpoždění ovlivňuje vaši kybernetickou bezpečnost, protože brání vaší schopnosti okamžitě reagovat na hrozby. Time drift a duty cycle jsou související metriky. Větší časový drift se objevuje, když je duty cycle pod 100%.
Dashboard přehledu na systémové úrovni¶
Dashboard přehledu na systémové úrovni monitoruje servery zapojené do vaší instalace TeskaLabs LogMan.io. Každý uzel instalace má svou vlastní sekci v dashboardu. Když narazíte na problém ve vašem systému, tento dashboard vám pomůže provést počáteční hodnocení vašeho serveru tím, že vám ukáže, zda je problém spojen s vstup/výstupem, využitím CPU, sítí nebo místem na disku. Pro konkrétnější analýzu se však zaměřte na specifické metriky v Grafana nebo InfluxDB.
Zahrnuté metriky:
- IOWait: Procento času, kdy CPU zůstává nečinné, zatímco čeká na žádosti o diskový I/O (vstup/výstup). Jinými slovy, IOWait vám říká, kolik času zpracování je plýtváno čekáním na data. Vysoký IOWait, zejména pokud je kolem nebo přesahuje 20% (v závislosti na vašem systému), signalizuje, že rychlost čtení/zápisu disku se stává úzkým hrdlem systému. Rostoucí IOWait naznačuje, že výkon disku omezuje schopnost systému přijímat a ukládat více logů, což ovlivňuje celkovou propustnost a efektivitu systému.
- Uptime: Doba, po kterou server běží bez toho, aby byl vypnut nebo restartován.
- Load: Představuje průměrný počet procesů čekajících v frontě na CPU čas za posledních 5 minut. Je to přímý indikátor, jak zaneprázdněný váš systém je. V systémech s více jádry CPU by tato metrika měla být považována ve vztahu k celkovému počtu dostupných jader. Například zatížení 64 na systému se 64 jádry může být přijatelné, ale nad 100 indikuje vážný stres a neodpovídavost. Ideální zatížení se liší v závislosti na konkrétní konfiguraci a případu použití, ale obecně by nemělo přesahovat 80% celkového počtu jader CPU. Konzistentně vysoké hodnoty zatížení naznačují, že systém se potýká s efektivním zpracováním příchozích logů.
- RAM usage: Procento celkové paměti, která je aktuálně využívána systémem. Udržování využití RAM mezi 60-80% je obecně optimální. Využití nad 80% často vede ke zvýšenému využití swapu, což může zpomalit systém a vést k nestabilitě. Monitorování využití RAM je klíčové pro zajištění, že systém má dostatek paměti k efektivnímu zvládání pracovního zatížení bez použití swapu, který je výrazně pomalejší.
- CPU usage: Přehled procenta kapacity CPU, která je aktuálně používána. Průměruje využití mezi všemi jádry CPU, což znamená, že jednotlivá jádra mohou být pod nebo nadměrně využita. Vysoké využití CPU, zejména nad 95%, naznačuje, že systém čelí výzvám spojeným s kapacitou CPU, kde hlavním omezením je kapacita zpracování CPU. Tato metrika dashboardu pomáhá rozlišit mezi problémy s I/O (kde je úzkým hrdlem přenos dat) a problémy s CPU. Je to klíčový nástroj pro identifikaci úzkých hrdel zpracování, i když je důležité tuto metriku interpretovat společně s ostatními systémovými indikátory pro přesnější diagnostiku.
- Swap usage: Kolik swapového prostoru je využíváno. Swapová partition je vyhrazený prostor na disku použitý jako dočasná náhrada za RAM ("přetečení dat"). Když je RAM plná, systém dočasně ukládá data do swapového prostoru. Vysoké využití swapu, přes přibližně 5-10%, naznačuje, že systému dochází paměť, což může vést ke sníženému výkonu a nestabilitě. Trvalé vysoké využití swapu je znakem toho, že systém potřebuje více RAM, protože silné spoléhání na swapový prostor se může stát hlavním úzkým hrdlem výkonu.
- Disk usage: Měří, kolik kapacity úložiště je aktuálně využíváno. Ve vašem systému pro správu logů je klíčové udržovat využití disku pod 90% a činit opatření, pokud dosáhne 80%. Nedostatečný prostor na disku je častou příčinou selhání systému. Monitorování využití disku pomáhá v proaktivním řízení úložných zdrojů, což zajišťuje dostatek prostoru pro příchozí data a systémové operace. Vzhledem k tomu, že většina systémů je konfigurována k mazání dat po 18 měsících skladování, může se využití disku začít stabilizovat po 18 měsících provozu systému. Více si přečtěte o životním cyklu dat.
Dashboard metrik Elasticsearch¶
Dashboard metrik Elasticsearch monitoruje zdraví Elastic pipeline. (Většina uživatelů TeskaLabs LogMan.io používá databázi Elasticsearch pro ukládání log dat.)
Zahrnuté metriky:
- Cluster health: Zelená je dobrá; žlutá a červená indikují problém.
- Number of nodes: Uzel je jedna instance Elasticsearch. Počet uzlů je, kolik uzlů je součástí vašeho clusteru Elasticsearch v LogMan.io.
- Shards
- Active shards: Počet celkem aktivních shardů. Shard je jednotka, ve které Elasticsearch distribuuje data po celém clusteru.
- Unassigned shards: Počet shardů, které nejsou k dispozici. Mohou být v uzlu, který je vypnutý.
- Relocating shards: Počet shardů, které jsou v procesu přesunu do jiného uzlu. (Možná budete chtít vypnout uzel kvůli údržbě, ale stále chcete, aby všechna vaše data byla dostupná, takže můžete přesunout shard do jiného uzlu. Tato metrika vám řekne, zda jsou nějaké shardy aktivně v tomto procesu a proto zatím nemohou poskytovat data.)
- Used mem: Použitá paměť. Použitá paměť na 100% by znamenala, že Elasticsearch je přetížený a vyžaduje vyšetřování.
- Output queue: Počet úkolů čekajících na zpracování ve výstupní frontě. Vysoký počet může naznačovat významné zpoždění nebo úzké hrdlo.
- Stored GB: Množství diskového prostoru používaného pro ukládání dat v clusteru Elasticsearch. Monitorování využití disku pomáhá zajistit dostatek volného prostoru a plánovat nezbytné rozšíření kapacity.
- Docs count: Celkový počet dokumentů uložených v indexech Elasticsearch. Monitorování počtu dokumentů může poskytnout přehled o růstu dat a požadavcích na správu indexů.
- Task max waiting in queue: Maximální doba, po kterou úkol čekal ve frontě na zpracování. Je užitečná pro identifikaci zpoždění ve zpracování úkolů, což může ovlivnit výkon systému.
- Open file descriptors: Popisovače souborů jsou handly, které umožňují systému spravovat a přistupovat k souborům a síťovým připojením. Monitorování počtu otevřených popisovačů souborů je důležité pro zajištění efektivního řízení systémových zdrojů a prevenci potenciálních úniků handle, které by mohly vést k nestabilitě systému.
- Used cpu %: Procento CPU zdrojů aktuálně používaných Elasticsearch. Monitorování využití CPU pomáhá pochopit výkon systému a identifikovat potenciální úzká místa v CPU.
- Indexing: Míra, jakou jsou nové dokumenty indexovány do Elasticsearch. Vyšší míra znamená, že váš systém může efektivněji indexovat více informací.
- Inserts: Počet nových dokumentů přidávaných do indexů Elasticsearch. Tato linie následuje pravidelný vzor, pokud máte konzistentní počet vstupů. Pokud linie nepravidelně stoupne nebo klesne, může být problém ve vaší datové pipeline, která zabraňuje událostem dosáhnout Elasticsearch.
Dashboard zpoždění konzumentů Burrow¶
Dashboard Burrow monitoruje konzumenty a partitiony Apache Kafka. Více se dozvíte o Burrow zde.
Termíny Apache Kafka:
- Consumers: Konzumenti čtou data. Předplácejí si jeden nebo více témat a čtou data v pořadí, ve kterém byla vyprodukována.
- Consumer groups: Konzumenti jsou obvykle organizováni do skupin konzumentů. Každý konzument ve skupině čte z exkluzivních partitionů témat, která si předplácejí, což zajišťuje, že každý záznam je zpracován skupinou pouze jednou, i když více konzumentů čte.
- Partitions: Témata jsou rozdělena na partitiony. Toto umožňuje distribuci dat po celém clusteru, což umožňuje současné čtení a zápis operací.
Zahrnuté metriky:
- Group status: Celkový zdravotní stav skupiny konzumentů. Stav OK znamená, že skupina funguje normálně, zatímco varování nebo chyba mohou indikovat problémy, jako jsou problémy s připojením, selhalí konzumenti nebo nesprávné konfigurace.
- Total lag: V tomto případě lze lag chápat jako frontu úkolů čekajících na zpracování mikroslužbou. Metrika total lag představuje počet zpráv, které byly vyprodukovány do tématu, ale ještě nebyly spotřebovány konkrétním konzumentem nebo skupinou konzumentů. Pokud je lag 0, vše je správně odesláno a není žádná fronta. Vzhledem k tomu, že Apache Kafka má tendenci seskupovat data do dávky, určité množství lagu je často normální. Nicméně, rostoucí lag nebo lag nad přibližně 300 000 (toto číslo závisí na kapacitě vašeho systému, konfiguraci a citlivosti) je důvodem k vyšetřování.
- Partitions lag: Lag jednotlivých partitionů v rámci tématu. Možnost vidět lagu jednotlivých partitionů odděleně vám říká, zda některé partitiony mají větší frontu nebo vyšší zpoždění než jiné, což může indikovat nerovnoměrnou distribuci dat nebo jiné specifické problémy s partitionem.
- Partition status: Stav jednotlivých partitionů. Stav OK naznačuje, že partition funguje normálně. Varování nebo chyby mohou naznačovat problémy jako zastavený konzument, který nečte z partitionu. Tato metrika pomáhá identifikovat specifické problémy s partitionem, které by nemusely být zjevné při pohledu na celkový stav skupiny.
Profylaktická kontrola¶
Úvod¶
Profylaktické kontroly MUSÍ být prováděny pravidelně (týdně, měsíčně atd.), ideálně ve stejný den v týdnu a v konzistentní čas. Je zásadní zohlednit variace v množství a frekvenci příchozích událostí, které mohou kolísat na základě dne v týdnu, pracovní doby a státních svátků.
Doporučená periodicita profylaktických kontrol:
- 1x týdně v období "hypercare"; období hypercare je stabilizační období po počáteční instalaci produktu, trvající přibližně 3 měsíce.
- 1x měsíčně
Výsledky profylaktických kontrol by měly být zdokumentovány ve dvou samostatných reportech:
- Report dodavatele – Udržován pro interní sledování v systému dodavatele (TeskaLabs).
- Report klienta – Sdílen s koncovým uživatelem prostřednictvím jejich podpůrného Slack kanálu nebo jiného podpůrného kanálu.
Note
Dbejte na to, abyste jasně vysvětlili a popsali zjištění, a zajistěte, že závažné problémy jsou již interně řešeny. Pokud je řešení na cestě, vždy to v reportu komunikujte.
Přerozdělení podpory¶
Seznam jednotlivců zapojených do konkrétních projektů lze nalézt v interní dokumentaci. Pokud nastane problém, eskalujte ho vhodně na základě zapojeného klienta, partnera nebo zákazníka.
Postup profylaktické kontroly¶
Požadavky¶
- Přístup (HTTPS, SSH) k příslušné instalaci TeskaLabs LogMan.io.
- Ujistěte se, že všechny tenanty, které máte k dispozici, jsou během těchto kontrol přezkoumány.
Funkčnosti TeskaLabs LogMan.io¶
Kontrola navigace a funkčnosti¶
- Prozkoumejte každý přiřazený tenant kontrolou všech komponent v postranním panelu:
- Objev: Ověřte přístupnost logů, výkon vyhledávání a provádění dotazů. Ujistěte se, že jsou logy správně indexovány a dostupné.
- Dashboardy: Zkontrolujte správnost vizualizace dat, aktualizované widgety a správné filtrování. Ujistěte se, že grafy a diagramy odrážejí očekávané metriky.
- Reporty: Ověřte generování reportů, jejich formátování a přesnost dat. Ujistěte se, že naplánované reporty jsou doručovány správně.
- Export: Otestujte extrakci dat a ujistěte se, že exportované soubory jsou správně formátovány a obsahují očekávaný obsah.
- Archiv: Ověřte, že archivované logy jsou dostupné a uloženy podle očekávání.
- Zdroje logů:
- Sběrače: Ujistěte se, že všechny sběrače jsou aktivní, přijímají data a jsou správně nakonfigurovány.
- Event Lanes: Ověřte správnou klasifikaci událostí a potvrďte, že nedochází k anomáliím v zpracování.
- Základní linie: Zkontrolujte základní metriky, abyste zajistili, že odpovídají očekávaným prahům, a přezkoumejte změny.
- Upozornění: Potvrďte, že mechanismy upozornění fungují, otestujte spouštěče upozornění a přezkoumejte eskalace.
- Nástroje: Ujistěte se, že vestavěné nástroje (např. Grafana, Kibana) fungují podle očekávání.
- Vyhledávání: Ověřte tabulky pro vyhledávání na přesnost a ujistěte se, že jsou správně odkazovány v zpracování událostí.
- Knihovna: Potvrďte dostupnost a správné verze sdílených zdrojů a obsahu.
- Údržba:
- Konfigurace: Ujistěte se, že systémová nastavení a konfigurace jsou správně udržovány a aktualizovány.
- Služby: Ověřte, že backendové služby jsou funkční a běží hladce.
-
Autentizace a role:
- Přihlašovací údaje: Zkontrolujte dostupné přihlašovací údaje a udržujte je aktuální.
- Tenanty: Potvrďte přístup k tenantům a zajistěte správnou izolaci dat.
- Relace: Přezkoumejte logy relací na anomálie nebo pokusy o neoprávněný přístup.
- Role: Ujistěte se, že kontroly přístupu na základě rolí jsou správně vynucovány.
- Zdroje: Ověřte dostupnost sdílených systémových zdrojů.
- Klienti: Ujistěte se, že konfigurace klientů jsou správně udržovány a aktuální.
-
Poznámka: Pokud nejste superuživatel, nemusíte vidět každou sekci uvedenou výše.
ASAB-IRIS - Testování šablon¶
- Otestujte odeslání e-mailu a zprávy na Slack prostřednictvím knihovny.
- Jakékoli problémy v této části by měly být hlášeny interně.
Monitorování zdrojů logů¶
Časové zóny logů¶
- Kde zkontrolovat: Obrazovka Objev TeskaLabs LogMan.io
- Zkontrolujte logy s
@timestamp
v budoucnosti (nyní+2H nebo více) - Hlášení problémů:
- Nesprávné časové zóny by měly být hlášeny interně.
- Pokud je problém způsoben nesprávnými nastaveními logovacího zařízení, hlaste to do podpůrného Slack kanálu klienta.
- Analyzujte zdroj (
host.hostname
,lmio.source
nebo IP adresa) a zahrňte to do profylaktického reportu.
Zdroje logů¶
- Kde zkontrolovat: Obrazovka Objev – Event Lanes, obrazovka Event lane a Baseliner
- Cíl: Zajistit, aby každý připojený zdroj logů byl aktuálně aktivní, prozkoumat všechny výpadky a anomálie v logování.
- Hlášení problémů:
- Interně a do podpůrného Slack kanálu klienta/partnera.
Ostatní události¶
- Kde zkontrolovat: TeskaLabs LogMan.io - index
lmio-others-events
na obrazovce Objev - Běžné zdroje chybových logů:
- Logy depository
- Nestrukturované logy
- Víceřádkové a fragmentované logy
- Hlášení problémů: Interně týmu parsec.
Systémové logy¶
- Kde zkontrolovat: TeskaLabs LogMan.io - Systémový tenant, index Události & Ostatní
- Hlášení problémů:
- Různé typy logů se mohou objevit zde; zaměřte se na chybové a varovné logy.
- Hlášení nálezů interně nebo do podpůrného Slack kanálu klienta, pokud je to nutné.
Baseliner¶
- Kde zkontrolovat: Obrazovka Baseliner TeskaLabs LogMan.io
- Zahrňte kontrolu přesměrování z obrazovky Objev na obrazovku Baseliner.
- Hlášení problémů: Pokud je Baseliner neaktivní, hlaste to interně.
Monitorování Elasticsearch¶
- Kde zkontrolovat: Grafana, dedikovaný dashboard – Monitorování ElasticSearch a Kibana Stack
- Kontrola vzorových dat za posledních 24 hodin
- Ukazatele k monitorování:
- Neaktivní uzly → Měly by být nula
- Zdraví systému → Mělo by být zelené; okamžitě eskalujte, pokud je žluté nebo červené.
- Nepřiřazené shardy → Měly by být nula a zelené; žluté nebo nenulové vyžaduje monitorování a hlášení.
- JVM Heap → Monitorujte využití heapu, aby zůstalo pod 75 %, aby se předešlo nadměrnému garbage collection, což může zpomalit provádění dotazů. Pokud využití heapu často překračuje 85 %, zvažte zvýšení přidělené paměti nebo optimalizaci dotazů a indexování.
- Přiřazené ILM → Zkontrolujte, že politiky ILM jsou správně aplikovány na indexy, aby se zajistilo, že data jsou přesunována podle definovaných strategií uchovávání a výkonu. Nesprávně nakonfigurované ILM může vést k vyšším nákladům na úložiště a zhoršenému výkonu vyhledávání.
- Hlášení problémů: Okamžitě eskalujte závažné problémy interně.
Přehled na systémové úrovni¶
- Kde zkontrolovat: Grafana, dedikovaný dashboard – Přehled na systémové úrovni
- Kontrola vzorových dat za posledních 24 hodin
- Metriky k monitorování:
- Využití disku: Nemělo by přesáhnout 80 % (kromě
/boot
, který by neměl přesáhnout 95 %). - Zátěž: Neměla by přesáhnout 40 %; maximální zátěž by měla odpovídat počtu jader.
- CPU Nemělo by překročit 85 % využití po delší dobu.
- IOWait: Mělo by být pod 10 %; hodnoty nad 20 % naznačují významné zpoždění při čtení/zápisu na disk.
- Využití RAM: Nemělo by překročit 70 %; trvalé využití nad 80 % vyžaduje vyšetřování.
- Swap Měl by být minimální; časté nebo vysoké využití swapu naznačuje tlak na paměť a vyžaduje další analýzu.
- Hlášení problémů: Hlášení interně.
Přehled zpoždění Kafka¶
- Definice: Zpoždění v tomto kontextu se vztahuje na zpoždění mezi tím, kdy je zpráva vyprodukována do Kafka tématu, a kdy je zpracována příslušnou skupinou spotřebitelů. Vysoká hodnota zpoždění naznačuje, že spotřebitelé nezpracovávají zprávy dostatečně rychle, což může vést k potenciálním zpožděním zpracování dat a neefektivnostem systému.
- Kde zkontrolovat: Grafana, dedikovaný dashboard – Přehled zpoždění Kafka
- Skupiny k monitorování:
lmio parsec
lmio depositor
lmio baseliner
lmio correlator
- Klíčová metrika: Hodnota zpoždění by se neměla zvyšovat v průběhu času.
- Hlášení problémů:
- Pokud se zpoždění zvyšuje ve srovnání s předchozím týdnem, hlaste to v interním Slack kanálu.
- Závažné zvýšení zpoždění by mělo být okamžitě eskalováno.
Monitorování velikosti indexů a životního cyklu¶
- Kde zkontrolovat: Kibana, Monitorování stacku nebo Správa stacku
- Kroky:
- Klikněte na Indexy.
- Seřaďte sloupec Dat od největšího po nejmenší.
- Prozkoumejte indexy větší než 200 GB.
- Kontrola ILM:
- Pokud index postrádá číselný suffix, není připojen k ILM.
- Zkontrolujte, zda jsou indexy správně klasifikovány jako hot/warm/cold.
- Shardování:
- Shardování by nemělo překročit 500-600 shardů na uzel, aby se předešlo nadměrnému využití zdrojů.
- Ověřte alokaci shardů napříč uzly clusteru, abyste zajistili vyvážené rozložení.
- Hlášení problémů: Hlášení interně a okamžitě eskalujte.
Počítání EPS¶
- Definice: EPS se vztahuje na počet logových událostí přijatých za sekundu. Monitorování EPS pomáhá sledovat rychlost příjmu systému, detekovat anomálie a zajistit, aby systém mohl efektivně zvládat špičkové zatížení.
- Kde zkontrolovat: UI LogMan.io za posledních 7 dní
- Metriky k získání:
- PRŮMĚRNÁ hodnota
- MAXIMÁLNÍ hodnota
Metriky
Systémové monitorovací metriky¶
Když logy a události procházejí systémem TeskaLabs LogMan.io, jsou logy a události zpracovávány několika TeskaLabs mikroslužbami a také Apache Kafka, a většina nasazení ukládá data do Elasticsearch.
Protože mikroslužby a další technologie zpracovávají obrovské množství událostí, není praktické je monitorovat pomocí logů.
Místo toho sledují stav a zdraví každé mikroslužby a dalších částí vašeho systému metriky, nebo-li měření.
K metrikám můžete přistupovat v Grafana a/nebo InfluxDB s použitím přednastavených nebo vlastních vizualizací. Každá metrika každé mikroslužby se aktualizuje přibližně jednou za minutu.
Zobrazení metrik¶
K systémovým monitorovacím metrikám můžete přistupovat pomocí Grafana a/nebo InfluxDB prostřednictvím webové aplikace TeskaLabs LogMan.io na stránce Nástroje.
Použití Grafana pro zobrazení metrik¶
Přednastavené dashboardy¶
Deployujeme TeskaLabs LogMan.io s připravenou sadou monitorovacích a diagnostických dashboardů - podrobnosti a pokyny pro přístup zde. Tyto dashboardy vám poskytují širší přehled o tom, co se děje ve vašem systému. Doporučujeme nejprve konzultovat tyto dashboardy, pokud nevíte, které konkrétní metriky chcete zkoumat.
Použití nástroje Explore v Grafana¶
1. V Grafana klikněte na tlačítko (menu) a přejděte na Explore.
2. Nastavte zdroj dat na InfluxDB.
3. Použijte klikací tvůrce dotazů:
Tvůrce dotazů Grafana
FROM:
1. Measurement: Klikněte na select measurement a vyberte skupinu metrik. V tomto případě je skupina metrik bspump.pipeline
.
2. Tag: Klikněte na znaménko plus vedle WHERE a vyberte tag. Protože tento příklad zobrazuje metriky z mikroslužby, je vybrán appclass::tag
.
3. Tag value: Klikněte na select tag value a vyberte hodnotu. V tomto příkladu dotaz zobrazí metriky z mikroslužby Parsec.
Volitelně můžete přidat další filtry v sekci FROM, jako je pipeline a hostitel.
SELECT:
4. Fields: Přidejte pole pro přidání specifických metrik do dotazu.
5. Aggregation: Můžete si vybrat metodu agregace pro každou metriku. Uvědomte si, že Grafana nemůže zobrazit graf, ve kterém jsou některé hodnoty agregovány a jiné nejsou.
GROUP BY:
6. Fill: Můžete zvolit fill(null)
nebo fill(none)
pro rozhodnutí, jak vyplnit mezery mezi datovými body. fill(null)
nevyplňuje mezery, takže výsledný graf bude mít datové body s mezerami mezi nimi. fill(none)
spojí datové body čárou, takže je snazší vidět trendy.
4. Přizpůsobte časový rámec podle potřeby a klikněte na Run query.
Pro více informací o funkci Explore v Grafana, navštivte dokumentaci Grafana.
Použití InfluxDB pro zobrazení metrik¶
Pokud máte přístup k InfluxDB, můžete ji použít k prozkoumání dat. InfluxDB poskytuje tvůrce dotazů, který vám umožní filtrovat metriky, které chcete vidět, a získat vizualizace (grafy) těchto metrik.
Pro přístup k InfluxDB:
- V webové aplikaci LogMan.io přejděte na Nástroje.
- Klikněte na InfluxDB a přihlaste se.
Použití tvůrce dotazů:
Tento příklad vás provede zkoumáním metriky, která je specifická pro mikroslužbu, jako je metrika monitorování pipeline. Pokud hledáte metriku, která nezahrnuje mikroslužbu, začněte tagem _measurement
, který pak filtrujte dalšími relevantními tagy.
-
V InfluxDB, v levém postranním panelu klikněte na ikonu pro přechod na Data Explorer. Nyní můžete vidět vizuální tvůrce dotazů InfluxDB.
-
V prvním boxu vyberte bucket. (Váš bucket metrik bude pravděpodobně pojmenován buď
metrics
nebo podle vaší organizace.) -
V dalším filtru vyberte appclass z rozbalovacího menu, abyste viděli seznam mikroslužeb, které produkují metriky. Klikněte na mikroslužbu, ze které chcete zobrazit metriky.
-
V dalším filtru vyberte _measurement z rozbalovacího menu, abyste viděli seznam skupin metrik. Vyberte skupinu, kterou chcete vidět.
-
V dalším filtru vyberte _field z rozbalovacího menu, abyste viděli seznam dostupných metrik. Vyberte metriky, které chcete vidět.
-
Mikroslužba může mít více pipeline. Pro zúžení výsledků na konkrétní pipeline použijte další filtr. Vyberte pipeline z rozbalovacího menu a vyberte pipeline, kterou chcete reprezentovat.
- Volitelně také můžete vybrat hostitele v dalším filtru. Bez filtru InfluxDB zobrazuje data ze všech dostupných hostitelů, ale pravděpodobně máte pouze jednoho hostitele. Pro výběr hostitele zvolte host v rozbalovacím menu a vyberte hostitele.
-
K načtení vizualizace klikněte na Submit.
Vizualizace vytvořená v tomto příkladě:
Pro více informací o funkci Data explorer v InfluxDB, navštivte dokumentaci InfluxDB.
Metriky pipeline¶
Metriky pipeline, nebo měření, monitorují propustnost logů a událostí v pipeline mikroslužeb. Můžete použít tyto metriky pipeline k pochopení stavu a zdraví každé mikroslužby.
Data, která procházejí mikroslužbami, jsou rozložena a měřena v událostech. (Každá událost je jedna zpráva v Kafka a bude mít za následek jeden záznam v Elasticsearch.) Protože události jsou počitatelné, metriky kvantifikují propustnost, což vám umožní posoudit stav a zdraví pipeline.
BSPump
Několik mikroslužeb TeskaLabs je postaveno na technologii BSPump, takže názvy metrik obsahují bspump
.
Mikroslužby postavené na BSPump:
Architektura mikroslužeb
Interní architektura každé mikroslužby se liší a může ovlivnit vaši analýzu metrik. Navštivte naši stránku Architecture.
Nejspíše mikroslužby, které produkují nevyrovnané event.in
a event.out
počítadla metriky bez toho, aby měly chybu, jsou:
- Parser/Parsec - Díky své interní architektuře; parser posílá události do jiné pipeline (Enricher), kde nejsou události započítány v
event.out
. - Correlator - Protože korelátor posuzuje události, jak jsou zapojeny do vzorů, často má nižší počet
event.out
neževent.in
.
Metriky¶
Názvy a tagy v Grafana a InfluxDB
- Metriky pipeline jsou seskupeny pod tagem
measurement
. - Metriky pipeline jsou produkovány pro mikroslužby (tag
appclass
) a mohou být dále filtrovány pomocí dodatečných tagůhost
apipeline
. - Každá jednotlivá metrika (například
event.in
) je hodnota v tagufield
.
Všechny metriky se aktualizují automaticky jednou za minutu jako výchozí nastavení.
bspump.pipeline
¶
event.in
¶
Popis: Počítá počet událostí vstupujících do pipeline
Jednotka: Počet (událostí)
Interpretace: Sledování event.in
v průběhu času vám může ukázat vzory, špičky a trendy v tom, kolik událostí bylo přijato mikroslužbou. Pokud nepřicházejí žádné události, event.in
je čára na 0. Pokud očekáváte propustnost, a event.in
je 0, je problém v datové pipeline.
event.out
¶
Popis: Počítá počet událostí opouštějících pipeline úspěšně
Jednotka: Počet (událostí)
Interpretace: event.out
by měla být obvykle stejná jako event.in
, ale jsou zde výjimky. Některé mikroslužby jsou konstruovány tak, aby měly buď více výstupů na jeden vstup, nebo aby odváděly data takovým způsobem, že výstup není detekován touto metrikou.
event.drop
¶
Popis: Počítá počet událostí, které byly ztraceny nebo zpráv, které byly ztraceny mikroslužbou.
Jednotka: Počet (událostí)
Interpretace: Protože mikroslužby postavené na BSPump nejsou obecně navrženy na ztrácení zpráv, jakoukoli ztrátu je nejspíše chyba.
Při přejíždění nad grafem v InfluxDB můžete vidět hodnoty jednotlivých čar v jakémkoli bodě času. V tomto grafu můžete vidět, že
event.out
je rovna event.in
a event.drop
je rovna 0, což je očekávané chování mikroslužby. Stejný počet událostí opouští pipeline, jaký do ní vstupuje, a žádné události nejsou ztraceny.
warning
¶
Popis: Počítá počet varování generovaných v pipeline.
Jednotka: Počet (varování)
Interpretace: Varování vám říkají, že existuje problém s daty, ale pipeline byla stále schopna je zpracovat. Varování je méně závažné než chyba.
error
¶
Popis: Počítá počet chyb v pipeline.
Jednotka: Počet (chyb)
Interpretace: Mikroslužby mohou generovat chyby z různých důvodů. Hlavním důvodem pro chybu je, že data neodpovídají očekávání mikroslužby a pipeline nebyla schopna tato data zpracovat.
bspump.pipeline.eps
¶
EPS znamená událostí za sekundu.
eps.in
¶
Popis: "Události za sekundu dovnitř" - Rychlost událostí úspěšně vstupujících do pipeline
Jednotka: Události za sekundu (rychlost)
Interpretace: eps.in
by měla zůstat konzistentní v průběhu času. Pokud eps.in
mikroslužby zpomaluje nečekaně v průběhu času, může zde být problém v datové pipeline před mikroslužbou.
eps.out
¶
Popis: "Události za sekundu ven" - Rychlost událostí úspěšně opouštějících pipeline
Jednotka: Události za sekundu (rychlost)
Interpretace: Podobně jako u event.in
a event.out
, eps.in
a eps.out
by měly být obvykle stejné, ale mohou se lišit v závislosti na mikroslužbě. Pokud události vstupují do mikroslužby mnohem rychleji, než opouštějí, a toto není očekávané chování té pipeline, můžete potřebovat řešit chybu způsobující úzké hrdlo v mikroslužbě.
eps.drop
¶
Popis: "Událostech za sekundu ztracených" - rychlost událostí ztracených v pipeline
Jednotka: Události za sekundu (rychlost)
Interpretace: Viz event.drop
. Pokud eps.drop
rychle roste, a to není očekávané chování mikroslužby, to znamená, že události jsou ztraceny, a existuje problém v pipeline.
Podobně jako u grafu
event.in
a event.out
, očekávané chování většiny mikroslužeb je, že eps.out
se rovná eps.in
s drop
rovno 0.
warning
¶
Popis: Počítá počet varován generovaných v pipeline ve specifikovaném časovém období.
Jednotka: Počet (varování)
Interpretace: Varování vám říkají, že existuje problém s daty, ale pipeline byla stále schopna je zpracovat. Varování je méně závažné než chyba.
error
¶
Popis: Počítá počet chyb v pipeline ve specifikovaném časovém období.
Jednotka: Počet (chyb)
Interpretace: Mikroslužby mohou generovat chyby z různých důvodů. Hlavním důvodem pro chybu je, že data neodpovídají očekávání mikroslužby a pipeline nebyla schopna tato data zpracovat.
bspump.pipeline.gauge
¶
Gauge metrika, procento vyjádřené jako číslo od 0 do 1.
warning.ratio
¶
Popis: Poměr událostí, které generovaly varování ve srovnání s celkovým počtem úspěšně zpracovaných událostí.
Interpretace: Pokud poměr varování nečekaně roste, prozkoumejte pipeline pro problémy.
error.ratio
¶
Popis: Poměr událostí, které nebyly zpracovány, ve srovnání s celkovým počtem úspěšně zpracovaných událostí.
Interpretace: Pokud poměr chyb nečekaně roste, prozkoumejte pipeline pro problémy. Můžete vytvořit trigger, který vás upozorní, když error.ratio
překročí například 5%.
bspump.pipeline.dutycycle
¶
Duty cycle (také nazýván power cycle) popisuje, zda pipeline čeká na zprávy (připraven, hodnota 1) nebo není schopna zpracovat nové zprávy (zaneprázdněn, hodnota 0).
Obecně:
- Hodnota 1 je přijatelná, protože pipeline může zpracovat nové zprávy.
- Hodnota 0 signalizuje problém, protože pipeline nemůže zpracovat nové zprávy.
Pochopení myšlenky duty cycle
Můžeme použít lidskou produktivitu k vysvětlení konceptu duty cycle. Pokud osoba vůbec není zaneprázdněná a nemá co dělat, čeká na úkol. Jejich duty cycle čtení je na 100% - tráví všechen svůj čas čekáním a může přijmout více práce. Pokud je člověk zaneprázdněn něčím a nemůže přijmout žádné další úkoly, jejich duty cycle je na 0%.
Výše uvedený příklad (není z InfluxDB) ukazuje, jak vypadá změna duty cycle na velmi krátkém časovém měřítku. V tomto příkladu pipeline měla dvě instance, kdy byla na 0, což znamená, že nebyla připravena a nebyla schopna zpracovat nové příchozí události. Mějte na paměti, že duty cycle vašeho systému může kolísat mezi 1 nebo 0 tisíckrát za sekundu; grafy duty cycle
ready
, které uvidíte v Grafana nebo InfluxDB, už budou agregovány (více níže).
ready
¶
Popis: ready
agreguje (průměruje) hodnoty duty cycle jednou za minutu. Zatímco duty cycle je vyjádřena jako 0 (false, zaneprázdněný) nebo 1 (true, čekající), metrika ready
představuje procento času, kdy duty cycle je na 0 nebo 1. Proto je hodnota ready
procento kdekoli mezi 0 a 1, takže graf nevypadá jako typický graf duty cycle.
Jednotka: Procento vyjádřené jako číslo od 0 do 1
Interpretace: Monitorování duty cycle je kritické pro pochopení kapacity vašeho systému. Zatímco každý systém je jiný, obecně ready
by mělo zůstat nad 70%. Pokud ready
klesne pod 70%, znamená to, že duty cycle klesl na 0 (zaneprázdněný) více než 30% času v tom intervalu, což ukazuje, že systém je velmi zaneprázdněn a vyžaduje určitou pozornost nebo úpravu.
Nahoře uvedený graf ukazuje, že většinu času byla duty cycle připravena více než 90% času během těchto dvou dnů. Nicméně existují dva body, kdy klesla blízko a pod 70%.
timedrift
¶
Metrika timedrift
slouží jako způsob, jak porozumět, jak moc se časování původů událostí (obvykle @timestamp
) liší od toho, co systém považuje za "aktuální" čas. Toto může být užitečné pro identifikování problémů, jako jsou zpoždění nebo nepřesnosti v mikroslužbě.
Každá hodnota je kalkulována jednou za minutu jako výchozí nastavení:
avg
¶
Průměr. Toto kalkuluje průměrný časový rozdíl mezi tím, kdy událost skutečně nastala a kdy ji váš systém zaznamenal. Pokud je toto číslo vysoké, může to znamenat stálé zpoždění.
median
¶
Medián. Toto vám říká prostřední hodnotu všech timedriftů pro daný interval, poskytuje více "typický" pohled na časovou přesnost vašeho systému. Medián je méně citlivý na extrémy než průměr, protože je to hodnota, nikoli výpočet.
stddev
¶
Standardní odchylka. Toto vám dává představu o tom, jak moc timedrift kolísá. Vysoká standardní odchylka může znamenat, že vaše časování je nekonzistentní, což by mohlo být problematické.
min
¶
Minimum. Toto ukazuje nejmenší timedrift ve vaší sadě dat. Je užitečné pro pochopení nejlepšího možného scénáře v přesnosti časování vašeho systému.
max
¶
Maximum. Toto ukazuje největší časový rozdíl. To vám pomáhá pochopit nejhorší scénář, což je klíčové pro identifikování horních hranic potenciálních problémů.
V tomto grafu časového driftu vidíte špičku zpoždění předtím, než se pipeline vrátí do normálu.
commlink
¶
commlink je komunikační spojení mezi LogMan.io Collectorem a LogMan.io Receiverem. Tyto metriky jsou specifické pro data zasílaná z mikroslužby Collector do mikroslužby Receiver.
Tagy: ActivityState
, appclass
(pouze LogMan.io Receiver), host
, identity
, tenant
- bytes.in: byty, které vstupují do LogMan.io Receiveru
- event.in: události, které vstupují do LogMan.io Receiveru
logs
¶
Počet logů, které procházejí mikroslužbami.
Tagy: appclass
, host
, identity
, instance_id
, node_id
, service_id
, tenant
- critical: Počet kritických logů
- errors: Počet chybových logů
- warnings: Počet varovných logů
Metriky využití disku¶
Monitorujte pečlivě využití disku, abyste předešli běžné příčině selhání systému.
disk
¶
Metriky pro monitorování využití disku. Více informací naleznete v dokumentaci InfluxDB Telegraf pluginu.
Tagy: device
, fstype
(typ souborového systému), mode
, node_id
, path
- free: Celkové množství volného místa na disku, měřeno v bytech.
- inodes_free: Počet volných inode, což odpovídá počtu volných deskriptorů souborů dostupných na souborovém systému.
- inodes_total: Celkový počet inode nebo deskriptorů souborů, které souborový systém podporuje.
- inodes_used: Počet inode nebo deskriptorů souborů aktuálně používaných na souborovém systému.
- total: Celková kapacita disku nebo úložného zařízení, měřeno v bytech.
- used: Množství disku aktuálně používaného, měřeno v bytech.
- used_percent: Procento diskového prostoru, které je aktuálně používáno v poměru k celkové kapacitě.
diskio
¶
Metriky pro monitorování diskového provozu a časování. Konzultujte dokumentaci InfluxDB Telegraf pluginu pro definici každé metriky.
Tagy: name
, node_id
, wwid
- io_time
- iops_in_progress
- merged_reads
- merged_writes
- read_bytes
- read_time
- reads
- weighted_io_time
- write_bytes
- write_time
- writes
Metriky výkonu systému¶
cpu
¶
Metriky pro sledování CPU systému. Viz dokumentace InfluxDB Telegraf pluginu pro více informací.
Tagy: ActivityState
, cpu
, node_id
- time_active: Celkový čas, kdy byl CPU aktivní, vykonával úlohy kromě nečinnosti.
- time_guest: Čas strávený během virtuálního CPU pro hostované operační systémy.
- time_guest_nice: Čas, který CPU strávil běžícím niced guestem (guest s pozitivní hodnotou nices).
- time_idle: Celkový čas, kdy CPU nebyl používán (nečinný).
- time_iowait: Čas, kdy byl CPU nečinný a čekal na dokončení I/O operací.
- time_irq: Čas strávený řešením hardwarových přerušení.
- time_nice: Čas, který CPU strávil zpracováním uživatelských procesů s pozitivní hodnotou nices.
- time_softirq: Čas strávený řešením softwarových přerušení.
- time_steal: Čas, který virtuální CPU čekal na skutečný CPU, zatímco hypervisor servisoval jiný virtuální procesor.
- time_system: Čas, který CPU strávil běžícím systémovými (jádrovými) procesy.
- time_user: Čas strávený vykonáváním uživatelských procesů.
- usage_active: Procento času, kdy byl CPU aktivní, vykonával úlohy.
- usage_guest: Procento času CPU stráveného během virtuálních CPU pro hostované operační systémy.
- usage_guest_nice: Procento času CPU stráveného během niced guestů.
- usage_idle: Procento času, kdy byl CPU nečinný.
- usage_iowait: Procento času, kdy byl CPU nečinný z důvodu čekání na I/O operace.
- usage_irq: Procento času stráveného řešením hardwarových přerušení.
- usage_nice: Procento času CPU stráveného procesy s pozitivní hodnotou nices.
- usage_softirq: Procento času stráveného řešením softwarových přerušení.
- usage_steal: Procento času, kdy virtuální CPU čekal na skutečný CPU, zatímco hypervisor servisoval jiný procesor.
- usage_system: Procento času CPU stráveného na systémových (jádrových) procesech.
- usage_user: Procento času CPU stráveného vykonáváním uživatelských procesů.
mdstat
¶
Statistiky o Linux MD RAID polích nakonfigurovaných na hostiteli. RAID (redundant array of inexpensive or independent disks) kombinuje více fyzických disků do jedné jednotky za účelem datové redundance (a tím bezpečnosti nebo ochrany před ztrátou v případě selhání disku) a výkonu systému (rychlejší přístup k datům). Navštivte dokumentaci InfluxDB Telegraf pluginu pro více informací.
Tagy: ActivityState
(aktivní nebo neaktivní), Devices
, Name
, _field
, node_id
- BlocksSynced: Počet bloků, které byly prohledány, pokud se pole obnovuje/kontroluje.
- BlocksSyncedFinishTime: Minuty zbývající do očekávaného dokončení obnovy skenování.
- BlocksSyncedPct: Procento zbývající obnovy skenování.
- BlocksSyncedSpeed: Aktuální rychlost, jakou probíhá obnovování, uvedená v K/sec.
- BlocksTotal: Celkový počet bloků v poli.
- DisksActive: Počet disků v poli, které jsou považovány za zdravé.
- DisksDown: Počet disků v poli, které jsou aktuálně nefunkční, nebo neoperativní.
- DisksFailed: Počet aktuálně selhaných disků v poli.
- DisksSpare: Počet náhradních disků v poli.
- DisksTotal: Celkový počet disků v poli.
processes
¶
Všechny procesy, seskupené podle stavu. Najděte dokumentaci InfluxDB Telegraf pluginu zde.
Tagy: node_id
- blocked: Počet procesů ve zablokovaném stavu, čekající na zdroj nebo událost, která by se stala dostupnou.
- dead: Počet procesů, které dokončily exekuci, ale stále mají záznam v tabulce procesů.
- idle: Počet procesů ve stavu nečinnosti, obvykle znamenající, že aktivně nepracují.
- paging: Počet procesů, které čekají na stránkování, buď na swapování dovnitř nebo ven z disku.
- running: Počet procesů, které aktuálně pracují nebo jsou připraveny k vykonávání.
- sleeping: Počet procesů, které jsou ve spánkovém stavu, nečinné do chvíle, dokud nejsou splněny určité podmínky nebo nenastanou události.
- stopped: Počet procesů, které jsou zastaveny, obvykle kvůli přijmu signálu nebo debugování.
- total: Celkový počet procesů aktuálně existujících v systému.
- total_threads: Celkový počet vláken napříč všemi procesy, protože procesy mohou mít více vláken.
- unknown: Počet procesů v neznámém stavu, kde jejich stav nelze určit.
- zombies: Počet zombie procesů, které dokončily vykonání, ale stále mají záznam v tabulce procesů, protože nadřazený proces nečetl jejich exit status.
system
¶
Tyto metriky poskytují obecné informace o systémovém zatížení, době provozu a počtu přihlášených uživatelů. Navštivte InfluxDB Telegraf plugin pro detaily.
Tagy: node_id
- load1: Průměrné systémové zatížení za poslední jednu minutu, indikující počet procesů v čekacím řetězci systému.
- load15: Průměrné systémové zatížení za posledních 15 minut, čímž poskytuje dlouhodobější pohled na nedávné systémové zatížení.
- load5: Průměrné systémové zatížení za posledních 5 minut, což nabízí krátkodobější perspektivu nedávného systémového zatížení.
- n_cpus: Počet dostupných jader CPU v systému.
- uptime: Celkový čas v sekundách, po který systém běžel od posledního spuštění nebo restartu.
temp
¶
Odečty teplot zaznamenané senzory systému. Navštivte dokumentaci InfluxDB Telegraf pluginu pro detaily.
Tagy: node_id
, sensor
- temp: Teplota
Specifické metriky sítě¶
net
¶
Metriky pro použití síťového rozhraní a protokolů u Linuxových systémů. Monitorování objemu přenosu dat a možných chyb je důležité pro pochopení zdraví a výkonu sítě. Navštivte dokumentaci pluginu InfluxDB Telegraf pro podrobnosti.
Tagy: interface
, node_id
bytes pole: Monitorování objemu přenosu dat, které je důležité pro správu šířky pásma a plánování kapacity sítě.
- bytes_recv: Celkový počet bajtů přijatých rozhraním
- bytes_sent: Celkový počet bajtů odeslaných rozhraním
drop pole: Zahozené pakety jsou často znakem síťového přetížení, hardwarových problémů nebo nesprávných konfigurací. Zahozené pakety mohou vést ke snížení výkonu.
- drop_in: Celkový počet přijatých paketů zahozených rozhraním
- drop_out: Celkový počet odeslaných paketů zahozených rozhraním
error pole: Vysoké míry chyb mohou signalizovat problémy s hardwarem sítě, interferencí nebo problémy s konfigurací.
- err_in: Celkový počet detekovaných chyb při příjmu rozhraním
- err_out: Celkový počet detekovaných chyb při odesílání rozhraním
packet pole: Počet odeslaných a přijatých paketů poskytuje indikaci provozu v síti a může pomoci identifikovat, zda je síť přetížena nebo zda existují problémy s přenosem paketů.
- packets_recv: Celkový počet paketů odeslaných rozhraním
- packets_sent: Celkový počet paketů přijatých rozhraním
nstat
¶
Metriky sítě. Navštivte dokumentaci pluginu InfluxDB Telegraf pro další informace.
Tagy: name
, node_id
ICMP pole¶
Metriky ICMP (internet control message protocol) se používají pro síťovou diagnostiku a kontrolní zprávy, jako například hlášení chyb a provozní dotazy. Navštivte tuto stránku pro další definice polí.
Klíčové pojmy:
- Echo requests/replies (ping): Používá se k testování dostupnosti a doby kolce (round-trip time).
- Destination unreachable: Indikuje, že daný cíl není dostupný.
- Parameter problems: Signalizuje problémy s parametry IP hlavičky.
- Redirect messages: Instrukce k použití jiného směru (route).
- Time exceeded messages: Indikuje, že čas k životu (TTL) pro paket vypršel.
IP pole¶
Metriky IP (internet protocol) monitorují hlavní protokol pro směrování paketů napříč internetem a lokálními sítěmi.
Navštivte tuto stránku pro další definice polí.
Klíčové pojmy:
- Address errors: Chyby spojené s nesprávnými nebo nedostupnými IP adresami.
- Header errors: Problémy v IP hlavičce, jako nesprávné kontrolní součty nebo chyby formátování.
- Delivered packets: Pakety úspěšně doručené na jejich cílové místo.
- Discarded packets: Pakety zahozené kvůli chybám nebo nedostatku prostoru v bufferu.
- Forwarded datagrams: Pakety směrované na jejich další skok směrem k cíli.
- Reassembly failures: Selhání při znovuskládání fragmentovaných IP paketů.
- IPv6 multicast/broadcast packets: Pakety zaslané více cílům nebo všem uzlům v segmentu sítě v IPv6.
TCP pole¶
Tyto metriky monitorují TCP, nebo transmission control protocol, který poskytuje spolehlivý, uspořádaný a chybově kontrolovaný přenos dat mezi aplikacemi. Navštivte tuto stránku pro další definice polí.
Klíčové pojmy:
- Connection opens: Zahájení nové TCP spojení.
- Segments: Jednotky přenosu dat v TCP.
- Reset segments (RST): Používá se k náhlému ukončení spojení.
- Retransmissions: Opětovné odesílání dat, která nebyla úspěšně přijata.
- Active/passive connection openings: Spojení zahájená aktivně (odchozí) nebo pasivně (příchozí).
- Checksum errors: Chyby zjištěné v kontrolním součtu segmentu TCP.
- Timeout retransmissions: Opětovné odesílání dat po časovém limitu, což indikuje možnou ztrátu paketů.
UDP pole¶
Tyto metriky monitorují UDP, nebo user datagram protocol, který umožňuje nízkolatenční (nízké zpoždění) ale méně spolehlivý přenos dat v porovnání s TCP. Navštivte tuto stránku pro další definice polí.
- Datagrams: Základní jednotky přenosu v UDP.
- Receive/send buffer errors: Chyby kvůli nedostatečnému prostoru v bufferu pro příchozí/odchozí data.
- No ports: Datagramy zaslané na port bez posluchače.
- Checksum errors: Chyby v poli pro kontrolní součet UDP datagramů.
Všechna pole nstat
- Icmp6InCsumErrors
- Icmp6InDestUnreachs
- Icmp6InEchoReplies
- Icmp6InEchos
- Icmp6InErrors
- Icmp6InGroupMembQueries
- Icmp6InGroupMembReductions
- Icmp6InGroupMembResponses
- Icmp6InMLDv2Reports
- Icmp6InMsgs
- Icmp6InNeighborAdvertisements
- Icmp6InNeighborSolicits
- Icmp6InParmProblems
- Icmp6InPktTooBigs
- Icmp6InRedirects
- Icmp6InRouterAdvertisements
- Icmp6InRouterSolicits
- Icmp6InTimeExcds
- Icmp6OutDestUnreachs
- Icmp6OutEchoReplies
- Icmp6OutEchos
- Icmp6OutErrors
- Icmp6OutGroupMembQueries
- Icmp6OutGroupMembReductions
- Icmp6OutGroupMembResponses
- Icmp6OutMLDv2Reports
- Icmp6OutMsgs
- Icmp6OutNeighborAdvertisements
- Icmp6OutNeighborSolicits
- Icmp6OutParmProblems
- Icmp6OutPktTooBigs
- Icmp6OutRedirects
- Icmp6OutRouterAdvertisements
- Icmp6OutRouterSolicits
- Icmp6OutTimeExcds
- Icmp6OutType133
- Icmp6OutType135
- Icmp6OutType143
- IcmpInAddrMaskReps
- IcmpInAddrMasks
- IcmpInCsumErrors
- IcmpInDestUnreachs
- IcmpInEchoReps
- IcmpInEchos
- IcmpInErrors
- IcmpInMsgs
- IcmpInParmProbs
- IcmpInRedirects
- IcmpInSrcQuenchs
- IcmpInTimeExcds
- IcmpInTimestampReps
- IcmpInTimestamps
- IcmpMsgInType3
- IcmpMsgOutType3
- IcmpOutAddrMaskReps
- IcmpOutAddrMasks
- IcmpOutDestUnreachs
- IcmpOutEchoReps
- IcmpOutEchos
- IcmpOutErrors
- IcmpOutMsgs
- IcmpOutParmProbs
- IcmpOutRedirects
- IcmpOutSrcQuenchs
- IcmpOutTimeExcds
- IcmpOutTimestampReps
- IcmpOutTimestamps
- Ip6FragCreates
- Ip6FragFails
- Ip6FragOKs
- Ip6InAddrErrors
- Ip6InBcastOctets
- Ip6InCEPkts
- Ip6InDelivers
- Ip6InDiscards
- Ip6InECT0Pkts
- Ip6InECT1Pkts
- Ip6InHdrErrors
- Ip6InMcastOctets
- Ip6InMcastPkts
- Ip6InNoECTPkts
- Ip6InNoRoutes
- Ip6InOctets
- Ip6InReceives
- Ip6InTooBigErrors
- Ip6InTruncatedPkts
- Ip6InUnknownProtos
- Ip6OutBcastOctets
- Ip6OutDiscards
- Ip6OutForwDatagrams
- Ip6OutMcastOctets
- Ip6OutMcastPkts
- Ip6OutNoRoutes
- Ip6OutOctets
- Ip6OutRequests
- Ip6ReasmFails
- Ip6ReasmOKs
- Ip6ReasmReqds
- Ip6ReasmTimeout
- IpDefaultTTL
- IpExtInBcastOctets
- IpExtInBcastPkts
- IpExtInCEPkts
- IpExtInCsumErrors
- IpExtInECT0Pkts
- IpExtInECT1Pkts
- IpExtInMcastOctets
- IpExtInMcastPkts
- IpExtInNoECTPkts
- IpExtInNoRoutes
- IpExtInOctets
- IpExtInTruncatedPkts
- IpExtOutBcastOctets
- IpExtOutBcastPkts
- IpExtOutMcastOctets
- IpExtOutMcastPkts
- IpExtOutOctets
- IpForwDatagrams
- IpForwarding
- IpFragCreates
- IpFragFails
- IpFragOKs
- IpInAddrErrors
- IpInDelivers
- IpInDiscards
- IpInHdrErrors
- IpInReceives
- IpInUnknownProtos
- IpOutDiscards
- IpOutNoRoutes
- IpOutRequests
- IpReasmFails
- IpReasmOKs
- IpReasmReqds
- IpReasmTimeout
- TcpActiveOpens
- TcpAttemptFails
- TcpCurrEstab
- TcpEstabResets
- TcpExtArpFilter
- TcpExtBusyPollRxPackets
- TcpExtDelayedACKLocked
- TcpExtDelayedACKLost
- TcpExtDelayedACKs
- TcpExtEmbryonicRsts
- TcpExtIPReversePathFilter
- TcpExtListenDrops
- TcpExtListenOverflows
- TcpExtLockDroppedIcmps
- TcpExtOfoPruned
- TcpExtOutOfWindowIcmps
- TcpExtPAWSActive
- TcpExtPAWSEstab
- TcpExtPAWSPassive
- TcpExtPruneCalled
- TcpExtRcvPruned
- TcpExtSyncookiesFailed
- TcpExtSyncookiesRecv
- TcpExtSyncookiesSent
- TcpExtTCPACKSkippedChallenge
- TcpExtTCPACKSkippedFinWait2
- TcpExtTCPACKSkippedPAWS
- TcpExtTCPACKSkippedSeq
- TcpExtTCPACKSkippedSynRecv
- TcpExtTCPACKSkippedTimeWait
- TcpExtTCPAbortFailed
- TcpExtTCPAbortOnClose
- TcpExtTCPAbortOnData
- TcpExtTCPAbortOnLinger
- TcpExtTCPAbortOnMemory
- TcpExtTCPAbortOnTimeout
- TcpExtTCPAutoCorking
- TcpExtTCPBacklogDrop
- TcpExtTCPChallengeACK
- TcpExtTCPDSACKIgnoredNoUndo
- TcpExtTCPDSACKIgnoredOld
- TcpExtTCPDSACKOfoRecv
- TcpExtTCPDSACKOfoSent
- TcpExtTCPDSACKOldSent
- TcpExtTCPDSACKRecv
- TcpExtTCPDSACKUndo
- TcpExtTCPDeferAcceptDrop
- TcpExtTCPDirectCopyFromBacklog
- TcpExtTCPDirectCopyFromPrequeue
- TcpExtTCPFACKReorder
- TcpExtTCPFastOpenActive
- TcpExtTCPFastOpenActiveFail
- TcpExtTCPFastOpenCookieReqd
- TcpExtTCPFastOpenListenOverflow
- TcpExtTCPFastOpenPassive
- TcpExtTCPFastOpenPassiveFail
- TcpExtTCPFastRetrans
- TcpExtTCPForwardRetrans
- TcpExtTCPFromZeroWindowAdv
- TcpExtTCPFullUndo
- TcpExtTCPHPAcks
- TcpExtTCPHPHits
- TcpExtTCPHPHitsToUser
- TcpExtTCPHystartDelayCwnd
- TcpExtTCPHystartDelayDetect
- TcpExtTCPHystartTrainCwnd
- TcpExtTCPHystartTrainDetect
- TcpExtTCPKeepAlive
- TcpExtTCPLossFailures
- TcpExtTCPLossProbeRecovery
- TcpExtTCPLossProbes
- TcpExtTCPLossUndo
- TcpExtTCPLostRetransmit
- TcpExtTCPMD5NotFound
- TcpExtTCPMD5Unexpected
- TcpExtTCPMTUPFail
- TcpExtTCPMTUPSuccess
- TcpExtTCPMemoryPressures
- TcpExtTCPMinTTLDrop
- TcpExtTCPOFODrop
- TcpExtTCPOFOMerge
- TcpExtTCPOFOQueue
- TcpExtTCPOrigDataSent
- TcpExtTCPPartialUndo
- TcpExtTCPPrequeueDropped
- TcpExtTCPPrequeued
- TcpExtTCPPureAcks
- TcpExtTCPRcvCoalesce
- TcpExtTCPRcvCollapsed
- TcpExtTCPRenoFailures
- TcpExtTCPRenoRecovery
- TcpExtTCPRenoRecoveryFail
- TcpExtTCPRenoReorder
- TcpExtTCPReqQFullDoCookies
- TcpExtTCPReqQFullDrop
- TcpExtTCPRetransFail
- TcpExtTCPSACKDiscard
- TcpExtTCPSACKReneging
- TcpExtTCPSACKReorder
- TcpExtTCPSYNChallenge
- TcpExtTCPSackFailures
- TcpExtTCPSackMerged
- TcpExtTCPSackRecovery
- TcpExtTCPSackRecoveryFail
- TcpExtTCPSackShiftFallback
- TcpExtTCPSackShifted
- TcpExtTCPSchedulerFailed
- TcpExtTCPSlowStartRetrans
- TcpExtTCPSpuriousRTOs
- TcpExtTCPSpuriousRtxHostQueues
- TcpExtTCPSynRetrans
- **TcpExtTCPTSRe
Metriky specifické pro autorizaci¶
TeskaLabs SeaCat Auth (jak je uvedeno v tagu appclass
) zajišťuje veškerou autorizaci v LogMan.io, včetně přihlašovacích údajů, přihlášení a relací.
credentials
¶
Tagy: appclass
(pouze SeaCat Auth), host
, instance_id
, node_id
, service_id
- default: Počet přihlašovacích údajů (uživatelských účtů) ve vašem nasazení TeskaLabs LogMan.io.
logins
¶
Počet neúspěšných a úspěšných přihlášení přes TeskaLabs SeaCat Auth.
Tagy: appclass
(pouze SeaCat Auth), host
, instance_id
, node_id
, service_id
- failed: Počítá neúspěšné pokusy o přihlášení. Informuje v okamžiku přihlášení.
- successful: Počítá úspěšná přihlášení. Informuje v okamžiku přihlášení.
sessions
¶
Relace začíná, když se uživatel přihlásí do LogMan.io, a metrika sessions
počítá otevřené relace.
Tagy: appclass
(pouze SeaCat Auth), host
, instance_id
, node_id
, service_id
- sessions: Počet otevřených relací v daném okamžiku
Metriky paměti¶
Sledováním metrik využití paměti můžete pochopit, jak jsou paměťové prostředky využívány. To vám může poskytnout poznatky o oblastech, které mohou potřebovat optimalizaci nebo úpravu.
memory
a os.stat
¶
Tagy: appclass
, host
, identity
, instance_id
, node_id
, service_id
, tenant
VmPeak
¶
Význam: Vrcholová velikost virtuální paměti. Toto je vrcholová nebo aktuální celková velikost virtuální paměti používané mikroslužbou. Virtuální paměť zahrnuje jak fyzickou RAM, tak diskový swap prostor (součet všech oblastí virtuální paměti zapojených do procesu).
Interpretace: Sledování vrcholu může pomoci identifikovat, zda služba nepoužívá více paměti, než se očekávalo, což může naznačovat únik paměti nebo potřebu optimalizace.
VmLck
¶
Význam: Velikost uzamčené paměti. To označuje část paměti, která je uzamčena v RAM a nemůže být swapována na disk.
Interpretace: Vysoké množství uzamčené paměti může potenciálně snížit flexibilitu systému v řízení paměti, což může vést k problémům s výkonem.
VmPin
¶
Význam: Velikost připnuté paměti. Toto je část paměti, která je "připnuta" na místě; fyzická lokalizace paměťové stránky v rámci RAM nemůže být automaticky změněna nebo swapována na disk.
Interpretace: Stejně jako uzamčená paměť, připnutá paměť nemůže být přesunuta, takže vysoká hodnota může také omezit flexibilitu systému.
VmHWM
¶
Význam: Maximální velikost rezidentní sady ("high water mark"). Toto je maximální množství fyzické RAM, které mikroslužba použila.
Interpretace: Pokud je tato hodnota konzistentně vysoká, může to naznačovat, že služba potřebuje optimalizaci nebo že potřebujete přidělit více fyzické RAM.
VmRSS
¶
Význam: Velikost rezidentní sady. To ukazuje část paměti mikroslužby, která je držena v RAM.
Interpretace: Vysoká hodnota RSS by mohla znamenat, že vaše služba používá hodně RAM, což by mohlo vést k problémům s výkonem, pokud začne používat swap.
VmData
, VmStk
, VmExe
¶
Význam: Velikost segmentů dat, zásobníku a textu. Tyto hodnoty představují velikosti různých paměťových segmentů: data, zásobník a spustitelný kód.
Interpretace: Sledování těchto hodnot vám může pomoci pochopit paměťovou stopu vaší služby a může být užitečné při ladění nebo optimalizaci vašeho kódu.
VmLib
¶
Význam: Velikost sdíleného knihovního kódu. Toto zahrnuje spustitelné stránky s odečteným VmExe a ukazuje množství paměti používané sdílenými knihovnami v procesu.
Interpretace: Pokud je toto vysoké, možná budete chtít ověřit, zda jsou všechny knihovny potřebné, protože přidávají k paměťové stopě.
VmPTE
¶
Význam: Velikost položek stránkovací tabulky. To označuje velikost stránkovací tabulky, která mapuje virtuální paměť na fyzickou paměť.
Interpretace: Velká velikost může znamenat, že je používáno hodně paměti, což může být problém, pokud se příliš zvětšuje.
VmSize
¶
Význam: Velikost dvouúrovňových stránkovacích tabulek. Toto je rozšíření VmPTE, které označuje velikost dvouúrovňových stránkovacích tabulek.
Interpretace: Stejně jako VmPTE pomáhá sledování této velikosti v identifikování potenciálních problémů s pamětí.
VmSwap
¶
Význam: Velikost swapované virtuální paměti. To označuje množství virtuální paměti, která byla swapována na disk. shmem
swap není zahrnut.
Interpretace: Časté swapování je obecně špatné pro výkon; pokud je tento metr vysoký, budete možná potřebovat přidělit více RAM nebo optimalizovat své služby.
mem
¶
Další měření týkající se paměti. Navštivte dokumentaci pluginu InfluxDB Telegraf pro podrobnosti.
-
Tagy:
node_id
-
active: Paměť aktuálně v použití nebo nedávno použitá, a tedy ne okamžitě k dispozici pro vysazení.
- available: Množství paměti, která je okamžitě k dispozici pro nové procesy bez swapování.
- available_percent: Procento celkové paměti, která je okamžitě k dispozici pro nové procesy.
- buffered: Paměť použitá jádrem pro věci jako metadata systému souborů, odlišná od cache.
- cached: Paměť použitá k ukládání nedávno použitých dat pro rychlý přístup, není okamžitě uvolněna, když ji procesy přestanou vyžadovat.
- commit_limit: Celkové množství paměti, které lze přidělit procesům, včetně RAM i swap prostoru.
- committed_as: Celkové množství paměti aktuálně přidělené procesy, i když není použita.
- dirty: Paměťové stránky, které byly modifikovány, ale ještě nebyly zapsány do svého datového umístění v úložišti.
- free: Množství paměti, které je aktuálně neobsazeno a k dispozici k použití.
- high_free: Množství volné paměti v oblasti vysoké paměti systému (paměť mimo přímý přístup jádra).
- high_total: Celkové množství systémové paměti v oblasti vysoké paměti.
- huge_page_size: Velikost každé velké stránky (větší než standardní paměťové stránky používané systémem).
- huge_pages_free: Počet velkých stránek, které nejsou aktuálně používány.
- huge_pages_total: Celkový počet velkých stránek dostupných v systému.
- inactive: Paměť, která nebyla nedávno použita a může být zpřístupněna pro jiné procesy nebo diskovou cache.
- low_free: Množství volné paměti v oblasti nízké paměti systému (paměť přímo přístupná jádrem).
- low_total: Celkové množství systémové paměti v oblasti nízké paměti.
- mapped: Paměť použitá pro mapované soubory, jako jsou knihovny a spustitelné soubory v paměti.
- page_tables: Paměť použitá jádrem k udržování mapování virtuální paměti na fyzickou paměť.
- shared: Paměť používaná více procesy nebo sdílená mezi procesy a jádrem.
- slab: Paměť použitá jádrem pro cache datových struktur.
- sreclaimable: Část slab paměti, která může být zpětně získána, například cache, které mohou být uvolněny v případě potřeby.
- sunreclaim: Část slab paměti, která nemůže být zpětně získána pod tlakem paměti.
- swap_cached: Paměť, která byla swapována na disk, ale stále je v RAM.
- swap_free: Množství swap prostoru, který aktuálně není používán.
- swap_total: Celkové množství dostupného swap prostoru.
- total: Celkové množství fyzické RAM dostupné v systému.
- used: Množství paměti, která je aktuálně používána procesy.
- used_percent: Procento celkové paměti, která je aktuálně používána.
- vmalloc_chunk: Největší souvislý blok paměti dostupný v prostoru vmalloc jádra.
- vmalloc_total: Celkové množství paměti dostupné v prostoru vmalloc jádra.
- vmalloc_used: Množství paměti aktuálně používané v prostoru vmalloc jádra.
- write_back: Paměť, která je aktuálně zapsána zpět na disk.
- write_back_tmp: Dočasná paměť použitá během operací zápisu zpět.
Metriky specifické pro kernel¶
kernel
¶
Metriky pro monitorování Linuxového kernelu. Navštivte dokumentaci pluginu InfluxDB Telegraf pro více detailů.
Štítky: node_id
- boot_time: Čas, kdy byl systém naposledy spuštěn, měřený v sekundách od Unixového epochu (1. ledna 1970). To vám řekne dobu provozu systému a čas posledního restartu. Tento údaj můžete převést na datum pomocí (Unix epoch time converter).
- context_switches: Počet (integer) přepnutí kontextu, které kernel provedl. Přepnutí kontextu nastává, když se CPU přepne z jednoho procesu nebo vlákna na jiné. Vysoký počet přepnutí kontextu může naznačovat, že mnoho procesů soutěží o čas CPU, což může být znakem vysokého zatížení systému.
- entropy_avail: Množství (integer) dostupné entropie (náhodnosti, kterou lze generovat) v systému, což je zásadní pro bezpečné generování náhodných čísel. Nízká entropie může ovlivnit kryptografické funkce a bezpečnou komunikaci. Entropie je spotřebovávána různými operacemi a postupem času doplňována, takže sledování této metriky je důležité pro udržení bezpečnosti.
- interrupts: Celkový počet (integer) přerušení zpracovaných od spuštění systému. Přerušení je signál procesoru vyslaný hardwarem nebo softwarem, který označuje událost vyžadující okamžitou pozornost. Vysoký počet přerušení může naznačovat zaneprázdněný nebo možná přetížený systém.
- processes_forked: Celkový počet (integer) forků (vytvořených) procesů od spuštění systému. Sledování rychlosti vytváření procesů může pomoci při diagnostice výkonových problémů systému, zejména v prostředích, kde jsou procesy často spouštěny a zastavovány.
kernel_vmstat
¶
Statistiky virtuální paměti kernelu shromážděné přes proc/vmstat
. Navštivte dokumentaci pluginu InfluxDB Telegraf pro více detailů.
Relevantní termíny
- Aktivní stránky: Stránky, které jsou aktuálně používány nebo byly nedávno použity.
- Neaktivní stránky: Stránky, které nebyly nedávno použity, a proto je pravděpodobnější, že budou přesunuty na swap space nebo znovu použity.
- Anonymní stránky: Stránky paměti, které nejsou zálohovány souborem na disku; typicky se používají pro data, která není třeba ukládat, jako jsou programové zásobníky.
- Bounce buffer: Dočasná paměť používaná k usnadnění přenosu dat mezi zařízeními, která nemohou přímo adresovat vzájemnou paměť.
- Kompakce: Proces přeskupování stránek v paměti pro vytvoření větších souvislých volných prostorů, často užitečný pro alokaci obrovských stránek.
- Špinavé stránky: Stránky, které byly upraveny v paměti, ale dosud nebyly zapsány zpět na disk.
- Eviktování: Proces odstraňování stránek z fyzické paměti, buď jejich přesunutím na disk (swapování) nebo jejich odstraněním, pokud již nejsou potřeba.
- Stránky zálohované souborem: Stránky paměti, které jsou spojeny se soubory na disku, například spustitelné soubory nebo datové soubory.
- Volné stránky: Stránky paměti, které jsou k dispozici pro použití a nejsou aktuálně přiděleny žádnému procesu nebo datům.
- Obrovské stránky: Velké stránky paměti, které mohou být použity procesy, čímž se snižuje režie tabulek stránek.
- Prokládání: Proces distribuce stránek paměti mezi různé paměťové uzly nebo zóny, typicky za účelem optimalizace výkonu v systémech s nejednotným přístupem k paměti (NUMA).
- NUMA (nejednotný přístup k paměti): Návrh paměti, kde procesor přistupuje ke své vlastní lokální paměti rychleji než k nelokální paměti.
- Alokace stránek: Proces přiřazování volných stránek paměti k pokrytí požadavku procesu nebo kernelu.
- Výpadek stránky: Událost, která nastane, když program zkusí přistoupit ke stránce, která není ve fyzické paměti, což vyžaduje, aby to OS zpracoval alokací stránky nebo jejím vyzvednutím z disku.
- Tabulka stránek: Datová struktura používaná operačním systémem k ukládání mapování mezi virtuálními adresami a fyzickými adresami paměti.
- Sdílená paměť (shmem): Paměť, ke které mohou přistupovat více procesů.
- Slab stránky: Stránky paměti používané kernelem k ukládání objektů pevných velikostí, jako jsou struktury souborů nebo cache inodů.
- Swap space: Prostor na disku použitý k ukládání stránek paměti, které byly vyřazeny z fyzické paměti.
- THP (transparentní obrovské stránky): Funkce, která automaticky spravuje přidělení obrovských stránek pro zlepšení výkonu bez nutnosti změn v aplikacích.
- Vmscan: Kernelový proces, který skenuje stránky paměti a rozhoduje, které stránky vyřadit nebo swapovat na základě jejich použití.
- Zápis zpět: Proces zápisu špinavých stránek zpět na disk.
Štítky: node_id
- nr_free_pages: Počet volných stránek v systému.
- nr_inactive_anon: Počet neaktivních anonymních stránek.
- nr_active_anon: Počet aktivních anonymních stránek.
- nr_inactive_file: Počet neaktivních stránek zálohovaných souborem.
- nr_active_file: Počet aktivních stránek zálohovaných souborem.
- nr_unevictable: Počet stránek, které nelze vyřadit z paměti.
- nr_mlock: Počet stránek zamčených do paměti (mlock).
- nr_anon_pages: Počet anonymních stránek.
- nr_mapped: Počet stránek namapovaných do uživatelského prostoru.
- nr_file_pages: Počet stránek zálohovaných souborem.
- nr_dirty: Počet aktuálně špinavých stránek.
- nr_writeback: Počet stránek pod zápisem zpět.
- nr_slab_reclaimable: Počet stránek slabů, které lze znovu použít.
- nr_slab_unreclaimable: Počet stránek slabů, které nelze znovu použít.
- nr_page_table_pages: Počet stránek použitých pro tabulky stránek.
- nr_kernel_stack: Množství stránek zásobníku kernelu.
- nr_unstable: Počet nestabilních stránek.
- nr_bounce: Počet stránek bounce bufferů.
- nr_vmscan_write: Počet stránek zapsaných vmscan.
- nr_writeback_temp: Počet dočasných stránek pod zápisem zpět.
- nr_isolated_anon: Počet izolovaných anonymních stránek.
- nr_isolated_file: Počet izolovaných stránek souborů.
- nr_shmem: Počet stránek sdílené paměti.
- numa_hit: Počet stránek alokovaných v preferovaném uzlu.
- numa_miss: Počet stránek alokovaných v nepreferovaném uzlu.
- numa_foreign: Počet stránek určených pro jiný uzel.
- numa_interleave: Počet proložených stránek.
- numa_local: Počet stránek alokovaných v lokálním uzlu.
- numa_other: Počet stránek alokovaných v jiných uzlech.
- nr_anon_transparent_hugepages: Počet anonymních transparentních obrovských stránek.
- pgpgin: Počet kilobajtů přečtených z disku.
- pgpgout: Počet kilobajtů zapsaných na disk.
- pswpin: Počet stránek swapovaných dovnitř.
- pswpout: Počet stránek swapovaných ven.
- pgalloc_dma: Počet alokovaných stránek v DMA zóně.
- pgalloc_dma32: Počet alokovaných stránek v DMA32 zóně.
- pgalloc_normal: Počet alokovaných stránek v normální zóně.
- pgalloc_movable: Počet alokovaných stránek v mobilní zóně.
- pgfree: Počet uvolněných stránek.
- pgactivate: Počet aktivovaných neaktivních stránek.
- pgdeactivate: Počet deaktivovaných aktivních stránek.
- pgfault: Počet výpadků stránek.
- pgmajfault: Počet velkých výpadků stránek.
- pgrefill_dma: Počet doplněných stránek v DMA zóně.
- pgrefill_dma32: Počet doplněných stránek v DMA32 zóně.
- pgrefill_normal: Počet doplněných stránek v normální zóně.
- pgrefill_movable: Počet doplněných stránek v mobilní zóně.
- pgsteal_dma: Počet získaných stránek v DMA zóně.
- pgsteal_dma32: Počet získaných stránek v DMA32 zóně.
- pgsteal_normal: Počet získaných stránek v normální zóně.
- pgsteal_movable: Počet získaných stránek v mobilní zóně.
- pgscan_kswapd_dma: Počet naskenovaných stránek v DMA zóně přes kswapd.
- pgscan_kswapd_dma32: Počet naskenovaných stránek v DMA32 zóně přes kswapd.
- pgscan_kswapd_normal: Počet naskenovaných stránek v normální zóně přes kswapd.
- pgscan_kswapd_movable: Počet naskenovaných stránek v mobilní zóně přes kswapd.
- pgscan_direct_dma: Počet přímo naskenovaných stránek v DMA zóně.
- pgscan_direct_dma32: Počet přímo naskenovaných stránek v DMA32 zóně.
- pgscan_direct_normal: Počet přímo naskenovaných stránek v normální zóně.
- pgscan_direct_movable: Počet přímo naskenovaných stránek v mobilní zóně.
- zone_reclaim_failed: Počet neúspěšných pokusů o znovuzískání zóny.
- pginodesteal: Počet získaných stránek inodů.
- slabs_scanned: Počet naskenovaných stránek slabů.
- kswapd_steal: Počet stránek získaných kswapd.
- kswapd_inodesteal: Počet stránek inodů získaných kswapd.
- kswapd_low_wmark_hit_quickly: Frekvence, jak rychle kswapd zasáhl nízkou hladinu vody.
- kswapd_high_wmark_hit_quickly: Frekvence, jak rychle kswapd zasáhl vysokou hladinu vody.
- kswapd_skip_congestion_wait: Počet případů, kdy kswapd přeskočil čekání kvůli přetížení.
- pageoutrun: Počet zpracovaných stránek pageout.
- allocstall: Počet případů, kdy se allocation page zasekla.
- pgrotated: Počet rotovaných stránek.
- compact_blocks_moved: Počet bloků přesunutých během kompakce.
- compact_pages_moved: Počet stránek přesunutých během kompakce.
- compact_pagemigrate_failed: Počet neúspěšných migrací stránek během kompakce.
- compact_stall: Počet záseků během kompakce.
- compact_fail: Počet neúspěchů kompakce.
- compact_success: Počet úspěšných kompakcí.
- htlb_buddy_alloc_success: Počet úspěšných alokací HTLB buddy.
- htlb_buddy_alloc_fail: Počet neúspěšných alokací HTLB buddy.
- unevictable_pgs_culled: Počet zněmněných neevikovatelných stránek.
- unevictable_pgs_scanned: Počet naskenovaných neevikovatelných stránek.
- unevictable_pgs_rescued: Počet zachráněných neevikovatelných stránek.
- unevictable_pgs_mlocked: Počet zamčených neevikovatelných stránek.
- unevictable_pgs_munlocked: Počet odemčených neevikovatelných stránek.
- unevictable_pgs_cleared: Počet vymazaných neevikovatelných stránek.
- unevictable_pgs_stranded: Počet opuštěných neevikovatelných stránek.
- unevictable_pgs_mlockfreed: Počet neevikovatelných stránek uvolněných z mlocku.
- thp_fault_alloc: Počet výpadků, které způsobil alokace THP.
- thp_fault_fallback: Počet výpadků, které využily fallback z THP.
- thp_collapse_alloc: Počet alokací THP zkolabovaných.
- thp_collapse_alloc_failed: Počet neúspěšných alokací THP zkolabovaných.
- thp_split: Počet THP rozdělených.
Tenant metriky¶
Můžete zkoumat zdraví a stav mikroslužeb specifických pro jednotlivé tenanta, pokud máte ve svém systému více LogMan.io tenantů. Tenant metriky jsou specifické pro mikroslužby LogMan.io Parser, Dispatcher, Correlator a Watcher.
Pojmenování a tagy v Grafana a InfluxDB
- Skupiny tenant metrik jsou uvedeny pod tagem
measurement
. - Tenant metriky jsou produkovány pro vybrané mikroslužby (tag
appclass
) a mohou být dále filtrovány pomocí dodatečných tagůhost
apipeline
. - Každá jednotlivá metrika (například
eps.in
) je hodnotou v tagufield
.
Tagy jsou pipeline
(ID pipeline), host
(hostname mikroslužby) a tenant
(jméno tenanta malými písmeny). Navštivte stránku Pipeline metriky pro podrobnější vysvětlení a návody pro interpretaci jednotlivých metrik.
bspump.pipeline.tenant.eps
¶
Počítací metrika s následujícími hodnotami, aktualizována jednou za minutu:
eps.in
: Počet událostí za sekundu vstupujících do pipeline pro tenanta.eps.aggr
: Agregovaný počet událostí (hodnota je vynásobena atributemcnt
v událostech) za sekundu vstupujících do pipeline pro tenanta.eps.drop
: Počet událostí za sekundu v pipeline pro tenanta, které byly zahozeny.eps.out
: Počet událostí za sekundu úspěšně opouštějících pipeline pro tenanta.warning
: Počet varování za definovaný časový interval v pipeline pro tenanta.error
: Počet chyb za definovaný časový interval v pipeline pro tenanta.
V LogMan.io Parseru pocházejí nejrelevantnější metriky z ParsersPipeline
(když data poprvé vstoupí do Parseru a jsou zpracována přes preprocessory a parsery) a EnrichersPipeline
. V LogMan.io Dispatcheru pocházejí nejrelevantnější metriky z EventsPipeline
a OthersPipeline
.
bspump.pipeline.tenant.load
¶
Počítací metrika s následujícími hodnotami, aktualizována jednou za minutu:
load.in
: Velikost v bytech všech událostí vstupujících do pipeline pro tenanta za definovaný časový interval.load.out
: Velikost v bytech všech událostí opouštějících pipeline pro tenanta za definovaný časový interval.
Korrelátorové metriky¶
Následující metriky jsou specifické pro LogMan.io Korrelátor. Detekce (známé také jako korelační pravidla) jsou založeny na mikroslužbě Korrelátor.
Pojmenování a tagy v Grafana a InfluxDB
- Skupiny korrelátorových metrik jsou pod tagem
measurement
. - Korrelátorové metriky jsou produkovány pouze pro mikroslužbu Korrelátor (tag
appclass
) a mohou být dále filtrovány pomocí dodatečných tagůcorrelator
pro izolaci jednoho korrelátoru ahost
. - Každá jednotlivá metrika (například
in
) je hodnota v tagufield
.
correlator.predicate
¶
Počítadlo, které počítá, kolik událostí prošlo sekcí predicate
nebo filtrem detekce. Každá metrika se aktualizuje jednou za minutu, takže časový interval odkazuje na období přibližně jedné minuty.
in
: Počet událostí vstupujících do predicate v časovém intervalu.hit
: Počet událostí úspěšně odpovídajících predicate (splňující podmínky filtru) v časovém intervalu.miss
: Počet událostí neprocházejících predicate v časovém intervalu (nesplňující podmínky filtru) a tudíž opouštějících Korrelátor.error
: Počet chyb v predicate v časovém intervalu.
correlator.trigger
¶
Počítadlo, které počítá, kolik událostí prošlo sekcí trigger
korrelátoru. Trigger definuje a vykonává akci. Každá metrika se aktualizuje jednou za minutu, takže časový interval odkazuje na období přibližně jedné minuty.
in
: Počet událostí vstupujících do triggeru v časovém intervalu.out
: Počet událostí opouštějících trigger v časovém intervalu.error
: Počet chyb v triggeru v časovém intervalu, měl by být rovenin
mínusout
.
Continuity plan
za minutu. InfluxDB se používá k ukládání telemetrických dat. Grafana se používá jako webové uživatelské rozhraní pro inspekci telemetrie.
-
Alertování a notifikace: Monitorovací systém je nakonfigurován tak, aby generoval upozornění a notifikace v případě potenciálních selhání, jako je nízký prostor na disku, vysoké využití zdrojů nebo zvýšené chybovosti.
-
Monitorovací panely: Monitorovací panely jsou poskytovány v Grafaně, které zobrazují nejdůležitější metriky pro systém, jako je využití zdrojů, chybovost a doby odezvy.
-
Konfigurace monitorování: Pravidelně se provádějí revize a aktualizace konfigurace monitorování, aby se zajistilo, že je efektivní a odráží změny v systému.
-
Školení v monitorování: Školení jsou poskytována pro monitorovací tým a další relevantní strany o monitorovacím systému a monitorovacích panelech v Grafaně.
Architektura vysoké dostupnosti¶
TeskaLabs LogMan.io je nasazen v architektuře s vysokou dostupností (HA) s více uzly, aby se snížilo riziko jednotlivých bodů selhání.
Architektura vysoké dostupnosti je návrhový vzor, který má za cíl zajistit, aby systém zůstal funkční a dostupný, i v případě selhání nebo narušení.
V clusteru LogMan.io zahrnuje architektura vysoké dostupnosti následující komponenty:
-
Vyvažování zátěže: Distribuce příchozího provozu mezi více instancemi mikroservisů, čímž se zlepšuje odolnost systému a snižuje dopad selhání.
-
Redundantní úložiště: Ukládání dat redundatně napříč více úložnými uzly, aby se předešlo ztrátě dat v případě selhání úložiště.
-
Více brokerů: Použití více brokerů v Apache Kafka pro zlepšení odolnosti messaging systému a snížení dopadu selhání brokerů.
-
Automatické přepnutí: Automatické přepínací mechanismy, jako je volba vůdce v Apache Kafka, aby se zajistilo, že systém pokračuje v činnosti v případě selhání uzlu clusteru.
-
Monitorování a alertování: Použití monitorovacích a alertovacích komponentů k detekci potenciálních selhání a spuštění automatických přepínacích mechanismů, když je to nutné.
-
Postupné aktualizace: Aktualizace systému bez narušení jeho normálního provozu, tím, že se uzly aktualizují jeden po druhém, bez výpadku.
-
Replikace dat: Replikace logů napříč více uzly clusteru, aby se zajistilo, že systém pokračuje v činnosti, i když jeden nebo více uzlů selže.
Komunikační plán¶
Jasný a dobře komunikovaný plán pro reakci na selhání a komunikaci se zainteresovanými stranami pomáhá minimalizovat dopad selhání a zajistit, že všichni jsou na stejné vlně.
-
Identifikace zainteresovaných stran: Identifikujte všechny zainteresované strany, které je třeba informovat během a po katastrofě, jako jsou zaměstnanci, zákazníci, dodavatelé a partneři.
-
Účastnící organizace: Operátor LogMan.io, integrační strana a dodavatel (TeskaLabs).
-
Komunikační kanály: Komunikační kanály, které budou použity během a po katastrofě, jsou Slack, e-mail, telefon a SMS.
-
Plán eskalace: Specifikujte plán eskalace, aby se zajistilo, že správní lidé budou informováni ve správný čas během katastrofy a že komunikace je koordinována a efektivní.
-
Aktualizace a údržba: Pravidelně aktualizujte a udržujte komunikační plán, aby odrážel změny v organizaci, jako jsou nové zainteresované strany nebo komunikační kanály.
Reference
TeskaLabs LogMan.io Referenční příručka¶
Vítejte v Referenční příručce. Zde naleznete definice a detaily o každé komponentě LogMan.io.
Kolektor
LogMan.io Kolektor¶
TeskaLabs LogMan.io Kolektor je mikroslužba odpovědná za sběr logů a dalších událostí z různých vstupů a jejich odesílání do LogMan.io Receiver.
- Pro nastavení sběru událostí z různých zdrojů logů, viz podtéma Log zdroje.
- Pro popis konfigurace, viz Konfigurace pro pokyny k nastavení.
- Pro podrobné možnosti konfigurace, viz Inputs, Transformace a Outputs.
- Pro vytvoření simulátoru logů, viz Mirage.
- Pro detaily komunikace mezi Kolektorem a Receiver, viz dokumentace LogMan.io Receiver.
Zdroje logů
Shromažďování protokolů ze Syslog¶
Pro shromažďování protokolů z různých Syslog zdrojů poskytuje TeskaLabs LogMan.io Collector možnost nastavit TCP a/nebo UDP příjmový port, který vyhovuje široké škále Syslog protokolů. Můžete jednoduše nakonfigurovat zdroj protokolů (například Linux server nebo síťové zařízení), aby posílal protokoly do kolektoru, obvykle na port 514 (TCP a/nebo UDP) a TeskaLabs LogMan.io Collector tyto protokoly zpracuje.
Tip
Syslog protokol obvykle používá port 514, TCP nebo UDP, ale TeskaLabs LogMan.io Collector může být nakonfigurován také pro použití jiných portů.
Aby bylo možné tuto funkci využít, nakonfigurujte své zdroje protokolů tak, aby přeposílaly protokoly na port 514. TeskaLabs LogMan.io Collector automaticky detekuje původ příchozích dat a podle toho je kategorizuje do proudů (event lanes).
Chytrá klasifikace¶
TeskaLabs LogMan.io Collector klasifikuje příchozí protokoly pomocí chytré funkce. To umožňuje pohodlnou možnost nakonfigurovat všechny zdroje protokolů tak, aby posílaly protokoly na IP adresu TeskaLabs LogMan.io Collector a na konkrétní port, včetně velmi jednoduché konfigurace síťové cesty.
TeskaLabs LogMan.io Collector používá klasifikační mapu ve své YAML konfiguraci.
Konfigurace¶
Tento příklad ukazuje konfiguraci TeskaLabs LogMan.io Collector pro použití Syslog a chytrou klasifikaci příchozích protokolů na portu 514 UDP a TCP.
Název proudu je důležitý
Název proudu uvedený v konfiguraci LogMan.io Collector je důležitý. LogMan.io vybírá správná pravidla pro analýzu, obsah a další komponenty související se zdrojem protokolů na základě názvu proudu. Přečtěte si více o názvech proudů zde.
Zde je příklad minimální konfigurace, ve které budou všechny příchozí protokoly odeslány do proudu generic
.
classification:
smart514: &smart514 # YAML ukotvení odkazující na vstupy SmartDatagram a SmartStream
# Všechny události jsou odeslány do proudu 'generic'
generic:
- ip: "*"
# Poslouchá na UDP 514
input:SmartDatagram:UDP514:
address: 514
smart: *smart514
output: smart
# Poslouchá na TCP 514
input:SmartStream:TCP514:
address: 514
smart: *smart514
output: smart
# Připojení k LogMan.io
output:CommLink:smart: {}
Zde je příklad konfigurace se čtyřmi proudy linux-syslog-rfc5424-1
, fortinet-fortigate-1
, fortinet-fortigate-2
a linux-rsyslog-1
s různými možnostmi, jak můžete klasifikovat příchozí IP adresy, porty a protokoly.
classification:
smart514: &smart514 # YAML ukotvení odkazující na vstupy SmartDatagram a SmartStream
linux-syslog-rfc5424-1: # název proudu
- ip: "192.168.0.1" # Jedna IPv4 adresa
port: 80 # Jediný port
protocol: TCP # TCP protokol
- ip: "2001:db8::1" # Jedna IPv6 adresa
port: "1000-2000" # Rozsah portů
protocol: UDP # UDP protokol
fortinet-fortigate-1:
- ip: "10.0.0.0/8" # IPv4 rozsah
port: 14000
protocol: UDP
- ip: "fd00::/8" # IPv6 rozsah
port: "*" # Libovolný port
protocol: UDP
fortinet-fortigate-2:
- ip: "*" # Libovolná IP adresa
port: "*" # Libovolný port
protocol: UDP
linux-rsyslog-1:
- ip: "::1" # Lokální IP adresy
# Poslouchá na UDP 514
input:SmartDatagram:UDP514:
address: 514
smart: *smart514
output: smart
# Poslouchá na TCP 514
input:SmartStream:TCP514:
address: 514
smart: *smart514
output: smart
# Protokoly jsou přeposílány do LogMan.io pomocí CommLink
output:CommLink:smart: {}
Warning
Chytrá klasifikace funguje pouze s výstupem CommLink.
SmartDatagram a SmartStream¶
SmartDatagram
(pro UDP) a SmartStream
(pro TCP) zdroje jsou podobné jako Datagram
/TCP
a Stream
/UDP
zdroje, s další možností smart
, která odkazuje na příslušnou podsekci v classification
.
# Poslouchá na UDP 514
input:SmartDatagram:UDP514:
address: 514
smart: *smart514
output: smart
# Poslouchá na TCP 514
input:SmartStream:TCP514:
address: 514
smart: *smart514
output: smart
Warning
Sekce classification
musí být specifikována PŘED sekcemi input:...
, jinak není odkaz *smart514
rozpoznán.
Klasifikační mapa¶
Sekce classification
může obsahovat jeden nebo více klasifikátorů.
Každý klasifikátor specifikuje kombinaci rozsahů IP adres, rozsahů portů a protokolů; a převádí je do proudu. Každý protokol, který dorazí do TeskaLabs LogMan.io Collector chytrého syslogu, je porovnán s těmito klasifikátory a výsledný proud je použit jako jeho cíl v LogMan.io. Pokud není nalezen žádný shodný, protokol jde do generic stream (pojmenovaného generic
).
Tip
Proud lze nalézt v komponentě Archiv TeskaLabs LogMan.io.
linux-syslog-rfc5424-1:
- ip: "192.168.0.1"
port: 80
protocol: TCP
- ip: "2001:db8::1"
port: "1000-2000"
protocol: UDP
linux-syslog-rfc5424-1
je název proudu.
ip¶
- Jedna IPv4/IPv6 adresa:
92.168.0.1
,2001:db8::1
- Rozsah IPv4/IPv6 adres:
10.0.0.0/8
,fd00::/8
- Zástupný znak
*
pro všechny IPv4/IPv6 adresy
port¶
- Jediný port:
5400
- Rozsah portů:
4000-8000
- Pokud není specifikováno nebo
*
, používá se rozsah0-65535
protokol¶
TCP
/UDP
- Pokud není specifikováno, používají se oba TCP a UDP
*
zástupný znak může být příliš široký
Ujistěte se, že zástupný znak *
je obalen uvozovkami v YAML "*"
. Hvězdička bez uvozovek by porušila syntaxi YAML.
Překrývající se IP adresy a porty¶
IP adresy a porty se mohou překrývat. V takovém případě je vybrán nejkonkrétnější shodný. V následujícím příkladu je 25400
shodný s fortinet-fortigate-3
, 25100
s fortinet-fortigate-2
a 24000
s fortinet-fortigate-1
:
fortinet-fortigate-1:
- ip: "192.168.0.1"
port: 24000-30000
fortinet-fortigate-2:
- ip: "192.168.0.1"
port: 25000-26000
fortinet-fortigate-3:
- ip: "192.168.0.1"
port: 25400
Totéž platí pro IP adresy.
Generic stream¶
Pokud není během klasifikace identifikován cílový proud, je protokol přeposlán do proudu generic
.
Příklad klasifikace proudu
Představte si, že připojujete nové zdroje protokolů z rozsahu IP adres 192.168.0.0/24
.
Bez klasifikátoru jsou události shromažďovány do proudu generic
a uloženy v Archivu.
Po prozkoumání proudů v Archivu zjistíte, že existuje zdroj typu logsox
.
Klasifikujete proud, abyste ho oddělili od ostatních příchozích dat:
logsox-1:
- ip: "192.168.0.0/24"
Při vytváření pravidel pro analýzu pro proud zjistíte, že příchozí události logsox
z IP 192.168.0.68
mají jinou formu než ostatní.
Můžete tento proud izolovat a aplikovat na něj různá pravidla analýzy:
logsox-1:
- ip: "192.168.0.0/24"
logsox-2:
- ip: "192.168.0.68"
Názvy proudů¶
Výběr správného názvu proudu je důležitý, protože TeskaLabs LogMan.io určuje technologii, vybírá správná pravidla analýzy, dashboardy a další obsah na základě názvu proudu.
Aby bylo možné připojit zdroj protokolů, který existuje v Knihovně, a automaticky přiřadit správnou event lane, musí název proudu odpovídat jednomu z šablon event lane umístěných ve složce /Templates/EventLanes/
v Knihovně.
Níže je tabulka, která uvádí názvy proudů používané různými technologiemi při připojení k LogMan.io Collector. Nahraďte hvězdičku "*" na konci názvu proudu libovolným číslem. Například můžete použít čítač (fortinet-fortigate-1
, fortinet-fortigate-2
, linux-rsyslog-1
, ...) nebo číslo portu (fortinet-fortigate-10000
, fortinet-fortigate-20000
, linux-rsyslog-30000
, ...).
Název technologie | Název proudu |
---|---|
Bitdefender GravityZone | bitdefender-gravityzone-* |
Broadcom Brocade Switch | broadcom-brocade-switch-* |
Cisco ASA | cisco-asa-* |
Cisco FTD | cisco-ftd-* |
Cisco iOS | cisco-ios-* |
Cisco ISE | cisco-ise-* |
Cisco Switch Nexus | cisco-switch-nexus-* |
Cisco WLC | cisco-wlc-* |
Dell iDRAC | dell-idrac-* |
Dell PowerVault | dell-powervault-* |
Dell Switch | dell-switch-* |
Devolutions Web Server | devolutions-web-server-* |
EATON UPS | eaton-ups-* |
ESET Protect | eset-protect-* |
F5 | f5-* |
FileZilla | filezilla-* |
Fortinet FortiClient | fortinet-forticlient-* |
Fortinet FortiGate | fortinet-fortigate-* |
Fortinet FortiMail | fortinet-fortimail-* |
Fortinet FortiSwitch | fortinet-fortiswitch-* |
Gordic Ginis | gordic-ginis-* |
Helios | helios-* |
HPE Aruba ClearPass | hpe-aruba-clearpass-* |
HPE Aruba IAP | hpe-aruba-iap-* |
HPE Aruba IAP | hpe-aruba-switch-* |
HPE iLO | hpe-ilo-* |
HPE LaserJet Series | hpe-laserjet-* |
HPE Primera | hpe-primera-* |
HPE StoreOnce | hpe-storeonce-* |
IBM QRAD | ibm-qrad-* |
IceWarp | icewarp-mailserver-* |
Kubernetes | kubernetes-* |
Linux Auditd | linux-auditd-* |
Linux Rsyslog | linux-rsyslog-* |
Linux Syslog RFC 3164 | linux-syslog-rfc3164-* |
Linux Syslog RFC 5424 | linux-syslog-rfc5424-* |
McAfee Webwasher | mcafee-webwasher-* |
MikroTik | mikrotik-* |
Minolta Bizhub | minolta-bizhub-* |
Nginx | nginx-* |
Ntopng | ntopng-* |
OpenVPN | openvpn-* |
Oracle Cloud | oracle-cloud-* |
Oracle Listener | oracle-listener-* |
Oracle Spark | oracle-spark-* |
PfSense | pfsense-* |
SentinelONE | sentinelone-* |
Sophos Device Standard Format | sophos-device-standard-format-* |
Sophos Standard Syslog Protocol | sophos-standard-syslog-protocol-* |
Sophos Unstructured Format | sophos-unstructured-* |
Squid Proxy | squid-proxy-* |
Synology NAS | synology-nas-* |
Ubiquiti UniFi | ubiquiti-unifi-* |
Veeam Backup & Replication | veeam-backup-replication-* |
VMware Cloud Director | vmware-cloud-director-* |
VMware ESXi | vmware-esxi-* |
VMware vCenter | vmware-vcenter-* |
ySoft SafeQ | ysoft-safeq-* |
ZyXEL Switch | zyxel-switch-* |
Example
Příklad konfigurace tří zdrojů protokolů připojených přes TCP/UDP:
- Dva zdroje Fortinet FortiGate na portech 10000 a 20000
- Jeden zdroj Linux Rsyslog na portu 30000
# Fortinet FortiGate na portu 10000
input:TCP:fortinet-fortigate-1:
address: 10000
output: fortinet-fortigate-1
output:CommLink:fortinet-fortigate-1: {}
# Fortinet FortiGate na portu 20000
input:TCP:fortinet-fortigate-2:
address: 20000
output: fortinet-fortigate-2
output:CommLink:fortinet-fortigate-2: {}
# Linux Rsyslog na portu 30000
input:TCP:linux-rsyslog-1:
address: 30000
output: linux-rsyslog-1
output:CommLink:linux-rsyslog-1: {}
Microsoft Windows
Sběr logů z Microsoft Windows¶
Existuje několik způsobů, jak sbírat logy nebo Windows Events z Microsoft Windows.
Window Event Collector (WEC/WEF)¶
Bezagenta Window Event Collector (WEC) zasílá logy z Windows počítačů prostřednictvím Windows Event Forwarding (WEF) služby do TeskaLabs LogMan.io Collector. TeskaLabs LogMan.io Collector pak funguje jako Window Event Collector (WEC). Konfigurace WEF může být nasazena pomocí Group Policy, buď centrálně spravovanou serverem Active Directory nebo pomocí Local Group Policy. S Active Directory na místě nejsou vyžadovány žádné další konfigurační požadavky na jednotlivých Windows strojích.
Tip
Tento způsob sběru Windows Events doporučujeme.
Windows Remote Management¶
Bezagenta dálkové ovládání se připojuje k požadovanému Windows počítači přes Windows Remote Management (také známý jako WinRM) a spustí příkaz pro sběr, který tam běží jako samostatný proces a sbírá jeho standardní výstup.
Pokračovat na nastavení WinRM.
Agent na Windows počítači¶
V tomto způsobu běží TeskaLabs LogMan.io Collector jako agent na požadovaném Windows počítači(ích) a sbírá Windows Events.
Sběr z Microsoft Windows pomocí WEC/WEF¶
Bezagentový Windows Event Collector (WEC) odesílá logy z Windows počítačů přes službu Windows Event Forwarding (WEF) do TeskaLabs LogMan.io Collector. TeskaLabs LogMan.io Collector poté funguje jako Windows Event Collector (WEC). Konfiguraci WEF lze nasadit pomocí Group Policy, buď centrálně spravovanou serverem Active Directory nebo pomocí Local Group Policy. S Active Directory nejsou na jednotlivých Windows strojích potřeba žádné další konfigurační požadavky.
Schéma: Tok událostí sběru WEC/WEF v TeskaLabs LogMan.io.
Předpoklady¶
- Microsoft Active Directory Domain Controller, v tomto příkladu poskytuje doménové jméno
domain.int
/DOMAIN.int
- TeskaLabs LogMan.io Collector, v tomto příkladu s IP adresou
10.0.2.101
a hostitelským jménemlmio-collector
, běží ve stejné síti jako Windows počítače včetně Active Directory - IP adresa TeskaLabs LogMan.io Collector MUSÍ být fixní (tj. rezervovaná DHCP serverem)
- Datum a čas TeskaLabs LogMan.io Collector MUSÍ být synchronizovány pomocí NTP
- TeskaLabs LogMan.io Collector BY MĚL používat DNS server Active Directory
- TeskaLabs LogMan.io Collector MUSÍ být schopen vyřešit hostitelská jména serverů doménových kontrolerů Active Directory
- TeskaLabs LogMan.io Collector MUSÍ být schopen dosáhnout na
udp/88
atcp/88
porty (autentizace Kerberos verze 5) na Microsoft Active Directory Domain Controller, příslušný KDC - Všechny Windows stanice a servery MUSÍ být schopny dosáhnout na
tcp/5985
atcp/5986
pro WEF audp/88
,tcp/88
(autentizace Kerberos) porty
Tip
Toto nastavení využívá autentizaci Kerberos. Autentizace Kerberos používá Kerberos tickety specifické pro doménu Active Directory vydávané doménovým kontrolerem pro autentizaci a šifrování přeposílání logů. Je to optimální volba pro Windows počítače, které jsou spravovány prostřednictvím domény.
Active Directory¶
1.1. Vytvoření nového uživatele v Active Directory
Projděte Windows Administrative Tools > Active Directory Users and Computers > DOMAIN.int
> Users
Klikněte pravým tlačítkem a vyberte New > User
Zadejte následující informace:
- Full name:
TeskaLabs LogMan.io
- User logon name:
lmio-collector
Warning
Přihlašovací jméno uživatele musí být stejné jako jméno počítače TeskaLabs LogMan.io Collector. Najdete ho na obrazovce nastavení TeskaLabs LogMan.io collector.
Klikněte na "Next".
Nastavte heslo pro uživatele.
Tento příklad používá Password01!
.
Warning
Použijte silné heslo podle vaší politiky. Toto heslo bude použito v pozdějším kroku tohoto postupu.
Odškrtněte "User must change password at next logon".
Zaškrtněte "Password never expires".
Klikněte na Next a poté na tlačítko Finish pro vytvoření uživatele.
Nakonec klikněte pravým tlačítkem na nového uživatele, klikněte na Properties a otevřete záložku Account.
- Zaškrtněte "This account supports Kerberos AES 128 bit encryption".
- Zaškrtněte "This account supports Kerberos AES 256 bit encryption".
Nový uživatel lmio-collector
je nyní připraven.
1.2. Vytvoření A záznamu v DNS serveru pro TeskaLabs LogMan.io Collector
Použití DHCP pro rezervaci IP adresy sběrače
Pevná IP adresa MUSÍ být přidělena TeskaLabs LogMan.io Collector. To může být provedeno "rezervováním" IP adresy v DHCP serveru Active Directory.
Projděte Windows Administrative Tools > DNS > Forward Lookup Zones > DOMAIN.int
Klikněte pravým tlačítkem a vyberte "New Host (A or AAAA)…"
Přidejte záznam s názvem lmio-collector
a IP adresou 10.0.2.101
.
Upravte tento záznam podle IP adresy vašeho TeskaLabs LogMan.io Collector.
Klikněte na tlačítko Add Host pro dokončení.
1.3. Vytvoření hostitelského principálu
Vytvořte hostitelský principál a přidružený keytab soubor pro hostitele TeskaLabs LogMan.io Collector. Spusťte následující příkaz na příkazovém řádku serveru Active Directory Domain Controller (cmd.exe
):
ktpass /princ host/lmio-collector.domain.int@DOMAIN.INT /pass Password01! /mapuser DOMAIN\lmio-collector -pType KRB5_NT_PRINCIPAL /out host-lmio-collector.keytab /crypto AES256-SHA1
Proces je citlivý na velikost písmen
Ujistěte se, že jste KAPITALIZOVALI vše, co je kapitalizováno v našich příkladech (například host/lmio-collector.domain.int@DOMAIN.INT
).
Musí být KAPITALIZOVÁNO i v případě, že vaše doména obsahuje malá písmena.
Keytab soubor host-lmio-collector.keytab
je vytvořen.
1.4. Vytvoření http principálu
Vytvořte servisní principál a přidružený keytab soubor pro službu:
ktpass /princ http/lmio-collector.domain.int@DOMAIN.INT /pass Password01! /mapuser DOMAIN\lmio-collector -pType KRB5_NT_PRINCIPAL /out http-lmio-collector.keytab /crypto AES256-SHA1
Keytab soubor http-lmio-collector.keytab
je vytvořen.
1.5. Sběr keytab souborů ze serveru Windows
Sesbírejte dva keytab soubory z výše uvedených kroků. Nahrajete je do TeskaLabs LogMan.io v pozdějším kroku.
Skupinové politiky¶
2.1. Otevřete konzoli pro správu skupinových politik
Projděte Windows Administrative Tools > Group Policy Management, vyberte svou doménu, v tomto příkladu DOMAIN.int
.
2.2. Vytvoření objektu skupinové politiky
V konzoli správy skupinových politik vyberte svou doménu, například DOMAIN.int
.
Klikněte pravým tlačítkem na doménu a vyberte "Create a GPO in this domain, and Link it here....
Zadejte název nového GPO, "TeskaLabs LogMan.io Windows Event Forwarding", poté vyberte OK.
2.3. Konfigurace objektu skupinové politiky
Nové GPO je vytvořeno a připojeno k vaší doméně. Pro konfiguraci nastavení politiky klikněte pravým tlačítkem na vytvořené GPO a vyberte "Edit...".
Otevře se "Group Policy Management Editor" pro přizpůsobení GPO.
2.4. Konfigurace politiky přeposílání událostí v sekci Konfigurace počítače
V "Group Policy Management Editor" projděte Computer Configuration > Policies > Administative Templates > Windows Components a vyberte Event Forwarding.
Vyberte "Configure target Subscription Manager".
Povolte nastavení a vyberte Show.
Vyplňte umístění TeskaLabs LogMan.io Collector:
Server=http://lmio-collector.domain.int:5985/wsman/SubscriptionManager/WEC,Refresh=60
Stiskněte OK pro uložení nastavení.
2.5. Použití
Spusťte gpupdate /force
v cmd.exe
na serveru Windows.
Bezpečnostní log¶
WEF nemůže přistupovat k bezpečnostnímu logu Windows ve výchozím nastavení.
Pro povolení přeposílání bezpečnostního logu přidejte Network Service
do WEF.
Tip
Bezpečnostní log Windows je nejdůležitějším zdrojem informací o kybernetické bezpečnosti a musí být nakonfigurován.
3.1. Otevřete konzoli pro správu skupinových politik
Projděte Windows Administrative Tools > Group Policy Management, vyberte svou doménu, v tomto příkladu DOMAIN.int
.
Klikněte pravým tlačítkem a vyberte "Edit...".
Projděte Computer Configuration > Administrative Templates > Windows Components > a vyberte Event Log Service.
Potom vyberte Security.
Vyberte Configure log access.
3.2. Nastavení přístupu k logu
Do pole "Log Access" zadejte:
O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)
Vysvětlení
- O:BA: Určuje, že vlastníkem objektu je Built-in Administrators group.
- G:SY: Určuje, že primární skupina je SYSTEM.
-
D:: Označuje, že následující část definuje Discretionary Access Control List (DACL).
-
Built-in Administrators (BA): Oprávnění pro čtení a zápis.
- SYSTEM (SY): Plná kontrola s oprávněními pro čtení a zápis a speciální oprávnění pro správu logů událostí.
- Builtin\Event Log Readers (S-1-5-32-573): Oprávnění pouze pro čtení.
- Network Service (S-1-5-20): Oprávnění pouze pro čtení.
Stiskněte OK.
3.3. Použití
Spusťte gpupdate /force
v cmd.exe
na serveru Windows.
Odstraňování problémů
Uživatel Network Service musí být součástí skupiny Event Log Readers, aby měl přístup k bezpečnostním logům.
Postupujte podle těchto kroků pro konfiguraci přístupu:
-
Otevřete příkazový řádek RUN pomocí Windows Key + R
-
Zadejte pro otevření Místního správce uživatelů: lusrmgr.msc (pro edici Windows Home použijte gpedit.msc)
-
Otevřete: Skupiny
-
Vyberte: Event Log Readers
-
Přidejte uživatele NT AUTHORITY\NETWORK SERVICE
- Klikněte na "Add"
- Zadejte přesný název: NT AUTHORITY\NETWORK SERVICE
- Klikněte na "Check Names" pro ověření
-
Pro autentizaci Kerberos:
- Přidejte doménový servisní účet (např.
DOMAIN\lmio-collector
) - Pouze pokud používáte doménovou autentizaci
- Přidejte doménový servisní účet (např.
-
Klikněte na OK pro uložení změn
-
Otevřete příkazový řádek (
cmd.exe
) jako správce -
Restartujte službu WinRM:
net stop winrm timeout /t 5 net start winrm
Poznámka: Tato konfigurace musí být aplikována na všech počítačích odesílajících bezpečnostní logy. Pro podnikové prostředí použijte nasazení pomocí skupinové politiky místo ruční konfigurace.
TeskaLabs LogMan.io¶
4.1. Konfigurace sběru Microsoft událostí
V TeskaLabs Logman.io, projděte na Collectors > Váš Collector > Microsoft Windows.
Vyplňte Realm a FQDN doménového kontroleru, přidejte keytab soubory pro host a http a stiskněte Apply.
4.2. Sběr logů je nakonfigurován
Pokročilá témata¶
Alternativy¶
- Použití SSL certifikátů místo Active Directory a Kerberos
- Použití local group policy místo Group Policy Active Directory
Přeposílání Event Log¶
Kanál událostí Eventlog-forwardingPlugin/Operational
zaznamenává relevantní informace o strojích, které jsou nastaveny k přeposílání logů do sběrače.
Zahrnuje také informace o možných problémech se subscribemi WEF.
Použijte aplikaci Event Viewer pro zkoumání.
Ruční konfigurace¶
Sběr z Microsoft Windows pomocí Windows Remote Management¶
Ovládání bez agentů se připojí k požadovanému počítači se systémem Windows přes Windows Remote Management (známé také jako WinRM) a spustí příkaz pro sběr dat tam jako samostatný proces, aby se získal jeho standardní výstup.
Specifikace vstupu: input:WinRM:
Vstup WinRM se připojí ke vzdálenému serveru Windows, kde zavolá specifikovaný příkaz.
Poté periodicky kontroluje nový výstup na stdout
a stderr
, takže se chová podobně jako input:SubProcess
.
Konfigurační možnosti LogMan.io Collector WinRM¶
endpoint: # URL koncového bodu API správy Windows vzdáleného počítače se systémem Windows (např. http://MyMachine:5985/wsman)
transport: ntlm # Typ autentizace
server_cert_validation: # Specifikujte ověření certifikátu (výchozí: ignore)
cert_pem: # (volitelné) Uveďte cestu k certifikátu (při použití HTTPS)
cert_key_pem: # (volitelné) Uveďte cestu k soukromému klíči
username: # (volitelné) Při použití autentizace uživatelského jména (např. přes ntlm), specifikujte uživatelské jméno ve formátu <DOMAIN>\<USER>
password: # Heslo výše autentizovaného uživatele
output: # Do kterého výstupu poslat příchozí události
Následující konfigurace objasňuje příkaz, který by měl být vzdáleně volán:
# Přečtěte 1000 systémových logů jednou za 2 sekundy
command: # Specifikujte příkaz, který by měl být vzdáleně volán (např. wevtutil qe system /c:1000 /rd:true)
chilldown_period: # Jak často v sekundách by měl být vzdálený příkaz volán, pokud skončí (výchozí: 5)
duplicity_check: # Specifikujte, zda kontrolovat duplicity na základě času (true/false)
duplicity_reverse_order: # Specifikujte, zda kontrolovat duplicity v obráceném pořadí (např. logy 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)
Sběr pomocí agenta na Windows stroji¶
TeskaLabs LogMan.io Collector běží jako agent na požadovaném Windows stroji a sbírá Windows Události.
Specifikace vstupu: input:WinEvent
Poznámka: input:WinEvent
funguje pouze na strojích založených na Windows.
Tento vstup periodicky čte Windows Události z určeného typu událostí.
Konfigurační volby LogMan.io Collector WinEvent¶
server: # (volitelné) Určete zdroj událostí (výchozí: localhost, tj. celý lokální stroj)
event_type: # (volitelné) Určete typ události, která bude čtena (výchozí: System)
buffer_size: # (volitelné) Určete, kolik událostí by mělo být přečteno v jednom dotazu (výchozí: 1024)
event_block_size: # (volitelné) Určete množství událostí, po kterém bude provedena nečinnost pro provedení dalších operací (výchozí: 100)
event_idle_time: # (volitelné) Určete dobu nečinnosti v sekundách uvedenou výše (výchozí: 0.01)
last_value_storage: # Trvalé úložiště pro aktuální poslední hodnotu (výchozí: ./var/last_value_storage)
output: # Kam mají být odeslány příchozí události
Typ události lze určit pro každý Log událostí Windows, včetně:
Application
pro logy aplikaceSystem
pro systémové logySecurity
pro bezpečnostní logy atd.
Sbírání logů z Microsoft 365¶
TeskaLabs LogMan.io může sbírat logy z Microsoft 365, dříve známého jako Microsoft Office 365.
Existují následující třídy logů Microsoft 365:
-
Audit logy: Obsahují informace o různých uživatelských, administrátorských, systémových a politikových akcích a událostech z Azure Active Directory, Exchange a SharePoint.
-
Message Trace: Umožňuje získat přehled o e-mailovém provozu procházejícím přes Microsoft Office 365 Exchange mail server.
Aktivace auditu Microsoft 365¶
Ve výchozím nastavení je auditní logování aktivováno pro podnikovou organizaci Microsoft 365 a Office 365. Při nastavování logování pro organizaci Microsoft 365 nebo Office 365 byste však měli ověřit stav auditu Office 365.
1) Přejděte na https://compliance.microsoft.com/ a přihlaste se
2) V levém navigačním panelu Microsoft 365 compliance centra klikněte na Audit
3) Klikněte na banner Spustit záznam uživatelské a administrátorské aktivity
Změna může trvat až 60 minut, než se projeví.
Pro více informací, viz Zapnout nebo vypnout audit.
Konfigurace Microsoft 365¶
Než budete moci sbírat logy z Microsoft 365, musíte konfigurovat Microsoft 365. Uvědomte si, že konfigurace zabere značné množství času.
1) Nastavte si předplatné na Microsoft 365 a předplatné na Azure
Potřebujete předplatné na Microsoft 365 a předplatné na Azure, které je přidruženo k vašemu předplatnému na Microsoft 365.
Můžete využít zkušební předplatné na obojí, Microsoft 365 a Azure, pro začátek.
Pro více informací, viz Vítejte v Office 365 Developer Program.
2) Zaregistrujte TeskaLabs LogMan.io collector v Azure AD
To vám umožní vytvořit identitu pro TeskaLabs LogMan.io a přiřadit specifická oprávnění, která potřebuje pro sbírání logů z Microsoft 365 API.
Přihlaste se do Azure portálu pomocí přihlašovacích údajů z vašeho předplatného na Microsoft 365, které chcete použít.
3) Navigujte do Azure Active Directory
4) Na stránce Azure Active Directory vyberte "App registrations" (1) a poté "New registration" (2)
5) Vyplňte registrační formulář pro TeskaLabs LogMan.io aplikaci
- Název: "TeskaLabs LogMan.io"
- Podporované typy účtů: "Účet v tomto organizačním adresáři"
- URL přesměrování: Žádné
Stiskněte "Register" pro dokončení procesu.
6) Sbírejte důležité informace
Uložte následující informace ze stránky registrované aplikace v Azure portálu:
- Application (client) ID aka
client_id
- Directory (tenant) ID aka
tenant_id
7) Vytvořte klientské tajemství
Client secret se používá pro bezpečné autorizování a přístup TeskaLabs LogMan.io.
Po zobrazení stránky vaší aplikace, vyberte v levém panelu záložku Certifikáty & tajemství (1). Pak vyberte záložku "Client secrets" (2). Na této záložce vytvořte nové klientské tajemství (3).
8) Vyplňte informace o novém klientském tajemství
- Popis: "TeskaLabs LogMan.io Client Secret"
- Vyprší: 24 měsíců
Stiskněte "Add" pro pokračování.
9) Klikněte na ikonu se schránkou, aby se hodnota klientského tajemství zkopírovala do schránky
Uložte Value (ne Secret ID) pro konfiguraci TeskaLabs LogMan.io, bude použito jako client_secret
.
10) Určete oprávnění pro TeskaLabs LogMan.io, aby mohlo přistupovat k Microsoft 365 Management API
Přejděte na App registrations > All applications v Azure portálu a vyberte "TeskaLabs LogMan.io".
11) Vyberte API Permissions (1) v levém panelu a potom klikněte na Add a permission (2)
12) Na záložce Microsoft APIs vyberte Microsoft 365 Management APIs
13) Na rozbalovací stránce vyberte všechny typy oprávnění
- Delegovaná oprávnění
ActivityFeed.Read
ActivityFeed.ReadDlp
ServiceHealth.Read
- Aplikační oprávnění
ActivityFeed.Read
ActivityFeed.ReadDlp
ServiceHealth.Read
Klikněte na "Add permissions" pro dokončení.
14) Přidejte oprávnění "Microsoft Graph"
- Delegovaná oprávnění
AuditLog.Read.All
- Aplikační oprávnění
AuditLog.Read.All
Vyberte "Microsoft Graph", "Delegovaná oprávnění", najděte a vyberte "AuditLog.Read.All" v "Audit Log".
Pak znovu vyberte "Microsoft Graph", "Aplikační oprávnění", najděte a vyberte "AuditLog.Read.All" v "Audit Log".
15) Přidejte oprávnění "Office 365 Exchange online" pro sbírání Message Trace reportů
Klikněte na "Add a permission" znovu.
Pak přejděte na "APIs my organization uses".
Zadejte "Office 365 Exchange Online" do vyhledávacího pole.
Nakonec vyberte položku "Office 365 Exchange Online".
Vyberte "Aplikační oprávnění".
Zadejte "ReportingWebService" do vyhledávacího pole.
Zaškrtněte políčko "ReportingWebService.Read.All".
Nakonec klikněte na tlačítko "Add permissions".
16) Udělte souhlas admina
17) Navigujte zpět do Azure Active Directory
18) Navigujte na Role a administrátory
19) Přidělte TeskaLabs LogMan.io roli Global Reader
Zadejte "Global Reader" do vyhledávacího pole.
Pak klikněte na položku "Global Reader".
Vyberte "Add assignments".
Zadejte "TeskaLabs LogMan.io" do vyhledávacího pole. Alternativně použijte "Application (client) ID" z předchozích kroků.
Vyberte položku "TeskaLabs LogMan.io"; položka se objeví v "Selected items".
Stiskněte tlačítko "Add".
Gratulujeme! Vaše Microsoft 365 je nyní připravena pro sběr logů.
Konfigurace TeskaLabs LogMan.io¶
Příklad¶
connection:MSOffice365:MSOffice365Connection:
client_id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
tenant_id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
client_secret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# Sbírání Microsoft 365 Audit.General
input:MSOffice365:MSOffice365Source1:
connection: MSOffice365Connection
content_type: Audit.General
output: ms-office365-01
# Sbírání Microsoft 365 Audit.SharePoint
input:MSOffice365:MSOffice365Source2:
connection: MSOffice365Connection
content_type: Audit.SharePoint
output: ms-office365-01
# Sbírání Microsoft 365 Audit.Exchange
input:MSOffice365:MSOffice365Source3:
connection: MSOffice365Connection
content_type: Audit.Exchange
output: ms-office365-01
# Sbírání Microsoft 365 Audit.AzureActiveDirectory
input:MSOffice365:MSOffice365Source4:
connection: MSOffice365Connection
content_type: Audit.AzureActiveDirectory
output: ms-office365-01
# Sbírání Microsoft 365 DLP.All
input:MSOffice365:MSOffice365Source5:
connection: MSOffice365Connection
content_type: DLP.All
output: ms-office365-01
output:XXXXXX:ms-office365-01: {}
# Sbírání Microsoft 365 Message Trace logů
input:MSOffice365MessageTraceSource:MSOffice365MTSource1:
connection: MSOffice365Connection
output: ms-office365-message-trace-01
output:XXXXXX:ms-office365-message-trace-01: {}
Připojení¶
Připojení k Microsoft 365 musí být nakonfigurováno jako první v sekci connection:MSOffice365:...
.
connection:MSOffice365:MSOffice365Connection:
client_id: # Application (client) ID z Azure Portálu
tenant_id: # Directory (tenant) ID z Azure Portálu
client_secret: # Hodnota klientského tajemství z Azure Portálu
resources: # (volitelné) zdroje, ze kterých chcete získávat data, oddělené čárkou (,) (výchozí: https://manage.office.com,https://outlook.office365.com)
Danger
Pole client id
, tenant_id
a client secret
MUSÍ být zadaná pro úspěšné připojení k Microsoft 365.
Sbírání z Microsoft 365 activity logs¶
Konfigurační možnosti pro nastavení sběru Audit logů (Audit.AzureActiveDirectory
, Audit.SharePoint
, Audit.Exchange
, Audit.General
a DLP.All
):
input:MSOffice365:MSOffice365Source1:
connection: # ID MSOffice365 připojení
output: # Kam posílat příchozí události
content_type: # (volitelné, ale doporučené) Typ obsahu získávaných logů (výchozí: Audit.AzureActiveDirectory Audit.SharePoint Audit.Exchange Audit.General DLP.All)
refresh: # (volitelné) Interval obnovování v sekundách pro získání zpráv z API (výchozí: 600)
last_value_storage: # (volitelné) Perzistentní úložiště pro aktuální poslední hodnotu (výchozí: ./var/last_value_storage)
Sbírání z Microsoft 365 Message Trace¶
Konfigurační možnosti pro nastavení zdroje dat pro Microsoft 365 Message Trace:
```yaml input:MSOffice365MessageTraceSource:MSOffice365MessageTraceSource1: connection: # ID MSOffice365 připojení
Sběr událostí z Apache Kafka¶
TeskaLabs LogMan.io Collector je schopen sbírat události z Apache Kafka, konkrétně z jejích topics. Události uložené v Kafka mohou obsahovat data zakódovaná v bytech, jako jsou logy o různých uživatelských, administrativních, systémových, zařízeníových a politických akcích.
Předpoklady¶
Aby bylo možné vytvořit Kafka spotřebitele, je nutné znát bootstrap_servers
, tedy umístění Kafka uzlů, stejně jako topic
, ze kterého se budou data číst.
Konfigurace LogMan.io Collector¶
LogMan.io Collector poskytuje input:Kafka:
vstupní sekci, kterou je třeba specifikovat v YAML konfiguraci. Konfigurace vypadá následujícím způsobem:
input:Kafka:KafkaInput:
bootstrap_servers: <BOOTSTRAP_SERVERS>
topic: <TOPIC>
group_id: <GROUP_ID>
...
Tato vstupní sekce vytvoří Kafka spotřebitele pro specifické topic(y).
Konfigurační možnosti týkající se navázání spojení:
bootstrap_servers: # Kafka uzly, ze kterých se budou číst zprávy (například `kafka1:9092,kafka2:9092,kafka3:9092`)
Konfigurační možnosti týkající se nastavení Kafka Spotřebitele:
topic: # Název topiců, ze kterých se budou číst zprávy (například `lmio-events` nebo `^lmio.*`)
group_id: # Název spotřebitelské skupiny (například: `collector_kafka_consumer`)
refresh_topics: # (nepovinné) Pokud se očekává vytvoření více topiců během spotřeby, tato volba specifikuje v sekundách, jak často má proběhnout obnovení odběrů topiců (například: `300`)
Volby bootstrap_servers
, topic
a group_id
jsou vždy povinné!
topic
může být název, seznam názvů oddělených mezerami nebo jednoduchý regex (pro přizpůsobení všech dostupných topics použijte ^.*
).
Pro více konfiguračních možností prosím odkažte na librdkafka konfigurační příručku.
Shromažďování z Beats nebo Logstash¶
Konfigurace TeskaLabs LogMan.io¶
Základní konfigurační úryvek sběrače:
input:Lumberjack:logstash:
output: ...
logstash
je identifikovaný vstup a může být nahrazen čímkoli jedinečným v konfiguračním souboru.
address
specifikuje síťové rozhraní a/nebo port, který bude použit pro naslouchání.
Výchozí hodnota je '5044', pro naslouchání na tcp/5044
.
Volitelný atribut smart
může být použit k určení chytré mapy, když je připojen k output:CommLink
.
Tip
Protokol používaný pro tuto extrakci se nazývá Lumberjack a ve výchozím nastavení běží na tcp/5044
s volitelným SSL.
Třídy zdrojů logů input:Lumberjack:
, input:Logstash:
a input:Beats:
jsou ve skutečnosti synonyma.
Konfigurace SSL¶
Příchozí SSL je detekováno automaticky.
Následující konfigurační možnosti specifikují SSL připojení:
cert
: Cesta k SSL certifikátu klientakey
: Cesta k soukromému klíči SSL certifikátu klientapassword
: Heslo k souboru soukromého klíče (volitelné, výchozí: žádné)cafile
: Cesta k PEM souboru s certifikátem(y) CA pro ověření SSL serveru (volitelné, výchozí: žádné)capath
: Cesta k adresáři s certifikátem(y) CA pro ověření SSL serveru (volitelné, výchozí: žádné)cadata
: jeden nebo více PEM-encoded certifikátů CA pro ověření SSL serveru (volitelné, výchozí: žádné)ciphers
: SSL šifry (volitelné, výchozí: žádné)dh_params
: Parametry výměny klíčů Diffie–Hellman (D-H) (TLS) (volitelné, výchozí: žádné)verify_mode
: Jeden z CERT_NONE, CERT_OPTIONAL nebo CERT_REQUIRED (volitelné); pro více informací viz: github.com/TeskaLabs/asab
Konfigurace Beats¶
Tento zdroj logů může být použit k shromažďování logů pomocí rodiny nástrojů Beats. Beats jsou lehké datové přepravce od Elastic.
Podporované Beats:
Konfigurační úryvek:
output.logstash:
hosts: ["<collector>:5044"]
Příklad konfigurace winlogbeat¶
winlogbeat.yaml
:
output.logstash:
hosts: ["<collector>:5044"]
winlogbeat.event_logs:
- name: Application
ignore_older: 72h
- name: System
ignore_older: 72h
- name: Security
ignore_older: 72h
- name: Setup
ignore_older: 72h
- name: Microsoft-Windows-Sysmon/Operational
ignore_older: 72h
- name: Microsoft-Windows-Windows Defender/Operational
ignore_older: 72h
- name: Microsoft-Windows-GroupPolicy/Operational
ignore_older: 72h
- name: Microsoft-Windows-TaskScheduler/Operational
ignore_older: 72h
- name: Microsoft-Windows-Windows Firewall With Advanced Security/Firewall
ignore_older: 72h
- name: Windows PowerShell
event_id: 400, 403, 600, 800
ignore_older: 72h
- name: Microsoft-Windows-PowerShell/Operational
event_id: 4103, 4104, 4105, 4106
ignore_older: 72h
- name: ForwardedEvents
tags: [forwarded]
logging.to_files: true
logging.files:
rotateeverybytes: 10485760 # = 10MB
Příklad konfigurace filebeat¶
filebeat.yaml
:
output.logstash:
hosts: ["<collector>:5044"]
filebeat.inputs:
- type: filestream
fields:
stream: <stream name>
paths:
- /path/to/the/file.log
Shromažďování událostí z Google Cloud PubSub¶
Info
Tato možnost je dostupná od verze v23.27
a dále.
TeskaLabs LogMan.io Collector může shromažďovat události z Google Cloud PubSub pomocí nativního asynchronního konzumenta.
Dokumentace Google Cloud PubSub
Vysvětlení Pull Subscription Google Cloudu
Předpoklady¶
V Pub Sub je třeba shromáždit následující informace:
1.) Název projektu, ze kterého mají být zprávy spotřebovány
2.) Název předplatného vytvořeného v tématu, ze kterého mají být zprávy spotřebovány
Jak vytvořit PubSub předplatné
3.) Soubor účtu služby se soukromým klíčem pro autorizaci k danému tématu a předplatnému
Nastavení vstupu pro LogMan.io kolektor¶
Vstup pro Google Cloud PubSub¶
Vstup nazvaný input:GoogleCloudPubSub:
musí být uveden v konfiguračním souboru YAML kolektoru LogMan.io:
input:GoogleCloudPubSub:GoogleCloudPubSub:
subscription_name: <NÁZEV_PŘEDPLATNÉHO_V_TÉMATU>
project_name: <NÁZEV_PROJEKTU_PRO_SPOTŘEBU>
service_account_file: <CESTA_K_SOUBORU_UČTU_SLŽBY>
output: <VÝSTUP>
<NÁZEV_PŘEDPLATNÉHO_V_TÉMATU>
, <NÁZEV_PROJEKTU_PRO_SPOTŘEBU>
a <CESTA_K_SOUBORU_UČTU_SLŽBY>
musí být poskytnuty z Google Cloud Pub Sub.
Výstupem jsou události jako byte stream s následujícími metainformacemi: publish_time
, message_id
, project_name
a subscription_name
.
Potvrzení¶
Potvrzení/uznání je prováděno automaticky po zpracování každé jednotlivé dávky zpráv, aby nebyly stejné zprávy opakovaně posílány PubSub.
Výchozí dávka je 5 000 zpráv a může být změněna v konfiguraci vstupu pomocí možnosti max_messages
:
max_messages: 10000
Sběr z Bitdefender¶
TeskaLabs LogMan.io může sbírat Bitdefender logy z požadavků prováděných Bitdefenderem, jak je specifikováno v dokumentaci API serveru.
Konfigurace LogMan.io Collector¶
Na serveru LogMan.io, kam jsou logy přeposílány, spusťte instanci LogMan.io Collector s následující konfigurací. V sekci listen
nastavte příslušný port nakonfigurovaný v Log Forwarding v Bitdefender.
Konfigurace Bitdefender serveru¶
input:Bitdefender:BitdefenderAPI:
listen: 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>
encoding: utf-8
output: <OUTPUT_ID>
output:xxxxxx:<OUTPUT_ID>:
...
Sběr z zařízení Cisco IOS¶
Tato metoda sběru je navržena pro sběr logů z produktů Cisco, které provozují IOS, jako je například přepínač Cisco Catalyst 2960 nebo router Cisco ASR 9200.
Konfigurace logu¶
Nakonfigurujte vzdálenou adresu kolektoru a úroveň logování:
CATALYST(config)# logging host <hostname nebo IP kolektoru LogMan.io> transport tcp port <číslo-portu>
CATALYST(config)# logging trap informational
CATALYST(config)# service timestamps log datetime year msec show-timezone
CATALYST(config)# logging origin-id <hostname>
Formát logu obsahuje následující pole:
-
timestamp ve formátu UTC s:
- rokem, měsícem, dnem
- hodinou, minutou a sekundou
- milisekundou
-
hostname zařízení
-
log level je nastaven na informational
Příklad výstupu
<189>36: CATALYST: Aug 22 2022 10:11:25.873 UTC: %SYS-5-CONFIG_I: Configured from console by admin on vty0 (10.0.0.44)
Synchronizace času¶
Je důležité, aby čas zařízení Cisco byl synchronizován pomocí NTP.
Předpoklady jsou: * Internetové připojení (pokud používáte veřejný NTP server) * Konfigurovaná volba name-server (pro rozlišení DNS dotazu)
LAB-CATALYST(config)# no clock timezone
LAB-CATALYST(config)# no ntp
LAB-CATALYST(config)# ntp server <hostname nebo IP NTP serveru>
Příklad konfigurace s NTP serverem Google:
CATALYST(config)# no clock timezone
CATALYST(config)# no ntp
CATALYST(config)# do show ntp associations
%NTP je zakázáno.
CATALYST(config)# ntp server time.google.com
CATALYST(config)# do show ntp associations
adresa 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 (synchronizováno), # master (nesynchronizováno), + vybráno, - kandidát, ~ konfigurováno
CATALYST(config)# do show clock
10:57:39.110 UTC Mon Aug 22 2022
Sbírání z Citrix¶
TeskaLabs LogMan.io může sbírat Citrix logy pomocí Syslog prostřednictvím přesměrování logů přes TCP (doporučeno) nebo UDP komunikaci.
Citrix ADC¶
Pokud jsou Citrix zařízení připojena přes ADC, existuje následující návod na to, jak povolit Syslog přes TCP. Ujistěte se, že vyberete správný server a port LogMan.io pro přesměrování logů.
F5 BIG-IP¶
Pokud jsou Citrix zařízení připojena k F5 BIG-IP, použijte následující návod. Ujistěte se, že vyberete správný server a port LogMan.io pro přesměrování logů.
Konfigurace LogMan.io Collector¶
Na serveru LogMan.io, kam jsou logy přesměrovány, spusťte instance LogMan.io Collector s následující konfigurací.
Přesměrování logů přes TCP¶
input:TCPBSDSyslogRFC6587:Citrix:
address: 0.0.0.0:<PORT_SET_IN_FORWARDING>
output: WebSocketOutput
output:WebSocket:WebSocketOutput:
url: http://<LMIO_SERVER>:<YOUR_PORT>/ws
tenant: <YOUR_TENANT>
debug: false
prepend_meta: false
Přesměrování logů přes UDP¶
input:Datagram:Citrix:
address: 0.0.0.0:<PORT_SET_IN_FORWARDING>
output: WebSocketOutput
output:WebSocket:WebSocketOutput:
url: http://<LMIO_SERVER>:<YOUR_PORT>/ws
tenant: <YOUR_TENANT>
debug: false
prepend_meta: false
Sbírání logů z Fortinet FortiGate¶
TeskaLabs LogMan.io může sbírat logy Fortinet FortiGate přímo nebo skrze FortiAnalyzer pomocí přeposílání logů přes TCP (doporučeno) nebo UDP komunikaci.
Přeposílá logy do LogMan.io¶
Jak ve FortiGate, tak ve FortiAnalyzer musí být zvolen typ Syslog
spolu s odpovídajícím portem.
Pro precizní návody, viz následující odkaz:
Konfigurace Collectoru LogMan.io¶
Na serveru LogMan.io, kam jsou logy přeposílány, spusťte LogMan.io Collector instance s následující konfigurací.
V sekci address
nastavte odpovídající port, který je nastaven v přeposílání logů ve FortiAnalyzer.
Přeposílání logů přes TCP¶
input:TCPBSDSyslogRFC6587:Fortigate:
address: 0.0.0.0:<PORT_SET_IN_FORWARDING>
output: <OUTPUT_ID>
output:xxxxxxx:<OUTPUT_ID>:
...
Přeposílání logů přes UDP¶
input:Datagram:Fortigate:
address: 0.0.0.0:<PORT_SET_IN_FORWARDING>
output: <OUTPUT_ID>
output:xxxxxxx:<OUTPUT_ID>:
...
Sběr událostí z Microsoft Azure Event Hub¶
Tato možnost je dostupná od verze v22.45
výše
TeskaLabs LogMan.io Collector může sbírat události z Microsoft Azure Event Hub pomocí nativního klienta nebo Kafka. Události uložené v Azure Event Hub mohou obsahovat jakákoli data kódovaná v bajtech, jako jsou logy o různých akcích uživatelů, administrátorů, systémů, zařízení a politik.
Nastavení Microsoft Azure Event Hub¶
Pro to, aby LogMan.io Collector mohl číst události, je třeba získat následující přihlašovací údaje: connection string
, event hub name
a consumer group
.
Získání connection string z Microsoft Azure Event Hub¶
1) Přihlaste se do Azure portálu s administrátorskými právy do příslušného Azure Event Hubs Namespace.
Namespace Azure Event Hubs je k dispozici v sekci Resources
.
2) V vybraném Azure Event Hubs Namespace klikněte na Shared access policies
v sekci Settings
v levém menu.
Klikněte na tlačítko Add
, zadejte název politiky (doporučený název je: LogMan.io Collector) a v pravém vyskakovacím okně by se měly objevit podrobnosti o politice.
3) V vyskakovacím okně vyberte možnost Listen
, aby tato politika měla právo číst z event hubů spojených s daným namespace.
Viz následující obrázek.
4) Zkopírujte Connection string-primary key
a klikněte na Save
.
Politika by měla být viditelná v tabulce uprostřed obrazovky.
Connection string začíná předponou Endpoint=sb://
.
Získání consumer group¶
5) V namespace Azure Event Hubs vyberte možnost Event Hubs
z levého menu.
6) Klikněte na event hub, který obsahuje události určené ke sběru.
7) V event hubu klikněte na tlačítko + Consumer group
uprostřed obrazovky.
8) V pravém vyskakovacím okně zadejte název consumer group (doporučená hodnota je lmio_collector
) a klikněte na Create
.
9) Tento postup opakujte pro všechny event huby určené ke sběru.
10) Zapište si název consumer group a všechny event huby pro následnou konfiguraci LogMan.io Collector.
Nastavení vstupu LogMan.io Collector¶
Azure Event Hub Input¶
Vstup s názvem input:AzureEventHub:
musí být zadán v YAML konfiguraci LogMan.io Collector:
input:AzureEventHub:AzureEventHub:
connection_string: <CONNECTION_STRING>
eventhub_name: <EVENT_HUB_NAME>
consumer_group: <CONSUMER_GROUP>
output: <OUTPUT>
<CONNECTION_STRING>
, <EVENT_HUB_NAME>
a <CONSUMER_GROUP>
jsou poskytovány podle výše uvedeného průvodce.
Následující meta možnosti jsou k dispozici pro parser: 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 byte stream, podobně jako vstup Kafka.
Azure Monitor Through Event Hub Input¶
Azure Monitor Through Event Hub Input načítá události z Azure Event Hub, načítá Azure Monitor JSON log a rozkládá jednotlivé záznamy na logové linky, které jsou poté odesílány na definovaný výstup.
Vstup s názvem input:AzureMonitorEventHub:
musí být zadán v YAML konfiguraci LogMan.io Collector:
input:AzureMonitorEventHub:AzureMonitorEventHub:
connection_string: <CONNECTION_STRING>
eventhub_name: <EVENT_HUB_NAME>
consumer_group: <CONSUMER_GROUP>
encoding: # výchozí: utf-8
output: <OUTPUT>
<CONNECTION_STRING>
, <EVENT_HUB_NAME>
a <CONSUMER_GROUP>
jsou poskytovány podle výše uvedeného průvodce.
Následující meta možnosti jsou k dispozici pro parser: 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 byte stream, podobně jako vstup Kafka.
Alternativa: Kafka Input¶
Azure Event Hub také poskytuje (s výjimkou uživatelů základní vrstvy) rozhraní Kafka, takže lze použít standardní Kafka vstup LogMan.io Collector.
Existuje několik možností autentizace v Kafka, včetně OAuth atd.
Nicméně, pro účely dokumentace a opětovné použití connection string
, preferujeme jednoduchou autentizaci SASL pomocí connection string
z výše uvedeného průvodce.
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: <OUTPUT>
<CONNECTION_STRING>
, <EVENT_HUB_NAME>
a <CONSUMER_GROUP>
jsou poskytovány podle výše uvedeného průvodce, <NAMESPACE>
je název zdroje Azure Event Hub (také zmíněn v průvodci výše).
Následující meta možnosti jsou k dispozici pro parser: kafka_key
, kafka_headers
, _kafka_topic
, _kafka_partition
a _kafka_offset
.
Výstupem jsou události jako byte stream.
Sbírejte logy z databáze pomocí ODBC¶
Úvod¶
Doporučený způsob získávání logů a dalších událostí z databází je pomocí ODBC. ODBC poskytuje jednotný způsob, jak připojit LogMan.io k různým databázovým systémům.
Tip
Příklady ODBC připojovacích řetězců naleznete zde.
ODBC ovladač a konfigurace¶
Musíte poskytnout ODBC ovladač pro databázový systém, který chcete integrovat s LogMan.io. Příslušný ODBC ovladač musí být kompatibilní s Ubuntu 20.04 LTS, 64bit.
ODBC ovladače je třeba nasadit do LogMan.io Collectoru, konkrétně do adresáře /odbc
.
Alternativně vám naše podpora pomůže nasadit správný ODBC ovladač pro váš databázový systém nebo poskytne LogMan.io Collector s integrovaným ODBC ovladačem.
Note
ODBC ovladače jsou vystaveny softwaru LogMan.io collector skrze Docker volumes.
Konfigurace ODBC se provádí v souborech /odbc/odbcinst.ini
a odbc.ini
.
Konfigurace inputu Collectoru¶
Specifikace zdroje inputu je input:ODBC:
.
Příklad konfigurace ODBC collectoru:
input:ODBC:ODBCInput:
dsn: Driver={FreeTDS};Server=MyServer;Port=1433;Database=MyDatabase;TDS_Version=7.3;UID=MyUser;PWD=MyPassword
query: 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
MySQL ODBC konfigurace¶
MySQL ODBC ovladače lze získat na následující odkazu.
Balíček ovladače je třeba rozbalit do adresáře /odbc/mysql
.
Záznamy v souboru /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
Microsoft SQL Server ODBC konfigurace¶
Microsoft SQL Server ODBC ovladače lze získat na následující odkazu.
Záznamy v souboru /odbc/odbcinst.ini
:
[ODBC Driver 17 for SQL Server]
Description=Microsoft ODBC Driver 17 for SQL Server
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
Microsoft SQL Server ODBC alternativní konfigurace¶
Alternativní připojení k Microsoft SQL Server poskytuje projekt FreeTDS, konkrétně jeho ODBC ovladač.
Záznamy v souboru /odbc/odbcinst.ini
:
[FreeTDS]
Description=FreeTDS Driver for Linux & 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
MariaDB ODBC konfigurace¶
MariaDB ODBC ovladače lze získat na následující odkazu.
SAP IQ, Sybase IQ, Sybase ASE ODBC konfigurace¶
SAP IQ / Sybase IQ / Sybase ASE / SQL Anywhere ODBC ovladače musí být staženy z podpůrné stránky SAP.
Balíček ovladače je třeba rozbalit do adresáře /odbc/sybase
.
Záznam v souboru /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
Oracle Database ODBC konfigurace¶
Ovladače Oracle ODBC (konkrétně Oracle Instant Client ODBC) získáte z Oracle Instant Client stránky.
Po stažení a dekomprimování, umístěte ovladače do adresáře /odbc/oracle
.
Záznam v souboru /odbc/odbcinst.ini
:
[Oracle 19 ODBC driver]
Description=Oracle ODBC driver for Oracle 19
Driver=/odbc/oracle/libsqora.so.19.1
UsageCount=1
Příklad připojovacího řetězce:
Driver={Oracle 19 ODBC driver};Dbq=//<host>:<port>/<service_name>;Uid=<username>;Pwd=<password>;
PostgreSQL ODBC konfigurace¶
Entry in the /odbc/odbcinst.ini
:
[PostgreSQL Unicode]
Description=PostgreSQL ODBC driver (Unicode)
Driver=/odbc/postgresql/psqlodbcw.so
UsageCount=1
Záznam v souboru /odbc/odbcinst.ini
:
Driver={PostgreSQL Unicode};Server=<host>;Port=5432;Database=<database>;Uid=<username>;Pwd=<password>;
Řešení problémů¶
Přidání ODBC Tracing¶
Pokud potřebujete větší náhled do ODBC připojení, můžete povolit sledování ODBC.
Přidejte tuto sekci do souboru /odbc/odbcinst.ini
:
[ODBC]
Trace = yes
TraceFile = /odbc/trace.log
Po spuštění collectoru bude výstup sledování ODBC systému uložen do souboru /odbc/trace.log
.
Tento soubor je dostupný také mimo kontejner.
Ověření konfigurace ODBC¶
Příkaz odbcinst -j
(spuštěný uvnitř kontejneru) lze použít k ověření připravenosti ODBC:
# odbcinst -j
unixODBC 2.3.6
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /root/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8
Docker-compose¶
LogMan.io collector lze spustit pomocí docker-compose
.
Toto je výpis relevantních záznamů ze souboru docker-compose.yaml
:
lmio-collector:
image: docker.teskalabs.com/lmio/lmio-collector
...
volumes:
- /odbc/odbcinst.ini:/etc/odbcinst.ini
- /odbc/odbc.ini:/etc/odbc.ini
- /odbc:/odbc
...
network_mode: host
Následně je třeba LogMan.io Collector znovu vytvořit pomocí:
docker-compose up -d
Shromažďování logů z Oracle Cloud¶
Můžete shromažďovat logy z Oracle Cloud Infrastructure (OCI).
Více o OCI Logging naleznete zde.
Pro konfiguraci LogMan.io Collector budete potřebovat:
- Generovat nový API klíč spolu s novými veřejnými a soukromými klíči v OCI konzoli
- Vytvořit nový vyhledávací dotaz pro API požadavky
Generování API klíče v OCI konzoli¶
-
Přihlaste se do své OCI konzole.
-
Přejděte na Zdroje, vyberte API klíče a klikněte na Přidat API klíč.
-
Ujistěte se, že je vybraná možnost Generovat pár API klíčů. Klikněte na Stáhnout soukromý klíč a poté Stáhnout veřejný klíč. Poté klikněte na Přidat.
-
Bude vytvořen konfigurační soubor se všemi potřebnými přihlašovacími údaji. Vložte obsah textového pole do souboru
data/oci/config
. -
Vyplňte
key_file
cestou k vašemu soukromému klíčovému souboru.
Important
Nikdy nesdílejte svůj soukromý klíč s nikým jiným. Uchovávejte ho v tajnosti ve vlastním souboru. Možná budete muset změnit oprávnění veřejného a soukromého klíče po jejich stažení.
Jak funguje proces požadavku?
Soukromé a veřejné klíče jsou součástí asymetrického šifrovacího systému. Veřejný klíč je uložen u Oracle Cloud Infrastructure a používá se k ověření identity klienta. Soukromý klíč, který uchováváte v bezpečí a nikdy jej nesdílíte, se používá k podepisování vašich API požadavků.
Když vytvoříte požadavek na OCI API, klientský software použije soukromý klíč k vytvoření digitálního podpisu pro požadavek. Tento podpis je unikátní pro každý požadavek a je generován na základě dat požadavku. Klient potom odešle API požadavek společně s tímto digitálním podpisem do Oracle Cloud Infrastructure.
Po obdržení požadavku Oracle použije veřejný klíč (který již má), aby ověřil digitální podpis. Pokud je podpis platný, potvrzuje to, že požadavek skutečně odeslal držitel odpovídajícího soukromého klíče (vy) a že nebyl během přenosu změněn. Tento proces je důležitý pro zachování integrity a autenticity komunikace.
Soukromý klíč sám o sobě nikdy není odesílán po síti. Zůstává na straně klienta. Bezpečnost celého procesu závisí na tom, že soukromý klíč zůstane důvěrný. Pokud by byl kompromitován, ostatní by mohli předstírat vaši službu a odesílat požadavky na OCI vaším jménem.
Specifikace vyhledávacího dotazu pro logování¶
Prosím, obraťte se na oficiální dokumentaci pro vytvoření nových dotazů.
Budete potřebovat následující informace:
- Compartment OCID
- Log group OCID
- Log OCID
Příklad vyhledávacího dotazu pro logování
search "<compartment_OCID>/<log_group_OCID>/<log_OCID>" | where level = 'ERROR' | sort by datetime desc
Konfigurace¶
Níže je uvedena požadovaná konfigurace pro LogMan.io Collector:
input:Oracle:OCIInput:
oci_config_path: ./data/oci/config # Cesta k vašemu OCI konfiguračnímu souboru (povinné)
search_query: search '<compartment_OCID>/<log_group_OCID>/<log_OCID>' | where level = 'ERROR' # (povinné)
encoding: utf-8 # Kódování eventů (volitelné)
interval: 10 # Počet sekund mezi požadavky na OCI (volitelné)
output: <output_id> # (povinné)
Vývoj¶
Warning
LogMan.io Collector Oracle Source je postaven na OCI integraci pro API, která používá synchronní požadavky. Může dojít k problémům, pokud je velký TCP vstup.
Sběr událostí ze Zabbix¶
TeskaLabs LogMan.io Collector může sbírat události ze Zabbix prostřednictvím Zabbix API.
Zdroj Zabbix Metrics¶
Zdroj Zabbix Metrics pravidelně odesílá požadavky event.get
a history.get
.
Požadavek event.get
se používá k vyhledání dat událostí ze serveru Zabbix. Události v Zabbix představují významné události v monitorovaném prostředí, jako jsou spuštění triggerů, akce průzkumníka nebo interní události Zabbix.
Požadavek history.get
se používá k vyhledání historických dat ze Zabbix, která obsahují různé typy monitorovacích dat, jako jsou číselné hodnoty, textové logy a další.
Konfigurace¶
Příklad minimální požadované konfigurace:
input:ZabbixMetrics:<SOURCE_ID>:
url: https://192.0.0.5/api_jsonrpc.php # URL pro Zabbix API
auth: b03.......6f # Autorizační token pro Zabbix API
output: <output_id>
output:<type>:<output_id>:
...
Volitelně můžete konfigurovat vlastnosti požadavků:
interval: 60 # (volitelné, výchozí: 60) Časový interval mezi požadavky v sekundách
max_requests: 100 # (volitelné, výchozí: 50) Počet současných požadavků
request timeout: 10 # (volitelné, výchozí: 10) Timeout pro požadavky v sekundách
sleep_on_error: 10 # (volitelné, výchozí: 10) Když dojde k chybě, LMIO Collector počká určitou dobu a pak požadavky odešle znovu
Můžete také změnit kódování příchozích událostí:
encoding: utf-8 # (volitelné) Kódování příchozích událostí
Typy historie¶
V Zabbix objekt historie představuje zaznamenaný kus dat spojený s metrikou v čase. Tyto objekty historie jsou základní pro analýzu výkonu a stavu monitorovaných entit, neboť ukládají skutečné sbírané datové body. Každý objekt historie je spojen se specifickou položkou a obsahuje časové razítko, které označuje, kdy byla data sesbírána. Objekty historie se používají ke sledování a analýze trendů, generování grafů a spouštění alertů na základě historických dat.
Mnoho různých typů objektů historie může být vráceno v událostech. Další informace najdete v oficiální dokumentaci.
Typ objektu historie | Název | Využití |
---|---|---|
0 | číselné plovoucí číslo | metriky jako zatížení CPU, teplota, atd. |
1 | znakový | záznamy logů, statusy služeb, atd. |
2 | log | systémové a aplikační logy |
3 | (výchozí) číselné bez znaménka | volné místo na disku, síťový provoz, atd. |
4 | text | popisy, zprávy, atd. |
5 | binární | binární zprávy |
Typy historie jsou konfigurovány následujícím způsobem:
histories_to_return: "0,1,3" # (volitelné, výchozí: '0,3') Seznam typů historie
Položky metrik¶
Položka metriky v Zabbix specifikuje typ dat, který má být sesbíraný z monitorovaného hostu. Každá položka je spojena s klíčem, který jednoznačně identifikuje data, která mají být sesbírána, stejně jako další atributy, jako typ dat, frekvenci sběru a jednotky měření. Položky mohou představovat různé typy dat, včetně číselných hodnot, textů, záznamů logů a další.
Server Zabbix typicky obsahuje velké množství hostů, od kterých bude historie sbírána. Chcete-li filtraci podle specifických položek metrik, postupujte takto:
- Vytvořte CSV soubor se seznamem typů metrik, každou na samostatném řádku:
Uptime
Number of processes
Number of threads
FortiGate: System uptime
VMware: Uptime
CPU utilization
CPU user time
...
- Konfigurujte cestu k souboru v konfiguraci Zabbix Metrics Source v LogMan.io Collector:
items_list_filename: conf/items.csv
Tip
Doporučujeme filtrovat menší podmnožinu typů metrik, aby nedošlo k přetížení serveru Zabbix.
Zdroj Zabbix Security¶
Zdroj Zabbix Security pravidelně odesílá požadavky event.get
a alert.get
.
Požadavek event.get
se používá k vyhledání dat událostí ze serveru Zabbix. Události v Zabbix představují významné události v monitorovaném prostředí, jako jsou spuštění triggerů, akce průzkumníka nebo interní události Zabbix.
Požadavek alert.get
se používá k vyhledání dat alertů ze serveru Zabbix. Alerty v Zabbix jsou oznámení generovaná v reakci na určité podmínky nebo události, jako jsou změny stavu triggeru, akce průzkumníka nebo interní systémové události. Tyto alerty mohou být konfigurovány k upozorňování administrátorů nebo provádění automatizovaných akcí k řešení problémů.
Požadovaná konfigurace¶
Příklad minimální požadované konfigurace:
input:ZabbixSecurity:<SOURCE_ID>:
url: https://192.0.0.5/api_jsonrpc.php # URL pro Zabbix API
auth: b03.......6f # Autorizační token pro Zabbix API
output: <output_id>
output:<type>:<output_id>:
...
Volitelně můžete konfigurovat vlastnosti požadavků:
interval: 60 # (volitelné, výchozí: 60) Časový interval mezi požadavky v sekundách
request timeout: 10 # (volitelné, výchozí: 10) Timeout pro požadavky v sekundách
sleep_on_error: 10 # (volitelné, výchozí: 10) Když dojde k chybě, LMIO Collector počká určitou dobu a pak požadavky odešle znovu
Můžete také změnit kódování příchozích událostí:
encoding: utf-8 # (volitelné) Kódování příchozích událostí
ESET Connect API Zdroj¶
ESET Connect je API brána mezi klientem a kolekcí backendových služeb ESET. Funguje jako reverzní proxy, která přijímá všechna volání aplikačního programového rozhraní (API), agreguje různé služby potřebné k jejich splnění a vrací odpovídající výsledek.
Vytvoření nového API klienta¶
Warning
Pro vytvoření nového uživatele musíte mít superuser oprávnění v ESET Business Account.
- Přihlašte se jako superuser (Administrátor) do ESET Business Account.
-
Otevřete Správu uživatelů a klikněte na tlačítko Nový uživatel dole.
-
Vytvořte účet s oprávněním read-only a zapněte přepínač Integrace.
-
Nový uživatelský účet by měl být úspěšně vytvořen s možností čtení z ESET Connect API.
Sbírání detekcí z připojených zařízení¶
Připojená zařízení jsou organizována v skupinách zařízení. Každá skupina může mít své podskupiny. Jedno zařízení může být členem různých podskupin. Je možné monitorovat detekce z vybraných zařízení nebo vybraných skupin zařízení. Pokud tyto nejsou specifikovány, všechna zařízení jsou monitorována.
Konfigurace LogMan.io Collectoru¶
'input:ESET:EsetSource':
client_id: john.doe@domain.com # (povinné) E-mail API Klienta
client_secret: client_secret # (povinné) Heslo pro API Klienta
interval: 10 # (volitelné, default: 10) Interval mezi požadavky v sekundách.
Konfigurace LogMan.io Collectoru¶
Konfigurace LogMan.io Collectoru obvykle sestává ze dvou souborů.
- Konfigurace Collectoru (
/conf/lmio-collector.conf
, formát INI) specifikuje cestu ke konfiguračnímu souboru pipeline a případně dalším volbám na úrovni aplikace. - Konfigurace Pipeline (
/conf/lmio-collector.yaml
, formát YAML) specifikuje, ze kterých vstupů se data sbírají (inputs), jak se data transformují (transforms) a jak se data dále posílají (outputs).
Konfigurace Collectoru¶
[config]
path=/conf/lmio-collector.yaml
Konfigurace Pipeline¶
Konfigurace pipeline je ve formátu YAML. Více pipeline může být konfigurováno ve stejném konfiguračním souboru pipeline.
Každá sekce představuje jednu komponentu pipeline. Vždy začíná buď input:
, transform:
, output:
nebo connection:
a má formu:
input|transform|output:<TYPE>:<ID>
kde <TYPE>
určuje typ komponenty. <ID>
se používá pro referenci a může být libovolně zvoleno.
- Input specifikuje zdroj/vstup logů.
- Output specifikuje výstup, kam se logy odesílají.
- Connection specifikuje připojení, které může používat
output
. - Transform specifikuje transformační akci, která se aplikuje na logy (volitelné).
Typická konfigurace pipeline pro LogMan.io Receiver:
# Připojení k LogMan.io (centrální část)
connection:CommLink:commlink:
url: https://recv.logman.example.com/
# Vstup
input:Datagram:udp-10002-src:
address: 0.0.0.0 10002
output: udp-10002
# Výstup
output:CommLink:udp-10002: {}
Podrobné možnosti konfigurace každé komponenty naleznete v kapitolách Inputs, Transformations a Outputs. Dokumentaci k CommLink připojení najdete v LogMan.io Receiver.
Docker Compose¶
version: '3'
services:
lmio-collector:
image: docker.teskalabs.com/lmio/lmio-collector
container_name: lmio-collector
volumes:
- ./lmio-collector/conf:/conf
- ./lmio-collector/var:/app/lmio-collector/var
network_mode: host
restart: always
Vstupy LogMan.io Collector¶
Note
Tato kapitola se týká nastavení zdrojů logů sbíraných přes síť, syslog, soubory, databáze atd. Pro nastavení sběru událostí z různých zdrojů logů, viz podtéma Zdroje logů.
Síť¶
Sekce: input:TCP
, input:Stream
, input:UDP
, input:Datagram
Tyto vstupy naslouchají na zadané adrese pomocí TCP, UDP nebo Unix Socket.
Tip
Logy by měly být shromažďovány přes protokol TCP. Pouze pokud to není možné, použijte protokol UDP.
Možnosti konfigurace pro naslouchání:
address: # Zadejte IPv4, IPv6 nebo UNIX cestu k souboru pro naslouchání
output: # Na který výstup odeslat příchozí události
Zde jsou možné formy address
:
8080
nebo*:8080
: Naslouchejte na portu 8080 na všech dostupných síťových rozhraních na IPv4 a IPv60.0.0.0:8080
: Naslouchejte na portu 8080 na všech dostupných síťových rozhraních na IPv4:::8080
: Naslouchejte na portu 8080 na všech dostupných síťových rozhraních na IPv61.2.3.4:8080
: Naslouchejte na portu 8080 na konkrétním síťovém rozhraní (1.2.3.4
) na IPv4::1:8080
: Naslouchejte na portu 8080 na konkrétním síťovém rozhraní (::1
) na IPv6/tmp/unix.sock
: Naslouchejte na UNIX socketu/tmp/unix.sock
Následující možnosti konfigurace jsou dostupné pouze pro input:Datagram
:
max_packet_size: # (volitelné) Zadejte maximální velikost paketů v bajtech (výchozí: 65536)
receiver_buffer_size: # (volitelné) Omezte velikost vyrovnávací paměti přijímače v bajtech (výchozí: 0)
Warning
LogMan.io Collector běží uvnitř Docker kontejneru. Povolení propagace síťových portů musí být nastaveno takto:
services:
lmio-collector-tenant:
network_mode: host
Note
TCP (Transmission Control Protocol) a UDP (User Datagram Protocol) jsou oba protokoly používané k odesílání dat přes síť.
TCP je Stream, protože poskytuje spolehlivé, uspořádané a kontrolované doručení datového proudu.
Naproti tomu UDP je datagram, který odesílá pakety nezávisle, což umožňuje rychlejší přenos, ale s menší spolehlivostí a bez záruky pořadí, podobně jako jednotlivé, nesouvisející zprávy.
Tip
Pro troubleshooting použijte tcpdump
pro zachycení syrového síťového provozu a poté použijte Wireshark pro hlubší analýzu.
Příklad zachycení provozu na portu TCP/10008:
$ sudo tcpdump -i any tcp port 10008 -s 0 -w /tmp/capture.pcap -v
Až bude zachyceno dostatečné množství provozu, stiskněte Ctrl-C a shromážděte soubor /tmp/capture.pcap
, který obsahuje zachycený provoz.
Tento soubor může být otevřen ve Wiresharku.
Syslog¶
Sekce: input:TCPBSDSyslogRFC6587
, input:TCPBSDSyslogNoFraming
Speciální případy vstupu TCP pro parsování SysLog přes TCP. Pro více informací viz RFC 6587 a RFC 3164, sekce 4.1.1
Možnosti konfigurace pro naslouchání na zadané cestě:
address: # Zadejte IPv4, IPv6 nebo UNIX cestu k souboru pro naslouchání (např. 127.0.0.1:8888 nebo /data/mysocket)
output: # Na který výstup odeslat příchozí události
Následující možnosti konfigurace jsou dostupné pouze pro input:TCPBSDSyslogRFC6587
:
max_sane_msg_len: # (volitelné) Maximální velikost v bajtech SysLog zprávy, která má být přijata (výchozí: 10000)
Následující možnosti konfigurace jsou dostupné pouze pro input:TCPBSDSyslogNoFraming
:
buffer_size: # (volitelné) Maximální velikost v bajtech SysLog zprávy, která má být přijata (výchozí: 64 * 1024)
variant: # (volitelné) Varianta SysLog formátu příchozí zprávy, může být `auto`, `nopri` bez PRI čísla na začátku a `standard` s PRI (výchozí: auto)
Subprocess¶
Sekce: input:SubProcess
Vstup SubProcess spouští příkaz jako podproces sběrače LogMan.io, přičemž
pravidelně kontroluje jeho výstup na stdout
(řádky) a stderr
.
Možnosti konfigurace zahrnují:
command: # Zadejte příkaz, který má být spuštěn jako podproces (např. tail -f /data/tail.log)
output: # Na který výstup odeslat příchozí události
line_len_limit: # (volitelné) Limit délky jednoho přečteného řádku (výchozí: 1048576)
ok_return_codes: # (volitelné) Které návratové kódy znamenají běžný stav příkazu (výchozí: 0)
Sledování souboru¶
Sekce: input:SmartFile
Smart File Input se používá pro sběr událostí z více souborů, jejichž obsah může být dynamicky změněn,
nebo soubory mohou být odstraněny jiným procesem, podobně jako příkaz tail -f
v shellu.
Smart File Input vytváří monitorovaný souborový objekt pro každou cestu k souboru, která je zadána v konfiguraci v možnosti path
.
Monitorovaný soubor pravidelně kontroluje nové řádky v souboru, a pokud se objeví, řádek je přečten v bajtech a předán dál do pipeline, včetně meta informací, jako je název souboru a extrahované části cesty k souboru, viz sekce parametry extrakce.
Různé protokoly se používají pro čtení z různých formátů logových souborů:
- Protokol řádků pro řádkově orientované logové soubory
- XML protokol pro XML-orientované logové soubory
- W3C Extended Log File Protocol pro logové soubory ve formátu W3C Extended Log File Format
- W3C DHCP Server Protocol pro logové soubory DHCP serveru
Povinné možnosti konfigurace:
input:SmartFile:MyFile:
path: | # Cesty k souborům oddělené novými řádky
/prvni/cesta/k/logum/*.log
/druha/cesta/k/logum/*.log
/dalsi/cesta/*s
protocol: # Protokol, který má být použit pro čtení
Volitelné možnosti konfigurace:
recursive: # Rekurzivní skenování zadaných cest (výchozí: True)
scan_period: # Období skenování souborů v sekundách (výchozí: 3 sekundy)
preserve_newline: # Zachovat nový řádek v výstupu (výchozí: False)
last_position_storage: # Perzistentní úložiště pro aktuální pozice ve čtených souborech (výchozí: ./var/last_position_storage)
Tip
Při složitějším setupu, jako je extrakce logů ze sdílené složky Windows, můžete využít rsync
pro synchronizaci logů ze sdílené složky do lokální složky na sběračském stroji. Potom Smart File Input čte logy z lokální složky.
Warning
Vnitřně je aktuální pozice v souboru uložena ve last position storage v proměnné pozice. Pokud je soubor last position storage smazán nebo není specifikován, všechny soubory jsou čteny znovu po restartu LogMan.io Collector, to znamená, že absence perzistence znamená resetování čtení při restartování.
Můžete konfigurovat cestu pro last position storage:
last_position_storage: "./var/last_position_storage"
Warning
Pokud je velikost souboru menší než předchozí zapamatovaná velikost souboru, soubor je znovu čten a zaslán do pipeline rozdělený na řádky.
Cesty k souborům¶
Globy cest k souborům jsou odděleny novými řádky. Mohou obsahovat zástupné znaky (např. *, **
atd.).
path: |
/prvni/cesta/*.log
/druha/cesta/*.log
/dalsi/cesta/*
Ve výchozím nastavení jsou soubory čteny rekurzivně. Rekurzivní čtení můžete zakázat pomocí:
recursive: False
Protokol řádků¶
protocol: line
line/C_separator: # (volitelné) Znak používaný jako oddělovač řádků. Výchozí: '\n'.
Protokol řádků se používá pro čtení zpráv z řádkově orientovaných logových souborů.
XML protokol¶
protocol: xml
tag_separator: '</msg>' # (povinné) Tag pro oddělovač.
XML protokol se používá pro čtení zpráv z XML-orientovaných logových souborů.
Parametr tag_separator
musí být zahrnut v konfiguraci.
Example
Příklad XML logového souboru:
...
<msg time='2024-04-16T05:47:39.814+02:00' org_id='orgid'>
<txt>Log message 1</txt>
</msg>
<msg time='2024-04-16T05:47:42.814+02:00' org_id='orgid'>
<txt>Log message 2</txt>
</msg>
<msg time='2024-04-16T05:47:43.018+02:00' org_id='orgid'>
<txt>Log message 3</txt>
</msg>
...
Konfigurační příklad:
input:SmartFile:Alert:
path: /xml-logs/*.xml
protocol: xml
tag_separator: "</msg>"
W3C Extended Log File Protocol¶
protocol: w3c_extended
W3C Extended Log File Protocol se používá pro sběr událostí z logových souborů ve formátu W3C Extended Log File Format a jejich serializaci do formátu JSON.
Příklad sběru událostí z Microsoft Exchange Server
Příklad konfigurace LogMan.io Collector:
input:SmartFile:MSExchange:
path: /MicrosoftExchangeServer/*.log
protocol: w3c_extended
extract_source: file_path
extract_regex: ^(?P<file_path>.*)$
Příklad obsahu logového souboru:
#Software: Microsoft Exchange Server
#Version: 15.02.1544.004
#Log-type: DNS log
#Date: 2024-04-14T00:02:48.540Z
#Fields: Timestamp,EventId,RequestId,Data
2024-04-14T00:02:38.254Z,,9666704,"SendToServer 122.120.99.11(1), AAAA exchange.bradavice.cz, (query id:46955)"
2024-04-14T00:02:38.254Z,,7204389,"SendToServer 122.120.99.11(1), AAAA exchange.bradavice.cz, (query id:11737)"
2024-04-14T00:02:38.254Z,,43150675,"Send completed. Error=Success; Details=id=46955; query=AAAA exchange.bradavice.cz; retryCount=0"
...
W3C DHCP Server Format¶
protocol: w3c_dhcp
W3C DHCP protokol se používá pro sběr událostí z logových souborů DHCP serveru. Je velmi podobný W3C Extended Log File Format s rozdílem v hlavičce logového souboru.
Tabulka identifikace událostí W3C DHCP
Event ID | Význam |
---|---|
00 | Log byl spuštěn. |
01 | Log byl zastaven. |
02 | Log byl dočasně pozastaven kvůli nízkému volnému místu na disku. |
10 | Klientovi byla přidělena nová IP adresa. |
11 | Klient obnovil pronájem. |
12 | Klient uvolnil pronájem. |
13 | Na síti byla nalezena používaná IP adresa. |
14 | Požadavek na pronájem nemohl být splněn, protože pool adres v rozsahu byl vyčerpán. |
15 | Pronájem byl odmítnut. |
16 | Pronájem byl smazán. |
17 | Pronájem vypršel a DNS záznamy pro vypršené pronájmy nebyly smazány. |
18 | Pronájem vypršel a DNS záznamy byly smazány. |
20 | BOOTP adresa byla přidělena klientovi. |
21 | Dynamická BOOTP adresa byla přidělena klientovi. |
22 | Požadavek na BOOTP nemohl být splněn, protože pool adres pro BOOTP v rozsahu byl vyčerpán. |
23 | BOOTP IP adresa byla smazána po ověření, že není používána. |
24 | Začátek operace čištění IP adres. |
25 | Statistika operace čištění IP adres. |
30 | Požadavek na aktualizaci DNS na určený DNS server. |
31 | Aktualizace DNS selhala. |
32 | Aktualizace DNS byla úspěšná. |
33 | Paket byl zahozen kvůli politice NAP. |
34 | Požadavek na aktualizaci DNS selhal, protože byla překročena mezní hodnota fronty požadavků na aktualizaci DNS. |
35 | Požadavek na aktualizaci DNS selhal. |
36 | Paket byl zahozen, protože server je v roli záložního serveru pro failover nebo hash ID klienta nesedí. |
50+ | Kódy nad 50 jsou používány pro informace o detekci rogue serveru. |
Příklad sběru událostí z DHCP serveru
Příklad konfigurace LogMan.io Collector:
```yaml input:SmartFile:DHCP
LogMan.io Collector Výstupy¶
Výstup collectoru je specifikován následovně:
output:<typ-výstupu>:<jméno-výstupu>:
debug: false
...
Společné volby výstupu¶
V každém výstupu mohou být meta informace specifikovány jako slovník v atributu meta
.
meta:
my_meta_tag: my_meta_tag_value # (volitelné) Vlastní meta informace, které budou později dostupné v LogMan.io Parseru v kontextu události
tenant
mohou být specifikovány přímo v konfiguraci výstupu.
Ladění¶
debug
(volitelné)
Specifikujte, zda se má výstup také zapisovat do logu pro ladění.
Výchozí: false
Předřazení meta informací¶
prepend_meta
(volitelné)
Předřadí meta informace příchozí události jako páry klíč-hodnota oddělené mezerami.
Výchozí: false
Poznámka
Meta informace zahrnují název souboru nebo z něj extrahované informace (v případě vstupu Smart File), vlastní definovaná pole (viz níže) atd.
TCP Výstup¶
Odesílá události přes TCP na server specifikovaný IP adresou a Portem.
output:TCP:<jméno-výstupu>:
address: <IP adresa>:<Port>
...
Adresa¶
address
Adresa serveru se skládá z IP adresy a portu.
Tip
Jsou podporovány adresy IPv4 i IPv6.
Maximální velikost paketů¶
max_packet_size
(volitelné)
Specifikuje maximální velikost paketů v bytech.
Výchozí: 65536
Velikost přijímacího bufferu¶
receiver_buffer_size
(volitelné)
Omezuje velikost přijímacího bufferu v bytech.
Výchozí: 0
UDP Výstup¶
Odesílá události přes UDP na specifikovanou IP adresu a Port.
output:UDP:<jméno-výstupu>:
address: <IP adresa>:<Port>
...
Adresa¶
address
Adresa serveru se skládá z IP adresy a portu.
Tip
Jsou podporovány adresy IPv4 i IPv6.
Maximální velikost paketů¶
max_packet_size
(volitelné)
Specifikuje maximální velikost paketů v bytech.
Výchozí: 65536
Velikost přijímacího bufferu¶
receiver_buffer_size
(volitelné)
Omezuje velikost přijímacího bufferu v bytech.
Výchozí: 0
WebSocket Výstup¶
Odesílá události přes WebSocket na specifikovanou URL.
output:WebSocket:<jméno-výstupu>:
url: <Server URL>
...
URL¶
url
Specifikujte cílovou WebSocket URL. Například http://example.com/ws
Tenant¶
tenant
Jméno tenantu, LogMan.io Collector, jméno tenantu je forwardováno do LogMan.io parseru a přidáno k události.
Neaktivní čas¶
inactive_time
(volitelné)
Specifikuje neaktivní čas v sekundách, po které budou nečinné Web Sockets uzavřeny.
Výchozí: 60
Velikost výstupní fronty¶
output_queue_max_size
(volitelné)
Specifikujte velikost paměťové výstupní fronty pro každý Web Socket
Cesta pro ukládání perzistentních souborů¶
buffer
(volitelné)
Cesta pro ukládání perzistentních souborů, když je Web Socket spojení offline.
Volby konfigurace SSL¶
Následující konfigurační volby specifikují SSL (HTTPS) připojení:
cert
: Cesta k SSL certifikátu klientakey
: Cesta k privátnímu klíči SSL certifikátu klientapassword
: Heslo privátního klíče (volitelné, výchozí: žádné)cafile
: Cesta k PEM souboru s CA certifikátem k ověření SSL serveru (volitelné, výchozí: žádné)capath
: Cesta k adresáři s CA certifikátem k ověření SSL serveru (volitelné, výchozí: žádné)ciphers
: SSL šifry (volitelné, výchozí: žádné)dh_params
: Diffie–Hellman (D-H) parametry výměny klíčů (TLS) (volitelné, výchozí: žádné)verify_mode
: Jedna z možností CERT_NONE, CERT_OPTIONAL nebo CERT_REQUIRED (volitelné); pro více informací viz: github.com/TeskaLabs/asab
Souborový Výstup¶
Odesílá události do specifikovaného souboru.
output:File:<jméno-výstupu>:
path: /data/output.log
...
Cesta¶
path
Cesta výstupního souboru.
Tip
Ujistěte se, že umístění výstupního souboru je dostupné uvnitř Docker kontejneru při použití Dockeru.
Příznaky¶
flags
(volitelné)
Jedna z možností O_CREAT
a O_EXCL
, kde první možnost povoluje vytvoření souboru, pokud neexistuje.
Výchozí: O_CREAT
Režim¶
mode
(volitelné)
Režim, kterým bude soubor zapsán.
Výchozí: ab
(připojené bajty).
Unix Socket (datagram)¶
Odesílá události do datagramově orientovaného Unix Domain Socket.
output:UnixSocket:<jméno-výstupu>:
address: <cesta>
...
Adresa¶
address
Cesta k Unix socket souboru, např. /data/myunix.socket
.
Maximální velikost paketů¶
max_packet_size
(volitelné)
Specifikuje maximální velikost paketů v bytech.
Výchozí: 65536
Unix Socket (stream)¶
Odesílá události do streamově orientovaného Unix Domain Socket.
output:UnixStreamSocket:<jméno-výstupu>:
address: <cesta>
...
Adresa¶
address
Cesta k Unix socket souboru, např. /data/myunix.socket
.
Maximální velikost paketů¶
max_packet_size
(volitelné)
Specifikuje maximální velikost paketů v bytech.
Výchozí: 65536
Print Výstup¶
Pomocný výstup, který vypisuje události do terminálu.
output:Print:<jméno-výstupu>:
...
Null Výstup¶
Pomocné výstupy, které zahazují události.
output:Null:<jméno-výstupu>:
...
LogMan.io Collector Transformace¶
Transformace se používají k předzpracování příchozích událostí s uživatelsky definovanou deklarací před jejich předáním do určeného výstupu.
Dostupné transformace¶
transform:Declarative:
poskytuje deklarativní procesor, který je konfigurován prostřednictvím deklarativní konfigurace (YAML)transform:XMLToDict:
se typicky používá pro XML soubory a Windows Události z WinRM.
LogMan.io Collector Mirage¶
LogMan.io Collector má schopnost vytvářet mock logy a posílat je skrze datový kanál, hlavně pro testovací a demonstrační účely. Zdroj, který produkuje mock logy, se nazývá Mirage.
Mirage používá LogMan.io Collector Library jako úložiště pro sesbírané logy od různých poskytovatelů. Logy v této knihovně jsou odvozeny z reálných logů.
Konfigurace vstupu Mirage¶
# Konfigurační YAML soubor pro vstupy
[config]
path=./etc/lmio-collector.yaml
# Připojení ke Knihovně, kde jsou uloženy logy Mirage
[library]
providers=git+http://user:password@gitlab.example.com/lmio/lmio-collector-library.git
[web]
listen=0.0.0.0 8088
input:Mirage:MirageInput:
path: /Mirage/<cesta>/
eps: <počet logů odeslaných za sekundu>
output: <output_id>
Průchodnost logů¶
Můžete definovat počet logů produkovaných každou sekundu (EPS - events per second).
Následující konfigurace bude produkovat 20 logů každou sekundu:
input:Mirage:MirageInput:
eps: 20
Tato konfigurace také přidá odchylku, takže každou sekundu bude počet mezi 10 a 40 logy:
input:Mirage:MirageInput:
eps: 20
deviation: 0.5
Aby bylo možné vytvořit realističtější zdroj logů a změnit EPS během dne, můžete použít scénáře.
input:Mirage:MirageInput:
eps: dayshift
deviation: 0.5
Dostupné možnosti jsou:
- normal
- gaussian
- dayshift
- nightshift
- tiny
- peak
Nakonec můžete vytvořit vlastní scénář. Můžete nastavit EPS každou minutu:
input:Mirage:MirageInput:
eps:
"10:00": 10
"12:00": 20
"15:10": 10
"15:11": 12
"16:00": 5
"23:00": 0
deviation: 0.5
Přidání nových zdrojů logů do Knihovny¶
- Vytvořte nový repozitář pro sběr logů nebo klonujte stávající.
- Vytvořte nový adresář. Pojmenujte adresář po zdroji logů.
- Vytvořte nový soubor pro každý log v adresáři zdrojů. Mirage může stejný log použít vícekrát při odesílání logů skrze kanál. (Nemusíte mít 100 samostatných logových souborů pro odeslání 100 logů - Mirage bude opakovat stejné logy.)
Ve výchozím nastavení, při odesílání logů skrze kanál, vybírá Mirage z vašich logových souborů náhodně a přibližně rovnoměrně, ale můžete přidat váhu logům k jejich změně.
Šablonování logů¶
K získání více unikátních logů bez nutnosti vytvářet více logových souborů, šablonujte vaše logy. Můžete si vybrat, která pole v logu budou mít proměnné hodnoty, poté vytvořit seznam hodnot, které chcete tím polem naplnit, a Mirage náhodně vybere hodnoty.
-
Ve vašem logu vyberte pole, které byste chtěli mít s proměnnými hodnotami. Nahraďte hodnoty pole za
${nazevPole}
, kdenazevPole
je to, čím budete pole ve vašem seznamu nazývat."user.name":${user.name}, "id":${id}, "msg":${msg}
-
Vytvořte soubor nazvaný
values.yaml
ve vašem adresáři zdrojů logů. -
V novém souboru
values.yaml
uveďte možné hodnoty pro každé šablonované pole. Pole ve vašem souboruvalues.yaml
musí odpovídat názvům polí ve vašich logových souborech.values: user.name: - Albus Brumbál - Harry Potter - Hermiona Grangerová id: - 171 - 182 - 193 msg: - Spojení ukončeno - Spojení přerušeno - Spojení úspěšné - Spojení selhalo
Formáty datumu a času¶
Mirage může generovat aktuální časové razítko pro každý log. K tomu musíte zvolit formát, ve kterém bude časové razítko. Pro přidání časového razítka do vašeho mock logu přidejte ${datetime: <format>}
do textu ve vašem souboru.
Example
${datetime: %y-%m-%d %H:%M:%S}
vygeneruje časové razítko 23-06-07 12:55:26
${datetime: %Y %b %d %H:%M:%S:%f}
vygeneruje časové razítko 2023 Jun 07 12:55:26:002651
Direktivy datumu a času¶
Direktivy datumu a času jsou odvozeny od Python modulu datetime
.
Direktiv | Význam | Příklad |
---|---|---|
%a |
Den týdne jako zkrácený název dle místnímu nastavení. | Ne, Po, ..., So (cs_CZ); |
%A |
Den týdne jako plné jméno dle místnímu nastavení. | Neděle, Pondělí, ..., Sobota (cs_CZ); |
%w |
Den týdne jako desetinné číslo, kde 0 je neděle a 6 je sobota. | 0, 1, ..., 6 |
%d |
Den v měsíci jako desetinné číslo doplněné nulou. | 01, 02, ..., 31 |
%b |
Měsíc jako zkrácený název dle místnímu nastavení. | Led, Úno, ..., Pro (cs_CZ); |
%B |
Měsíc jako plné jméno dle místnímu nastavení. | Leden, Únor, ..., Prosinec (cs_CZ); |
%m |
Měsíc jako desetinné číslo doplněné nulou. | 01, 02, ..., 12 |
%y |
Rok bez století jako desetinné číslo doplněné nulou. | 00, 01, ..., 99 |
%Y |
Rok se stoletím jako desetinné číslo. | 0001, 0002, ..., 2013, 2014, ..., 9998, 9999 |
%H |
Hodina (24hodinový cyklus) jako desetinné číslo doplněné nulou. | 00, 01, ..., 23 |
%I |
Hodina (12hodinový cyklus) jako desetinné číslo doplněné nulou. | 01, 02, ..., 12 |
%p |
Místní ekvivalent buď AM nebo PM. | AM, PM (en_US); am, pm (de_DE) |
%M |
Minuta jako desetinné číslo doplněné nulou. | 00, 01, ..., 59 |
%S |
Sekunda jako desetinné číslo doplněné nulou. | 00, 01, ..., 59 |
%f |
Mikrosekunda jako desetinné číslo, doplněné nulou na 6 číslic. | 000000, 000001, ..., 999999 |
%z |
UTC offset ve formě ±HHMM[SS[.ffffff]] (prázdný řetězec, pokud je objekt naivní). | (prázdný), +0000, -0400, +1030, +063415, -030712.345216 |
%Z |
Název časového pásma (prázdný řetězec, pokud je objekt naivní). | (prázdný), UTC, GMT |
%j |
Den v roce jako desetinné číslo doplněné nulou. | 001, 002, ..., 366 |
%U |
Číslo týdne v roce (neděle jako první den týdne) jako desetinné číslo doplněné nulou. Všechny dny v novém roce před první nedělí jsou považovány za týden 0. | 00, 01, ..., 53 |
%W |
Číslo týdne v roce (pondělí jako první den týdne) jako desetinné číslo doplněné nulou. Všechny dny v novém roce před prvním pondělím jsou považovány za týden 0. | 00, 01, ..., 53 |
%c |
Místní vhodné zobrazení data a času. | Út 16 Srp 21:30:00 1988 (cs_CZ); Di 16 Aug 21:30:00 1988 (de_DE) |
%x |
Místní vhodné zobrazení data. | 16.08.88 (cs_CZ); 16.08.1988 (de_DE) |
%X |
Místní vhodné zobrazení času. | 21:30:00 (cs_CZ); 21:30:00 (de_DE) |
%% |
Doslovný znak '%'. | % |
Váha logů¶
Pokud chcete, aby Mirage vybrala některé logy častěji a některé méně často, můžete dát určitým logovým souborům větší váhu. Váha znamená, jak mnohem častěji nebo méně často je logový soubor vybrán v porovnání s ostatními.
Chcete-li změnit váhu, přidejte číslo na začátek názvu logového souboru. Toto číslo vytvoří poměr s ostatními logovými soubory. Pokud soubor nezačíná číslem, Mirage jej považuje za 1.
Example
5-priklad1.log
2-priklad2.log
3-priklad3.log
priklad4.log
Mirage by tyto logy posílal v poměru 5:2:3:1.
Shromažďování do vyhledávání¶
Soubory¶
Chcete-li pravidelně sbírat vyhledávání ze souborů, jako jsou CSV, použijte vstup input:FileBlock:
s následující konfigurací:
path: # Určete složku vyhledávání, kde bude uložen soubor vyhledávání (např. /data/lookups/mylookup/*)
chilldown_period: # Určete, jak často v sekundách kontrolovat nové soubory (výchozí: 5)
FileBlock čte všechny soubory v jednom bloku (jedna událost je celý obsah souboru) a předává je na nakonfigurovaný výstup, což je obvykle output:WebSocket
.
Tímto způsobem je vyhledávání předáváno do LogMan.io Receiver, a nakonec do LogMan.io Parser, kde může být vyhledávání zpracováno a uloženo v Elasticsearch. Viz Parsování vyhledávání pro více informací.
Vzorová konfigurace¶
input:FileBlock:MyLookupFileInput:
path: /data/lookups/mylookup/*
chilldown_period: 10
output: LookupOutput
output:WebSocket:LookupOutput:
url: https://lm1/files-ingestor-ws
...
Výchozí konfigurace sběrače LogMan.io¶
Sběrač TeskaLabs LogMan.io je vybaven výchozí konfigurací navrženou pro rychlou a efektivní integraci s typickými zdroji logů, optimalizující počáteční nastavení a poskytující robustní konektivitu ihned po vybalení.
Výchozí síťové porty pro zdroje logů¶
Níže je uvedena tabulka s výchozími síťovými porty používanými různými technologiemi při připojování ke sběrači LogMan.io. Oba UDP (User Datagram Protocol) a TCP (Transmission Control Protocol) porty jsou k dispozici pro podporu různých potřeb síťové komunikace.
Dodavatel Technologie |
Produkt Varianta |
Rozsah portů | Název proudu | Poznámka |
---|---|---|---|---|
Linux | Syslog RFC 3164 | 10000 10009 |
linux-syslog-rfc3164 |
BSD Syslog Protocol |
Linux | Syslog RFC 5424 | 10020 10029 |
linux-syslog-rfc5424 |
IETF Syslog Protocol |
Linux | rsyslog | 10010 10019 |
linux-rsyslog |
|
Linux | syslog-ng | 10030 10039 |
linux-syslogng |
|
Linux | Auditd | 10040 10059 |
linux-auditd |
|
Fortinet | FortiGate | 10100 10109 |
fortinet-fortigate |
RFC6587 Framing on TCP |
Fortinet | FortiGate | 10110 10119 |
fortinet-fortigate |
|
Fortinet | FortiSwitch | 10120 10129 |
fortinet-fortiswitch |
No Framing on TCP |
Fortinet | FortiSwitch | 10130 10139 |
fortinet-fortiswitch |
|
Fortinet | FortiMail | 10140 10159 |
fortinet-fortimail |
|
Fortinet | FortiClient | 10160 10179 |
fortinet-forticlient |
|
Fortinet | FortiAnalyzer | 10180 10199 |
fortinet-fortianalyzer |
|
Cisco | ASA | 10300 10319 |
cisco-asa |
|
Cisco | FTD | 10320 10339 |
cisco-ftd |
|
Cisco | IOS | 10340 10359 |
cisco-ios |
|
Cisco | ISE | 10360 10379 |
cisco-ise |
|
Cisco | Switch Nexus | 10380 10399 |
cisco-switch-nexus |
|
Cisco | WLC | 10400 10419 |
cisco-wlc |
|
Dell | Switch | 10500 10519 |
dell-switch |
|
Dell | PowerVault | 10520 10539 |
dell-powervault |
|
Dell | iDRAC | 10540 10559 |
dell-idrac |
|
HPE | Aruba Clearpass | 10600 10619 |
hpe-aruba-clearpass |
|
HPE | Aruba IAP | 10620 10639 |
hpe-aruba-iap |
|
HPE | Aruba Switch | 10640 10659 |
hpe-aruba-switch |
|
HPE | Integrated Lights-Out (iLO) | 10660 10679 |
hpe-ilo |
|
HPE | Primera | 10680 10699 |
hpe-primera |
|
HPE | StoreOnce | 10700 10719 |
hpe-storeonce |
|
Bitdefender | Gravity Zone | 10740 10759 |
bitdefender-gravityzone |
|
Broadcom | Brocade Switch | 10760 10779 |
broadcom-brocade-switch |
|
Devolutions | Devolutions Web Server | 10800 10819 |
devolutions-web-server |
|
ESET | Protect | 10840 10859 |
eset-protect |
|
F5 | 10860 10879 |
f5 |
||
FileZilla | 10880 10899 |
filezilla |
||
Gordic | Ginis | 10900 10919 |
gordic-ginis |
|
IceWarp | Mail Server | 10920 10939 |
icewarp-mailserver |
|
Kubernetes | 10940 10959 |
kubernetes |
||
McAfee WebWasher | 10960 10979 |
mcafee-webwasher |
||
MikroTik | 10980 10999 |
mikrotik |
||
Oracle | Listener | 11000 11019 |
oracle-listener |
|
Oracle | Spark | 11020 11039 |
oracle-spark |
|
Ntopng | 11060 11079 |
ntopng |
||
OpenVPN | 11080 11099 |
openvpn |
||
SentinelOne | 11100 11119 |
sentinelone |
||
Squid | Proxy | 11120 11139 |
squid-proxy |
|
Synology | NAS | 11140 11159 |
synology-nas |
|
Veeam | Backup & Replication | 11160 11179 |
veeam-backup-replication |
|
ySoft | SafeQ | 11180 11199 |
ysoft-safeq |
|
Ubiquiti | UniFi | 11200 11219 |
ubiquiti-unifi |
|
VMware | vCenter | 11300 11319 |
vmware-vcenter |
|
VMware | vCloud Director | 11320 11339 |
vmware-vcloud-director |
|
VMware | ESXi | 11340 11359 |
vmware-esxi |
|
ZyXEL | Switch | 11440 11459 |
zyxel-switch |
|
Sophos | Standard Syslog Protocol | 11500 11519 |
sophos-standard-syslog-protocol |
Preferovaný formát protokolování. |
Sophos | Syslog Devide Standard Format | 11520 11539 |
sophos-device-standard-format |
Standardní formát protokolování zařízení je zastaralý. |
Sophos | Unstructured Format | 11540 11559 |
sophos-unstructured |
Ne strukturovaný formát protokolování je zastaralý. |
Custom | 14000 14099 |
custom |
Receiver
LogMan.io Receiver¶
TeskaLabs LogMan.io Receiver je mikroslužba zodpovědná za příjem logů a jiných událostí od LogMan.io kolektoru, jejich přeposílání do centrálního systému LogMan.io a archivaci surových logů. LogMan.io Receiver přeposílá příchozí logy do příslušných tenantů.
Note
LogMan.io Receiver nahrazuje LogMan.io Ingestor.
Komunikační spojení¶
Komunikace mezi lmio-collector
a lmio-receiver
se nazývá "commlink", což je zkratka pro Komunikační Spojení.
Jako primární komunikační protokol je použit websocket, ale také jsou využívány HTTPS volání z kolektoru. Kolektor udržuje websocket spojení s přijímačem otevřené po dlouhou dobu. Když je komunikační spojení z kolektoru ukončeno, kolektor se pokouší pravidelně znovu navázat spojení.
Pozor
Websocket spojení využívá serverem generované PING pakety k udržení websocketu otevřeného.
Komunikační Spojení je chráněno vzájemné SSL autorizací. To znamená, že každý lmio-collector
je vybaven soukromým klíčem a klientským SSL certifikátem. Soukromý klíč a klientský SSL certifikát jsou generovány automaticky během provisioningu nového kolektoru. Soukromý klíč a klientský SSL certifikát se používají k autentizaci kolektoru. Tento mechanismus také poskytuje silné šifrování provozu mezi kolektorem a centrální částí LogMan.io.
Produkční nastavení¶
Produkční nastavení je, že LogMan.io Kolektor (lmio-collector
) se připojuje přes HTTPS přes NGINX server k LogMan.io Přijímači (lmio-receiver
).
graph LR
lmio-collector -- "websocket & SSL" --> n[NGINX]
n[NGINX] --> lmio-receiver
Diagram: Produkční nastavení
Pro více informací pokračujte na sekci NGINX.
Nesprodukční nastavení¶
Přímé spojení z lmio-collector
na lmio-receiver
je také podporováno. Je vhodné pro nesprodukční nastavení, jako je testování nebo vývoj.
graph LR
lmio-collector -- "websocket & SSL" --> lmio-receiver
Diagram: Nesprodukční nastavení
Vysoká dostupnost¶
TeskaLabs LogMan.io Receiver je navržen tak, aby byl spuštěn v několika instancích, nezávisle na Tenantech LogMan.io. Doporučené nastavení je provozovat jeden TeskaLabs LogMan.io Receiver na každém uzlu centrálního LogMan.io clusteru s nasazeným NGINX.
TeskaLabs LogMan.io Collector používá DNS round-robin balancování pro připojení k jednomu z NGINX serverů. NGINX přesměruje příchozí komunikační odkazy na instanci receiveru, s preferencí receiveru běžícího na stejném uzlu jako NGINX.
Více než jedna lmio-receiver
instance může být provozována na uzlu clusteru, například pokud se výkon jediné instance lmio-receiver
stane úzkým hrdlem.
Příklad konfigurace vysoké dostupnosti
graph LR
c1[lmio-collector] -.-> n1[NGINX]
c1[lmio-collector] --> n2[NGINX]
c1[lmio-collector] -.-> n3[NGINX]
subgraph Node 3
n1[NGINX] --> r1[lmio-receiver]
end
subgraph Node 2
n2[NGINX] --> r2[lmio-receiver]
end
n2[NGINX] -.-> r1[lmio-receiver]
n2[NGINX] -.-> r3[lmio-receiver]
subgraph Node 1
n3[NGINX] --> r3[lmio-receiver]
end
Scénáře obnovy po selhání¶
- Instance
lmio-receiver
je ukončena: NGINX přerozděluje commlinks na další instance receiveru na jiných uzlech. - NGINX je ukončen: collector se znovu připojí k jinému NGINX v clusteru.
- Celý uzel clusteru je ukončen: collector se znovu připojí k jinému NGINX v clusteru.
Konfigurace přijímače¶
Přijímač vyžaduje následující závislosti:
- Apache ZooKeeper
- NGINX (pro nasazení v produkčním prostředí)
- Apache Kafka
Příklad¶
Toto je minimalistický příklad konfigurace přijímače LogMan.io:
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
[lifecycle]
hot=/data/ssd/receiver
warm=/data/hdd/receiver
cold=/data/nas/receiver
Zookeeper¶
Určete umístění serveru Zookeeper v clusteru.
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
Hint
Pro neprodukční nasazení je možné použít jeden server Zookeeper.
Lifecycle¶
Je potřeba specifikovat jednotlivé fáze lifecycle, obvykle určením cest k souborovým systémům.
[lifecycle]
hot=/data/ssd/receiver
warm=/data/hdd/receiver
cold=/data/nas/receiver
task_limit=20
Název fáze lifecycle (tj. 'hot', 'warm', 'cold') nesmí obsahovat znak "_".
Podrobnosti naleznete v kapitole Lifecycle.
Volba task_limit
určuje maximální počet současně běžících úloh lifecycle na tomto uzlu. Výchozí hodnota je 20.
Warning
Neměňte cesty lifecycle po té, co přijímač již data uložil. Změna cest se neprojeví retrospektivně a přijímač nebude schopen data pro danou fázi lifecycle nalézt.
Web API¶
Přijímač poskytuje dvě Web API: veřejné a soukromé.
Veřejné Web API¶
Veřejné Web API je určeno pro komunikaci se sběrači.
[web:public]
listen=3080
Výchozí port veřejného webového API je tcp/3080.
Tento port je určen k použití jako upstream NGINX pro připojení od sběračů. Jedná se o doporučené produkční nastavení.
Samostatné Veřejné Web API¶
Můžete provozovat lmio-receiver
bez NGINX v samostatném neprodukčním nastavení.
Warning
Nepoužívejte tento režim pro produkční nasazení.
Toto je ideální pro vývojová a testovací prostředí, protože nepotřebujete NGINX.
Toto je příklad konfigurace:
[web:public]
listen=3443 ssl:web:public
[ssl:web:public]
key=${THIS_DIR}/server-key.pem
cert=${THIS_DIR}/server-cert.pem
verify_mode=CERT_OPTIONAL
Toto je způsob, jak vygenerovat samopodepsaný serverový certifikát pro výše uvedenou konfiguraci:
$ openssl ecparam -genkey -name secp384r1 -out server-key.pem
$ openssl req -new -x509 -subj "/OU=LogMan.io Receiver" -key server-key.pem -out server-cert.pem -days 365
Soukromé Web API¶
[web]
listen=0.0.0.0 8950
Výchozí port soukromého webového API je tcp/8950.
Certificate Authority¶
Přijímač automaticky vytváří Certificate Authority používanou pro provisioning sběračů.
Artefakty CA jsou uloženy v Zookeeper ve složce /lmio/receiver/ca
.
./lmio-receiver.py -c ./etc/lmio-receiver.conf
29-Jun-2023 19:43:50.651408 NOTICE asab.application is ready.
29-Jun-2023 19:43:51.716978 NOTICE lmioreceiver.ca.service Certificate Authority created
...
Výchozí konfigurace CA:
[ca]
curve=secp384r1
auto_approve=no
Volba auto_approve
automatizuje proces registrace sběračů, každý přijatý CSR je automaticky schválen, pokud je nastavena na yes
.
WebSocket¶
Výchozí konfigurace WebSocketu (ke sběračům)
[websocket]
timeout=30
compress=yes
max_msg_size=4M
Apache Kafka¶
Připojení k Apache Kafka lze konfigurovat:
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
Pokud konfigurace není přítomna, pak nejsou události přeposílány do Apache Kafka.
Archive¶
Archivace je ve výchozím nastavení povolena. Nastavte volbu archive na no
, abyste archivovací funkci vypnuli.
[general]
archive=yes
Metriky¶
Přijímač produkuje vlastní telemetrii a také přeposílá telemetrii od sběračů do konfigurovaného úložiště dat telemetrie, jako je InfluxDB.
[asab:metrics]
...
Signing keys¶
Podpisový klíč se používá k digitálnímu podpisu archivů raw logů.
Můžete určit, jaká EC křivka bude použita pro podpisové klíče.
Výchozí hodnota je prime256v1
, také známá jako secp256r1
.
[signing]
curve=prime256v1
Kolektor¶
Poskytnutí kolektoru¶
Instance kolektoru musí být poskytnuta před tím, než je kolektoru povoleno odesílat logy do TeskaLabs LogMan.io. Poskytnutí je provedeno pouze jednou během životního cyklu kolektoru.
Note
TeskaLabs LogMan.io Receiver provozuje Certifikační autoritu. Poskytnutí je proces schválení CSR, který je ukončený vydáním klientského SSL certifikátu pro kolektor. Tento klientský certifikát je použit kolektorem k autentizaci.
Poskytnutí začíná na straně kolektoru. Minimální YAML konfigurace kolektoru specifikuje URL zprávového bodu LogMan.io pro komunikační linky.
connection:CommLink:commlink:
url: https://recv.logman.example.com/
Když se kolektor spustí, odešle svou žádost o zápis příjemci. Kolektor také vytiskne výstup podobný tomuto:
...
Čeká se na schválení, identita: 'ABCDEF1234567890'
Čeká se na schválení, identita: 'ABCDEF1234567890'
To znamená, že kolektor má jedinečnou identitu ABCDEF1234567890
a že příjemce čeká na schválení tohoto kolektoru.
Na straně příjemce je schválení uděleno následujícím voláním:
curl -X 'PUT' \
http://lmio-receiver/provision/ABCDEF1234567890 \
-H 'Content-Type: application/json' \
-d '{"tenant": "mytenant"}'
Warning
Uvedete správný tenant ve žádosti, místo hodnoty mytenant
.
Hint
Schválení může být uděleno také přes webový prohlížeč na "Schválit CSR přijaté od kolektoru" na http://lmio-receiver/doc
Mějte na paměti, že ABCDEF1234567890
musí být nahrazen skutečnou identitou z výstupu kolektoru.
Tenant musí být specifikován také v žádosti.
Když je toto volání provedeno, kolektor informuje, že je poskytnut a připraven:
Čeká se na schválení, identita: 'ABCDEF1234567890'
29-Jun-2023 02:05:35.276253 NOTICE lmiocollector.commlink.identity.service The certificate received!
29-Jun-2023 02:05:35.277731 NOTICE lmiocollector.commlink.identity.service [sd identity="ABCDEF1234567890"] Ready.
29-Jun-2023 02:05:35.436872 NOTICE lmiocollector.commlink.service [sd url="https://recv.logman.example.com/commlink/v2301"] Connected.
Certifikáty poskytnutých klientů jsou uloženy v ZooKeeper v /lmio/receiver/clients
.
Info
Název tenanta je uložen v generovaném klientském SSL certifikátu.
CSRs, které nejsou poskytnuty do 2 dnů, jsou odstraněny. Poskytnutí může být restartováno, pokud kolektor odešle nový CSR.
Odstranění kolektoru¶
Pro odstranění poskytnutého kolektoru na straně příjemce, smažte příslušný záznam z adresáře ZooKeeper /lmio/receiver/clients
.
To znamená, že jste odvolali povolení kolektoru připojovat se k přijímači.
Warning
Smazání neovlivní aktuálně připojené kolektory. Automatické odpojení je na produktové roadmapě.
Pro odstranění na straně kolektoru, smažte ssl-cert.pem
a ssl-key.pem
, když je kolektor zastavený.
Kolektor zahájí nový zápis pod novou identitou, když bude znovu spuštěn.
Tato akce se nazývá reset identity kolektoru.
Konfigurace kolektoru¶
connection:CommLink:commlink:
url: https://recv.logman.example.com/
input:..:LogSource1:
output: logsource-1
output:CommLink:logsource-1: {}
...
Sekce connection:CommLink:commlink:
Tato sekce konfiguruje komunikační linku do centrální části TeskaLabs LogMan.io.
Konfiguraci lze také poskytnout v konfiguračním souboru aplikace.
Pokud je sekce [commlink]
přítomna, položky z ní jsou načteny před aplikací hodnot z YAML.
Example
Prázdná YAML specifikace:
connection:CommLink:commlink: {}
...
URL je použito z konfiguračního souboru aplikace:
[commlink]
url=https://recv.logman.example.com/
...
Možnost url
Povinná hodnota s URL centrální části LogMan.io.
Musí použít protokol https://
, ne http://
.
Typické hodnoty jsou:
https://recv.logman.example.com/
- pro dedikovaný NGINX server pro příjem logůhttps://logman.example.com/lmio-receiver
- pro jeden DNS doménu na NGINX serveru
Může být také poskytnuto v proměnné prostředí LMIO_COMMLINK_URL
.
Možnost insecure
Volitelná (výchozí: no
) Booleovská hodnota, která při nastavení na yes
umožňuje nezabezpečené připojení k serveru.
Tato možnost umožňuje použití self-signed SSL certifikátů serveru.
Danger
Nepoužívejte možnost insecure
v produkčních konfiguracích.
Tip
Toto je jednoduchý způsob, jak můžete specifikovat důvěryhodný vlastní CA certifikát, abyste nemuseli nastavovat insecure: yes
.
connection:CommLink:commlink: {}
url: https://recv.logman.example.com/
cadata: |
-----BEGIN CERTIFICATE-----
<PEM form of the CA certificate>
-----END CERTIFICATE-----
...
Můžete specifikovat více než jeden CA certifikát. Mind the proper YAML formating, you need to indent the PEM block.
Můžete také použít cafile
a capath
k určení cest k vašemu CA.
Pokročilé možnosti konfigurace SSL¶
Následující konfigurační možnosti specifikují SSL (HTTPS) připojení:
cert
: Cesta ke klientskému SSL certifikátukey
: Cesta k privátnímu klíči klientského SSL certifikátupassword
: Heslo souboru s privátním klíčem (volitelné, výchozí: žádné)cafile
: Cesta k PEM souboru s CA certifikátem(i) pro ověření SSL serveru (volitelné, výchozí: žádné)capath
: Cesta k adresáři s CA certifikátem(i) pro ověření SSL serveru (volitelné, výchozí: žádné)cadata
: jeden nebo více PEM-encoded CA certifikátů pro ověření SSL serveru (volitelné, výchozí: žádné)ciphers
: SSL ciphers (volitelné, výchozí: žádné)dh_params
: Parametry pro výměnu klíčů Diffie–Hellman (D-H) (TLS) (volitelné, výchozí: žádné)verify_mode
: Jedna z CERT_NONE, CERT_OPTIONAL nebo CERT_REQUIRED (volitelné); pro více informací, viz: github.com/TeskaLabs/asab
Sekce output:CommLink:<stream>:
<stream>
Název streamu v archivu a v tématech Apache Kafka.
Logy budou přiváděny do názvu streamu received.<tenant>.<stream>
.
{}
znamená na konci, že pro tento výstup nejsou žádné možnosti.
Note
Platí také obecné možnosti pro output:
.
Jako například debug: true
pro ladění.
Více zdrojů¶
Kolektor může zpracovávat více zdrojů logů (event lanes) z jedné instance.
Pro každý zdroj přidejte sekce input:..
a output:CommLink:...
do konfigurace.
Example
connection:CommLink:commlink:
url: https://recv.logman.example.com/
# První (TCP) zdroj logů
input:Stream:LogSource1:
address: 8888 # Poslouchá na TCP/8888
output: tcp-8888
output:CommLink:tcp-8888: {}
# Druhý (UDP) zdroj logů
input:Datagram:LogSource2:
address: 8889 # Poslouchá na UDP/8889
output: udp-8889
output:CommLink:udp-8889: {}
# Třetí (UDP + TCP) zdroj logů
input:Stream:LogSource3s:
address: 8890 # Poslouchá na TCP/8890
output: p-8890
input:Datagram:LogSource3d:
address: 8890 # Poslouchá na UDP/8890
output: p-8890
output:CommLink:p-8890: {}
Warning
Zdroje logů shromažďované jednou instancí kolektoru musí sdílet jeden tenant.
Způsoby doručení¶
Když je kolektor online, logy a další události jsou doručeny okamžitě přes Websocket.
Když je kolektor offline, logy jsou uloženy v offline bufferu a jakmile se kolektor znovu připojí, buffered logy jsou synchronizovány zpět. Tento způsob doručení se nazývá syncback. Buffered logy jsou nahrány pomocí HTTP PUT žádosti.
Offline buffer¶
Když není kolektor připojen k příjemci, logy jsou uloženy v lokálním bufferu kolektoru a nahrány k příjemci ihned po obnovení konektivity.
Buffered logy jsou při uložení v offline bufferu komprimovány pomocí xz
.
Lokální buffer je adresář na souborovém systému, umístění této složky lze konfigurovat:
[general]
buffer_dir=/var/lib/lmio-receiver/buffer
Warning
Kolektor sleduje dostupnou kapacitu disku v této složce a přestane bufferovat logy, pokud je volné méně než 5% místa na disku.
Připojení během údržby¶
Kolektor se připojuje každý den během údržby - obvykle ve 4:00 ráno. Toto je k obnovení vyvážené distribuce připojených kolektorů napříč clusterem.
Archiv¶
LogMan.io Receiver archiv je neměnný, sloupcově orientovaný a pouze přídavný úložiště dat z přijatých surových logů.
Každý komunikační kanál dodává data do streamu.
Stream je nekonečná tabulka s poli.
Název streamu je složen z předpony received.
, názvu tenanta a komunikačního kanálu (např. received.mytenant.udp-8889
).
Archivní stream obsahuje následující pole pro každý logový záznam:
raw
: Surový log (řetězec, digitálně podepsaný)row_id
: Primární identifikátor řádku unikátní napříč všemi streamy (64bitové neznaménkové celé číslo)collected_at
: Datum a čas sběru logu na sběračireceived_at
: Datum a čas přijetí logu na přijímačisource
: Popis zdroje logu (řetězec)
Pole source
obsahuje:
- pro TCP vstupy:
<ip adresa> <port> S
(S označuje stream) - pro UDP vstupy:
<ip adresa> <port> D
(D označuje datagram) - pro souborové vstupy: název souboru
- pro ostatní vstupy: volitelná specifikace zdroje
Pole source
pro log doručený přes UDP
192.168.100.1 61562 D
Log byl nasbírán z IP adresy 192.168.100.1 a portu UDP/61562.
Partice¶
Každý stream je rozdělen na partice. Partice stejného streamu mohou být umístěny na různých instancích přijímače.
Info
Partice mohou sdílet identická časová období. To znamená, že záznamy dat ze stejného časového rozmezí mohou být nalezeny ve více než jedné partici.
Každá partice má své číslo (part_no
), začínající od 0.
Toto číslo se monotónně zvyšuje pro nové partice v archivu, napříč streamy.
Číslo partice je globálně unikátní v rámci clusteru.
Číslo partice je zakódováno do názvu partice.
Název partice je 6 znakový název, který začíná aaaaaa
(tedy partice #0) a pokračuje aaaaab
(partice #1) a tak dále.
Partici lze prozkoumat v Zookeeperu:
/lmio/receiver/db/received.mytenant.udp-8889/aaaaaa.part
partno: 0 # Číslo partice se překládá na aaaaaa
count: 4307 # Počet řádků v této partici
size: 142138 # Velikost partice v bajtech (nekomprimováno)
created_at:
iso: '2023-07-01T15:22:53.265267'
unix_ms: 1688224973265267
closed_at:
iso: '2023-07-01T15:22:53.283168'
unix_ms: 1688224973283167
extra:
address: 192.168.100.1 49542 # Adresa sběrače
identity: ABCDEF1234567890 # Identita sběrače
stream: udp-8889
tenant: mytenant
columns:
raw:
type: string
collected_at:
summary:
max:
iso: '2023-06-29T20:33:18.220173'
unix_ms: 1688070798220173
min:
iso: '2023-06-29T18:25:03.363870'
unix_ms: 1688063103363870
type: timestamp
received_at:
summary:
max:
iso: '2023-06-29T20:33:18.549359'
unix_ms: 1688070798549359
min:
iso: '2023-06-29T18:25:03.433202'
unix_ms: 1688063103433202
type: timestamp
source:
summary:
token:
count: 2
type: token:rle
Tip
Protože je název partice globálně unikátní, je možné partici přesunout na sdílené úložiště, např. NAS nebo cloudové úložiště z různých uzlů clusteru. Celoživotní cyklus je navržen tak, aby se názvy particí nekolidovaly, takže data nebudou přepsána různými přijímači, ale správně sestavena na "sdíleném" úložišti.
Životní cyklus¶
Životní cyklus partice je definován pomocí fází.
Ingest partice jsou partice, které přijímají data. Jakmile je příjem dokončen, tedy přestane se do této partice zapisovat, je uzavřena. Partice nemohou být znovu otevřeny.
Když je partice uzavřena, začíná její životní cyklus. Každá fáze je konfigurována tak, aby ukazovala na specifický adresář na souborovém systému.
Životní cyklus je definován na úrovni streamu, ve vstupu /lmio/receiver/db/received...
v ZooKeeperu.
Tip
Partice lze také ručně přesunout do požadované fáze pomocí API volání.
Výchozí životní cyklus¶
Výchozí životní cyklus se skládá ze tří fází: hot, warm a cold.
graph LR
I(Ingest) --> H[Hot];
H --1 týden--> W[Warm];
W --6 měsíců--> D(Smazání);
H --ihned-->C[Cold];
C --18 měsíců--> CD(Smazání);
Příjem je prováděn ve hot fázi. Jakmile je příjem dokončen a partice uzavřena, je partice zkopírována do cold fáze. Po týdnu je partice přesunuta do warm fáze. To znamená, že partice je duplikována - jedna kopie je ve úložišti cold fáze, druhá kopie je ve úložišti warm fáze.
Partice v úložišti warm fáze je smazána po 6 měsících.
Partice v úložišti cold fáze je komprimována pomocí xz/LZMA. Partice je smazána z cold fáze po 18 měsících.
Definice výchozího životního cyklu
define:
type: jizera/stream
ingest: # (1)
phase: hot
rotate_size: 30G
rotate_time: daily
lifecycle:
hot:
- move: # (2)
age: 1w
phase: warm
- copy: # (3)
phase: cold
warm:
- delete: # (4)
age: 6M
cold:
- compress: # (5)
type: xz
preset: 6
threads: 4
- delete: # (6)
age: 18M
- Příjem nových logů do hot fáze.
- Po jednom týdnu přesunout partici z hot do warm fáze.
- Ihned po uzavření příjmu zkopírovat partici do cold fáze.
- Smazat partici po 6 měsících.
- Partici komprimovat okamžitě po příchodu do cold fáze.
- Smazat partici po 18 měsících z cold fáze.
Doporučení pro ukládání fází:
- Hot fáze by měla být umístěna na SSD
- Warm fáze by měla být umístěna na HDD
- Cold fáze je archiv, může být umístěna na NAS nebo pomalých HDD.
Note
Pro více informací navštivte Administrativní manuál, kapitolu o Diskovém úložišti.
Pravidla životního cyklu¶
move
: Přesunout partici ve specifikovanémage
do specifikovanéphase
.copy
: Zkopírovat partici ve specifikovanémage
do specifikovanéphase
.delete
: Smazat partici ve specifikovanémage
.
age
může být např. "3h" (tři hodiny), "5M" (pět měsíců), "1y" (jeden rok) a podobně.
Podporované postfixy age
:
y
: rok, resp. 365 dníM
: měsíc, resp. 31 dníw
: týdend
: denh
: hodinam
: minuta
Note
Pokud není age
zadáno, pak je věk nastaven na 0, což znamená, že akce životního cyklu je provedena ihned.
Pravidlo komprese¶
compress
: Komprimovat data při příjmu do fáze.
Aktuálně je podporován type: xz
s následujícími možnostmi:
preset
: Xz kompresní úroveň.
Komprese může být zhruba rozdělena do tří kategorií:
0...2
Rychlé úrovně s relativně nízkou paměťovou náročností. 1 a 2 by měly poskytnout kompresní rychlost a poměr srovnatelný s bzip2 1 a bzip2 9, resp.
3...5
Dobré kompresní poměry s nízkou až střední paměťovou náročností. Tyto úrovně jsou výrazně pomalejší než úrovně 0-2.
6...9
Vynikající komprese se střední až vysokou paměťovou náročností. Tyto úrovně jsou také pomalejší než nižší úrovně.
Výchozí je úroveň 6.
Pokud nechcete maximalizovat kompresní poměr, pravděpodobně nechcete použít úroveň vyšší než 7 kvůli rychlosti a paměťové náročnosti.
threads
: Maximální počet CPU vláken použitých pro kompresi.
Výchozí je 1.
Nastavte na 0 pro použití tolika vláken, kolik je jader procesoru.
Manuální dekomprese
Můžete použít xz --decopress
nebo unxz
z XZ Utils.
Můžete použít 7-Zip pro dekompresi souborů archivu na Windows.
Vždy pracujte s kopiemi souborů v archivu; nejprve zkopírujte všechny soubory z archivu a neměňte (dekomprimujte) soubory v archivu.
Pravidlo replikace¶
replica
: Určuje počet kopií dat (replik), které by měly být přítomny ve fázi.
Repliky jsou uloženy na různých instancích přijímače, takže počet replik by NEMĚL být vyšší než počet přijímačů v clusteru, který provozuje danou fázi. Jinak "nadměrné" repliky nebudou vytvořeny, protože se nenalezne dostupná instance přijímače.
Replikace ve fázi hot
define:
type: jizera/stream
lifecycle:
hot:
- replica:
factor: 2
...
factor
: Počet kopií dat ve fázi, výchozí hodnota je 1.
Rotace¶
Partice rotace je mechanismus, který uzavírá partice pro příjem za specifických podmínek. Když je partice pro příjem uzavřena, nová data jsou ukládána do nově vytvořené další partice pro příjem. Tím je zajištěno více či méně rovnoměrné rozdělení nekonečného proudu dat.
Rotace je konfigurována na úrovni streamu pomocí:
rotate_time
: období (např.daily
), po které může být partice v režimu příjmurotate_size
: maximální velikost partice; postfixyT
,G
,M
ak
jsou podporovány pomocí základu 10.
Obě možnosti mohou být použity současně.
Výchozí rotace streamu je daily
a 30G
.
Plán
Pouze možnost daily
je momentálně dostupná pro rotate_time
.
Vydávání dat¶
Data mohou být extrahována z archivu (např. pro zpracování třetími stranami, migraci a podobně) kopírováním adresáře dat particí v rámci vydávání.
Použijte Zookeeper k identifikaci, které partice jsou v rámci vydávání a kde jsou fyzicky umístěny na úložištích.
Sloupec raw
může být přímo zpracován nástroji třetích stran.
Pokud jsou data komprimována konfigurací životního cyklu, může být potřeba dekomprese.
Note
To znamená, že nemusíte partici přesouvat například z cold fáze do warm nebo hot fáze.
Přehrávání dat¶
Archivované logy lze přehrát do následných centrálních komponent.
Nenapadnutelnost¶
Archiv je kryptograficky zabezpečený, navržený pro sledovatelnost a nenapadnutelnost. Digitální podpisy se používají k ověření autenticity a integrity dat, což poskytuje jistotu, že logy nebyly pozměněny a byly skutečně vygenerovány uvedeným zdrojem logu.
Tento přístup založený na digitálních podpisech k udržování logů je zásadním prvkem bezpečných logovacích praktik a pilířem robustního informačního bezpečnostního management systému. Tyto logy jsou klíčové nástroje pro forenzní analýzu během reakcí na incidenty, detekci anomálií nebo škodlivých aktivit, auditování a dodržování předpisů.
K zajištění bezpečnosti logů používáme následující kryptografické algoritmy: SHA256, ECDSA.
Hashovací funkce, SHA256, je aplikována na každý surový logový záznam. Tato funkce vezme vstupní surový logový záznam a vytvoří řetězec bajtů pevné délky. Výstup (nebo hash) je unikátní pro vstupní data; mírná změna ve vstupu vytvoří dramaticky odlišný výstup, což je charakteristika známá jako "efekt laviny".
Tento unikátní hash je poté podepsán pomocí privátního podpisového klíče prostřednictvím ECDSA algoritmu, který generuje digitální podpis, který je unikátní jak pro data, tak pro klíč. Tento digitální podpis je uložen spolu se surovými logovými daty, což certifikuje, že data logu pocházejí z daného zdroje logu a nebyla během uložení pozměněna.
Digitální podpisy sloupců raw
jsou uloženy v ZooKeeperu (kanonické umístění) a v souborovém systému pod názvem col-raw.sig
.
Každá partice je také vybavena jedinečným SSL podpisovým certifikátem, pojmenovaným signing-cert.der
.
Tento certifikát, ve spojení s digitálním podpisem, může být použit k ověření, že col-raw.data
(původní surové logy) nebyly pozměněny, což zajišťuje integritu dat.
Important
Uvědomte si, že přidružený privátní podpisový klíč není uložen nikde, kromě procesní paměti, z bezpečnostních důvodů. Privátní klíč je odstraněn, jakmile partice dokončí svůj příjem dat.
Podpisový certifikát
Odesílání do Kafka¶
Pokud je Apache Kafka konfigurováno v nastavení, každá přijatá log událost je přeposlána LogMan.io Receiverem do Kafka topic. Topic je vytvořen automaticky, když je přeposlána první zpráva.
Název Apache Kafka topic je odvozen od názvu streamu: received.<tenant>.<stream>
, je stejný jako název v archivu.
Příklad Kafka topiců
received.mytenant.udp-8889
received.mytenant.tcp-7781
Surová log událost je odeslána v těle Kafka zprávy.
Následující informace jsou přidány do hlavičky zprávy:
row_id
: Row Id, globálně unikátní identifikátor události v archivu. Není přítomen, pokud je archiv deaktivován. 64bit binární big endian unsigned integer.collected_at
: Datum a čas sběru události, Unix timestamp v mikrosekundách jako řetězec.received_at
: Datum a čas přijetí události, Unix timestamp v mikrosekundách jako řetězec.source
: Zdroj události, řetězec.tenant
: Název tenant, který tuto zprávu přijal, řetězec. (ZASTARALÉ)
Plán
Automatizované nastavení Kafka topicu (jako je počet Kafka partitions) bude implementováno v budoucích verzích.
Konfigurace NGINX¶
Doporučujeme použít dedikovaný virtuální server v NGINX pro LogMan.io Receiver respektive komunikační odkazy z LogMan.io Collector na LogMan.io Receiver.
Tento server sdílí proces NGINX serveru a IP adresu a je provozován na dedikované DNS doméně, odlišné od LogMan.io Web UI.
Například, LogMan.io Web UI běží na http://logman.example.com/ a receiver je dostupný na https://recv.logman.example.com/.
V tomto příkladu logman.example.com
a recv.logman.example.com
mohou být přeloženy na stejnou IP adresu.
Více NGINX serverů může být nakonfigurováno na různých uzlech clusteru, aby zvládaly příchozí spojení od kolektorů, sdílející stejný DNS název. Doporučujeme implementovat tuto možnost pro vysoce dostupné clustery.
upstream lmio-receiver-upstream {
server 127.0.0.1:3080; # (1)
server node-2:3080 backup; # (2)
server node-3:3080 backup;
}
server {
listen 443 ssl; # (3)
server_name recv.logman.example.com;
ssl_certificate recv-cert.pem; # (4)
ssl_certificate_key recv-key.pem;
ssl_client_certificate conf.d/receiver/client-ca-cert.pem; # (5)
ssl_verify_client optional;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EECDH+AES:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;
ssl_stapling on;
ssl_stapling_verify on;
server_tokens off;
add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
location / { # (8)
proxy_pass http://lmio-receiver-upstream;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-SSL-Verify $ssl_client_verify; # (6)
proxy_set_header X-SSL-Cert $ssl_client_escaped_cert;
client_max_body_size 500M; # (7)
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
-
Odkazuje na lokálně běžící
lmio-receiver
, veřejný Web API port. Toto je primární destinace, protože šetří síťový provoz. -
Záložní odkazy na receivery běžící na jiných uzlech clusteru, které běží
lmio-receiver
, v tomto příkladunode-2
anode-3
. Zálohy budou použity, když lokálně běžící instance není dostupná. V instalaci na jednom uzlu tyto položky zcela přeskočte. -
Toto je dedikovaný HTTPS server běžící na https://recv.logman.example.com.
-
Musíte poskytnout SSL serverový klíč a certifikát. Můžete použít samopodepsaný certifikát nebo certifikát poskytovaný certifikační autoritou.
-
Certifikát
client-ca-cert.pem
je automaticky vytvořenlmio-receiver
. Viz část "Client CA certifikát". -
Toto ověřuje SSL certifikát klienta (
lmio-collector
) a předává tuto informacilmio-receiver
. -
lmio-collector
může nahrávat části buffered logů. -
URL cesta, kde je vystavena API
lmio-collector
.
Ověření SSL web serveru
Po dokončení konfigurace NGINX vždy ověřte kvalitu konfigurace SSL pomocí např. Qualsys SSL Server test. Měli byste získat celkové hodnocení "A+".
Příkaz OpenSSL pro generování samopodepsaného serverového certifikátu
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 \
-keyout recv-key.pem -out recv-cert.pem -sha256 -days 380 -nodes \
-subj "/CN=recv.logman.example.com" \
-addext "subjectAltName=DNS:recv.logman.example.com"
Tento příkaz generuje samopodepsaný certifikát pomocí kryptografie eliptické křivky se zakřivením secp384r1
.
Certifikát je platný 380 dní a obsahuje SAN rozšíření pro specifikaci názvu hostitele recv.logman.example.com
.
Soukromý klíč a certifikát jsou uloženy do recv-key.pem
a recv-cert.pem
respektive.
Client CA certifikát¶
NGINX potřebuje soubor client-ca-cert.pem
pro možnost ssl_client_certificate
.
Tento soubor je generován lmio-receiver
během prvního spuštění, je to export certifikátu klientské CA z Zookeeper od lmio/receiver/ca/cert.der
.
Z tohoto důvodu musí být lmio-receiver
spuštěn před tím, než je vytvořena konfigurace tohoto virtuálního serveru NGINX.
lmio-receiver
vygeneruje tento soubor do složky ./var/ca/client-ca-cert.pem
.
docker-compose.yaml
lmio-receiver:
image: docker.teskalabs.com/lmio/lmio-receiver
volumes:
- ./nginx/conf.d/receiver:/app/lmio-receiver/var/ca
...
nginx:
volumes:
- ./nginx/conf.d:/etc/nginx/conf.d
...
Jedna DNS doména¶
lmio-receiver
může být alternativně umístěn na stejné doméně a portu jako LogMan.io Web IU.
V tomto případě je API lmio-receiver
vystaveno na podcestě: http://logman.example.com/lmio-receiver
Ukázka z konfigurace NGINX pro HTTPS server "logman.example.com".
upstream lmio-receiver-upstream {
server 127.0.0.1:3080;
server node-2:3080 backup;
server node-3:3080 backup;
}
...
server {
listen 443 ssl;
server_name logman.example.com;
...
ssl_client_certificate conf.d/receiver/client-ca-cert.pem;
ssl_verify_client optional;
...
location /lmio-receiver {
rewrite ^/lmio-receiver/(.*) /$1 break;
proxy_pass http://lmio-receiver-upstream;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-SSL-Verify $ssl_client_verify;
proxy_set_header X-SSL-Cert $ssl_client_escaped_cert;
client_max_body_size 500M;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
V tomto případě musí být nastavení lmio-collector
CommLink:
connection:CommLink:commlink:
url: https://logman.example.com/lmio-receiver/
...
Load balancing a vysoká dostupnost¶
Load balancing je nakonfigurován pomocí sekce upstream
konfigurace NGINX.
upstream lmio-receiver-upstream {
server node-1:3080;
server node-2:3080 backup;
server node-3:3080 backup;
}
Kolektor se připojuje k příjemci prostřednictvím NGINX pomocí dlouhotrvajícího WebSocket spojení (Commlink). NGINX se nejprve pokusí předat příchozí spojení na "node-1". Pokud to selže, pokusí se předat jednoho ze záloh: "node-2" nebo "node-3". "node-1" je přednostně "localhost", takže síťový provoz je omezen, ale může být překonfigurován jinak.
Protože spojení WebSocket je trvalé, webový socket zůstane připojen k "záložnímu" serveru, i když se primární server stane znovu online. Kolektor se znovu připojí "při údržbě" (denně, během noci) k obnovení správného vyvážení.
Tento mechanismus také poskytuje funkci vysoké dostupnosti instalace. Když je NGINX nebo instance příjemce dole, kolektory se připojí k jiné instanci NGINX a tato instance předá tato spojení dostupným příjemcům.
Pro rozložení příchozího webového provozu mezi dostupné instance NGINX se doporučuje vyvážení DNS round-robin. Ujistěte se, že hodnota TTL DNS souvisejících záznamů (A, AAAA, CNAME) je nastavena na nízkou hodnotu, například 1 minutu.
Interní Architektura Přijímače¶
Architektura¶
Commlink¶
MessagePack je použit pro doručování logů/událostí jak v instant tak syncback režimu.
Commlink je také použit pro obousměrné doručování JSON zpráv, jako jsou metriky kolektoru, které jsou zasílány do InfluxDB v centrálním clusteru.
Struktura Archivu¶
- Stream: identifikovaný podle Stream Name
- Partition: identifikovaná podle Partition Number
- Row: identifikovaná podle Row Number, respektive podle Row Id
- Column: identifikovaná podle názvu.
- Row: identifikovaná podle Row Number, respektive podle Row Id
- Partition: identifikovaná podle Partition Number
Stream je nekonečná datová struktura rozdělená na partitiony. Partition se vytváří a naplňuje během ingestování řádků. Jakmile partition dosáhne určité velikosti nebo věku, je rotována, což znamená, že partition je uzavřena a vytvoří se nová ingestující partition. Jakmile je partition uzavřena, nemůže být znovu otevřena a zůstává pouze pro čtení po zbytek svého životního cyklu.
Partition obsahuje řádky, které jsou dále rozděleny na sloupce. Struktura sloupců je fixní v jedné partition, ale může být odlišná v jiných partition ve stejném streamu.
Archívní Soubory¶
Data streamů a konkrétních partition jsou uložena na souborovém systému ve složkách, které jsou specifikovány fázemi životního cyklu.
Obsah adresáře /data/ssd/receiver
(hot fáze)
+ received.mytenant.udp-8889
+ aaaaaa.part
+ summary.yaml
+ signing-cert.der
+ col-raw.data
+ col-raw.pos
+ col-raw.sig
+ col-collected_at.data
+ col-received_at.data
+ col-source.data
+ col-source-token.data
+ col-source-token.pos
+ aaaaab.part
+ summary.yaml
+ ...
+ aaaaac.part
+ summary.yaml
+ ...
+ received.mytenant.tcp-7781
...
Adresář partition aaaaaa.part
obsahuje celý obsah partition.
Struktura je stejná pro každou fázi životního cyklu.
Soubor summary.yaml
obsahuje ne-kanonické informace o partition.
Kanonická verze informací je v Zookeeper.
Soubor signing-cert.der
obsahuje SSL certifikát pro ověření digitálních podpisů col-*.sig
.
Certifikát je jedinečný pro každou partition.
Soubory col-*.data
obsahují data pro dané pole.
Číslo Partition / part_no
¶
Nezáporné 24bitové celé číslo, rozsah 0..16,777,216, max. 0xFF_FF_FF.
Číslo partition je dodáváno pomocí sdíleného čítače v Zookeeper, umístěného na /lmio/receiver/db/part.counter
.
To znamená, že každá partition má jedinečné číslo bez ohledu na to, ke kterému streamu patří.
Důvod
10[let] * 365[dní v roce] * 24[hodin denně] * 10[bezpečnost] = 876000 partition (5% z max.)
Číslo partition je často zobrazeno jako řetězec o 6 znacích, například aaaaaa
.
Je to Base-16 zakódovaná verze tohoto celého čísla, používající znaky abcdefghijklmnop
.
Číslo Řádku / row_no
¶
Pozice v rámci partition.
Nezáporné 40bitové celé číslo 0xFF_FF_FF_FF_FF (rozsah 0..1,099,511,627,775)
Důvod
1.000.000 EPS za 24 hodin * 10[bezpečnost] = 860,400,000,000
Id Řádku / row_id
¶
Globální jedinečný 64bitový identifikátor řádku (logu, události).
Protože row_id
je složen z part_no
, zaručuje svou globální jedinečnost nejen v rámci jednoho streamu, ale napříč všemi streamy.
Výpočet
row_id = (part_no << 24) | row_no
row_id:
+------------------------+--------------------------+
| part_no | row_no |
+------------------------+--------------------------+
Typ Sloupce string
¶
Typ sloupce string používá dva typy souborů:
-
col-<column name>.data
: Surová bajtová data vstupů ve sloupci. Každý vstup je sekvenčně přidáván na konec souboru, což z něj činí soubor pouze pro přidávání. Vstupy tak nejsou ukládány s explicitními oddělovači nebo značkami záznamů. Místo toho je poloha každého vstupu sledována v doprovodném souborucol-<column name>.pos
. -
col-<column name>.pos
: Počáteční bajtové pozice každého vstupu v odpovídajícím souborucol-<column name>.data
. Každá pozice je uložena jako 32bitové nezáporné celé číslo. Pozice jsou ukládány sekvenčně v pořadí, v jakém jsou přidávány docol-<column name>.data
. N-té celé číslo v souborucol-<column name>.pos
označuje počáteční pozici N-tého vstupu v souborucol-<column name>.data
. Délka N-tého vstupu je rozdíl mezi N-tým celým číslem a (N+1)-tým celým číslem v souborucol-<column name>.pos
.
Sekvenční Přístup k Datům¶
Sekvenční přístup k datům zahrnuje čtení dat v pořadí, v jakém jsou uložena v souborech sloupce.
Níže jsou kroky k sekvenčnímu přístupu k datům:
-
Otevřete oba soubory
col-<column name>.pos
acol-<column name>.data
. Přečtěte první 32bitové celé číslo ze souborucol-<column name>.pos
. Inicializujte aktuální pozici s hodnotou 0. -
Přečtěte další 32bitové celé číslo, zde označované jako hodnota pozice, ze souboru
col-<column name>.pos
. Výpočet délky vstupu dat je proveden odečtením aktuální pozice od hodnoty pozice. Poté aktualizujte aktuální pozici na nově přečtenou hodnotu pozice. -
Přečtěte data ze souboru
col-<column name>.data
pomocí délky vypočtené v kroku 2. Tato délka dat odpovídá skutečnému obsahu databázového řádku. -
Opakujte kroky 2 a 3 pro čtení dalších řádku. Pokračujte v tomto procesu, dokud nedosáhnete konce souboru
col-<column name>.pos
, což by znamenalo, že všechny řádky dat byly přečteny.
Náhodný Přístup k Datům¶
Pro přístup k N-tému řádku ve sloupci postupujte takto:
-
Přesuňte se na (N-1)-tého pozici v souboru
col-<column name>.pos
nebo na 0, pokud je N == 0. Každá pozice odpovídá 32bitovému celému číslu, takže N-tá pozice odpovídá N-tému 32bitovému číslu. Například pro přístup k 6. řádku se přesuňte na 5. celé číslo (20 bajtů od začátku, protože každé celé číslo má 4 bajty). -
Přečtěte jedno nebo dvě 32bitová celá čísla ze souboru
col-<column name>.pos
. Pokud N == 0, přečtěte pouze jedno celé číslo, pozice je předpokládaná jako 0. První celé číslo označuje počáteční pozici požadovaného vstupu v souborucol-<column name>.data
. Pro N > 0, přečtěte dvě celá čísla. Druhé celé číslo označuje počáteční pozici dalšího vstupu. Rozdíl mezi druhým a prvním číslem dává délku požadovaného vstupu. -
Přesuňte se na pozici v souboru
col-<column name>.data
označenou prvním číslem přečteným v předchozím kroku. -
Přečtěte vstup ze souboru
col-<column name>.data
pomocí vypočtené délky z kroku 2.
Typ Sloupce timestamp
¶
Typ sloupce timestamp používá jeden typ souboru: col-<column name>.data
.
Každé záznam v tomto sloupci je 64bitový Unixový časový razítko představující datum a čas v přesnosti mikrosekund.
Info
Unixový časový razítko je způsob sledování času jako celkového počtu sekund, které uplynuly od 1970-01-01 00:00:00 UTC, bez započítání přestupných sekund.
Přesnost na úrovni mikrosekundy umožňuje sledovat čas ještě přesněji.
Sloupec timestamp shrnuje minimální a maximální časový razítko v každé partition.
Toto shrnutí je v Zookeeper a v souboru summary.yaml
na souborovém systému.
Sekvenční Přístup k Datům¶
Sekvenční přístup ke sloupci timestamp zahrnuje čtení každého časového razítka v pořadí, v jakém jsou uložena:
- Otevřete soubor
col-<column name>.data
. - Přečtěte 64bitové celé číslo ze souboru
col-<column name>.data
. Toto celé číslo je váš Unixový časový razítko v mikrosekundách. - Opakujte krok 2, dokud nedosáhnete konce souboru, což znamená, že jste přečetli všechna časová razítka.
- Zavřete soubor.
Náhodný Přístup k Datům¶
Pro přístup k časovému razítku na specifické pozici řádku (Nth pozice):
- Přesuňte se na N-tou pozici v souboru
col-<column name>.data
. Jelikož každé časové razítko je 64bitové (nebo 8bajtové) celé číslo, pro přístup k N-tému časovému razítku se přesuňte na N * 8. bajt. - Přečtěte 64bitové celé číslo ze souboru
col-<column name>.data
. Toto je váš Unixový časový razítko v mikrosekundách pro N-tý řádek.
Typ Sloupce token
¶
Sloupec typu token je navržen pro ukládání textových dat v optimalizovaném formátu. Je obzvláště vhodný pro scénáře, kde sloupec obsahuje relativně malý počet odlišných, opakujících se hodnot.
Místo přímého ukládání skutečných textových dat kóduje typ sloupce token každý řetězec na celé číslo. Tento kódovací proces je realizován indexem, který je sestaven na základě všech jedinečných textových hodnot v partišním sloupci. Každému jedinečnému řetězci je v tomto indexu přiřazen jedinečný celočíselný identifikátor a tyto identifikátory nahrazují původní řetězce ve sloupci token.
Samotný index je reprezentován pozicí řetězce v páru přidružených souborů: col-<column name>-token.data
a col-<column name>-token.pos
.
Viz typ sloupce string pro více podrobností.
Tento přístup poskytuje významné úspory úložného prostoru a zvyšuje efektivitu dotazů pro sloupce s omezeným množstvím často se opakujících hodnot. Kromě toho umožňuje rychlejší operace porovnávání, protože porovnání celých čísel je obvykle rychlejší než porovnání řetězců.
Nebezpečí
Uvědomte si, že tento přístup nemusí přinést výhody, pokud je počet unikátních textových hodnot velký nebo pokud jsou textové hodnoty většinou jedinečné. Režie na udržování indexu by mohla převážit výhody úspory místa a výkonu pomocí kompaktního úložiště celých čísel.
Typ sloupce token používá tři typy souborů:
col-<column name>.data
: Index hodnot sloupce, každý reprezentovaný jako 16bitové nezáporné celé číslo.col-<column name>-token.data
acol-<column name>-token.pos
: Index používá stejnou strukturu jako typ sloupce string. Pozice řetězce v těchto souborech představuje kódovanou hodnotu řetězce ve sloupci token.
Sekvenční Přístup k Datům¶
Sekvenční přístup ke sloupci token zahrnuje čtení každého tokenu v pořadí, v jakém jsou uloženy.
To se provádí pomocí indexů uložených v souboru col-<column name>.data
a jejich překladem na skutečné textové hodnoty pomocí souborů col-<column name>-token.data
a col-<column name>-token.pos
.
Zde jsou kroky k sekvenčnímu přístupu k datům:
- Otevřete soubor
col-<column name>.data
. Tento soubor obsahuje 16bitová nezáporná celá čísla, která slouží jako indexy do seznamu tokenů. - Přečtěte 16bitové nezáporné celé číslo ze souboru
col-<column name>.data
. To je index vašeho tokenového řetězce. - Použijte "Náhodný přístup k datům" z typu sloupce string na souborech
col-<column name>-token.data
acol-<column name>-token.pos
k získání textové hodnoty. - Opakujte kroky 2 a 3, dokud nedosáhnete konce souboru
col-<column name>.data
, což naznačuje, že všechny tokeny byly přečteny. - Zavřete všechny soubory.
Náhodný Přístup k Datům¶
Náhodný přístup ve sloupci token umožňuje získat jakýkoliv záznam bez potřeby procházet předchozí záznamy. To může být zvláště výhodné ve scénářích, kde je potřeba získat pouze konkrétní záznamy, nikoli celý dataset.
Pro přístup k tokenu na specifické pozici řádku (Nth pozice):
- Přesuňte se na N-tou pozici v souboru
col-<column name>.data
. Každý záznam indexu je 16bitové (nebo 2bajtové) celé číslo, proto se pro dosažení N-tého záznamu přesuňte na N * 2. bajt. - Přečtěte 16bitové celé číslo ze souboru
col-<column name>.data
. Toto je váš indexový záznam pro N-tý řádek. - Použijte "Náhodný přístup k datům" z typu sloupce string na souborech
col-<column name>-token.data
acol-<column name>-token.pos
k získání textové hodnoty.
Typ Sloupce token:rle
¶
Sloupec typu token:rle rozšiřuje typ sloupce token přidáním Run-Length Encoding (RLE) pro další optimalizaci úložiště. Tento typ je obzvlá
Parsec
LogMan.io Parsec¶
TeskaLabs LogMan.io Parsec je mikroservis zodpovědný za parsování logů z různých Kafka témat. LogMan.io Parsec vkládá logy do jednoho EVENTS
Kafka tématu, pokud parsování uspěje, a do OTHERS
Kafka tématu, pokud parsování selže.
Parsování je proces analyzování původního logu (který je typicky ve formátu jednoho/víceřádkového řetězce, JSON, nebo XML) a transformace do seznamu dvojic klíč-hodnota, které popisují log data (jako například kdy se původní událost stala, priorita a závažnost logu, informace o procesu, který log vytvořil, atd.).
Note
LogMan.io Parsec nahrazuje LogMan.io Parser.
Jednoduchý příklad parsování
Parsování vezme syrový log, jako například tento:
<30>2023:12:04-15:33:59 hostname3 ulogd[1620]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth2.3009" outitf="eth6" srcmac="e0:63:da:73:bb:3e" dstmac="7c:5a:1c:4c:da:0a" srcip="172.60.91.60" dstip="192.168.99.121" proto="17" length="168" tos="0x00" prec="0x00" ttl="63" srcport="47100" dstport="12017"
@timestamp: 2023-12-04 15:33:59.033
destination.ip: 192.168.99.121
destination.mac: 7c:5a:1c:4c:da:0a
destination.port: 12017
device.model.identifier: SG230
dns.answers.ttl 63
event.action: Packet dropped
event.created: 2023-12-04 15:33:59.033
event.dataset: sophos
event.id: 2001
event.ingested: 2023-12-04 15:39:10.039
event.original: <30>2023:12:04-15:33:59 hostname3 ulogd[1620]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth2.3009" outitf="eth6" srcmac="e0:63:da:73:bb:3e" dstmac="7c:5a:1c:4c:da:0a" srcip="172.60.91.60" dstip="192.168.99.121" proto="17" length="168" tos="0x00" prec="0x00" ttl="63" srcport="47100" dstport="12017"
host.hostname: hostname3
lmio.event.source.id: hostname3
lmio.parsing: parsec
lmio.source: mirage
log.syslog.facility.code: 3
log.syslog.facility.name: daemon
log.syslog.priority: 30
log.syslog.severity.code: 6
log.syslog.severity.name: information
message id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth2.3009" outitf="eth6" srcmac="e0:63:da:73:bb:3e" dstmac="7c:5a:1c:4c:da:0a" srcip="172.60.91.60" dstip="192.168.99.121" proto="17" length="168" tos="0x00" prec="0x00" ttl="63" srcport="47100" dstport="12017"
observer.egress.interface.name: eth6
observer.ingress.interface.name: eth2.3009
process.name: ulogd
process.pid: 1620
sophos.action: drop
sophos.fw.rule.id: 60002
sophos.prec: 0x00
sophos.protocol: 17
sophos.sub: packetfilter
sophos.sys: SecureNet
sophos.tos: 0x00
source.bytes: 168
source.ip: 172.60.91.60
source.mac: e0:63:da:73:bb:3e
source.port: 47100
tags: lmio-parsec:v23.47
tenant: default
_id: e1a92529bab1f20e43ac8d6caf90aff49c782b3d6585e6f63ea7c9346c85a6f7
_prev_id: 10cc320c9796d024e8a6c7e90fd3ccaf31c661cf893b6633cb2868774c743e69
_s: DKNA
LogMan.io Parsec Konfigurace¶
Závislosti LogMan.io Parsec:
- Apache Kafka: Zdroj neparsovaných událostí a cíl parsovaných událostí.
- Apache Zookeeper: Obsah knihovny, hlavně parsovací pravidla, ale také další sdílené informace o clusteru.
Minimální konfigurace s event lane¶
LogMan.io Parsec může být nakonfigurován s nebo bez event lane. Doporučujeme použít první možnost.
Když je použit event lane, LogMan.io Parsec čte Kafka témata, cestu pro parsovací pravidla a volitelně charset, schéma a časové pásmo.
Toto je minimální konfigurace pro LogMan.io Parsec s event lane:
[tenant]
name=<tenant> # (1)
[eventlane]
name=/EventLanes/<tenant>/<eventlane>.yaml #(2)
[library]
providers=
zk:///library
...
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092 # (3)
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181 # (4)
- Název tenantu, pod kterým služba běží.
- Název event lane použitý pro Kafka témata, cestu pro parsovací pravidla a volitelně charset, schéma a časové pásmo.
- Adresy Kafka serverů v clusteru.
- Adresy Zookeeper serverů v clusteru.
Apache Zookeeper¶
Každá LogMan.io mikroslužba by měla inzerovat sama sebe do Zookeeper.
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
Knihovna¶
Konfigurace knihovny specifikuje odkud jsou načítány deklarace (definice) Parsec.
Knihovna může sestávat z jednoho nebo více poskytovatelů, typicky Zookeeper nebo git repozitáře.
[library]
providers=
zk:///library
# další vrstvy knihovny mohou být zahrnuty
Pozor
Pořadí vrstev je důležité. Vyšší vrstvy přepíší vrstvy pod nimi. Pokud je jeden soubor přítomen ve více vrstvách, pouze ten zahrnutý v nejvyšší vrstvě je načten.
Apache Kafka¶
Připojení k Apache Kafka musí být nakonfigurováno tak, aby bylo možné přijímat a odesílat události:
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
Bez této konfigurace nelze správně navázat spojení k Apache Kafka.
Minimální konfigurace bez event lane¶
Pokud není použit event lane, musí být parsovací pravidla, časové pásmo a schéma zahrnuty v konfiguraci.
Toto je konfigurace požadovaná pro LogMan.io Parsec když není použit event lane:
[pipeline:ParsecPipeline:KafkaSource]
topic=received.<tenant>.<stream> # (1)
[pipeline:ParsecPipeline:KafkaSink]
topic=events.<tenant>.<stream> # (2)
[pipeline:ErrorPipeline:KafkaSink]
topic=others.<tenant> # (3)
[tenant]
name=<tenant> # (5)
schema=/Schemas/ECS.yaml # (6)
[parser]
name=/Parsers/<parsing rule> # (4)
[library]
providers=
zk:///library
...
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092 # (7)
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181 # (8)
- Název received tématu, ze kterého jsou události načítány.
- Název events tématu, do kterého jsou úspěšně parsované události odesílány.
- Název others tématu, do kterého jsou neúspěšně parsované události odesílány.
- Specifikujte která parsovací pravidla aplikovat.
- Název tenanta, pod kterým tato instance Parsecu běží.
- Schéma by mělo být uloženo ve složce
/Schemas/
v knihovně. - Adresy Kafka serverů v clusteru.
- Adresy Zookeeper serverů v clusteru.
Parsovací pravidlo¶
Každý parsek musí vědět, jaká parsovací pravidla aplikovat.
[parser]
name=/Parsers/<parsing rule>
Název parseru specifikuje cestu, odkud jsou načítány deklarace parsovacích pravidel.
MUSÍ BÝT uloženy ve složce /Parsers/
.
Parsovací pravidla jsou YAML soubory.
Standardní formát cesty je <vendor>/<type>
, například Microsoft/IIS
nebo Oracle/Listener
, ale v případě, že je použita pouze jedna technologie, může být použito pouze jméno poskytovatele, například Zabbix
nebo Devolutions
.
Konfigurace event lane¶
Tato sekce volitelně specifikuje významné atributy parsovaných událostí.
[eventlane]
timezone=Europe/Prague
charset=iso8859_2
timezone
: Pokud zdroj logů produkuje logy v konkrétním časovém pásmu, odlišném od tenanta výchozího časového pásma, musí to být zde specifikováno.
Název časového pásma musí být v souladu s IANA Time Zone Database. Interně jsou všechny časové značky převáděny na UTC.
charset
: Pokud zdroj logů produkuje logy v kódování/charsetu odlišném od UTF-8, musí být charset zde specifikován.
Seznam podporovaných charsetů je zde.
Interně je každý text kódován v UTF-8.
Kafka témata¶
Specifikace těchto témat ze kterých přichází původní logy a témat, kde jsou úspěšně parsované a neúspěšně parsované logy odesílány.
Doporučený způsob volby témat je vytvořit jedno 'received' a jedno 'events' téma pro každý event lane, jedno 'others' téma pro každý tenant.
[pipeline:ParsecPipeline:KafkaSource]
topic=received.<tenant>.<stream>
[pipeline:ParsecPipeline:KafkaSink]
topic=events.<tenant>.<stream>
[pipeline:ErrorPipeline:KafkaSink]
topic=events.<tenant>
Varování
Název pipeline ParsecPipeline
byl představen v Parsec verzi v23.37
. Název KafkaParserPipeline
, používaný v předchozích verzích, je zastaralý. Konec životnosti je 30. ledna 2024.
Kafka Consumer Group¶
LogMan.io Parsec často běží ve více instancích v clusteru. Sada instancí, které konzumují ze stejného received tématu, se nazývá Consumer group. Tato skupina je identifikována jedinečným group.id. Každá událost je konzumována jedním a pouze jedním členem skupiny.
LogMan.io Parsec vytváří group.id
automaticky následovně:
- Když je použit event lane,
group.id
má formátlmio-parsec-<tenant>-<eventlane>
. - Když není použit event lane,
group.id
má formátlmio-parsec-<tenant>-<parser name>
. group.id
může být přepsán v konfiguraciParsecPipeline
následovně:
[pipeline:ParsecPipeline:KafkaSource]
group_id=lmio-parsec-<stream>
Varování
Změnou group.id se vytvoří nová consumer group a začne číst události od začátku. (To závisí na parametr auto.offset.reset
Kafka clusteru, který je ve výchozím nastavení earliest
.)
Metriky¶
Parsec produkuje vlastní telemetrii pro monitoring a také předává telemetrii od kolektorů do konfigurovaného úložiště telemetrických dat, jako je InfluxDB. Čtěte více o metrikách.
Zahrnout v konfiguraci:
[asab:metrics]
...
Event Lanes¶
Vztah k LogMan.io Parsec¶
TeskaLabs LogMan.io Parsec čte důležitou část své konfigurace z event lane. Tato konfigurace zahrnuje:
- Kafka témata, ze kterých se přijímají události a do kterých se posílají parsované a chybové události
- Pravidla pro parsování (deklarace)
- (volitelně) časové pásmo, charset a schéma
group.id
pro konzumaci zreceived
tématu
Proto každá instance LogMan.io Parsec běží pod přesně jedním eventlane (pod přesně jedním tenantem).
Note
Čtení konfigurace z event lane bylo zavedeno ve verzi v24.14
.
Deklarace¶
Toto je minimální požadovaná definice event lane, nacházející se v adresáři /EventLanes/<tenant>
v knihovně:
---
define:
type: lmio/event-lane
parsec:
name: /Parsers/path/to/parser # (1)
kafka:
received:
topic: received.tenant.stream
events:
topic: events.tenant.stream
others:
topic: others.tenant
- Cesta k pravidlu pro parsování. Musí začínat
/Parsers
. Standardní formát cesty je<vendor>/<type>
, např.Microsoft/IIS
neboOracle/Listener
, ale v případě, že se používá pouze jedna technologie, může být použit pouze název poskytovatele, např.Zabbix
neboDevolutions
.
Když se spustí Parsec a načte event lane, vytvoří se dva pipeline:
ParsecPipeline
mezi tématy received a eventsErrorPipeline
cílený na téma others
group.id
použitý pro konzumaci z tématu received má tvar: lmio-parsec-<tenant>-<eventlane>
Časové pásmo, schéma, charset¶
Časové pásmo, schéma a charset jsou standardně čteny z konfigurace tenant, ale tyto vlastnosti mohou být přepsány v event lane:
---
define:
type: lmio/event-lane
timezone: UTC
charset: utf-16
schema: /Schemas/CEF.yaml
timezone
: Pokud zdroj logů produkuje logy ve specifickém časovém pásmu, které se liší od výchozího časového pásma tenant, musí to být zde specifikováno.
Název časového pásma musí být v souladu s IANA Time Zone Database. Interně jsou všechny časové údaje převedeny do UTC.
charset
: Pokud zdroj logů produkuje logy v charsetu (nebo kódování) odlišném od UTF-8, musí zde být charset specifikován.
Seznam podporovaných charset je zde.
Interně je každý text kódován v UTF-8.
Výstup z analýzy¶
Když používáte LogMan.io Parsec k analýze logů, výsledkem tohoto procesu je to, co označujeme jako „parsovaná událost“. Tento výstup je zásadním aspektem správy logů, protože transformuje surová data z logů do strukturovaného formátu, který je snazší pochopit, analyzovat a jednat na jeho základě.
Parsovaná událost není jen jakákoli sbírka dat; je to pečlivě strukturovaný výstup, který prezentuje informace ve formátu plochého seznamu. To znamená, že každý kus informace z původního logu je extrahován a prezentován jako pár klíč-hodnota. Tyto páry jsou přímočaré, což usnadňuje identifikaci toho, co každá část dat představuje.
Pary klíč-hodnota¶
-
Klíč: Toto je jedinečný identifikátor, který popisuje typ informace obsažené v hodnotě. Klíče jsou předdefinované štítky, které představují konkrétní aspekty logových dat, jako jsou časová razítka, chybové kódy, uživatelská ID apod. Klíče jsou definovány ve schématu.
-
Hodnota: Toto jsou vlastní data nebo informace spojené s klíčem. Hodnoty se mohou velmi lišit, od číselných kódů a časových značek po textové popisy nebo uživatelské vstupy. Typ hodnoty je definován ve schématu.
Výstupní událost je typicky serializována jako JSON objekt.
Příklad parsované události
{
"@timestamp": 12345678901,
"event.created": 12345678902,
"event.ingested": 12345678903,
"event.original": "<1> 2023-03-01 myhost myapp: Hello world!",
"key1": "value1",
"key2": "value2",
}
Běžná pole parsovaných událostí¶
Warning
Tato kapitola používá ECS schéma!
Z parsec (implicitní):
@timestamp
: Pokud není časová značka parsována, toto pole je automaticky vytvořeno s časem parsování.
Od kolektoru:
event.original
: Původní událost ve svém surovém formátu.event.created
: Čas, kdy byla událost zachycena LogMan.io Sběračem.lmio.source
: Název zdroje logu (vytvořeno LogMan.io Sběračem).
Od příjemce:
event.ingested
: Čas, kdy byla událost zpracována LogMan.io Příjemcem.tenant
: Název rentiera LogMan.io, ve kterém Parsec zpracoval tuto událost, specifikované v konfiguraci._id
: Jedinečný identifikátor události.
Štítky¶
Plán
Bude zde možnost přidávat libovolné štítky k události, což umožní vlastní filtrování.
V tuto chvíli je jediný štítek, který je automaticky přidán do pole tags
, verze LogMan.io Parsec.
Chybové události¶
Když parsování selže nebo dojde k neočekávané chybě, událost je odeslána do jiné Event lane (ErrorPipeline
),
kde je obohacena o informace o tom, kdy a proč se to stalo.
Každá chybová událost obsahuje:
@timestamp
: Čas, kdy byla událost zpracována s chybou v UNIX časovém razítku (počet sekund od epochy).event.original
: Původní událost ve svém surovém formátu.error.message
: Chybová zpráva.error.stack_trace
: Data o tom, kde v kódu došlo k výjimce.event.dataset
: Název datasetu specifikovaného v mapování nebo cesta pro parser v Knihovně.event.created
: Čas, kdy byla událost vytvořena LogMan.io Sběračem.event.ingested
: Čas, kdy byla událost zpracována LogMan.io Příjemcem.tenant
: Název tenanta, kterému byla tato událost určena.
Parsovací pravidla
Deklarace¶
Deklarace popisují, jak by měl být event parsován. Jsou uloženy jako soubory YAML v knihovně. LogMan.io Parsec interpretuje tyto deklarace a vytváří z nich parsovací procesory.
Existují tři typy deklarací:
- Deklarace parseru: Parser bere jako vstup původní event nebo konkrétní pole částečně parsovaného eventu, analyzuje jeho jednotlivé části a ukládá je jako páry klíč-hodnota do eventu.
- Deklarace mapování: Mapování bere jako vstup částečně parsovaný event, přejmenuje názvy polí a eventuálně převádí datové typy. Funguje spolu se schématem (ECS, CEF).
- Deklarace doplňovače: Doplňovač doplňuje částečně parsovaný event o další data.
Tok dat¶
Typická, doporučená sekvence parsování je řetězec deklarací:
- První hlavní deklarace parseru zahajuje řetězec a další parsery (nazývané sub-parsery) extrahují podrobnější data z polí vytvořených předchozím parserem.
- Poté (jediná) deklarace mapování přejmenuje klíče parsovaných polí podle schématu a filtruje pole, která nejsou potřeba.
- Nakonec deklarace doplňovače doplňuje event o další data. Ačkoli je možné použít více souborů doplňovače, doporučuje se použít pouze jeden.
Důležité: Názvoslovné konvence
LogMan.io Parsec načítá deklarace v abecedním pořadí a vytváří odpovídající procesory ve stejném pořadí. Proto vytvářejte seznam souborů deklarací podle těchto pravidel:
-
Začněte všechny názvy souborů deklarací očíslovanou předponou:
10_parser.yaml
,20_parser_message.yaml
, ...,90_enricher.yaml
.Doporučuje se "nechat si místo" v číslování pro budoucí deklarace pro případ, že budete chtít přidat novou deklaraci mezi dvě stávající (např.
25_new_parser.yaml
). -
Do názvů souborů zahrňte typ deklarace:
20_parser_message.yaml
spíše než10_message.yaml
. - Do názvů souborů mapování zahrňte typ použitého schématu:
40_mapping_ECS.yaml
spíše než40_mapping.yaml
.
Příklad:
/Parsers/MůjParser/:
- 10_parser.yaml
- 20_parser_username.yaml
- 30_parser_message.yaml
- 40_mapping_ECS.yaml
- 50_enricher_lookup.yaml
- 60_enricher.yaml
Parsery¶
Deklarace parseru přijímá originální událost nebo konkrétní pole částečně parsované události jako vstup, analyzuje její jednotlivé části a ukládá je jako dvojice klíč-hodnota k události.
LogMan.io Parsec aktuálně podporuje tři typy deklarací parserů:
- JSON parser
- Windows Event parser
- Parsec parser
Struktura deklarace¶
K určení typu deklarace je třeba specifikovat sekci define
.
define:
type: <declaration_type>
Pro deklaraci parseru specifikujte type
jako parser
.
JSON parser¶
JSON parser se používá pro parsování událostí (nebo částí událostí) se strukturou JSON.
define:
name: JSON parser
type: parser/json
field: <custom_field>
target: <custom_target>
Když je specifikováno field
, parsování se aplikuje na toto pole; výchozí je aplikovat to na originální událost.
Když je specifikováno target
, parsed objekt se uloží do určeného cílového pole; výchozí je uložení s klíčem json
. Vlastní cílové pole musí dodržovat regulární výraz json[0-9a-zA-Z]
(začínající "json" následované jakýmkoliv alfanumerickým znakem).
Example
-
Následující originální událost se strukturou JSON je parsována JSON parserem s výchozím nastavením:
{ "key": { "foo": 1, "bar": 2 } }
10_parser.yamldefine: name: JSON parser type: parser/json
Výsledná událost bude:
{ "json": <JSON object>, }
-
Následující událost obsahuje vnitřní část JSON, takže JSON parser může být aplikován na toto předparsované pole a výsledek bude uložen do vlastního pole
jsonMessage
:<14>1 2023-05-03 15:06:12 {"key": {"foo": 1, "bar": 2}}
20_parser_message.yamldefine: name: JSON parser type: parser/json field: message target: jsonMessage
Výsledná událost bude:
{ "log.syslog.priority": 14, "@timestamp": 140994182325993472, "message": "{"key": {"foo": 1, "bar": 2}}", "jsonMessage": <JSON object> }
Windows Event parser¶
Windows Events parser se používá pro parsování událostí, které jsou produkovány Microsoft Windows. Tyto události jsou ve formátu XML.
define:
name: Windows Events Parser
type: parser/windows-event
Toto je kompletní Windows Event parser a bude parsovat události od Microsoft Windows, oddělující jednotlivá pole do dvojic klíč-hodnota.
Parsec parser¶
Parsec parser se používá pro parsování událostí v prostém textovém formátu. Je založen na SP-Lang Parsec expressions.
Pro parsování originálních událostí použijte následující deklaraci:
define:
name: My Parser
type: parser/parsec
parse:
!PARSE.KVLIST
- ...
- ...
- ...
define:
name: My Parser
type: parser/parsec
field: <custom_field>
parse:
!PARSE.KVLIST
- ...
- ...
- ...
Když je specifikováno field
, parsování se aplikuje na toto pole, jinak se aplikuje na originální událost. Proto musí být přítomno v každém subparseru.
Typy specifikací field
:
-
field: <custom_field>
- pravidelné pole předparsované předchozím parserem. -
field: json /key/foo
- JSON klíč/key/foo
z předparsovaného JSON objektujson
. Název JSON objektu a JSON klíč musí být odděleny mezerou. JSON klíč vždy začíná"/"
, a každá další úroveň je oddělena znakem/
. -
JSON klíč se specifikovaným typem, výchozí typ je
string
.
field:
json: /key/foo
type: int
Příklady deklarací Parsec parseru¶
Příklad 1: Jednoduchý příklad
Pro účely příkladu, řekněme, že chceme parsovat sbírku jednoduchých událostí:
Ahoj Miroslave z Prahy!
Ahoj Kristýno z Plzně.
{
"name": "Miroslav",
"city": "Prague"
}
{
"name": "Kristýna",
"city": "Pilsen"
}
define:
type: parser/parsec
parse:
!PARSE.KVLIST
- !PARSE.UNTIL " "
- name: !PARSE.UNTIL " "
- !PARSE.EXACTLY "from "
- city: !PARSE.LETTERS
Příklad 2: Složitější příklad
Pro účely příkladu, řekněme, že chceme parsovat sbírku jednoduchých událostí:
Proces cleaning[123] skončil s kódem 0.
Proces log-rotation skončil s kódem 1.
Proces cleaning[657] začal.
A chceme výstup ve následujícím formátu:
{
"process.name": "cleaning",
"process.pid": 123,
"event.action": "process-finished",
"return.code": 0
}
{
"process.name": "log-rotation",
"event.action": "process-finished",
"return.code": 1
}
{
"process.name": "cleaning",
"process.pid": 657,
"event.action": "process-started"
}
Deklarace bude následující:
define:
type: parser/parsec
parse:
!PARSE.KVLIST
- !PARSE.UNTIL " "
- !TRY
- !PARSE.KVLIST
- process.name: !PARSE.UNTIL "["
- process.pid: !PARSE.UNTIL "]"
- !PARSE.SPACE
- !PARSE.KVLIST
- process.name: !PARSE.UNTIL " "
- !TRY
- !PARSE.KVLIST
- !PARSE.EXACTLY "started."
- event.action: "process-started"
- !PARSE.KVLIST
- !PARSE.EXACTLY "finished with code "
- event.action: "process-finished"
- return.code: !PARSE.DIGITS
Příklad 3: Parsování syslog událostí
Pro účely příkladu, řekněme, že chceme parsovat jednoduchou událost ve formátu syslog:
<189> Sep 22 10:31:39 server-abc server-check[1234]: User "harry potter" logged in from 198.20.65.68
Chceme výstup ve následujícím formátu:
{
"PRI": 189,
"timestamp": 1695421899,
"server": "server-abc",
"process.name": "server-check",
"process.pid": 1234,
"user": "harry potter",
"action": "log-in",
"ip": "198.20.65.68"
}
Vytvoříme dva parsery. První parser bude parsovat záhlaví syslog a druhý bude parsovat zprávu.
define:
name: Syslog parser
type: parser/parsec
parse:
!PARSE.KVLIST
- !PARSE.EXACTLY "<"
- PRI: !PARSE.DIGITS
- !PARSE.EXACTLY ">"
- timestamp: ...
- server: !PARSE.UNTIL " "
- process.name: !PARSE.UNTIL "["
- process.pid: !PARSE.UNTIL "]"
- !PARSE.EXACTLY ":"
- message: !PARSE.CHARS
Tento parser
define:
type: parser/parsec
field: message
drop: yes
parse:
!PARSE.KVLIST
- !PARSE.UNTIL " "
- user: !PARSE.BETWEEN { what: '"' }
- !PARSE.EXACTLY " "
- !PARSE.UNTIL " "
- !PARSE.UNTIL " "
- !PARSE.UNTIL " "
- ip: !PARSE.CHARS
Příklad 4: Parsování JSON událostí
Pro účely příkladu, řekněme, že chceme parsovat JSON událost:
{
"data": {
"action": "allow",
"backendStatusCode": "200",
"clientAddr": "89.183.114.162",
"countryCode": "cz",
"host": "www.praha.cz",
"response": {
"backendTime": "0.043",
"code": "200"
}
},
"time": "2024-03-03T01:15:03.480Z"
}
Vytvoříme dva parsery. První parser bude parsovat originální událost a uloží ji jako JSON objekt v poli json
.
define:
type: parser/json
Výsledná událost bude:
{
"json": <JSON object>
}
Další parser bude parsovat pole /time
ze JSON objektu.
define:
type: parser/parsec
field: json /time
parse:
!PARSE.KVLIST
- "@timestamp": !PARSE.DATETIME
- year: !PARSE.DIGITS
- '-'
- month: !PARSE.MONTH "number"
- '-'
- day: !PARSE.DIGITS
- 'T'
- hour: !PARSE.DIGITS
- ':'
- minute: !PARSE.DIGITS
- ':'
- second: !PARSE.DIGITS
- microsecond: !PARSE.FRAC base: "micro"
Výsledná událost bude:
{
"json": <JSON object>,
"@timestamp": 140994182325993472
}
Mapování¶
Po získání všech deklarovaných polí z analyzátorů musí být pole obvykle přejmenována podle nějakého schématu (ECS, CEF) v procesu nazývaném mapování.
Proč je mapování nezbytné?
Pro uložení dat událostí v Elasticsearch je důležité, aby názvy polí v logech odpovídaly Elastic Common Schema (ECS), standardizované, otevřené kolekci názvů polí kompatibilních s Elasticsearch. Proces mapování přejmenuje pole z analyzovaných logů podle tohoto schématu. Mapování zajišťuje, že logy z různých zdrojů mají jednotné a konzistentní názvy polí, což umožňuje Elasticsearch je správně interpretovat.
Důležité
Ve výchozím nastavení pracuje mapování jako filtr. Ujistěte se, že do deklarace mapování zahrnete všechna pole, která chcete v analyzovaném výstupu. Jakékoliv pole, které není specifikováno v mapování, bude z události odstraněno.
Psaní deklarace mapování¶
Deklarace mapování napište v YAML. (Deklarace mapování nepoužívají výrazy SP-Lang.)
define:
type: parser/mapping
schema: /Schemas/ECS.yaml
mapping:
<original_key>: <new_key>
<original_key>: <new_key>
...
Specifikujte parser/mapping
jako type
v sekci define
. V poli schema
specifikujte cestu k souboru schématu, který používáte. Pokud používáte Elasticsearch, použijte Elastic Common Schema (ECS).
Standardní mapování¶
Pro přejmenování klíče a změnu datového typu hodnoty:
Warning
Nový datový typ musí odpovídat datovému typu specifikovanému ve schématu pro toto pole.
Specifikací type: auto
bude datový typ automaticky určen ze schématu na základě názvu pole.
mapping:
<original_key>:
field: <new_key>
type: <new_type>
Dostupné datové typy najdete zde.
Pro přejmenování klíče a úpravu hodnoty:
mapping:
<original_key>:
field: <new_key>
apply: <new_type>
apply
, musíte specifikovat typ analyzované hodnoty a název argumentu VALUE
.
mapping:
<original_key>:
field: <new_key>
value_type: <type>
apply: <new_type>
Example
Upravení hodnoty řetězce na hodnotu IP pomocí výrazu PARSE.IP
a přejmenování na nový klíč:
'json /client-ip':
field: client.ip
apply: !PARSE.IP
Upravení hodnoty řetězce na malá písmena a přejmenování na nový klíč:
Uveďte počáteční typ hodnoty a použijte jej jako argument VALUE
ve funkci apply
.
'json /client-hostname':
field: client.address
value_type: str
apply: !LOWER
what: !ARG VALUE
Pro přejmenování klíče bez změny datového typu hodnoty:
mapping:
<original_key>: <new_key>
Mapování z JSON¶
Pro přejmenování klíče uloženého v objektu JSON:
mapping:
<jsonObject> <jsonPointer>: <new_key>
/
a každá další úroveň je oddělena znakem /
.
Pro přejmenování klíče uloženého v objektu JSON se specifickým párem klíč-hodnota:
mapping:
<jsonObject> <jsonPointer/[key:value]/jsonPointer>: <new_key>
Název objektu JSON a JSON ukazatel musí být odděleny mezerou. JSON ukazatel vždy začíná znakem /
a každá další úroveň je oddělena znakem /
.
Specifikovaný pár klíč-hodnota umožňuje vybrat požadovaný objekt JSON (viz příklad níže).
Pro přejmenování klíče uloženého v objektu JSON a změnu datového typu hodnoty:
mapping:
<jsonObject> <jsonPointer>:
field: <new_key>
type: <new_type>
Jak bylo uvedeno dříve, je možné změnit datový typ specifikací pole type
.
Příklad¶
Příklad 1: Mapování z JSON
Pro účely příkladu si představme, že chceme analyzovat jednoduchou událost ve formátu JSON:
{
"act": "user login",
"ip": "178.2.1.20",
"usr": "harry_potter",
"id": "6514-abb6-a5f2"
}
a chtěli bychom, aby finální výstup vypadal takto:
{
"event.action": "user login",
"source.ip": "178.2.1.20",
"user.name": "harry_potter"
}
Všimněte si, že názvy klíčů v původní události se liší od názvů klíčů v požadovaném výstupu.
Pro počáteční deklaraci parseru v tomto případě můžeme použít jednoduchý JSON parser:
define:
type: parser/json
Tento parser vytvoří objekt JSON a uloží jej do pole json
.
Pro změnu názvů jednotlivých polí vytvoříme tento soubor deklarace mapování, 20_mapping_ECS.yaml
, ve kterém popíšeme, která pole mapovat a jak:
---
define:
type: parser/mapping # určete typ deklarace
schema: /Schemas/ECS.yaml # které schéma je použito
mapping:
json /act: 'event.action'
json /ip:
field: 'source.ip'
type: auto
json /usr: 'user.name'
Tato deklarace vytvoří požadovaný výstup. Datový typ pole source.ip
bude automaticky určen na základě schématu a odpovídajícím způsobem změněn.
Příklad 2: Mapování z JSON se specifickým párem klíč-hodnota
Dalším příkladem je mapování pro složitou událost ve formátu JSON, která se skládá z objektu JSON se specifickým párem klíč-hodnota:
{
"CreationTime": "2022-01-19T11:07:41",
"ExtendedProperties": [
{
"Name": "ResultStatusDetail",
"Value": "Redirect"
},
{
"Name": "UserAgent",
"Value": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) MicrosoftTeams-Preview/1.4.00.26453 Chrome/85.0.4183.121 Electron/10.4.7 Safari/537.36"
},
{
"Name": "RequestType",
"Value": "OAuth2:Authorize"
}
],
}
Abychom získali pole z objektu JSON, který obsahuje specifický pár klíč-hodnota, použijte následující syntaxi:
---
define:
type: parser/mapping # určete typ deklarace
schema: /Schemas/ECS.yaml # které schéma je použito
mapping:
json /ExtendedProperties/[Name:ResultStatusDetail]/Value: 'o365.audit.ExtendedProperties.ResultStatusDetail'
json /ExtendedProperties/[Name:UserAgent]/Value: 'o365.audit.ExtendedProperties.UserAgent'
json /ExtendedProperties/[Name:RequestType]/Value: 'o365.audit.ExtendedProperties.RequestType'
Obohacovače¶
Obohacovače doplňují analyzované události o extra data.
Obohacovač může:
- Vytvořit nové pole v události.
- Přetransformovat hodnoty pole nějakým způsobem (změna velikosti písmen, provedení výpočtu apod.).
- Smazat existující pole, pokud je splněna zadaná podmínka.
Obohacovače se nejčastěji používají k:
- Určení datasetu, kde budou logy uloženy v ElasticSearch (přidání pole
event.dataset
). - Získání facility a severity z pole se syslog prioritou.
define:
type: parsec/enricher
enrich:
event.dataset: <dataset_name>
new.field: <expression>
...
delete:
existing.field: <expression>
- Obohacovače píšeme v YAML.
- Specifikuj
parsec/enricher
v polidefine
.
Note
Obě sekce enrich
a delete
jsou volitelné, ale musíte použít alespoň jednu z nich.
Příklad 1: Obohaťte událost o nová pole
Následující příklad je obohacovač používaný pro události ve formátu syslog. Předpokládejme, že máte parser pro události ve formě:
<14>1 2023-05-03 15:06:12 server pid: Username 'HarryPotter' logged in.
{
"log.syslog.priority": 14,
"user.name": "HarryPotter"
}
Chcete získat syslog severity a facility, které jsou vypočteny standardním způsobem:
(facility * 8) + severity = priority
Také byste chtěli snížit jméno HarryPotter
na harrypotter
, aby uživatelé byli jednotní napříč různými logovými zdroji.
Proto vytvoříte obohacovač:
define:
type: parsec/enricher
enrich:
event.dataset: 'dataset_name'
user.id: !LOWER { what: !GET {from: !ARG EVENT, what: user.name} }
# facility a severity jsou vypočteny ze 'syslog.pri' standardním způsobem
log.syslog.facility.code: !SHR
what: !GET { from: !ARG EVENT, what: log.syslog.priority }
by: 3
log.syslog.severity.code: !AND [ !GET {from: !ARG EVENT, what: log.syslog.priority}, 7 ]
Příklad 2: Smazat nevhodné pole z události
Následující obohacovač smaže pole host.name
z události, pokud jeho hodnota obsahuje řetězec SRV
:
define:
type: parsec/enricher
delete:
host.name: !IN
what: "SRV"
where: !GET {from: !ARG EVENT, what: host.name}
Datum/časová pole¶
Zpracování dat a časů (časových razítek) je klíčové při analýze událostí.
Aby byly události zobrazeny v aplikaci LogMan.io, musí události obsahovat pole @timestamp
s odpovídajícím datem, časem a časovým pásmem.
Datumová a časová pole, v souladu s ECS:
Pole | Význam |
---|---|
@timestamp |
Čas, kdy původní událost nastala. Musí být zahrnuto v deklaracích. |
event.created |
Čas, kdy byla původní událost zaznamenána Kolektorem LogMan.io. |
event.ingested |
Čas, kdy byla původní událost přijata Přijímačem LogMan.io. |
Za normálních podmínek, pokud nedošlo k žádnému zásahu do dat, by hodnoty časových razítek měly být chronologické: @timestamp
< event.created
< event.ingested
.
Užitečné odkazy a nástroje¶
- UNIX časový konvertor
- Formát datum/času jazyka SP-Lang: toto je výstupní formát všech rozparsovaných časových razítek produkovaných Parsecem.
LogMan.io Parsec Klíčové termíny¶
Důležité termíny relevantní pro LogMan.io Parsec.
Událost¶
Jednotka dat, která prochází procesem parsingu, je označována jako událost. Původní událost přichází do LogMan.io Parsec jako vstup a následně je parsnuta procesory. Pokud je parsing úspěšný, vyprodukuje parsovanou událost, a pokud parsing selže, vyprodukuje chybovou událost.
Původní událost¶
Původní událost je vstup, který LogMan.io Parsec přijímá - jinými slovy, neparnutý log. Může být reprezentován neopracovaným (případně kódovaným) řetězcem nebo strukturou ve formátu JSON nebo XML.
Parsovaná událost¶
Parsovaná událost je výstup z úspěšného parsingu, formátovaný jako neuspořádaný seznam párů klíč-hodnota serializovaný do struktury JSON. Parsovaná událost vždy obsahuje unikátní ID, původní událost a obvykle informaci o tom, kdy byla událost vytvořena zdrojem a přijata Apache Kafka.
Chybová událost¶
Chybová událost je výstup z neúspěšného parsingu, formátovaný jako neuspořádaný seznam párů klíč-hodnota serializovaný do struktury JSON. Je vytvořena, když parsing, mapování nebo obohacování selže, nebo když dojde k jiné výjimce v LogMan.io Parsec. Vždy obsahuje původní událost, informaci o tom, kdy byla událost neúspěšně parsnuta, a chybovou zprávu popisující důvod, proč proces parsingu selhal. Navzdory neúspěšnému parsingu bude chybová událost vždy ve formátu JSON, páry klíč-hodnota.
Knihovna¶
Vaše TeskaLabs LogMan.io Knihovna obsahuje všechny vaše deklarace (a mnoho dalších typů souborů). Své deklarace můžete upravovat ve vaší Knihovně prostřednictvím Zookeeper.
Deklarace¶
Deklarace popisují, jak bude událost transformována. Deklarace jsou soubory YAML, které LogMan.io Parsec umí interpretovat k vytvoření deklarativních procesorů. V LogMan.io Parsec existují tři typy deklarací: parsování, obohacování a mapování. Více viz Deklarace.
Parser¶
Parser je typ deklarace, který bere původní událost nebo specifické pole částečně parsované události jako vstup, analyzuje její jednotlivé části a poté je ukládá jako páry klíč-hodnota do události.
Mapování¶
Deklarace mapování je typ deklarace, který bere částečně parsovanou událost jako vstup, přejmenovává názvy polí a případně konvertuje datové typy. Pracuje spolu se schématem (ECS, CEF). Také funguje jako filtr, který vynechává data, která nejsou potřebná ve finální parsované události.
Obohacování¶
Obohacovač je typ deklarace, která doplňuje částečně parsovanou událost o dodatečná data.
Migrace na Parsec s event lanes¶
Pro migraci z LogMan.io Parser nebo LogMan.io Parsec verze menší než v24.14
, která nepoužívá event lanes, použijte následující migrační příručku.
Předpoklady¶
- LogMan.io Depositor >
v24.11-beta
- LogMan.io Baseliner >
v24.11-beta
- LogMan.io Correlator >
v24.11-beta
Kroky migrace¶
-
Vytvořte nový event lane YAML soubor
/EventLanes/<tenant>/<eventlane>.yaml
v Knihovně. -
Přidejte následující vlastnosti do eventlane:
/EventLanes/tenant/eventlane.yaml--- define: type: lmio/event-lane parsec: name: /Parsers/path/to/parser kafka: received: topic: received.<tenant>.<stream> events: topic: events.<tenant>.<stream> others: topic: others.<tenant> elasticsearch: events: index: lmio-<tenant>-events-<eventlane> others: index: lmio-<tenant>-others
(Nahraďte
<tenant>
,<stream>
,<eventlane>
a/path/to/parser
specifickými hodnotami.) -
Vytvořte konfiguraci pro LogMan.io Parsec:
lmio-parsec.conf[tenant] name=<tenant> [eventlane] name=/EventLanes/<tenant>/<eventlane>.yaml [library] providers= zk:///library ... [kafka] bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092 [zookeeper] servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
-
Použijte buď starou Consumer group nebo vytvořte novou. Nejprve otevřete kafdrop, vyhledejte odpovídající
received
topic, podívejte se na Consumers a najděte Group ID staré LMIO Parser/LMIO Parsec. Rozhodněte se, zda budete používat starégroup.id
nebo vytvoříte nové.Warning
Při vytvoření nového
group.id
se vytvoří nová consumer group a začne číst události od začátku. (To závisí na parametruauto.offset.reset
Kafka clusteru, který je ve výchozím nastaveníearliest
.)V případě, že chcete zachovat starý
group.id
, přidejte do konfigurace následující sekci:lmio-parsec.conf[pipeline:ParsecPipeline:KafkaSource] group_id=<your group id>
Jinak se
group.id
automaticky vytvoří na základě názvu event lane:lmio-parsec-<tenant>-<eventlane>
. -
Spusťte službu. Ujistěte se, že běží, tak že se podíváte na její logy.
Neměly by se objevit žádné chybové logy. Pokud ano, podívejte se na troubleshooting. Měli byste také vidět upozorňující logy podobné těmto:
NOTICE lmioparsec.app Event Lane /EventLanes/default/linux-syslog-rfc3164-10001.yaml loaded successfully. NOTICE lmioparsec.app [sd timezone="Europe/Prague" charset="utf-8" schema="/Schemas/ECS.yaml" parser="/Parsers/Linux/Common"] Configuration loaded. NOTICE lmioparsec.declaration_loader [sd parsers="3" mappings="1" enrichers="1"] Declarations loaded. NOTICE lmioparsec.parser.pipeline [sd source_topic="received.default.linux-syslog-rfc3164-10001" events_topic="events.default.linux-syslog-rfc3164-10001" others_topic="others.default" group.id="custom-group-id"] ParsecPipeline is ready.
Zde byste měli vidět správné Kafka topics,
group.id
,charset
,schema
atimezone
. -
Ujistěte se, že služba spotřebovává zprávy z správného topicu se správným group id. Znovu otevřete kafdrop a najděte received topic. Zkontrolujte, zda byla vytvořena nová consumer group nebo zda Combined Lag staré skupiny začíná klesat.
-
Zkontrolujte, zda nové zprávy přicházejí do Kafky events topic.
events topic není vytvořen
Zkontrolujte others topic. Pokud tam přicházejí nové zprávy, pravidlo pro parsování není správné. Znovu zkontrolujte, zda používáte správný název parseru v event lane:
yaml "eventlane.yaml"
parsec:
name: /Parsers/path/to/parser
Pokud ano, pak jsou pravidla pro parsování nesprávná a měla by být změněna.
-
Zkontrolujte, zda LogMan.io Depositor běží. Otevřete events topic a zkontrolujte, zda z něj Depositor spotřebovává zprávy (v Combined Lag).
-
Zkontrolujte, zda jsou zprávy viditelné na obrazovce Průzkumník v uživatelském rozhraní LogMan.io.
Zprávy nejsou vůbec viditelné
Pokud nemůžete najít data na obrazovce Průzkumník, počkejte nějaký čas (cca 1-2 minuty), proces může nějakou dobu trvat. Potom zkontrolujte, zda existuje správný events topic a zda je event lane správně nakonfigurován. Pokud ano, zkontrolujte, zda zprávy nepřicházejí v nesprávném časovém pásmu nastavením časového rozsahu na (-1 den, +1 den).
Zprávy jsou viditelné ve špatném časovém pásmu
Pokud je časové pásmo nebo použitá schéma nesprávná, můžete ji přepsat v event lane:
```yaml title="/EventLanes/<tenant>/<eventlane>.yaml"
define:
type: lmio/event-lane
timezone: UTC
schema: /Schemas/ECS.yaml
```
Řešení problémů pro LogMan.io Parsec¶
Časová zóna¶
Kritické logy¶
CRITICAL lmio-parsec.app Chybí sekce 'zookeeper' v konfiguraci.
Přidejte sekci [zookeeper]
do konfigurace:
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
CRITICAL lmioparsec.app Chybí konfigurační možnost '[tenant] name'.
Přidejte jméno tenanta do konfigurace:
[tenant]
name=my-tenant
CRITICAL lmioparsec.app Konfigurační možnost '[eventlane] name' musí začínat '/EventLanes/'.
Upravte jméno event lane tak, aby začínalo /EventLanes
:
[eventlane]
name=/EventLanes/<tenant>/<eventlane>.yaml
CRITICAL lmioparsec.app Konfigurační možnost '[parser] name' musí začínat '/Parsers/'.
Ujistěte se, že cesta pro parsing rules začíná /Parsers
.
define:
type: lmio/event-lane
parsec:
name: /Parsers/path/to/parsers
CRITICAL lmioparsec.app Nelze najít soubor '/EventLanes/tenant/eventlane.yaml' v knihovně, ukončuji.
Ujistěte se, že soubor /EventLanes/tenant/eventlane.yaml
existuje a je povolen pro daného tenanta.
CRITICAL lmioparsec.app Nelze přečíst deklaraci '/EventLanes/tenant/eventlane.yaml': <popis chyby>, ukončuji.
V souboru /EventLanes/tenant/eventlane.yaml
je syntaktická chyba. Zkuste ji opravit inspirován popisem chyby.
Chybové logy¶
ERROR: lmioparsec.declaration_loader Nelze sestavit pipeline: žádné deklarace nenalezeny.
Ujistěte se, že máte v konfiguračním souboru event lane správně nastavenou cestu pro parsing rules.
Varovné logy¶
WARNING lmioparsec.declaration_loader Chybí sekce 'schema' v /Parsers/Linux/Common/50_enricher.yaml
Každé enricher rule, které stojí za mapping, by mělo obsahovat schema v sekci define
:
define:
type: parser/enricher
schema: /Schemas/ECS.yaml
Parser
Cascade Parser¶
Příklad¶
---
define:
name: Syslog RFC5424
type: parser/cascade
field_alias: field_alias.default
encoding: utf-8 # none, ascii, utf-8 ... (default: utf-8)
target: parsed # volitelné, specifikujte cíl parsované události (výchozí: parsed)
predicate:
!AND
- !CONTAINS
what: !EVENT
substring: '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+-(.*)$'
items:
- rt:
!DATETIME.PARSE
value: !ARG
format: '%b %d %H:%M:%S'
flags: Y
- dvchost
Sekce define
¶
Tato sekce obsahuje obecné definice a metadata.
Položka name
¶
Kratší název této deklarace, srozumitelný pro člověka.
Položka type
¶
Typ této deklarace musí být parser/cascade
.
Položka field_alias
¶
Název aliasu pole, který bude načten, aby mohly být v deklaraci použity alias názvy atributů události spolu s jejich kanonickými názvy.
Položka encoding
¶
Kódování příchozí události.
Položka target
(volitelné)¶
Výchozí cílový pipeline parsované události, pokud není specifikováno jinak v context
.
Možnosti zahrnují: parsed
, lookup
, unparsed
Položka description
(volitelné)¶
Delší, případně vícelinkový, srozumitelný popis deklarace.
Sekce predicate
(volitelná)¶
Sekce predicate
filtruje příchozí události pomocí výrazu.
Pokud výraz vrátí hodnotu True
, událost vstoupí do sekce parse
.
Pokud výraz vrátí hodnotu False
, událost je přeskočena.
Jiné návratové hodnoty jsou nedefinované.
Tato sekce může být použita ke zrychlení parsování přeskočením řádků s evidentně nerelevantním obsahem.
Vložení vnořených predikátových filtrů¶
Predikátové filtry jsou výrazy umístěné ve vyhrazeném souboru, které mohou být zahrnuty v mnoha různých predikátech jako jejich části.
Pokud chcete zahrnout externí predikátový filtr, umístěný buď v adresáři include
nebo filters
(tento je globální adresář umístěný v horní hierarchii knihovny LogMan.io),
použijte příkaz !INCLUDE
:
!INCLUDE predicate_filter
kde predicate_filter
je název souboru plus přípona .yaml
.
Obsah souboru predicate_filter.yaml
je výraz, který má být zahrnut, například:
---
!EQ
- !ITEM EVENT category
- "MyEventCategory"
Sekce parse
¶
Tato sekce specifikuje vlastní parsovací mechanismus.
Očekává se, že vrátí 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 parsovacích deklarací, které budou vyhodnocovány v pořadí (shora dolů), první deklarace, která vrátí nenulovou hodnotu, zastaví iteraci a tato hodnota je vrácena.
Příkaz !REGEX.PARSE
umožňuje transformovat řádek logu do struktury slovníku. Také umožňuje připojení podparátorů pro další dekompozici podřetězců.
Směrování výstupu¶
Aby bylo jasné, že parser nebude
parsovat událost, kterou doposud obdržel,
je potřeba nastavit atribut target
na unparsed
v rámci context
.
Poté mohou jiní parsery v pipeline obdržet a parsovat událost.
Stejně tak může být cíl nastaven na různé cílové skupiny,
jako například parsed
.
Pro nastavení target
v context
, se používá !CONTEXT.SET
:
- !CONTEXT.SET
what: <... výrok ...>
set:
target: unparsed
Příklad použití v parseru. Pokud žádný regulární výraz neodpovídá příchozí události,
událost je odeslána na cíl unparsed
, takže ji mohou zpracovat jiní parsery v řadě.
!FIRST
- !REGEX.PARSE
what: !EVENT
regex: '^(one)\s(two)\s(three)$'
items:
- one
- two
- three
- !REGEX.PARSE
what: !EVENT
regex: '^(uno)\s(duo)\s(tres)$'
items:
- one
- two
- three
# Zde začíná zpracování částečně parsované události
- !CONTEXT.SET
set:
target: unparsed
- !DICT
set:
unparsed: !EVENT
Komplexní parser událostí¶
Komplexní parser událostí zpracovává příchozí komplexní události, jako jsou události hledání (např. vytvoření, aktualizace, smazání hledání) a přidává je do tématu lmio-output
v rámci Kafka.
Odtud jsou rozparsované komplexní události také zaslány do tématu input
instancemi LogMan.io Watcher, takže korelátory a dispečeři mohou na tyto události také reagovat.
Ukázková deklarace¶
Ukázková YAML deklarace pro události hledání v rámci Komplexního parseru událostí může vypadat následovně:
p00_json_preprocessor.yaml¶
---
define:
name: Preprocesor pro JSON s extrakcí tenant
type: parser/preprocessor
tenant: JSON.tenant
function: lmiopar.preprocessor.JSON
p01_lookup_event_parser.yaml¶
---
define:
name: Parser událostí hledání
type: 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í LogMan.io knihovny.
Konfigurace Parseru LogMan.io¶
Nejprve je potřeba specifikovat, ze které knihovny se mají načítat deklarace, může to být buď ZooKeeper nebo Soubor.
Také každá běžící instance parseru musí vědět, které skupiny načíst z knihoven, viz níže:
# Deklarace
[declarations]
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=count
tenant=tenant
timestamp=end
groups
- názvy skupin, které budou použity z knihovny, oddělené mezerami; pokud skupina
je umístěna v podsložce, použijte jako oddělovač lomítko, např. parsers/cisco-asa@syslog
Pokud je knihovna prázdná nebo nejsou specifikovány skupiny,
všechny události, včetně jejich kontextových položek, budou uloženy
do Kafka tématu lmio-others
a zpracovány Dispatcherem LogMan.io,
jako by nebyly parsovány.
include_search_path
- specifikuje složky pro hledání YAML souborů, které budou později použity v příkazu !INCLUDE
(výraz jako !INCLUDE myFilterYAMLfromFiltersCommonSubfolder) v deklaracích, oddělené ;.
Pokud se po lomítku uvede hvězdička *
, budou všechny podsložky rekurzivně zahrnuty.
!INCLUDE příkaz očekává název souboru bez cesty a bez přípony jako vstup.
Chování je podobné atributu -I
při sestavování C/C++ kódu.
raw_event
- název pole vstupní zprávy logu (aka raw)
tenant
- název pole pro tenant/klienta
count
- název pole pro 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á Kafka témata použít pro vstup a výstup, pokud bylo parsování úspěšné nebo neúspěšné. Je také potřeba nakonfigurovat připojení ke Kafce, aby bylo jasné, ke kterým Kafka serverům se připojit.
# Kafka připojení
[connection:KafkaConnection]
bootstrap_servers=lm1:19092;lm2:29092;lm3:39092
[pipeline:ParsersPipeline:KafkaSource]
topic=collected
# group_id=lmioparser
# Kafka výstupy
[pipeline:EnrichersPipeline:KafkaSink]
topic=parsed
[pipeline:ParsersPipeline:KafkaSink]
topic=unparsed
Poslední povinná sekce specifikuje, které Kafka téma použít pro informace o změnách v lookupech (tj. referenčních seznamech) a který ElasticSearch instance je má načítat.
# Trvalé úložiště lookup
[asab:storage] # tato sekce je použita pro lookupy
type=elasticsearch
[elasticsearch]
url=http://elasticsearch:9200
# Update pipelines pro lookupy
[pipeline:LookupChangeStreamPipeline:KafkaSource]
topic=lookups
[pipeline:LookupModificationPipeline:KafkaSink]
topic=lookups
Instalace¶
Docker Compose¶
lmio-parser:
image: docker.teskalabs.com/lmio/lmio-parser
volumes:
- ./lmio-parser:/data
Konfigurace nového LogMan.io Parser instance¶
Pro vytvoření nové parser instance pro nový zdroj dat (soubory, online pomoc, SysLog atd.) je potřeba provést následující tři kroky:
- Vytvoření nového Kafka topicu pro nahrání sesbíraných dat
- Konfigurace příslušných LogMan.io Parser instancí v site-repository
- Nasazení
Vytvoření nového Kafka topicu pro nahrání sesbíraných dat¶
Nejprve je potřeba vytvořit nový topic pro sesbírané události.
Topic sesbíraných událostí jsou specifické pro každý typ zdroje dat a tenant (zákazníka). Standard pro pojmenování takovýchto Kafka topic je následující:
collected-<tenant>-<type>
kde tenant je název tenant v malých písmenách a type je typ zdroje dat. Příklady zahrnují:
collected-railway-syslog
collected-ministry-files
collected-johnandson-databases
collected-marksandmax-lookups
Topic pro sesbíraná data pro všechny tenanty může mít následující formát:
collected-default-lookups
Pro vytvoření nového Kafka topic:
1.) Vstupte do libovolného Kafka kontejneru přes docker exec -it o2czsec-central_kafka_1 bash
2.) Použijte následující příkaz pro vytvoření topicu 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 partition závisí na očekávaném množství dat a počtu instancí LogMan.io Parser. Vzhledem k tomu, že ve většině nasazení jsou tři běžící servery v clusteru, doporučuje se použít alespoň tři partition.
Konfigurace příslušných LogMan.io Parser instancí v site-repository¶
Vstupte do site repository s konfiguracemi pro LogMan.io cluster. Pro více informací o site repository se podívejte na sekci Naming Standards v části Reference.
Poté v každé složce serveru (jako je lm1, lm2, lm3) vytvořte následující záznam v souboru 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 tenantu/zákazníka (například railway) a <type>
typem dat (například online pomoc), příklady zahrnují:
railway-lookups-lmio-parser
default-lookups-lmio-parser
hbbank-syslog-lmio-parser
Když je záznam pro Docker Compose zahrnut v souboru docker-compose.yml
, postupujte podle těchto kroků:
1.) V každé složce serveru (lm1, lm2, lm3) vytvořte složku <tenant>-<type>
2.) Ve složkách <tenant>-<type>
vytvořte složku lmio-parser
3.) V vytvořených složkách lmio-parser
vytvořte soubor lmio-parser.conf
4.) Upravte lmio-parser.conf
a zadejte následující konfiguraci:
[asab:docker]
name_prefix=<server_name>-
socket=/var/run/docker.sock
# Deklarace
[declarations]
library=zk://lm1:12181,lm2:22181,lm3:32181/lmio/library.lib ./data/declarations
groups=<group>
raw_event=raw_event
count=count
tenant=tenant
timestamp=@timestamp
# API
[asab:web]
listen=0.0.0.0 0
[lmioparser:web]
listen=0.0.0.0 0
# Logování
[logging:file]
path=/log/log.log
backup_count=3
rotate_every=1d
# Připojení k 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
# Perzistentní úložiště lookups
[asab:storage] # tato sekce je používána lookups
type=elasticsearch
[elasticsearch]
url=http://<server_name>:9200/
username=<secret_username>
password=<secret_password>
# Aktualizace lookups 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 nahraďte každé z použití:
<group>
skupinou deklarací parseru načtenou v ZooKeeper; pro více informací se podívejte na sekci Library v části Reference této dokumentace
<server_name>
s názvem kořenové složky serveru, jako je lm1, lm2, lm3
<tenant>
s názvem vašeho tenantu, jako je hbbank, default, railway atd.
<type>
s typem vašeho zdroje dat, jako je online pomoc, syslog, soubory, databáze atd.
<secret_username>
a <secret_password>
s technickými údaji účtu ElasticSearch a InfluxDB,
které lze vidět v jiných konfiguracích ve site repository
Pro více informací o tom, co každá sekce konfigurace znamená, prosím podívejte se na sekci Configuration v postranním menu.
Nasazení¶
Pro nasazení nového parseru, prosím:
1.) Jděte na každý z LogMan.io serverů (lm1, lm2, lm3)
2.) Proveďte git pull
ve složce site repository, která by měla být umístěna ve /opt
adresáři
3.) Spusťte příkaz docker-compose up -d <tenant>-<type>-lmio-parser
pro spuštění instance LogMan.io Parser
4.) Nasadit a nakonfigurovat SyslogNG, LogMan.io Ingestor atd. pro odeslání sesbíraných dat do Kafka topicu collected-<tenant>-<type>
4.) Zkontrolujte logy ve složce /data/hdd/log/<tenant>-<type>/lmio-parser
pro jakékoliv chyby k opravě
(nahraďte <tenant>
a <type>
odpovídajícím způsobem)
Poznámky¶
Pro vytvoření datového streamu pro online pomoc, prosím použijte lookups
jako typ a podívejte se na sekci Lookups v postranním menu
pro správné vytvoření skupiny deklarací pro parsing.
DNS Enricher¶
DNS Enricher obohacuje události o informace získané z DNS serverů, jako jsou názvy hostitelů.
Příklad¶
Deklarace¶
---
define:
name: DNSEnricher
type: enricher/dns
dns_server: 8.8.8.8,5.5.4.8 # volitelné
attributes:
device.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 enricheru,
což je v případě DNS Enricher vždy enricher/dns
.
Položka name
¶
Kratší, lidsky čitelný název této deklarace.
Položka type
¶
Typ této deklarace, musí být enricher/dns
.
Položka dns_server
¶
Seznam DNS serverů, ze kterých se budou získávat informace, oddělený čárkou ,
.
Sekce attributes
¶
Specifikujte slovník s atributy pro načtení IP adresy nebo jiných informací z DNS.
Každý atribut by měl být následován dalším slovníkem se seznamem klíčů pro extrakci z DNS serveru.
Hodnota každého klíče je buď řetězec s názvem atributu události, do kterého má být hodnota uložena, nebo seznam, pokud má být hodnota vložena do více než jednoho atributu události.
Vyhledávání aliasů polí & Obohacovač¶
Vyhledávání¶
Vyhledávání aliasů polí obsahuje informace o kanonických názvech atributů událostí, spolu s jejich možnými aliasy (např. krátkými názvy atd.).
ID vyhledávání aliasů polí musí obsahovat následující podřetězec: field_alias
Záznam vyhledávání má následující strukturu:
key: canonical_name
value: {
"aliases": [
alias1, # např. krátký název
alias2, # např. dlouhý název
...
]
}
Aliasy polí mohou být specifikovány v sekci definic parserů, standardních obohacovačů a korelátorů,
takže aliasové názvy použité v deklarativním souboru (např. !ITEM EVENT alias
)
jsou přeloženy na kanonické názvy při přístupu k existujícímu prvku
(tj. !ITEM EVENT alias
nebo !ITEM EVENT canonical_name
).
Také by mělo být vyhledávání použito v obohacovači aliasů polí k transformaci všech aliasů na kanonické názvy po úspěšném parsování v LogMan.io Parseru.
Obohacovač¶
Obohacovač aliasů polí obohacuje událost kanonickými názvy existujících atributů, které jsou pojmenovány jedním ze specifikovaných aliasů, zatímco maže aliasové atributy v události.
Deklarace¶
---
define:
name: FieldAliasEnricher
type: enricher/fieldalias
lookup: field_alias.default
Sekce define
¶
Tato sekce definuje název a typ obohacovače,
který v případě Obohacovače aliasů polí je 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 (NEAKTUÁLNÍ)¶
Tento obohacovač je zastaralý, prosím používejte místo něj IPEnricher.
IP2Location obohacuje událost o specifikované atributy lokace na základě hodnot IPV4 nebo IPV6.
Příklad¶
Deklarace¶
---
define:
name: IP2Location
type: enricher/ip2location
zones:
- myLocalZone
- ip2location
- ...
attributes:
ip_addr1:
country_short: firstCountry
city: firstCity
L: firstL
ip_addr2:
country_short: secondCountry
city: secondCity
L: secondL
...
Vstup¶
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,
což v případě IP2Location je 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
¶
Specifikujte seznam zón (databázových souborů nebo streamů), které budou použity obohacovačem. První zóna, která úspěšně provede vyhledávání, je použita, takže je uspořádejte podle priority.
Sekce attributes
¶
Specifikujte slovník s atributy události IPV6, na které bude vyhledávání provedeno, jako například dvchost
.
Uvnitř slovníku uveďte pole/atributy z vyhledávání, které mají být načteny
a atributový název v události po načtení. Například:
ip_addr1:
country_short: firstCountry
city: firstCity
L: firstL
provede vyhledávání IP do GEO pro IP uloženou v event["ip_addr1"]
,
načte country_short
, city
, L
z vyhledávání (pokud jsou přítomny) a mapuje je na
event["firstCountry"]
, event["firstCity"]
, event["firstL"]
Vyhledávací atributy¶
Následující vyhledávací atributy, pokud jsou přítomny ve vyhledávací zóně, mohou být použity pro další mapování:
country_short: string
country_long: string
region: string
city: string
isp: string
L: dictionary (includes: lat: float, lon: float)
domain: string
zipcode: string
timezone: string
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
Vysokovýkonné Parsování¶
Vysokovýkonné parsování je parsování, které je přímo zkompilováno do strojového kódu, čímž se zajišťuje co nejvyšší rychlost parsování příchozích událostí.
Všechny vestavěné předzpracovatele, stejně jako deklarativní výrazy !PARSE
a !DATETIME.PARSE
, nabízejí vysokovýkonné parsování.
Procedurální parsování¶
Aby mohl být strojový/instrukční kód kompilován pomocí LLVM a C, všechny výrazy musí poskytovat definici procedurálního parsování, což znamená, že každý znak(y) v parsovacím vstupním řetězci musí mít definovanou délku výstupu a typ výstupu.
Zatímco u předzpracovatelů je tento postup transparentní a uživateli se nezobrazuje,
u výrazů !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:
- year: {type: ui64, format: d4}
- '-'
- month: {type: ui64, format: d2}
- '-'
- day: {type: ui64, format: d2}
- ' '
- hour: {type: ui64, format: d2}
První položka v atributu format
odpovídá prvním znakům v příchozí zprávě,
zde year
se tvoří z prvních čtyř znaků a je převeden na celé číslo (2021
).
Pokud je specifikován pouze jeden znak, je přeskočen a není uložen ve výstupní parsované struktuře.
Vysokovýkonné Výrazy¶
!DATETIME.PARSE
¶
!DATETIME.PARSE
implicitně vytváří datetime z parsované struktury,
která má následující atributy:
-
year
-
month
-
day
-
hour
(volitelně) -
minute
(volitelně) -
second
(volitelně) -
microsecond
(volitelně)
Formát - dlouhá verze¶
Atributy musí být specifikovány v inletu format
:
!DATETIME.PARSE
what: "2021-06-11 1712X000014"
format:
- year: {type: ui64, format: d4}
- '-'
- month: {type: ui64, format: d2}
- '-'
- day: {type: ui64, format: d2}
- ' '
- hour: {type: ui64, format: d2}
- minute: {type: ui64, format: d2}
- 'X'
- microsecond: {type: ui64, format: dc6}
Formát - krátká verze¶
Atribut format
může využívat zkrácenou notaci se zástupnými znaky %Y
, %m
, %d
, %H
, %M
, %S
a %u
(mikrosekundy),
které představují nezáporná čísla podle formátu v uvedeném příkladu:
!DATETIME.PARSE
what: "2021-06-16T11:17Z"
format: "%Y-%m-%dT%H:%MZ"
Výraz format
může být zjednodušen, pokud je formát datetime standardizovaný, jako je RFC3339
nebo iso8601
:
!DATETIME.PARSE
what: "2021-06-16T11:17Z"
format: iso8601
Pokud se časové pásmo liší od UTC, musí být také explicitně specifikováno:
!DATETIME.PARSE
what: "2021-06-16T11:17Z"
format: iso8601
timezone: Europe/Prague
Dostupné typy¶
Celé číslo¶
-
{type: ui64, format: d2}
- přesně 2 znaky na nezáporné celé číslo -
{type: ui64, format: d4}
- přesně 4 znaky na nezáporné celé číslo -
{type: ui64, format: dc6}
- 1 až 6 znaků na nezáporné celé číslo
IP Enricher¶
IP Enricher rozšiřuje události o geografické a další údaje spojené 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ý, dobře čitelný název této deklarace.
Položka type
¶
Existují čtyři typy IP Enricher, které se liší verzí IP (IPv4 nebo IPv6) a reprezentací IP adresy (číslo nebo řetězec). Použití číslovaného vstupu je rychlejší a preferovaná možnost.
enricher/ipv6
zpracovává IPv6 adresy v 128bitové dekadické číselné formě (například 281473902969579).enricher/ipv4
zpracovává IPv4 adresy v 32bitové dekadické číselné formě (například 3221226219).enricher/ipv6str
zpracovává IPv6 adresy v hexadecimální řetězcové formě oddělené dvojtečkami (například 2001:db8:0:0:1:0:0:1) jak je definováno v RFC 5952. Může také převádět a zpracovávat řetězcové adresy IPv4 (jakoenricher/ipv4str
).enricher/ipv4str
zpracovává IPv4 adresy v čtyřdílném dekadickém řetězci (například 192.168.16.0) jak je definováno v RFC 4001.
Položka base_path
¶
Specifikuje základní URL cestu, která obsahuje soubory zón pro vyhledávání.
Může ukazovat na:
* lokální souborový systém, např. /path/to/files/
* umístění v zookeeper, např. zk://zookeeper-server:2181/path/to/files/
* umístění HTTP, např. http://localhost:3000/path/to/files/
Sekce tenants
¶
IP Enricher může být nastaven pro multitenantní konfigurace. Tato sekce seznamuje tenanty, které by měly být zohledněny obohacovačem při vytváření specificních vyhledávání podle tenantů. Události označené tenantem, který není uveden v této sekci, budou obohaceny pouze globálními obohaceními (viz níže).
Sekce zones
¶
Specifikuje seznam vyhledávacích zón, které mají být použity obohacovačem, plus informaci, zda jsou globální nebo specifické pro tenant.
Globální vyhledávání může obohatit jakoukoliv událost, bez ohledu na jejího tenanta. Specifické pro tenant mohou obohatit pouze události s odpovídajícím kontextem tenanta.
Vyhledávací zóny by měly být seřazeny podle priority, od nejvyšší k nejnižší, protože vyhledávání probíhá přes zóny sekvenčně a končí, jakmile je nalezena první shoda.
zones:
- tenant: lookup-zone-1.pkl.gz
- tenant: lookup-zone-2.pkl.gz
- global: lookup-zone-glob.pkl.gz
Názvy zón musí odpovídat odpovídajícím názvům souborů včetně přípony.
Soubory pro globální vyhledávání musí být přímo v adresáři base_path
.
Soubory specifické pro tenant musí být uspořádány pod base_path
do složek
podle jejich tenanta. Například, předpokládejme, že jsme deklarovali
first_tenant
a second_tenant
, deklarace zón výše 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íž kontext je second_tenant
, se první pokusí o shodu
ve vyhledávání second_tenant/lookup-zone-1.pkl.gz
, pak ve
second_tenant/lookup-zone-2.pkl.gz
a nakonec ve lookup-zone-glob.pkl.gz
.
Sekce attributes
¶
Tato sekce specifikuje, které atributy události obsahují IP adresu a které atributy budou přidány do události, pokud bude nalezena shoda. Má následující strukturu slovníku:
ip_address:
lookup_attribute_name: event_attribute_name
IP adresa je extrahována z atributu události ip_address
.
Pokud odpovídá nějaké vyhledávací zóně, hodnota lookup_attribute_name
je uložena
do atributu události event_attribute_name
. Například:
source_ip:
country_code: source_country
Tím se událost zkouší porovnat na základě jejího atributu source_ip
a
uložit odpovídající hodnotu country_code
do pole události nazvaného 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ě.
Pro přidání názvu zóny do události použijte zone
jako název atribu pro vyhledávání, např.:
source_ip:
zone: source_zone_name
Tím se přidá název odpovídajícího vyhledávání do pole události source_zone_name
.
Mějte na paměti, že pokud ve vyhledávání existuje pole nazvané "zone", jeho hodnota bude použita místo jména vyhledávání.
Název vyhledávání je nastaven při vytváření souboru vyhledávací zóny.
Výchozí hodnota je název zdrojového souboru, ale může být nakonfigurována na jinou hodnotu.
Viz příkaz lmiocmd ipzone from-csv
v LogMan.io Commander pro podrobnosti.
Příklad použití¶
Deklarační soubor¶
---
define:
name: IPEnricher
type: enricher/ipv6
tenants:
- some-tenant
- another-tenant
zones:
- tenant: lookup-zone-1.pkl
- global: ip2location.pkl.gz
attributes:
ip_addr1:
country_code: sourceCountry
city_name: sourceCity
L: sourceLocation
ip_addr2:
country_code: destinationCountry
city_name: destinationCity
L: destinationL
...
Zde obohacovač čte IP adresu z atributu události ip_addr1
.
Pak se pokusí najít adresu ve svých vyhledávacích objektech: nejdříve ve
lookup-zone-1.pkl
, poté v ip2location.pkl.gz
.
Pokud najde shodu, získá vyhledávací hodnoty country_code
,
city_name
a L
a uloží je do příslušných polí události
sourceCountry
, sourceCity
a sourceLocation
.
Analogicky postupuje pro druhou adresu ip_addr2
.
Výsledek lze vidět níže.
Vstup¶
Feb 5 10:50:01 0:0:0:0:0:ffff:1f1f:e001 %ASA-1-105043 test
Řádek výše může být parsován do následujícího slovníku.
{
'rt': 1580899801.0,
'msg': 'test',
'ip_addr1': '0:0:0:0:0:ffff:1f1f:e001'
}
To 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í IP zón¶
Soubor pro vyhledávání IP je pickleovaný Python slovník.
Může být jednoduše vytvořen ze souboru CSV pomocí příkazu lmiocmd ipzone from-csv
naleznutelného v LogMan.io Commander.
CSV musí obsahovat řádek s hlavičkami s názvy sloupců.
Musí obsahovat sloupce ip_from
a ip_to
, a alespoň jeden další
sloupec s požadovanými hodnotami pro vyhledávání.
Například:
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 souboru pro vyhledávání nesmí překrývat.
POZNÁMKA
IP zóny v souboru CSV jsou považovány za uzavřené intervaly, tj. obě pole ip_from
a ip_to
jsou
zahrnuta v zóně, kterou vymezují.
IP2Location¶
Tímto příkazem lze také vytvořit soubor pro vyhledávání z IP2Location™ CSV databází. Všimněte si, že tyto soubory neobsahují názvy sloupců, takže řádek s hlavičkami musí být do souboru CSV přidán ručně před vytvořením vyhledávacího souboru.
IP Resolve Enricher & Expression¶
IP Resolve obohacuje událost o kanonický název hostitele a/nebo IP na základě buď IP adresy A síťového prostoru, nebo jakéhokoli názvu hostitele A sítě připojené k IP adrese v lookupu.
Lookup ID pro IP Resolve musí obsahovat následující podřetězec: ip_resolve
Záznam lookupu má následující strukturu:
key: [IP, network]
value: {
"hostnames": [
canonical_hostname,
hostname2,
hostname3
...
]
}
Příklad¶
Deklarace #1 - Enricher¶
---
define:
name: IPResolve
type: 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 - Expression¶
!IP.RESOLVE
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
with: !EVENT
lookup: lmio_ip_resolve # nepovinné
Vstup¶
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 enrichta, což je v případě IP Resolve vždy enricher/ipresolve
.
Prvek name
¶
Kratší název této deklarace, který je snadno čitelný pro lidi.
Prvek type
¶
Typ této deklarace, musí být enricher/ipresolve
.
Sekce source
¶
Specifikuje seznam atributů pro lookup. Každý atribut by měl být ve formátu:
[IP, network]
[hostname, network]
Pokud není síť specifikována, bude použita global
.
První úspěšný lookup vrátí výstupní hodnoty (ip
, hostname
).
Sekce ip
¶
Specifikuje atribut, kam se uloží lookuped IP adresa.
Sekce hostname
¶
Specifikuje atribut, kam se uloží lookuped kanonický název hostitele.
Kanonický název hostitele je první v hostnames
hodnoty lookupu.
Načítání lookupu ze souboru¶
Data lookupu pro IP Resolve mohou být načtena ze souboru pomocí LogMan.io Collector
input:FileBlock
.
Data budou dostupná v LogMan.io Parseru, kde by měla být
poslána na cíl lookup
. Lookup se tedy nedostane do tématu input
,
ale do tématu lookups
, odkud bude zpracován
LogMan.io Watcherem pro aktualizaci dat 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
rovno full
značí, že existující obsah lookupu by měl být
nahrazen items
v data
.
Pro vytvoření této struktury použijte následující deklarativní příklad Cascade Parseru:
---
define:
name: Demo of IPResolve parser
type: parser/cascade
target: lookup
parse:
!DICT
set:
action: full
lookup_id:
!JOIN
items:
- !ITEM CONTEXT filename
- ip_resolve
delimiter: '_'
data:
!DICT
set:
items:
!FOR
each:
!REGEX.SPLIT
what: !EVENT
regex: '\n'
do:
!FIRST
- !CONTEXT.SET
set:
_temp:
!REGEX.SPLIT
what: !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í lookups¶
Když je lookup přijat z LogMan.io Collector přes LogMan.io Ingestor, může se jednat buď o celý obsah lookupu (full frame), nebo jen jeden záznam (delta frame).
Předzpracování¶
Na základě formátu vstupního lookup souboru by měl být použit předzpracovatel, aby se zjednodušily následující deklarace a optimalizovala rychlost načítání lookupu. Obvykle bude použit buď JSON, XML nebo CSV předzpracovatel:
---
define:
name: Předzpracovatel pro CSV
type: parser/preprocessor
function: lmiopar.preprocessor.CSV
Tímto způsobem je obsah analyzovaného souboru uložen v CONTEXT
, odkud k němu lze přistupovat.
Full frame¶
Aby bylo možné uložit celý lookup do ElasticSearch prostřednictvím LogMan.io Watcher
a informovat jiné instance LogMan.io Parser a LogMan.io Correlator o změně
v celém lookup, měla by být použita deklarace Cascade Parser s konfigurací target: lookup
.
Takový lookup nevstoupí 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 hodnota action
rovna full
znamená, že existující obsah lookupu by měl být
nahrazen položkami v data
.
K vytvoření této struktury použijte následující deklarativní příklad Cascade Parseru.
Ukázková deklarace¶
---
define:
name: Ukázka parseru načítání lookupu
type: 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 lookup vstoupí do LogMan.io Parser, parsované lookup je posíláno do LogMan.io Watcher, aby bylo uloženo v ElasticSearch.
Delta frame¶
Aby bylo možné aktualizovat JEDNU položku v existujícím lookupu v ElasticSearch prostřednictvím LogMan.io Watcher
a informovat jiné instance LogMan.io Parser a LogMan.io Correlator o změně
v lookup, měla by být použita deklarace Cascade Parser s konfigurací target: lookup
.
Taková položka lookupu nevstoupí do tématu input
,
ale do tématu lookups
, odkud bude zpracována
LogMan.io Watcher, aby aktualizovala 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 hodnota action
rovna update_item
znamená, že obsah existující položky lookupu by měl být
nahrazen položkami v data
, nebo by měla být vytvořena nová položka lookupu.
K vytvoření této struktury použijte následující deklarativní příklad Cascade Parseru.
Ukázková deklarace¶
---
define:
name: Ukázka parseru načítání položek lookupu
type: parser/cascade
target: lookup
parse:
!DICT
set:
action: update_item
lookup_id: myLookup
data:
!DICT
set:
_id: !ITEM CONTEXT CSV.0.myID
...
Když obsah lookup vstoupí do LogMan.io Parser, parsované lookup je posíláno do LogMan.io Watcher, aby bylo uloženo v ElasticSearch.
MAC Vendor Enricher¶
MAC Vendor obohacuje události o specifické atributy dodavatele na základě jejich hodnoty MAC adresy (pro detekci dodavatele se zohledňuje pouze prvních 6 znaků).
Příklad¶
Deklarace¶
---
define:
name: MACVendor
type: enricher/macvendor
lookup: lmio_mac_vendor # volitelné
attributes:
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
¶
Specifikujte slovník s MAC atributy event
u, ve kterých se vyhledává, jako například MAC1
.
Uvnitř slovníku zmíněte název atributu v události, kam bude uložen detekovaný dodavatel.
Například:
MAC1:
detectedVendor1
prohledá MAC Vendor lookup pro MAC uložený v event["MAC1"]
,
nahraje dodavatele do event["detectedVendor1"]
, pokud je úspěšně nalezen.
Lookup soubory¶
Lookup soubory pro MAC Vendor obohacovač jsou založeny na standardu OUI: standards-oui.ieee.org/oui.txt
Soubory jsou uloženy v výchozím adresáři (/lookups/macvendor
),
který může být přepsán v konfiguraci:
[lookup:lmio_mac_vendor]
path=...
lmio_mac_vendor
je poskytované ID lookupu v definici obohacovače, které se výchozí nastavuje na lmio_mac_vendor
.
Parser Builder¶
Builder je nástroj pro snadné vytváření deklarací parseru/enricheru.
Pro spuštění builderu spusťte:
python3 builder.py -w :8081 ./example/asa-parser
Argument cesty specifikuje složku (nebo složky) s deklaracemi parserů a enhancerů (tedy YAML soubory). Doporučuje se směřovat do YAML knihovny.
YAML soubory jsou načteny v pořadí, které je specifikováno příkazovou řádkou, a poté se seřadí podle abecedního pořadí soubory *.yaml, které jsou nalezeny v příslušném adresáři.
Argument -I
umožňuje specifikovat složky, které budou použity jako základ pro direktivu !INCLUDE
. Povoleno je více záznamů.
Argument -w
určuje HTTP port.
Preprocessor
---
title: Parser preprocessor
---
# Parser preprocessor
*Parser preprocessor* umožňuje předzpracovat vstupní událost pomocí imperativního kódu, např. v Pythonu, Cythonu, C atd.
## Příklad
¶
---
title: Parser preprocessor
---
# Parser preprocessor
*Parser preprocessor* umožňuje předzpracovat vstupní událost pomocí imperativního kódu, např. v Pythonu, Cythonu, C atd.
## Příklad
define: name: Demo vestavěného Syslog předzpracování type: parser/preprocessor tenant: Syslog_RFC5424.STRUCTURED_DATA.soc@0.tenant # (volitelné) count: CEF.cnt # (volitelné)
function: lmiopar.preprocessor.Syslog_RFC5424
`tenant` specifikuje atribut tenant, který bude přečten a předán do `context['tenant']`
pro další distribuci zpracovaných i nezpracovaných událostí do specifických
ukazatelů/úložišť v LogMan.io Dispatcher
`count` specifikuje atribut count
s počtem událostí, které mají být přečteny a předány do `context['count']`
## Vestavěné preprocessory
Modul `lmiopar.preprocessor` obsahuje následující běžně používané preprocessory.
Tyto preprocessory jsou optimalizovány pro nasazení s vysokým výkonem.
### Syslog RFC5425 vestavěný preprocessor
`function: lmiopar.preprocessor.Syslog_RFC5424`
Toto je preprocessor pro protokol Syslog (nový) podle [RFC5425](https://tools.ietf.org/html/rfc5424).
Vstup pro tento preprocessor je platný Syslog záznam, např.:
Výstupem je, část zprávy v logu v události a parsované prvky v `context.syslog_rfc5424`.
context: Syslog_RFC5424: PRI: 165 FACILITY: 20 PRIORITY: 5 VERSION: 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: Application eventID: 1011 ...
### Syslog RFC3164 vestavěný preprocessor
`function: lmiopar.preprocessor.Syslog_RFC3164`
Toto je preprocessor pro protokol _BSD syslog_ (starší) podle [RFC3164](https://tools.ietf.org/html/rfc3164).
Syslog RFC3164 preprocessor lze nakonfigurovat v sekci `define`:
`year` specifikuje číselné označení roku, které bude aplikováno na časovou značku logů.
Také můžete specifikovat `smart` (výchozí) pro pokročilý výběr roku založený na měsíci.
`timezone` specifikuje časové pásmo logů, výchozí je `UTC`.
Vstup pro tento preprocessor je platný Syslog záznam, např.:
Výstupem je, část zprávy v logu v události a parsované prvky v `context.syslog_rfc3164`.
context: Syslog_RFC3164: PRI: 34 PRIORITY: 2 FACILITY: 4 TIMESTAMP: '2003-10-11T22:14:15.003Z' HOSTNAME: mymachine TAG: su PID: 10
`TAG` a `PID` jsou volitelné parametry.
### CEF vestavěný preprocessor
`function: lmiopar.preprocessor.CEF`
Toto je preprocessor pro _CEF_ nebo Common Event Format.
`year` specifikuje číselné označení roku, které bude aplikováno na časovou značku logů.
Také můžete specifikovat `smart` (výchozí) pro pokročilý výběr roku založený na měsíci.
`timezone` specifikuje časové pásmo logů, výchozí je `UTC`.
Vstup pro tento preprocessor je platný CEF záznam, např.:
Výstupem je, část zprávy v logu v události a parsované prvky v `context.CEF`:
eventId: '1234'
app: ssh
categorySignificance: /Informational/Warning
categoryBehavior: /Authentication/Verify
CEF může také obsahovat hlavičku Syslog.
To je podporováno řetězením relevantního preprocessoru Syslog s preprocesorem CEF.
Prosím, odkažte se na kapitolu o řetězení preprocessorů pro detaily.
### Vestavěné preprocessory formátů logů Apache HTTP serveru
Existují vysoce výkonné preprocessory pro běžné přístupy logů Apache HTTP serveru.
`function: lmiopar.preprocessor.Apache_Common_Log_Format`
Toto je preprocessor pro _Apache Common Log Format_.
`function: lmiopar.preprocessor.Apache_Combined_Log_Format`
Toto je preprocessor pro _Apache Combined Log Format_.
#### Příklad Apache Common Log
Vstup:
Výstup:
#### Příklad Apache Combined Log
Vstup:
Výstup:
### Microsoft ULS vestavěný preprocessor
`function: lmiopar.preprocessor.Microsoft_ULS`
Toto je preprocessor pro Microsoft_ULS podle [Microsoft Docs](https://docs.microsoft.com/cs-cz/archive/blogs/sharepoint_scott/ulsviewer-filters-performance-filters).
Pro Microsoft SharePoint ULS logy, které neobsahují názvy serverů ani korelaci polí,
je poskytnut vyhrazený preprocessor:
`function: lmiopar.preprocessor.Microsoft_ULS_Sharepoint`
Preprocessor Microsoft SharePoint ULS lze nakonfigurovat v sekci define:
`year` specifikuje číselné označení roku, které bude aplikováno na časovou značku logů.
Také můžete specifikovat `smart` (výchozí) pro pokročilý výběr roku založený na měsíci.
`timezone` specifikuje časové pásmo logů, výchozí je `UTC`.
Vstup pro tento preprocessor je platný záznam Microsoft ULS Sharepoint, např.:
Výstupem je, část zprávy v logu v události a parsované prvky v `context.Microsoft_ULS`.
context: Microsoft_ULS: TIMESTAMP: 1619613117.69 PROCESS: mssdmn.exe (0x38E0) THREAD: 0x4D10 PRODUCT: SharePoint Server Search CATEGORY: Connectors:SharePoint EVENTID: dvt6 LEVEL: High
### Query String preprocessor
`function: lmiopar.preprocessor.Query_String`
Toto je preprocessor pro Query String (key=value&key=value...) jako je meta informace z LogMan.io Collector
Příklad vstupu:
Výstupem je, část zprávy v logu v události a parsované prvky v `context.QUERY_STRING`.
context: QUERY_STRING: file_name: log.log search: true
### JSON vestavěný preprocessor
`function: lmiopar.preprocessor.JSON`
Toto je preprocessor pro formát JSON.
Očekává vstup ve formátu binárním nebo textovém, výstupní slovník je umístěn v události.
Vstupem pro tento preprocessor je tedy platný JSON záznam.
### XML vestavěný preprocessor
`function: lmiopar.preprocessor.XML`
Toto je preprocessor pro formát XML.
Očekává vstup ve formátu binárním nebo textovém, výstupní slovník je umístěn v události.
Vstupem pro tento preprocessor je tedy platný XML záznam, např.:
Výstup preprocessoru v `event`:
### CSV vestavěný preprocessor
`function: lmiopar.preprocessor.CSV`
Toto je preprocessor pro formát CSV.
Očekává vstup ve formátu binárním nebo textovém, výstupní slovník je umístěn v události.
Vstupem pro tento preprocessor je tedy platný CSV záznam, např.:
Výstup preprocessoru v `context["CSV"]`:
#### Parametry
V sekci `define` CSV preprocessoru, mohou být nastaveny následující parametry pro čtení CSV:
## Vlastní preprocessory
Vlastní preprocessory mohou být vyvolány z parseru, příslušný kód musí být přístupný mikroservisu parseru přes běžný způsob importu v Pythonu.
define: name: Demo vlastního Python preprocessoru type: parser/preprocessor
function: mypreprocessors.preprocessor
`mypreprocessors` je modul odpovídající složce s `__init__.py`, která obsahuje funkci `preprocessor()`.
Parser specifikuje `function` ke spuštění.
Používá notaci Pythonu a automaticky importuje modul.
Signatura funkce:
Preprocessor může (1) modifikovat událost (`!EVENT`) a/nebo (2) modifikovat kontext (`!CONTEXT`).
Výstup funkce `preprocessor` bude předán do následných parserů.
Preprocessor parser nevytváří zpracované události přímo.
Pokud funkce vrátí None, zpracování události je potichu ukončeno.
Pokud funkce vyvolá výjimku, výjimka bude zaznamenána a událost bude přeposlána do výstupu `unparsed`.
## Řetězení preprocessorů
Preprocessory mohou být řetězeny za účelem parsování složitějších vstupních formátů.
Výstup (neboli událost) z prvního preprocessoru je předán jako vstup druhému preprocessoru (a tak dále).
Například vstup je ve formátu CEF s hlavičkou Syslog RFC3164:
Standardní Obohacovač¶
Standardní Obohacovač obohacuje parsovanou událost o další pole. Obohacení probíhá po úspěšném přiřazení a parsování původního vstupu jedním z kaskádových parserů v rámci skupiny parsování.
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: "Byli jste obohaceni"
Sekce define
¶
Tato sekce obsahuje obecnou definici a metada.
Položka name
¶
Stručný, 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ávání aliasů polí, které mají být načteny, aby bylo možné použít aliasy názvů atributů událostí v deklaraci spolu s jejich kanonickými názvy.
Položka description
(volitelné)¶
Delší, případně víceřádkový, lidsky čitelný popis deklarace.
Sekce enrich
¶
Tato sekce specifikuje samotné obohacení příchozí události. Očekává se, že bude vrácen slovník.
Typické příkazy v sekci enrich
¶
Příkaz !DICT
umožňuje přidat pole / atributy k již parsované události.
Testování parserů¶
Je důležité testovat parsery, aby byla ověřena jejich funkčnost s různými vstupy. LogMan.io nabízí nástroje pro manuální a automatizované testování parserů.
LogMan.io Utility pro Parsování¶
Tento nástroj je určen pro ruční spuštění parserů z příkazového řádku. Je užitečný pro testování, protože aplikuje vybrané skupiny parserů na vstup a nezpracované události jsou uloženy do speciálního souboru, aby mohl být parser vylepšen, dokud tento „neparsovaný“ výstup nebude prázdný. Je navržen pro parsování velmi velkých vstupů.
Utility pro parsování je program příkazového řádku. 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 k parsování
-u, --unparsed-file
určuje soubor pro uložení neparcovaných událostí ze vstupu
a dále následují skupiny parserů z knihovny, odkud se načítají deklarativní parsery.
Následující aplikace provádí parsování na zadaném vstupním souboru s řádky oddělenými novými řádky, například:
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 produkuje soubor pouze s neparcovanými
událostmi, který má stejnou strukturu:
Feb 10 8:25:00 192.168.A1.1 X %ASA-1-105044 test3
Jednotkové Testy Parserů¶
LogMan.io poskytuje nástroj pro spuštění jednotkových testů nad knihovnou deklarací parserů a obohacovačů.
Chcete-li spustit:
python3 ./test.py ./example [--config ./config.json]
Nástroj hledá testy v knihovně, načítá je a poté je provádí v pořadí.
Formát jednotkových testů¶
Soubor jednotkového testu musí být umístěn v adresáři test
a název souboru musí odpovídat šabloně test*.yaml
. Jeden YAML testovací soubor může obsahovat jeden nebo více YAML dokumentů se specifikací testu.
---
input: |
řádek 1
řádek 2
...
groups:
# To znamená, že vše ze vstupu bude parsováno
unparsed: []
parsed:
- msg: řádek
num: 1
- msg: řádek
num: 2
Rozšíření parsovacího pipeline¶
Dodáváme LogMan.io knihovnu se standardními parsery, které jsou organizovány do předdefinovaných skupin. Někdy však můžete chtít rozšířit proces parsování vlastními parsers nebo obohacovači.
Zvažte následující vstupní událost, která bude parsována pomocí parserů z knihovny LogMan.io se skupinovým ID lmio_parser_default_syslog_rfc3164:
<163>Feb 22 14:12:56 vmhost01 2135: ERR042: Něco se pokazilo.
Tato událost bude parsována do strukturované události, která vypadá takto:
{
"@timestamp": 1614003176,
"ecs.version": "1.6.0",
"event.kind": "event",
"event.dataset": "syslog.rfc3164",
"message": "ERR042: Něco se pokazilo.\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ší klíčové slovo - chybový kód "ERR042", který není součástí strukturované události. Můžeme extrahovat tuto hodnotu do vlastního pole strukturované události přidáním obohacovače (typ parseru), který rozdělí část "message" události a vybere chybový kód.
Najděte Skupinu Parserů k Rozšíření¶
V výše uvedeném příkladu používáme parsery s ID skupiny lmio_parser_default_syslog_rfc3164
. Takže se pojďme přesunout do složky této skupiny v knihovně LogMan.io:
$ cd /opt/lmio-ecs # ... nebo vaše jiná umístění lmio-ecs
$ cd syslog_rfc3164-parser
Vytvoření Nového Deklaračního Souboru¶
Ve výchozím nastavení, bez rozšíření, 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
.
- "e" znamená "enricher" (obohacovač)
- "01" znamená prioritu, kterou tento obohacovač získá
- "-enricher" může být nahrazeno čímkoliv, co vám dává smysl
- "yaml" je povinná přípona
Přidání Obsahu do Deklaračního Souboru¶
Definice¶
Deklarace je YAML soubor s YAML záhlavím (v našem případě prázdným) a povinným blokem definice. Přidáváme standardní obohacovač s názvem "Error Code Enricher".
Přidejte následující do dekleračního souboru:
---
define:
name: Error Code Enricher
type: enricher/standard
Predikát¶
Chceme, aby náš obohacovač byl aplikován pouze na vybrané zprávy, takže musíme deklarovat predikát pomocí deklarativního jazyka.
Aplikujme obohacení na zprávy z hosta vmhost01
.
Přidejte následující do dekleračního souboru:
predicate:
!EQ
- !ITEM EVENT host.name
- "vmhost01"
Obohacení¶
Když se podíváme na "message" výše uvedené události, chceme zprávu rozdělit podle dvojteček, vzít hodnotu prvního prvku výsledků a uložit ji jako "error.code" (nebo jiné ECS pole).
Toho můžeme dosáhnout opět pomocí deklarativního jazyka.
Přidejte následující do dekleračního souboru:
enrich:
!DICT
with: !EVENT
set:
error.code: !CUT
what: !ITEM EVENT message
delimiter: ':'
field: 0
Výsledná událost předaná do parsovacího pipeline bude obsahovat všechna pole z původní události a jedno další pole "error.code", jehož hodnota je výsledkem !CUT
"message" pole z původní události (!ITEM EVENT message
) pomocí :
jako oddělovače a vybráním prvku na indexu 0
.
Takto vypadá obsah souboru e01-enricher.yaml
:
---
define:
name: Error Code Enricher
type: enricher/standard
predicate:
!EQ
- !ITEM EVENT host.name
- "vmhost01"
enrich:
!DICT
with: !EVENT
set:
error.code: !CUT
what: !ITEM EVENT message
delimiter: ':'
field: 0
Aplikování změn¶
Nová deklarace by měla být udržována ve verzi řízení. lmio-parser instance, která používá ID skupiny parserů, musí být restartována.
Závěr¶
Přidali jsme nový obohacovač do lmio_parser_default_syslog_rfc3164's parsovací pipeline.
Nové události z hosta vmhost01 nyní budou parsovány a obohaceny s následujícím výstupem události:
{
"@timestamp": 1614003176,
"ecs.version": "1.6.0",
"event.kind": "event",
"event.dataset": "syslog.rfc3164",
"message": "ERR042: Něco se pokazilo.\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",
"error.code": "ERR042"
}
Depositor
LogMan.io Depositor¶
TeskaLabs LogMan.io Depositor je mikroslužba zodpovědná za ukládání událostí v Elasticsearch a nastavování Elasticsearch artefaktů (jako jsou indexové šablony a ILM politiky) na základě deklarací event lane.
LogMan.io Depositor ukládá úspěšně zpracované nebo korelované události a další události do jejich příslušných Elasticsearch indexů.
Poznámka
LogMan.io Depositor nahrazuje LogMan.io Dispatcher.
Důležité poznámky¶
Požadavky a konfigurace¶
- Depositor vyžaduje specifické nastavení Elasticsearch s definovanými rolami uzlů, viz Požadavky
- Depositorova výchozí životnostní politika vyžaduje nastavení rolí uzlů v konfiguraci Elasticsearch, viz Požadavky
- Depositor výchozí přestane posílat data do Elasticsearch, pokud je zdraví clusteru pod
50 %
, viz Konfigurace - Depositor bere v úvahu všechny event lane soubory bez ohledu na to, zda jsou pro daného tenanta v UI deaktivovány či nikoli
Správa indexů¶
- Depositor vytváří svou vlastní indexovou šablonu a životnostní politiku (ILM) pro každý index specifikovaný v sekcích
events
aothers
uvnitř deklarace event lane, viz Event Lane - Depositorova výchozí indexová šablona má 6 shardů a 1 repliku
- Mapování polí (typy polí) v indexové šabloně vychází ze schématu event lane, viz Event Lane
Podrobnosti o životnostní politice¶
- Depositorova výchozí životnostní politika má limit 16 GB na primární shard na index (výchozí maximální velikost indexu je tedy 6 shardů * 16 GB * 2 pro repliku = 192 GB)
- Depositorova výchozí životnostní politika má povoleno zmenšování při vstupu do teplé fáze
- Depositorova výchozí životnostní politika smaže data po 180 dnech
Migrace¶
- Při migraci z LogMan.io Dispatcher na LogMan.io Depositor, viz sekci Migrace
Požadavky na Depositor¶
LogMan.io Depositor má následující závislosti:
- Elasticsearch
- Apache ZooKeeper
- Apache Kafka
- LogMan.io Knihovna s
/EventLanes
složkou a schéma ve složce/Schemas
Konfigurace Elasticsearch¶
Elasticsearch cluster musí být nakonfigurován následovně, aby LogMan.io Depositor správně fungoval.
Níže je záznam Docker Compose pro Elasticsearch uzly, použitím architektury 3-uzlového clustera s lm1
, lm2
a lm3
serverovými uzly.
Poznámka
Vezměte, prosím, na vědomí, že v souboru Docker Compose mají Elasticsearch uzly přiřazené příslušné role uzlů na základě ILM. Například hot uzly pro ILM horkou fázi musí obsahovat role uzlu data_hot
a data_content
.
Při vytváření záznamů Docker Compose pro Elasticsearch uzly je třeba změnit následující atributy:
- NODE_ID: Název serveru, na kterém instance Elasticsearch běží
- INSTANCE_ID: Název instance Elasticsearch. Ujistěte se, že jeho postfix
-1
je při této druhé instanci této služby změněn na-2
atd. INSTANCE_ID je tedy jedinečný identifikátor pro každou z instancí. - network.host: Název serveru, na kterém instance Elasticsearch běží
- node.attr.rack_id: Název serverového racku (pro velké nasazení) nebo název serveru, na kterém instance Elasticsearch běží
- discovery.seed_hosts: Názvy serverů a porty všech Elasticseach hlavních uzlů
- xpack.security.transport.ssl.certificate: Cesta k certifikátu specifickému pro danou instanci Elasticsearch
- xpack.security.transport.ssl.key: Cesta ke klíči certifikátu specifickému pro danou instanci Elasticsearch
- volumes: Cesta k datům dané instance Elasticsearch
elasticsearch-master-1:
network_mode: host
user: "1000:1000"
image: docker.elastic.co/elasticsearch/elasticsearch:7.17.9
environment:
- NODE_ID=lm1
- SERVICE_ID=elasticsearch
- INSTANCE_ID=elasticsearch-master-1
- network.host=lm1 # (1)
- node.attr.rack_id=lm1 # (2)
- node.name=elasticsearch-master-1
- node.roles=master,ingest
- cluster.name=lmio-es # (3)
- cluster.initial_master_nodes=elasticsearch-master-1,elasticsearch-master-2,elasticsearch-master-3 # (6)
- discovery.seed_hosts=lm1:9300,lm2:9300,lm3:9300
- http.port=9200
- transport.port=9300 # (4)
- "ES_JAVA_OPTS=-Xms4g -Xmx4g" # (5)
- ELASTIC_PASSWORD=$ELASTIC_PASSWORD
- xpack.security.enabled=true
- xpack.security.transport.ssl.enabled=true
- xpack.security.transport.ssl.verification_mode=certificate
- xpack.security.transport.ssl.certificate_authorities=certs/ca/ca.crt
- xpack.security.transport.ssl.certificate=certs/elasticsearch-master-1/elasticsearch-master-1.crt
- xpack.security.transport.ssl.key=certs/elasticsearch-master-1/elasticsearch-master-1.key
volumes:
- /data/ssd/elasticsearch/elasticsearch-master-1/data:/usr/share/elasticsearch/data
- ./elasticsearch/certs:/usr/share/elasticsearch/config/certs
restart: always
-
Uzel se připojí na veřejnou adresu a také ji použije jako svoji publikovanou adresu.
-
Rack ID nebo název datového centra. To má za účel umožnit ES efektivně a bezpečně spravovat repliky. Pro menší instalace je dostačující název hostitele.
-
Název Elasticsearch clusteru. V LogMan.io je pouze jeden Elasticsearch cluster.
-
Porty pro interní komunikaci mezi uzly.
-
Paměť přidělená pro tuto instanci Elasticsearch. 31 GB je maximální doporučená hodnota a server musí mít dostatečnou dostupnou paměť (pokud jsou tři Elasticsearch uzly s 31 GB a jeden master uzel se 4 GB, musí být k dispozici alespoň 128 GB).
-
Počáteční master uzly jsou instance ID všech Elasticsearch hlavních uzlů dostupných v LogMan.io clusteru. Názvy hlavních uzlů musí být sladěny s node.name. V LogMan.io (jak je definováno Maestro), je totožný s INSTANCE_ID.
elasticsearch-hot-1:
network_mode: host
user: "1000:1000"
image: docker.elastic.co/elasticsearch/elasticsearch:7.17.9
depends_on:
- es-master
environment:
- NODE_ID=lm1
- SERVICE_ID=elasticsearch
- INSTANCE_ID=elasticsearch-hot-1
- network.host=lm1 # (1)
- node.attr.rack_id=lm1 # (2)
- node.attr.data=hot # (3)
- node.name=elasticsearch-hot-1
- node.roles=data_hot,data_content # (6)
- cluster.name=lmio-es # (4)
- cluster.initial_master_nodes=elasticsearch-master-1,elasticsearch-master-2,elasticsearch-master-3 # (8)
- discovery.seed_hosts=lm1:9300,lm2:9300,lm3:9300
- http.port=9201
- transport.port=9301 # (5)
- "ES_JAVA_OPTS=-Xms31g -Xmx31g" # (7)
- ELASTIC_PASSWORD=$ELASTIC_PASSWORD
- xpack.security.enabled=true
- xpack.security.transport.ssl.enabled=true
- xpack.security.transport.ssl.verification_mode=certificate
- xpack.security.transport.ssl.certificate_authorities=certs/ca/ca.crt
- xpack.security.transport.ssl.certificate=certs/elasticsearch-hot-1/elasticsearch-hot-1.crt
- xpack.security.transport.ssl.key=certs/elasticsearch-hot-1/elasticsearch-hot-1.key
volumes:
- /data/ssd/elasticsearch/elasticsearch-hot-1/data:/usr/share/elasticsearch/data
- ./elasticsearch/certs:/usr/share/elasticsearch/config/certs
-
Uzel se připojí na veřejnou adresu a také ji použije jako svoji publikovanou adresu.
-
Rack ID nebo název datového centra. To má za účel umožnit ES efektivně a bezpečně spravovat repliky. Pro menší instalace je dostačující název hostitele.
-
Atributy
node.attr.data
jsou v konfiguraci kvůli zpětné kompatibilitě pro starší verze ILM, kde se používá vlastní alokace pomocínode.attr.data
. Toto platí pro instalace LogMan.io před 01/2024. -
Název Elasticsearch clusteru. V LogMan.io je pouze jeden Elasticsearch cluster.
-
Porty pro interní komunikaci mezi uzly.
-
Role uzlů jsou zde kvůli správnému fungování výchozí alokace ILM.
-
Paměť přidělená pro tuto instanci Elasticsearch. 31 GB je maximální doporučená hodnota a server musí mít dostatečnou dostupnou paměť (pokud jsou tři Elasticsearch uzly s 31 GB a jeden master uzel se 4 GB, musí být k dispozici alespoň 128 GB).
-
Počáteční master uzly jsou instance ID všech Elasticsearch hlavních uzlů dostupných v LogMan.io clusteru. Názvy hlavních uzlů musí být sladěny s node.name. V LogMan.io (jak je definováno Maestro), je totožný s INSTANCE_ID.
elasticsearch-warm-1:
network_mode: host
user: "1000:1000"
image: docker.elastic.co/elasticsearch/elasticsearch:7.17.9
depends_on:
- es-master
environment:
- NODE_ID=lm1
- SERVICE_ID=elasticsearch
- INSTANCE_ID=elasticsearch-warm-1
- network.host=lm1 # (1)
- node.attr.rack_id=lm1 # (2)
- node.attr.data=warm # (3)
- node.name=elasticsearch-warm-1
- node.roles=data_warm # (6)
- cluster.name=lmio-es # (4)
- cluster.initial_master_nodes=elasticsearch-master-1,elasticsearch-master-2,elasticsearch-master-3 # (8)
- discovery.seed_hosts=lm1:9300,lm2:9300,lm3:9300
- http.port=9202
- transport.port=9302 # (5)
- "ES_JAVA_OPTS=-Xms31g -Xmx31g" # (7)
- ELASTIC_PASSWORD=$ELASTIC_PASSWORD
- xpack.security.enabled=true
- xpack.security.transport.ssl.enabled=true
- xpack.security.transport.ssl.verification_mode=certificate
- xpack.security.transport.ssl.certificate_authorities=certs/ca/ca.crt
- xpack.security.transport.ssl.certificate=certs/elasticsearch-warm-1/elasticsearch-warm-1.crt
- xpack.security.transport.ssl.key=certs/elasticsearch-warm-1/elasticsearch-warm-1.key
volumes:
- /data/hdd/elasticsearch/elasticsearch-warm-1/data:/usr/share/elasticsearch/data
- ./elasticsearch/certs:/usr/share/elasticsearch/config/certs
-
Uzel se připojí na veřejnou adresu a také ji použije jako svoji publikovanou adresu.
-
Rack ID nebo název datového centra. To má za účel umožnit ES efektivně a bezpečně spravovat repliky. Pro menší instalace je dostačující název hostitele.
-
Atributy
node.attr.data
jsou v konfiguraci kvůli zpětné kompatibilitě pro starší verze ILM, kde se používá vlastní alokace pomocínode.attr.data
. Toto platí pro instalace LogMan.io před 01/2024. -
Název Elasticsearch clusteru. V LogMan.io je pouze jeden Elasticsearch cluster.
-
Porty pro interní komunikaci mezi uzly.
-
Role uzlů jsou zde kvůli správnému fungování výchozí alokace ILM.
-
Paměť přidělená pro tuto instanci Elasticsearch. 31 GB je maximální doporučená hodnota a server musí mít dostatečnou dostupnou paměť (pokud jsou tři Elasticsearch uzly s 31 GB a jeden master uzel se 4 GB, musí být k dispozici alespoň 128 GB).
-
Počáteční master uzly jsou instance ID všech Elasticsearch hlavních uzlů dostupných v LogMan.io clusteru. Názvy hlavních uzlů musí být sladěny s node.name. V LogMan.io (jak je definováno Maestro), je totožný s INSTANCE_ID.
elasticsearch-cold-1:
network_mode: host
user: "1000:1000"
image: docker.elastic.co/elasticsearch/elasticsearch:7.17.9
depends_on:
- es-master
environment:
- NODE_ID=lm1
- SERVICE_ID=elasticsearch
- INSTANCE_ID=elasticsearch-cold-1
- network.host=lm1
- node.attr.rack_id=lm1 # (2)
- node.attr.data=cold # (3)
- node.name=elasticsearch-cold-1
- node.roles=data_cold # (6)
- cluster.name=lmio-es # (4)
- cluster.initial_master_nodes=elasticsearch-master-1,elasticsearch-master-2,elasticsearch-master-3 # (8)
- discovery.seed_hosts=lm1:9300,lm2:9300,lm3:9300
- http.port=9203
- transport.port=9303 # (5)
- "ES_JAVA_OPTS=-Xms31g -Xmx31g" # (7)
- ELASTIC_PASSWORD=$ELASTIC_PASSWORD
- xpack.security.enabled=true
- xpack.security.transport.ssl.enabled=true
- xpack.security.transport.ssl.verification_mode=certificate
- xpack.security.transport.ssl.certificate_authorities=certs/ca/ca.crt
- xpack.security.transport.ssl.certificate=certs/elasticsearch-cold-1/elasticsearch-cold-1.crt
- xpack.security.transport.ssl.key=certs/elasticsearch-cold-1/elasticsearch-cold-1.key
volumes:
- /data/hdd/elasticsearch/elasticsearch-cold-1/data:/usr/share/elasticsearch/data
- ./elasticsearch/certs:/usr/share/elasticsearch/config/certs
-
Uzel se připojí na veřejnou adresu a také ji použije jako svoji publikovanou adresu.
-
Rack ID nebo název datového centra. To má za účel umožnit ES efektivně a bezpečně spravovat repliky. Pro menší instalace je dostačující název hostitele.
-
Atributy
node.attr.data
jsou v konfiguraci kvůli zpětné kompatibilitě pro starší verze ILM, kde se používá vlastní alokace pomocínode.attr.data
. Toto platí pro instalace LogMan.io před 01/2024. -
Název Elasticsearch clusteru. V LogMan.io je pouze jeden Elasticsearch cluster.
-
Porty pro interní komunikaci mezi uzly.
-
Role uzlů jsou zde kvůli správnému fungování výchozí alokace ILM.
-
Paměť přidělená pro tuto instanci Elasticsearch. 31 GB je maximální doporučená hodnota a server musí mít dostatečnou dostupnou paměť (pokud jsou tři Elasticsearch uzly s 31 GB a jeden master uzel se 4 GB, musí být k dispozici alespoň 128 GB).
-
Počáteční master uzly jsou instance ID všech Elasticsearch hlavních uzlů dostupných v LogMan.io clusteru. Názvy hlavních uzlů musí být sladěny s node.name. V LogMan.io (jak je definováno Maestro), je totožný s INSTANCE_ID.
Šablony Indexů¶
LogMan.io Depositor vytváří své vlastní šablony indexů s indexem events
z konfigurace elasticsearch
event lane, přidává postfix -template
. Všechny předchozí šablony indexů, pokud jsou přítomny, musí mít jiné jméno a jejich priorita nastavena na 0.
Konfigurace Depositoru¶
Vzor konfigurace¶
Toto je nejzákladnější konfigurace potřebná pro LogMan.io Depositor:
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
[library]
providers=zk:///library
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
[elasticsearch]
url=http://es01:9200
Zookeeper¶
Určete umístění serveru Zookeeper v clusteru.
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
Hint
Pro neprodukční nasazení je možné použít jediný server Zookeeper.
Knihovna¶
Určete cestu(y) ke knihovně, ze které se mají provést nahrávky deklarací.
[library]
providers=zk:///library
Hint
Protože je standardně využíváno schéma ECS.yaml
v /Schemas
, zvažte použití LogMan.io Common Library.
Kafka¶
Určete bootstrap servery Kafka clusteru.
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
Hint
Pro neprodukční nasazení je možné použít jediný server Kafka.
Elasticsearch¶
Určete URL adresy master nodů Elasticsearch.
Sekce ESConnection
se používá pro nastavení pokročilých parametrů připojení (viz níže).
Sekce elasticsearch
se používá pro ukládání URL a autentizačních údajů.
Sekce asab:storage
se používá pro explicitní povolení inicializace úložiště.
[asab:storage]
type=elasticsearch
[connection:ESConnection]
precise_error_handling=true
bulk_out_max_size=1582912
output_queue_max_size=5
loader_per_url=1
cluster_status_throttle=red
cluster_status_unthrottle=green
active_shards_percent_throttle=50
retry_errors=unavailable_shards_exception
throttle_errors=circuit_breaking_exception
[elasticsearch]
url=http://es01:9201
username=MYUSERNAME
password=MYPASSWORD
Hint
URL by mělo směřovat na hot node Elasticsearch na stejném serveru, kde je nasazen Depositor.
Pokročilé nastavení připojení k Elasticsearch¶
precise_error_handling¶
Určuje, že Elasticsearch by měl vracet informace o tom, které události způsobili problém spolu s chybou.
bulk_out_max_size¶
Velikost jednoho bulk požadavku odesílaného do Elasticsearch v bajtech.
Události jsou seskupeny do bulků, aby se snížil počet požadavků odesílaných do Elasticsearch.
output_queue_max_size¶
Maximální velikost fronty pro bulks Elasticsearch.
Pokud je číslo překročeno, daný pipeline je throttlován.
loader_per_url¶
Počet úkolů/loaderů na URL. Určuje počet požadavků, které mohou být současně odeslány na každou URL uvedenou v atributu URL.
cluster_status_throttle¶
Stav, do kterého musí cluster vstoupit, aby se Depositor zastavil/throttloval. Lze nastavit na none
.
Default: red
Možnosti: red
, yellow
, none
cluster_status_unthrottle¶
Stav, do kterého musí cluster vstoupit, aby se Depositor obnovil/unthrottloval, pokud byl throttlovaný.
Default: green
Možnosti: red
, yellow
, green
active_shards_percent_throttle¶
Minimální procento celkových shardů, které musí být aktivní/dostupné, aby Depositor mohl odesílat události.
Hodnota, která je pročentem, by měla být nastavena na 100 / (počet replik + 1)
.
Default: 50
retry_errors¶
Seznam chyb, které lze opakovat, oddělených čárkou, které způsobí opětné odeslání události do indexu událostí specifikovaného v event lane.
Note
Tato konfigurační volba je ve většině případů zbytečná, a proto se doporučuje ji z konfigurace vyloučit.
throttle_errors¶
Seznam chyb, oddělených čárkou, které způsobí throttle Dispatcheru, dokud nebudou vyřešeny.
Note
Tato konfigurační volba je ve většině případů zbytečná, a proto se doporučuje ji z konfigurace vyloučit.
Deklarace¶
Volitelná sekce pro určení, odkud načíst deklarace event lane a které schéma bude použito jako výchozí (pokud není specifikováno v dané deklaraci event lane).
[declarations]
path=/EventLanes/
schema=/Schemas/ECS.yaml
Hint
Ujistěte se, že změníte schéma, pokud používáte jiné schéma než ECS ve vašem nasazení jako výchozí. Změna cesty pro event lanes se nedoporučuje.
Event Lanes¶
TeskaLabs LogMan.io Depositor čte všechny event lanes z knihovny a vytváří Kafka-to-Elasticsearch pipelines na základě sekcí kafka
a elasticsearch
.
Note
Všechny nasazené instance TeskaLabs LogMan.io Depositor sdílejí stejné Group ID v rámci Kafka. Všechny instance si rozdělují spotřebu z Kafka partitions mezi sebou a tím poskytují nativní škálovatelnost.
Deklarace¶
Toto je příklad sekcí event lane relevantních pro LogMan.io Depositor:
---
define:
type: lmio/event-lane
kafka:
events:
topic: events.<tenant>.<stream> # Kafka téma pro zpracované události
others:
topic: others.<tenant>.<stream> # Kafka téma pro nezpracované události
elasticsearch:
events:
index: lmio-<tenant>-events-<stream> # Index alias pro události
others:
index: lmio-<tenant>-others # Index alias pro ostatní
Když je LogMan.io Depositor spuštěn a event lane je načten, jsou vytvořeny dvě pipelines. Events pipeline spotřebovává zprávy z Kafka tématu definovaného v kafka/events/topic
a ukládá je do Elasticsearch indexu, pomocí index aliasu definovaného v elasticsearch/events/index
.
Others pipeline podobně spotřebovává zprávy z tématu definovaného v kafka/others/topic
a ukládá je do indexu pomocí aliasu definovaného v elasticsearch/others/index
.
Index vs. index alias
V Elasticsearch je index kolekcí dokumentů, které sdílejí stejnou strukturu a jsou uloženy společně. Je to primární jednotka pro ukládání a vyhledávání dat.
Index alias je virtuální název, který může odkazovat na jeden nebo více indexů. Umožňuje zobrazit a manipulovat s daty stejného logického streamu.
V event lane je specifikován index alias. LogMan.io Depositor vytváří indexy na základě tohoto aliasu.
Například, když je index alias definován jako lmio-tenant-events-stream
, _LogMan.io Depositor
vytváří indexy
lmio-tenant-events-stream-000001
lmio-tenant-events-stream-000002
lmio-tenant-events-stream-000003
...
Komplexní event lanes
LogMan.io Depositor nativně nečte z Kafka tématu events.<tenant>.complex
a přeskočí komplexní event lanes.
Note
Depositor zvažuje VŠECHNY soubory event lane bez ohledu na to, zda jsou pro daného tenanta v UI zakázány nebo ne. Depositor není tenant-specifická služba.
Šablona indexu¶
LogMan.io Depositor vytváří a aktualizuje šablonu indexu pro každou event lane.
Mapování ve šabloně indexu je založeno na schématu event lane. Výchozí schéma pro event lane je /Schemas/ECS.yaml
. Může být změněno v deklaraci event lane:
---
define:
type: lmio/event-lane
schema: /Schemas/CEF.yaml
Je také možné specifikovat number_of_shards
a number_of_replicas
v sekci nastavení v elasticsearch
:
---
define:
type: lmio/event-lane
elasticsearch:
events:
settings:
number_of_shards: 6
number_of_replicas: 1
Výchozí hodnota number_of_shards
je 6 a number_of_replicas
je 1.
Note
Prosím zvažte pečlivě před změnou výchozích nastavení a schématu. Změna výchozích hodnot obvykle způsobuje problémy, jako jsou neporovnané detekční pravidla pro danou event lane, která používá jiné schéma.
Warning
Změny v šabloně indexu se projeví pouze po dalším rolloveru indexu, pokud již index v Elasticsearch existuje.
Politika životního cyklu¶
LogMan.io Depositor konfiguruje Index Lifecycle Policy pro každou event lane.
Výchozí¶
Výchozí politika životního cyklu obsahuje čtyři fáze: hot
, warm
, cold
a delete
.
-
Výchozí hot fáze pro daný index končí, když velikost primárního shardu přesáhne 16 GB nebo je starší než 7 dní.
-
Výchozí warm fáze pro daný index začíná buď když hot fáze skončí, nebo po 7 dnech, a zapne shrinking.
-
Výchozí cold fáze pro daný index začíná po 14 dnech.
-
Fáze delete smaže index po 180 dnech.
Vlastní¶
Výchozí ILM může být změněn, i když to není doporučeno pro většinu případů. Můžete to udělat specifikováním sekce lifecycle
v rámci sekce elasticsearch
event lane:
---
define:
type: lmio/event-lane
elasticsearch:
events:
lifecycle:
hot:
min_age: "0ms"
actions:
rollover:
max_primary_shard_size: "25gb" # Chceme větší primární shardy než je výchozí hodnota
max_age: "30d"
set_priority:
priority: 100
warm:
min_age: "7d"
actions:
shrink:
number_of_shards: 1
set_priority:
priority: 50
cold:
min_age: "14d"
actions:
set_priority:
priority: 0
delete:
min_age: 180d
actions:
delete:
delete_searchable_snapshot: true
Nastavte kompletní ILM politiku.
I když se snažíte změnit pouze jednu z fází, musíte specifikovat celou politiku životního cyklu. Vlastní ILM zcela přepisuje výchozí konfiguraci.
Žádná fáze delete
Pokud nechcete nastavit fázi delete
, jednoduše vynechte sekci delete
v event lane. Používejte to pouze pokud opravdu víte, co děláte!
Migrace Dispatcher na Depositor¶
Warning
Tato sekce je relevantní pro neautomatizované instalace TeskaLabs LogMan.io, které fungují s LogMan.io Dispatcher.
Migrace z LogMan.io Dispatcher na LogMan.io Depositor musí být provedena po jedné event lane podle níže uvedených kroků.
Warning
Než začnete s migrací, musíte dodržet Požadavky, a ujistit se, že máte správně nakonfigurované role uzlů pro Elasticsearch uzly v clusteru.
Kroky migrace¶
Vyberte jednu event lane k migraci a postupujte podle tohoto průvodce:
1. V Kibana, přejděte na Management > Stack Management, poté Index Management. Klikněte na Index Templates a najděte šablonu indexu spojenou s migrovaným event lane. Obvykle je název ve formátu lmio-tenant-events-eventlane-template
. Ve sloupci Akce (tři tečky) vpravo klikněte na Clone.
2. Ve Clone, změňte Název na backup-lmio-tenant-events-eventlane-template
a nastavte Prioritu na 0
.
3. Přejděte na Review template a klikněte na Create template.
4. Zkontrolujte, zda šablona backup-lmio-tenant-events-eventlane-template
existuje na kartě Index Template.
5. Odstraňte původní šablonu lmio-tenant-events-eventlane-template
a ponechte pouze záložní šablonu, kterou jste právě vytvořili.
6. Přejděte na LogMan.io UI do sekce Library a do složky /EventLanes
7. Pokud soubor event lane neexistuje, vytvořte nový soubor event lane s názvem fortigate.yaml
(nahraďte "fortigate" názvem vaší event lane) ve složce /EventLanes/tenant
(nahraďte "tenant" názvem vašeho tenanta). Pokud složka /EventLanes/tenant
neexistuje, musíte ji vytvořit v ZooKeeper UI.
8. Vytvořte sekce kafka
a elasticsearch
pro daný event lane se specifikovanými sekcemi events
a others
(viz Event Lane). Výchozí schéma pro mapování polí je /Schemas/ECS.yaml
, pokud není ve event lane specifikováno jinak.
9. Pokud není nasazen, nasadte LogMan.io Depositor s uvedenými sekcemi kafka
, elasticsearch
, zookeeper
a library
(viz Konfigurace).
10. Zkontrolujte logy LogMan.io Depositor pro varování. Prosím zkontrolujte jak Docker logy, tak logy souborů (pokud jsou logy souborů nakonfigurovány). Docker logy lze přistupit pomocí následujícího příkazu:
docker logs -f -n 1000 <lmio-depositor>
Nahraďte <lmio-depositor>
názvem Docker kontejneru LogMan.io Depositor ve vašem nasazení.
11. V Kibana, přejděte na Management > Stack Management, poté Index Management, a zkontrolujte, zda nové šablony indexu lmio-tenant-events-eventlane-template
a lmio-tenant-others-template
byly vytvořeny Depositor. Klikněte na šablonu indexu a zkontrolujte její nastavení a mapování. Výchozí nastavení zahrnuje 6 shardů a 1 repliku (viz Event Lane).
12. V Kibana, přejděte na Management > Stack Management, poté Index Lifecycle Policies a zkontrolujte, zda byly vytvořeny lmio-tenant-events-eventlane-ilm
a lmio-tenant-others-ilm
. Klikněte na jejich název a zkontrolujte nastavení fází hot, warm, cold a delete.
13. Pokud LogMan.io není nasazen nebo konfigurován pro tento účel, nasadte nebo nakonfigurujte Parsec, aby odesílal data do Kafka event topic specifikovaného v deklaraci event lane (zde: fortigate.yaml
). Prosím viz sekci Konfigurace Parsec.
14. V Kibana, přejděte na Management > Dev Tools a spusťte rollover indexu, nahrazující tenant
a eventlane
názvem vašeho tenanta a vaší event lane:
POST /lmio-tenant-eventlane/_rollover
15. Zkontrolujte, zda byl v reakci vytvořen nový index ve schránce na pravé straně obrazovky. Přejděte na Management > Stack Management, poté Index Management, na kartu Indices a najděte index lmio-tenant-events-eventlane-0000x
.
16. Klikněte na lmio-tenant-events-eventlane-0000x
, zkontrolujte, zda je připojen k správné lifecycle policy, což by mělo být lmio-tenant-events-eventlane-ilm
, a také zkontrolujte, zda je Current phase hot. Poté klikněte na Settings a Mappings a zkontrolujte počet shardů (výchozí je 6) a mapování polí, které je načteno ze schématu. Výchozí schéma je /Schemas/ECS.yaml
, pokud není v event lane specifikováno jinak.
17. V Kibana, přejděte na Analysis > Discover a zkontrolujte, zda data přicházejí do dané event lane.
18. V LogMan.io UI, přejděte na Discover a zkontrolujte, zda data přicházejí do dané event lane.
19. Opakujte kroky 1 až 18 pro všechny zbývající event lane (jejich indexy událostí). Teprve poté můžete dokončit migraci tím, že stejný postup provedete pro indexy others
.
Hint
V následujících dnech pravidelně kontrolujte, zda jsou všechny indexy připojeny k lifecycle policy (krok 16). Také se ujistěte, že indexy ve fázi hot
jsou přiřazeny k Elasticsearch uzlům typu hot
, což lze vidět v Kibana v Management > Stack Monitoring > Indices.
Note
Když můžete potvrdit, že vše funguje správně po týdnu, můžete odstranit původní záložní šablonu indexu backup-lmio-tenant-events-eventlane-template
.
Řešení problémů¶
Rady pro řešení nejčastějších problémů:
Po přepnutí indexu data nepřichází¶
Po přepnutí indexu trvá Elasticsearch obvykle několik minut, než zobrazí data.
Po několika minutách zkontrolujte data lmio-tenant-others
v Kibana Průzkumník nebo Průzkumník v LogMan.io UI. Pokud nejsou žádná příbuzná data, zkontrolujte ve stanici Kafka UI topic others.tenant
. Chybové zprávy v logech by měly být dostatečně specifické na to, aby popsaly, proč data nemohla být uložena v Elasticsearch. Obvykle to znamená, že je používán špatný schéma. Viz sekci Event Lane nebo krok 8 v sekci Migrace.
Pro pokročilé uživatele: Když nastavíte prioritu šablony indexu v backup-lmio-tenant-events-eventlane-template
(od kroku 4 v Migrace) z 0 na 2 nebo více a provedete přepnutí indexu, použije se stará zálohová šablona indexu pro vytvoření nových indexů, zatímco nová šablona indexu vytvořená aplikací Depositor bude ignorována. To by vám mělo poskytnout více času na prošetření problému v produkčním prostředí. Nezapomeňte pak snížit prioritu v backup-lmio-tenant-events-eventlane-template
zpět na 0.
SSD úložný prostor se stává plným kvůli Elasticsearch¶
V tomto případě je třeba upravit životnostní politiku v deklaraci konkrétního event lanu (například fortigate.yaml
), aby se data přesunula z fáze hot
do fáze warm
dříve. Ve výchozím nastavení se data zahřívají po 3 dnech
. Pro více informací o nastavení vlastní životnostní politiky, viz sekci Event Lane.
Jaká je maximální velikost indexu a jak ji mohu změnit?¶
Výchozí životnostní politika aplikace Depositor má limit 16 GB na primární shard na index, takže výchozí maximální velikost indexu je tedy 6 shardů * 16 GB * 2 pro repliku = 192 GB na index.
Pro změnu maximální velikosti indexu je třeba zadat vlastní životnostní politiku v rámci deklarace event lanu (například fortigate.yaml
), kde specifikujete atribut max_primary_shard_size
. Pro více informací o nastavení vlastní životnostní politiky, viz sekci Event Lane.
Existuje pouze index lmio-tenant-events
bez koncovky čísla a není spojená s žádnou životnostní politikou¶
Každý index spravovaný aplikací Depositor musí končit -00000x
, například lmio-tenant-events-eventlane-000001
.
Pokud tomu tak není, zkontrolujte jak Docker logy, tak souborové logy (pokud jsou souborové logy nakonfigurovány). Docker logy lze přistupovat pomocí následujícího příkazu:
docker logs -f -n 1000 <lmio-depositor>
Varování
Není jednoduchý způsob, jak přejmenovat předexistující index nazvaný lmio-tenant-events
bez životnostní politiky na lmio-tenant-events-eventlane-000001
. Proto zastavte aplikaci Depositor, smažte index lmio-tenant-events
, a pak znovu spusťte aplikaci Depositor. Vždy zkontrolujte logy pokaždé, když znovu spustíte aplikaci Depositor.
Existuje index s "Chyba životnostního cyklu indexu" a "no_node_available_exception", co se stalo?¶
K této chybě obvykle dochází, když je Elasticsearch restartován během fáze zmenšování indexu. Přesná zpráva je pak: """NoNodeAvailableException[could not find any nodes to allocate index [myindex] onto prior to shrink]
K vyřešení problému:
1. V Kibana, jděte na Management > Stack Management > Index management, pak Indices, a vyberte svůj index kliknutím na jeho název.
2. V detailu indexu, klikněte na Edit settings.
3. Uvnitř, nastavte následující hodnoty na null:
index.routing.allocation.require._name: null
index.routing.allocation.require._id: null
4. Klikněte na Save.
5. Jděte do Management > Dev Tools a proveďte následující příkaz, kde myindex
nahradíte názvem svého indexu:
POST /myindex/_ilm/retry
6. Vraťte se do Stack Management > Index management, Indices a zkontrolujte, zda chyba ILM zmizela pro daný index.
Existuje mnoho logů v others
, a nemohu najít ty s atributem interface
¶
Kafka Console Consumer může být použit k získání událostí z více topiků, zde ze všech topiků začínajících events
.
Dále můžete prohledávat pole v uvozovkách:
/usr/bin/kafka-console-consumer --bootstrap-server localhost:9092 --whitelist "events.*" | grep '"interface"'
Tento příkaz vám poskytne všechny příchozí logy s atributem interface
ze všech topiků events
.
Others Schema¶
Others schéma určuje schéma pro chyby, které nastaly během procesu parsování nebo ukládání. Je odvozeno z pojmenování schéma ECS.
---
define:
name: Others Schema
type: lmio/schema
fields:
_id:
type: "str"
representation: "base85"
docs: Unikátní identifikátor události, kódovaný ve formátu base85
'@timestamp':
type: "datetime"
docs: Časová značka, kdy došlo k ostatní události (to by mělo být aktuální čas)
event.ingested:
type: "datetime"
docs: Časová značka, kdy byla událost přijata
event.created:
type: "datetime"
docs: Časová značka, kdy byla událost vytvořena
event.original:
type: "str"
elasticsearch:
type: "text"
docs: Původní nezparsovaná zpráva události
event.dataset:
type: "str"
docs: Název datasetu pro událost
error.code:
type: "str"
docs: https://www.elastic.co/guide/en/ecs/current/ecs-error.html#field-error-code
error.id:
type: "str"
docs: Unikátní identifikátor chyby
error.message:
type: "text"
elasticsearch:
type: "text"
docs: Podrobnosti chybové zprávy
error.stack_trace:
type: "text"
elasticsearch:
type: "text"
docs: Informace o zásobníku chyb (stack trace)
error.type:
type: "str"
docs: Typ chyby
tenant:
type: "str"
docs: Identifikátor pro tenanta
Interní struktura Depositoru¶
Překladová tabulka¶
Překladová tabulka z typů SP-Lang na typy ElasticSearch je součástí repozitáře a kontejneru Depositoru ve lmiodepositor/elasticsearchartifacts/translation_table.json
.
Konverze datumu a času¶
Depositor kontroluje pole v událostech, která mají v schématu typ datetime
.
Pokud má pole hodnotu ve formátu SP-Lang datetime integer, datum se převede na formát ISO vhodný pro ElasticSearch.
Před nasazením se ovšem ujistěte, že výše zmíněná překladová tabulka obsahuje správnou definici formátu.
Baseliner
LogMan.io Baseliner¶
TeskaLabs LogMan.io Baseliner je mikroslužba, která na základě deklarací detekuje odchylky od vypočtené základní činnosti.
Baseline je sada vypočtených statistických metrik o činnosti dané entity pro dané časové období.
Příklady entit zahrnují: uživatel, zařízení, host server, dataset atd.
Note
Pokud upgradujete Baseliner na verzi v24.07-beta nebo novější, Baseliner zahájí fázi učení znovu. Toto je nutné kvůli změněnému přístupu k databázi. Následující aktualizace od verze v24.07-beta již nebudou vyžadovat znovu zahájení fáze učení.
Konfigurace LogMan.io Baselineru¶
LogMan.io Baseliner vyžaduje následující závislosti:
- Apache ZooKeeper
- NGINX (pro produkční nasazení)
- Apache Kafka
- MongoDB se složkou
/data/db
namapovanou na SSD (/data/ssd/mongo/data
) - Elasticsearch
- SeaCat Auth
- Knihovna LogMan.io se složkou
/Baselines
a schématem ve složce/Schemas
Umístění složky s daty MongoDB
Při používání Baselinera MUSÍ mít MongoDB svou složku s daty umístěnou na SSD/rychlém disku, nikoliv na HDD. Umístění složky s daty MongoDB na HDD povede ke zpomalení všech služeb, které MongoDB používají.
Příklad¶
Toto je nejzákladnější konfigurace požadovaná pro každou instanci LogMan.io Baselineru:
[declarations]
# /Baselines je výchozí cesta
groups=/Baselines
[tenants]
ids=default
[pipeline:BaselinerPipeline:KafkaSource]
topic=^events.tenant.*
[pipeline:OutputPipeline:KafkaSink]
topic=complex.tenant
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
[library]
providers=zk:///library
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
[elasticsearch]
url=http://es01:9200/
[mongodb.storage]
mongodb_uri=mongodb://mongodb1,mongodb2,mongodb3/?replicaSet=rs0
mongodb_database=baseliners
[auth]
multitenancy=yes
public_keys_url=http://localhost:8081/openidconnect/public_keys
Zookeeper¶
Specifikujte umístění serverů Zookeeperu v clusteru:
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
Hint
Pro neprodukční nasazení je možné použít jediný Zookeeper server.
Knihovna¶
Specifikujte cestu (cesty) ke Knihovně pro načtení deklarací:
[library]
providers=zk:///library
Hint
Protože je výchozí schéma ECS.yaml
ve složce /Schemas
, zvažte použití LogMan.io Common Library.
Kafka¶
Definujte bootstrap servery Kafka clusteru:
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
Hint
Pro neprodukční nasazení je možné použít jediný Kafka server.
Elasticsearch¶
Specifikujte URL hlavních uzlů Elasticsearch.
Elasticsearch je nezbytný pro používání vyhledávání, např. jako výraz !LOOKUP
nebo spouštěcí mechanismus vyhledávání.
[elasticsearch]
url=http://es01:9200
username=MYUSERNAME
password=MYPASSWORD
MongoDB¶
Specifikujte URL MongoDB clusteru s replikou sady.
MongoDB ukládá baseliny a čítače příchozích událostí.
[mongodb.storage]
mongodb_uri=mongodb://mongodb1,mongodb2,mongodb3/?replicaSet=rs0
mongodb_database=baseliners
Auth¶
Sekce Auth umožňuje multitenance, což omezuje přístup k baselinám pouze na uživatele s přístupem ke specifikovanému tenantovi:
[auth]
multitenancy=yes
public_keys_url=http://localhost:8081/openidconnect/public_keys
Input¶
Události pro baseliny jsou čteny z Kafka témat:
[pipeline:BaselinerPipeline:KafkaSource]
topic=^events.tenant.*
Deklarace (volitelné)¶
Definujte cestu pro deklarace baselinu. Výchozí cesta je /Baselines
a výchozí záložní schéma je /Schemas/ECS.yaml
.
Pokud používáte schéma jiné než ECS (Elastic Common Schema), můžete přizpůsobit cestu ke schématu.
[declarations]
groups=/Baselines
schema=/Schemas/ECS.yaml
Tenanti¶
Specifikujte tenanta, pro kterého chcete vytvořit baseliny. Můžete uvést více tenantů, oddělených čárkami, ale doporučuje se mít jeden tenant pro jeden baseline.
[tenants]
ids=tenant1
tenant_url=http://localhost:8080/tenant
Doporučuje se provozovat alespoň jednu instanci Baselinera na každého tenanta. Ve většině případů je vhodná jedna instance na tenanta.
Výstup¶
Pokud jsou použity triggery, můžete změnit výchozí téma pro výstupní pipeline:
[pipeline:OutputPipeline:KafkaSink]
topic=complex.tenant
Web APIs¶
Baseliner poskytuje jedno webové API.
Webové API je navrženo pro komunikaci s uživatelským rozhraním.
[web]
listen=0.0.0.0 8999
Výchozí port veřejného webového API je tcp/8999
.
Tento port je určen k tomu, aby sloužil jako upstream NGINX pro připojení od Collectors.
Deklarace pro definování základních linií¶
Deklarace pro základní linie jsou načítány z Knihovny ze složky specifikované v konfiguraci, například /Baseliners
.
Note
Baseliner používá ve výchozím nastavení /Schemas/ECS.yaml
, takže /Schemas/ECS.yaml
musí být také přítomen v Knihovně.
Deklarace¶
Toto je příklad definice základní linie, umístěný v složce /Baseliners
v Knihovně:
---
define:
name: Dataset
description: Vytváří základní linii pro každý dataset a spouští alarmy, pokud se skutečný počet odchýlí
type: baseliner
baseline:
region: Česká republika
period: den
learning: 4
classes: [pracovní dny, víkendy, svátky]
evaluate:
key: event.dataset
timestamp: "@timestamp"
analyze:
test:
!AND
- !LT
- !ARG VALUE
- 1
- !GT
- !ARG MEAN
- 10.0
trigger:
- event:
# Popis hrozby
# https://www.elastic.co/guide/en/ecs/master/ecs-threat.html
threat.framework: "MITRE ATT&CK"
threat.indicator.sightings: !ITEM EVENT hodnota
threat.indicator.confidence: "Vysoká"
threat.indicator.name: !ITEM EVENT dimenze
- notification:
type: email
to: ["myemail@example.co"]
template: "/Templates/Email/Notification_baseliner_dimension.md"
variables:
name: "Logy nepřicházejí do datasetu během dané UTC hodiny."
dimension: !ITEM EVENT dimenze
hour: !ITEM EVENT hodina
Sekce¶
baseline¶
baseline: # (1)
region: Česká republika #(2)
period: den # (3)
learning: 4 # (4)
classes: [pracovní dny, víkendy, svátky] # (5)
- Definuje, jak je daná základní linie postavena.
- Definuje, ve kterém regionu se aktivita odehrává (kvůli výpočtu svátků a podobně).
- Definuje časové období pro základní linii. Období může být buď
den
nebotýden
. - Definuje počet období (v tomto případě den), které uplynou od začátku příjmu vstupů do baselineru, než uživatel může vidět analýzu základní linie. Další podrobnosti níže.
- Definuje, které dny v týdnu chceme monitorovat. Třídy mohou zahrnovat jakékoli/všechny:
pracovní dny
,víkendy
, asvátky
.
learning
Pole learning
definuje fázi učení.
Fáze učení je doba od prvního výskytu hodnoty dimenze ve vstupu instance baselineru do momentu, kdy je základní linie zobrazena uživateli a probíhá analýza. V deklaraci je learning
počet období. Fáze učení je vypočítávána samostatně pro svátky, víkendy a pracovní dny. Základní linie jsou přes noc obnovovány (údržba).
V tomto příkladu je period
den
, takže learning
jsou 4 dny. S ohledem na kalendář fáze učení 4 dní začínající v pátek znamená 4 pracovní dny, a tedy končí ve středu večer.
predicate (volitelné)¶
Sekce predicate
filtruje příchozí události, které mají být považovány za aktivitu v základní linii.
Filtry pište pomocí jazyka TeskaLabs SP-Lang. Navštivte Predikáty nebo dokumentaci SP-Lang pro podrobnosti.
evaluate¶
Tato sekce specifikuje, které atributy z události budou použity při vytváření základní linie.
evaluate:
key: event.dataset # (1)
timestamp: "@timestamp" # (2)
- Specifikuje atribut/entitu k monitorování.
- Specifikuje atribut, ve kterém je uložena časová dimenze aktivity události.
analyze¶
Sekce test
v analyze
specifikuje, kdy spustit spouštěč, pokud se skutečná aktivita (!ARG VALUE
) odchýlí od základní linie. Testy pište pomocí SP-Lang.
analyze:
test:
!AND #(1)
- !LT #(2)
- !ARG VALUE # (3)
- 1
- !GT # (4)
- !ARG MEAN # (5)
- 10.0
- Všechny výrazy zanořené pod
AND
musí být pravdivé, aby test prošel. Zde, pokud je hodnota menší než 1 a průměr je větší než 10, spustí se spouštěč. - "Méně než"
- Získat (
!ARG
) hodnotu (VALUE
). Pokud je hodnota menší než1
, jak je specifikováno, výraz!LT
je pravdivý. - "Větší než"
- Získat (
!ARG
) průměr (MEAN
). Pokud je průměr větší než10.0
, jak je specifikováno, výraz!GT
je pravdivý.
Následující atributy jsou k dispozici a používají se v notaci SP-Lang:
TENANT: "str",
VALUE: "ui64",
STDEV: "fp64",
MEAN: "fp64",
MEDIAN: "fp64",
VARIANCE: "fp64",
MIN: "ui64",
MAX: "ui64",
SUM: "ui64",
HOUR: "ui64",
KEY: "str",
CLASS: "str",
trigger¶
Sekce trigger
definuje aktivitu, která je spuštěna po úspěšné analýze. (Více o triggery.)
Baseliner vytváří události
Při každé analýze (každou hodinu) vytváří Baseliner událost k shrnutí své analýzy. Tyto události vytvořené Baselinerem jsou k dispozici pro použití (jako EVENT
) s výrazy jako !ARG
a !ITEM
, což znamená, že můžete čerpat hodnoty z událostí pro vaše spouštěcí aktivity.
Tyto události vytvořené Baselinerem zahrnují pole:
tenant
Název tenanta, ke kterému základní linie patří.
dimension
Dimenze, ke které základní linie patří, jak je specifikováno v evaluate
.
class
Třída, ze které byla základní linie vypočítána.
Možnosti zahrnují: pracovní dny
, víkendy
, a svátky
hour
Číslo UTC hodiny, ve které analýza proběhla.
value
Hodnota aktuálního počtu událostí pro danou UTC hodinu.
Notifikační trigger¶
Notifikační trigger pošle zprávu, například e-mail. Viz Emailové notifikace pro více informací o zasílání emailových notifikací a používání emailových šablon.
Příklad notifikačního triggeru:
trigger:
- notification:
type: email #(1)
to: ["myemail@example.co"] # (2)
template: "/Templates/Email/Notification_baseliner_dimension.md" # (3)
variables: # (4)
name: "Logy nepřicházejí do datasetu během dané UTC hodiny."
dimension: !ITEM EVENT dimenze # (5)
hour: !ITEM EVENT hodina
- Specifikuje emailovou notifikaci
- Adresa příjemce
- Cesta k souboru emailové šablony v Knihovně LogMan.io
- Začíná sekce, která dává instrukce, jak vyplnit prázdná pole z emailové šablony. Prázdná pole v šabloně použité v tomto příkladu jsou
name
,dimension
ahour
. - Používá SP-Lang k získání informací (
!ITEM
) z události vytvořené Baselinerem (EVENT
) (viz níže). V tomto případě bude poledimension
v šabloně vyplněno hodnotoudimension
převzatou z události vytvořené Baselinerem.
Event trigger¶
Můžete použít event trigger k vytvoření logu nebo události, kterou budete moci vidět v uživatelském rozhraní TeskaLabs LogMan.io.
Příklad event triggeru:
- event: # (1)
threat.framework: "MITRE ATT&CK"
threat.indicator.sightings: !ITEM EVENT hodnota
threat.indicator.confidence: "Vysoká"
threat.indicator.name: !ITEM EVENT dimenze
- Tato nová událost je popisem hrozby použitím polí hrozeb z Elasticsearch
Analýza v uživatelském rozhraní¶
Ve výchozím nastavení poskytuje uživatelské rozhraní LogMan.io zobrazení analýz pro uživatele
a host
.
Zadejte analýzu ve schématu (ve výchozím nastavení: /Schemas/ECS.yaml
) takto:
host.id:
type: "str"
analysis: host
user.id:
type: "str"
analysis: user
...
Pokud je tenant nakonfigurován používat toto schéma (ve výchozím nastavení ECS), pole host.id
a user.id
v Průzkumník zobrazí odkaz na danou základní linii.
Analýza host
používá základní linii s názvem Host
ve výchozím nastavení:
---
define:
name: Host
Analýza user
používá základní linii s názvem User
ve výchozím nastavení:
---
define:
name: User
Pokud specifická analýza nemůže nalézt svou přidruženou základní linii, uživatelské rozhraní zobrazí prázdnou obrazovku pro danou analýzu.
Note
Obě základní linie potřebné pro analýzu jsou distribuovány jako součást Společné knihovny LogMan.io.
Correlator
LogMan.io Correlator¶
TeskaLabs LogMan.io Correlator je mikroslužba zodpovědná za provádění detekcí a hledání vzorců v datech na základě korelačních pravidel.
LogMan.io Correlator je vždy nasazen pro daného tenanta.
Důležité poznámky¶
-
Každý correlator má povinné sekce v konfiguračních souborech, viz sekci Konfigurace.
-
Correlator nemůže pracovat s korelačními pravidly. Více informací o tvorbě korelačních pravidel naleznete v sekci Window Correlator.
Konfigurace LogMan.io Correlatoru¶
Nejdříve je nutné specifikovat, kterou knihovnu použít pro načítání deklarací, která může být buď ZooKeeper nebo Soubor.
[library]
providers=zk://library
Vrstva knihovny ZooKeeper vyžaduje konfigurační sekci zookeeper
.
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
Také každá běžící instance parseru musí znát, které skupiny se mají načítat z knihoven a ke kterému tenantu patří, viz níže:
# Tenant
[tenant]
ids=mytenant
# Deklarace
[declarations]
groups=Firewall Common Authentication
# Složitý event lane (volitelné)
[eventlane]
path=/EventLanes/mytenant/complex.yaml
groups
- názvy skupin, které se mají použít z knihovny, oddělené mezerami; pokud je skupina
umístěna v podsložce složky, použijte jako oddělovač šikmou čáru, např. /Correlators/Firewall
Dále je potřeba vědět, které Kafka témy se mají použít jako default fallback vstupy a výstupy (pokud nejsou specifikované v korelacích v sekci logsource a složité event lane).
Připojení ke Kafce je také potřeba nakonfigurovat pro vědění, ke kterým Kafka serverům se připojit.
# Připojení ke Kafce
[kafka]
bootstrap_servers=lm1:19092;lm2:29092;lm3:39092
# Výchozí Kafka téma, ze kterého se čte, když není specifikován žádný logsource v korelačním pravidle (volitelné)
[pipeline:CorrelatorsPipeline:KafkaSource]
topic=lmio-events
group_id=lmio_correlator_firewall
# Výchozí Kafka téma pro trigger eventů, pokud není specifikován složitý event (volitelné)
[pipeline:OutputPipeline:KafkaSink]
topic=lmio-output
Poslední povinná sekce specifikuje, které nastavení Elasticsearch umožňuje pracovat s Lookups. Pro více informací viz sekci Lookups.
# Persistentní úložiště pro Lookups
[elasticsearch]
url=http://elasticsearch:9200
Instalace¶
Docker Compose¶
lmio-correlator:
image: docker.teskalabs.com/lmio/lmio-correlator:VERSION
volumes:
- ./lmio-correlator:/conf
- /data/ssd/lookups:/lookups
- /data/hdd/log/lmio-correlator:/log
- /data/ssd/correlators/lmio-correlator:/data
Nahraďte lmio-correlator
názvem instance korelatoru.
Korelator potřebuje znát svou konfigurační cestu, cestu k lookups (složka může být prázdná, záleží na použití lookups), cestu k logování a cestu pro ukládání svých dat.
Varování
Cesta k datům je povinná a musí být umístěna na rychlém disku, tj. SSD.
Window Correlator¶
Window correlator detekuje příchozí události na základě sekce predicate
a ukládá je do datových struktur na základě sekce evaluate
. Pokud je potom pravidlo test
v sekci analyze
shodné, je zavolána sekce trigger
.
Následující ukázka korelace detekuje více než nebo rovno 5 chybových připojení mezi dvěma IP adresami:
Ukázka¶
---
define:
name: "Network T1046 Network Service Discovery"
description: "Detekuje více než nebo rovno 5 chybových připojení mezi dvěma IP adresami"
type: correlator/window
logsource:
type: "Network"
mitre:
technique: "T1046"
tactic: "TA0007"
predicate:
!OR
- !EQ
- !ITEM EVENT log.level
- "error"
- !EQ
- !ITEM EVENT log.level
- "critical"
- !EQ
- !ITEM EVENT log.level
- "emergency"
evaluate:
dimension: [source.ip, destination.ip]
by: "@timestamp"
resolution: 60
analyze:
window: hopping
aggregate: sum
span: 10
test:
!GE
- !ARG
- 5
trigger:
- event:
threat.indicator.confidence: "Medium"
threat.indicator.ip: !ITEM EVENT source.ip
threat.indicator.port: !ITEM EVENT source.port
threat.indicator.type: "ipv4-addr"
Sekce define
¶
Tato sekce obsahuje běžnou definici a metadata.
Položka name
¶
Kratší název této deklarace srozumitelný lidem.
Položka type
¶
Typ této deklarace, musí být correlator/window
.
Položka description
(volitelné)¶
Delší, případně víceliniový, popis deklarace srozumitelný lidem.
Sekce logsource
¶
Specifikuje typy event lanes, z kterých by měly být čteny příchozí události.
Sekce predicate
¶
Sekce predicate
filtruje příchozí události pomocí výrazu.
Pokud výraz vrátí True
, událost přejde do sekce evaluate
.
Pokud výraz vrátí False
, událost je přeskočena.
Ostatní vrácené hodnoty jsou nedefinované.
Vložení vnořených filtrů predikátů¶
Filtry predikátů jsou výrazy umístěné ve vyhrazeném souboru, které mohou být vloženy do mnoha různých predikátů jako jejich části.
Pokud chcete vložit externí filtr predikátů, umístěný buď v knihovně,
použijte klíčové slovo !INCLUDE
:
!INCLUDE /predicate_filter.yaml
kde /predicate_filter
je cesta k souboru v knihovně.
Obsah souboru predicate_filter.yaml
je výraz, který má být vložen, například:
---
!EQ
- !ITEM EVENT category
- "MyEventCategory"
Sekce evaluate
¶
Sekce evaluate
specifikuje primární klíč, rozlišení a další atributy, které se aplikují na příchozí událost.
Funkce evaluate
je přidat událost do dvourozměrné struktury, definované časem a primárním klíčem.
Položka dimension
¶
Specifikuje jednoduchý nebo složený primární klíč (nebo dimenzi) pro událost. Dimenze je definována názvy polí vstupní události.
Příklad jednoduchého primárního klíče:
evaluate:
dimension: [source.ip]
Note
Tenant je automaticky přidán do seznamu dimenzí.
Příklad složeného primárního klíče:
evaluate:
dimension: [source.ip, destination.ip]
Pokud je přesně jedna dimenze jako DestinationHostname
v původní události
a korelace by měla proběhnout pro každou hodnotu dimenze, dimenze by měla být uzavřena v [
]
:
evaluate:
dimension: [source.ip, destination.ip, [DestinationHostname] ]
Položka by
¶
Specifikuje název pole vstupní události, které obsahuje informaci o datu/čase, která bude použita pro vyhodnocení. Výchozí hodnota je: @timestamp
.
Položka event_count
(volitelné)¶
Název atributu, který specifikuje počet událostí k korelaci v jedné události, čímž ovlivňuje "součet událostí" v analýze. Výchozí hodnota je 1.
Položka resolution
¶
Specifikuje rozlišení časové agregace korelátoru. Jednotka je sekundy.
evaluate:
resolution: 3600 # 1 hodina
Výchozí hodnota: 3600
Položka saturation
(volitelné)¶
Specifikuje délku trvání intervalu silent
po vyvolání trigger.
Je specifická pro dimenzi.
Jednotka je resolution.
Výchozí hodnota: 3
Sekce analyze
(volitelné)¶
Sekce analyze
obsahuje konfiguraci časového okna, které je aplikováno na vstupní události.
Výsledek analýzy časového okna podléhá konfigurovatelnému testu. Když je test úspěšný (tedy vrátí True
), je spuštěn trigger
.
Poznámka: Tato sekce je volitelná, výchozí chování je spustit trigger
pokud je alespoň jedna událost v tumbling s span rovno 2.
Položka when
(volitelné)¶
Specifikuje, kdy by měla proběhnout analýza událostí v oknech.
Možnosti:
event
(výchozí): Analýza probíhá po příchodu události a jejím vyhodnocení, obvykle užitečné pro korelaci shody a aritmetikuperiodic/...
: Analýza probíhá po zadaném intervalu v sekundách, napříkladperiodic/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 rozsahu časového okna, aby analýza neprobíhala příliš často.
Položka window
(volitelné)¶
Specifikuje, jaký druh časového okna použít.
Možnosti:
tumbling
: Pevnýspan
(délka trvání), nepřekrývající se, souvislé časové intervaly bez mezerhopping
: Pevnýspan
(délka trvání), překrývající se souvislé časové intervaly
Výchozí hodnota: hopping
Položka span
¶
Specifikuje šířku okna.
Jednotka je resolution
.
Položka aggregate
(volitelné)¶
Specifikuje jaké agregační funkce budou aplikovány na události v okně.
Funkce agregace¶
sum
: Součetmedian
: Mediánaverage
: Průměr (vážený)mean
: Aritmetický průměrstd
: Směrodatná odchylkavar
: Rozptylmean spike
: Pro detekci spike. Základní hodnota je průměr, vrací procento.median spike
: Pro detekci spike. Základní hodnota je medián, vrací procento.unique count
: Pro jedinečný počet atributů události: musí být poskytnutadimension
.
Výchozí hodnota: sum
Příklad jedinečného počtu:
analyze:
window: hopping
aggregate: unique count
dimension: client.ip
span: 6
test:
!GE
- !ARG
- 5
Spustí trigger, když je pozorováno 5 a více jedinečných client.ip
.
Položka test
(volitelné)¶
Sekce test
je výraz aplikovaný na výsledek výpočtu aggregate
.
Pokud výraz vrátí True
, trigger
bude spuštěn, pokud dimenze není již saturována.
Pokud výraz vrátí False
, žádná akce není přijata.
Ostatní vrácené hodnoty jsou nedefinované.
Sekce trigger
¶
Sekce trigger
specifikuje druhy akcí, které mají být provedeny, když test
v sekci analyze
spustí trigger
.
Podrobnosti viz kapitola correlator triggers.
Ukládací korelátor¶
V oblasti kybernetické bezpečnosti je ukládací korelátor nástrojem, který shromažďuje a dočasně ukládá související události na základě specifických identifikátorů, jako jsou ID zpráv. Tento proces pomáhá sledovat a analyzovat sekvence událostí v čase, což umožňuje identifikaci vzorců nebo anomálií, které mohou naznačovat bezpečnostní hrozby. Seskupením souvisejících událostí ukládací korelátor zvyšuje schopnost monitorovat a reagovat na potenciální kybernetické incidenty, poskytuje komplexní pohled na aktivity, které nemusí být zřejmé při zkoumání jednotlivých událostí zvlášť.
Analogie pro lepší pochopení¶
Představte si ukládacího korelátora jako detektiva, který skládá dohromady stopy z různých zdrojů. Představte si, že detektiv dostane dva lístky: jeden se jménem osoby a druhý s jejím umístěním. Jednotlivě tyto lístky neposkytují mnoho informací, ale detektiv si všimne, že oba lístky mají stejné číslo případu (ID). Detektiv je spojí a pochopí, kdo je kde. Podobně ukládací korelátor spojuje související události pomocí společného atributu, jako je ID, aby vytvořil úplný obrázek pro další analýzu.
Příklad scénáře¶
Představte si, že dostanete dva kusy pošty: jeden vám říká, kdo poslal dopis, a druhý vám říká, kdo ho obdržel. Jednotlivě tyto kusy pošty neposkytují celý obrázek. Ukládací korelátor je jako chytrý asistent, který si všimne, že oba kusy mají stejné sledovací číslo (ID zprávy) a spojí je do jednoho komplexního záznamu, který ukazuje jak odesílatele, tak příjemce. To pomáhá pochopit celý kontext komunikace.
Zvažte následující logy z Event lane Postfixu pro daný tenant:
June 14 09:19:21 alice postfix/qmgr[59833]: F3710A248D: from=<alice@example.com>, size=304, nrcpt=1 (queue active)
June 14 09:19:21 alice postfix/local[60446]: F3710A248D: to=<bob@example.com>, orig_to=<alice>, relay=local, delay=0.04, delay>
Tyto logy jsou zpracovávány samostatně pomocí LogMan.io Parsec. První log ukazuje, kdo poslal email (alice@example.com
), a druhý log ukazuje příjemce (bob@example.com
). Parsované logy vypadají takto:
# Log #1
{
"email.message_id": "F3710A248D",
"email.from.address": ["alice@example.com"],
...
}
# Log #2
{
"email.message_id": "F3710A248D",
"email.to.address": ["bob@example.com"],
...
}
Pro spojení všech informací pro budoucí analýzu je nutné konsolidovat události do jednoho logu, který obsahuje jak informace odesílatele, tak příjemce. Ukládací korelátor provádí tuto úlohu spojením parsovaných událostí pomocí společného atributu, jako je ID zprávy (F3710A248D
). Pokud žádná jiná událost se stejným ID zprávy nedorazí v rámci období send_after_seconds
, vytvoří se nová událost, která zahrnuje všechny shromážděné informace:
# Uložený log
{
"email.message_id": "F3710A248D",
"email.from.address": ["alice@example.com"],
"email.to.address": ["bob@example.com"],
...
}
Tento konsolidovaný log může být poté analyzován jinými detekčními korelátory, jako je Window Correlator, pro další vyšetřování a reakci na potenciální bezpečnostní incidenty.
Ukázka¶
Následující ukázka ukládá události podle jejich ID zpráv a odesílá je po 10 sekundách nečinnosti:
---
define:
name: "Ukládání událostí podle ID zprávy"
description: "Příklad pro ukládání událostí podle ID zprávy"
type: correlator/stashing
logsource:
vendor: [WietseVenama]
predicate:
!IN
what: message.id
where: !EVENT
stash:
dimension: message.id
send_after_seconds: 10 # Odeslat uloženou zprávu po sekundách nečinnosti
Sekce define
¶
Tato sekce obsahuje společnou definici a metadata.
Položka name
¶
Kratší čitelný název tohoto prohlášení.
Položka type
¶
Typ tohoto prohlášení, musí být correlator/stashing
.
Položka description
(volitelně)¶
Delší, případně vícero řádková čitelná popisná poznámka k prohlášení.
Sekce logsource
¶
Specifikuje zdroje logů, uvádí výrobce nebo produkty, jejichž události pocházející z event lanes budou zpracovány.
Sekce predicate
¶
Predicate
filtruje příchozí události pomocí výrazu. Pokud výraz vrátí !!true
, událost vstoupí do sekce stash
. Pokud !!false
, je událost přeskočena.
Zahrnutí zanořených filtračních predikátů¶
Filtrační predikáty jsou výrazy umístěné ve vyhrazeném souboru, které mohou být zahrnuty do mnoha různých predikátů jako jejich části.
Pro zahrnutí externího filtračního predikátu:
!INCLUDE /predicate_filter.yaml
kde /predicate_filter je cesta k souboru v knihovně.
Sekce stash
¶
Specifikuje chování ukládání, včetně dimenze pro seskupování událostí a časového limitu pro odesílání uložených událostí po nečinnosti.
Položka dimension
¶
Specifikuje primární klíč (nebo dimenzi) pro událost. Definováno názvy polí vstupních událostí.
Příklad primárního klíče:
stash:
dimension: [message.id]
Položka send_after_seconds
¶
Specifikuje časový limit pro odeslání uložených událostí po období nečinnosti. Jednotkou je sekundy.
stash:
send_after_seconds: 10 # 10 sekund
Shrnutí¶
Stručně řečeno, ukládací korelátor funguje jako chytrý organizátor, shromažďující a spojující související události k vytvoření úplného obrázku pro další analýzu. To pomáhá identifikovat vzorce a anomálie v kybernetické bezpečnosti, poskytuje efektivnější způsob monitorování a reakce na potenciální incidenty.
Entitní Korelátor¶
Korelátor oken detekuje příchozí události na základě sekce predicate
a ukládá je do datových struktur na základě sekce evaluate
. Pokud z události detekovaná dimenze neprodukuje žádná data, je volána sekce lost
v sekci triggers
, jinak je volána sekce seen
v sekci triggers
.
Příklad¶
define:
name: Detekce chování uživatelské entity
description: Detekce chování uživatelské entity
type: correlator/entity
span: 5
delay: 5m # doba analýzy = delay + resolution
logsource:
vendor: "Microsoft"
predicate:
!AND
- !EQ
- !ITEM EVENT message
- "FAIL"
- !EQ
- !ITEM EVENT device.vendor
- "Microsoft"
- !EQ
- !ITEM EVENT device.product
- "Exchange Server"
evaluate:
dimension: [source.user]
by: @timestamp # Název pole události s časem události
resolution: 60 # jednotka je sekunda
lookup_seen: active_users
lookup_lost: inactive_users
triggers:
lost:
- event:
severity: "Low"
seen:
- event:
severity: "Low"
Sekce define
¶
Tato sekce obsahuje obecné definice a meta data.
Položka name
¶
Kratší lidsky čitelný název této deklarace.
Položka type
¶
Typ této deklarace, musí být correlator/entity
.
Položka span
¶
Specifikuje šířku okna.
Jednotka je resolution
.
Položka delay
(volitelná)¶
Analýza probíhá po specifikovaném čase v sekundách a tento čas je založen na resolution
.
Pokud je potřeba prodloužit dobu a tím zpozdit analýzu, může být uvedena volba delay
, například 300
(300 sekund), 1h
(3600 sekund / jedna hodina) atd.
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 description
(volitelná)¶
Delší, případně víceřádkový, lidsky čitelný popis deklarace.
Sekce logsource
¶
Specifikuje typy event lanes, ze kterých by měly být čteny příchozí události.
Sekce predicate
(volitelná)¶
predicate
filtruje příchozí události pomocí výrazu.
Pokud výraz vrátí True
, událost přejde do sekce evaluate
.
Pokud výraz vrátí False
, je událost přeskočena.
Ostatní návratové hodnoty jsou nedefinované.
Sekce evaluate
¶
Sekce evaluate
specifikuje primární klíč, rozlišení a další atributy, které se aplikují na příchozí událost.
Funkcí evaluate
je přidat událost do dvourozměrné struktury, definované časem a primárním klíčem.
Položka dimension
¶
Specifikuje jednoduchý nebo složený primární klíč (nebo dimenzi) pro událost.
dimension
je definována názvy vstupních polí události.
Příklad jednoduchého primárního klíče:
evaluate:
dimension: [source.ip]
Note
Tenant je automaticky přidán do seznamu dimenzí.
Příklad složeného primárního klíče:
evaluate:
dimension: [source.ip, destination.ip]
Pokud je přesně jedna dimenze, jako je DestinationHostname
, seznam v původní události a korelace by měla probíhat pro každou hodnotu dimenze, měla by být dimenze zabalená do [
]
:
evaluate:
dimension: [source.ip, destination.ip, [DestinationHostname] ]
Položka by
¶
Specifikuje název pole vstupní události, které obsahuje datum/čas, který bude použit pro vyhodnocení. Výchozí hodnota je: @timestamp
.
Položka resolution
(volitelná)¶
Specifikuje rozlišení časové agregace korelátoru. Jednotka je sekundy.
evaluate:
resolution: 3600 # 1 hodina
Výchozí hodnota: 3600
Položka lookup_seen
¶
lookup_seen
specifikuje ID lookupu, kam se zapisují viděné entity s časem posledního vidění
Položka lookup_lost
¶
lookup_lost
specifikuje ID lookupu, kam se zapisují ztracené entity s časem poslední analýzy
Sekce triggers
¶
Sekce triggers
specifikuje druhy akcí, které mají být provedeny, když proběhne periodická analýza.
Podporované akce jsou lost
a seen
.
Podrobnosti viz kapitola korelační triggery.
seen
triggery¶
Triggery seen
se provádějí, když analýza nalezne události, které vstoupily do okna v analyzovaném čase.
Dimezi (název entity) lze získat pomocí !ITEM EVENT dimension
.
Čas poslední události, která přišla do okna v dané dimenzi, lze získat pomocí !ITEM EVENT last_event_timestamp
(entita aktualizována).
Příklad:
seen:
- lookup: user_inventory
key: !ITEM EVENT dimension
set:
last_seen: !ITEM EVENT last_event_timestamp
lost
triggery¶
Triggery lost
se provádějí, když analýza zjistí, že do specifikované dimenze v analyzovaném čase nepřišla žádná událost (entita klesla).
Dimezi (název entity) lze získat pomocí !ITEM EVENT dimension
.
Příklad:
lost:
- event:
severity: "Low"
dimension: !ITEM EVENT dimension
Korelátor shody¶
Korelátor shody detekuje příchozí události na základě sekce predicate
. Pokud událost odpovídá filtru predicate, je volána sekce trigger
.
Hint
Vždy zvažte použití Korelátoru okna místo Korelátoru shody, protože Korelátor shody produkuje jednu výstupní událost na jednu vstupní událost a tedy neprovádí žádné seskupování příchozích událostí na základě času.
Příklad¶
---
define:
name: "Network T1046 Network Service Discovery"
description: "Detekuje připojení mezi dvěma IP adresami"
type: correlator/match
logsource:
type: "Network"
mitre:
technique: "T1046"
tactic: "TA0007"
predicate:
!OR
- !EQ
- !ITEM EVENT log.level
- "error"
- !EQ
- !ITEM EVENT log.level
- "critical"
- !EQ
- !ITEM EVENT log.level
- "emergency"
trigger:
- event:
threat.indicator.confidence: "Medium"
threat.indicator.ip: !ITEM EVENT source.ip
threat.indicator.port: !ITEM EVENT source.port
threat.indicator.type: "ipv4-addr"
Sekce define
¶
Tato sekce obsahuje společnou definici a metadata.
Položka name
¶
Kratší, člověkem čitelný název této deklarace.
Položka type
¶
Typ této deklarace, musí být correlator/match
.
Položka description
(volitelné)¶
Delší, pravděpodobně víceliniový, člověkem čitelný popis deklarace.
Sekce logsource
¶
Specifikuje typy event lanes, ze kterých by měly být čteny příchozí události.
Sekce predicate
¶
Predicate
filtruje příchozí události pomocí výrazu. Pokud výraz vrátí True
, událost vstoupí do sekce trigger
.
Pokud výraz vrátí False
, pak je událost přeskočena.
Jiné návratové hodnoty jsou nedefinované.
Sekce trigger
¶
Sekce trigger
specifikuje, jaké druhy akcí mají být provedeny, když je trigger
vyvolán úspěšným výsledkem v sekci predicate
.
Podrobnosti viz kapitola triggery korelátoru.
Spouštěče¶
Spouštěče definují výstup korelátorů, baselineů atd. Žijí v sekci trigger
korelátoru. Každé pravidlo v knihovně může definovat mnoho spouštěčů (je to seznam).
Spouštěč může přistupovat k původní události prostřednictvím výrazu !EVENT
, což je poslední událost, která prošla testem hodnocení.
Hodnota z agregační funkce je dostupná na !ARG
.
Spouštěč event
¶
Tento spouštěč vloží novou událost
do komplexního Event lane.
Příklad event spouštěče:
trigger:
- event:
threat.indicator.confidence: "Medium"
threat.indicator.ip: !ITEM EVENT source.ip
threat.indicator.port: !ITEM EVENT source.port
threat.indicator.type: "ipv4-addr"
Může se jednat až o 5 výsledků, například v agregační funkci mean spike
:
trigger:
- event:
events: !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 lookupu. To znamená, že může přidat (set), inkrementovat (add), dekrementovat (sub) a odstranit (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á záznam do lookupu user_list
:
trigger:
- lookup: user_list
key: !ITEM EVENT user.name
set:
score: 1
Příklad spouštěče, který odstraní záznam z lookupu user_list
:
trigger:
- lookup: user_list
delete: !ITEM EVENT user.name
Příklad spouštěče, který inkrementuje čítač (pole my_counter
) v záznamu lookupu user_list
:
trigger:
- lookup: user_list
key: !ITEM EVENT user.name
add: my_counter
Příklad spouštěče, který dekrementuje čítač (pole my_counter
) v záznamu lookupu user_list
:
trigger:
- lookup: user_list
key: !ITEM EVENT user.name
sub: my_counter
Pokud pole čítače neexistuje, je vytvořeno s defaultní hodnotou 0.
Spouštěč notification
¶
Tento spouštěč vloží nové oznámení do primární datové cesty, kterou čte asab-iris
.
Příklad notification spouštěče:
- notification:
type: email
template: "/Templates/Email/notification_4728.md"
to: eliska.novotna@teskalabs.com
variables:
name: "brute-force"
events: !ARG
Výstrahy
LogMan.io Alerty¶
TeskaLabs LogMan.io Alerty je mikroslužba zodpovědná za správu tiketů alertů/incidentů, poskytující API a Kafka handler skrze téma lmio-alerts
.
LogMan.io Alerty - konfigurace¶
LogMan.io Alerty mají následující závislosti:
- Apache ZooKeeper
- NGINX (pro produkční nasazení)
- Apache Kafka
- MongoDB
- Elasticsearch
- TeskaLabs SeaCat Auth
- LogMan.io Knihovna s adresáři
/Alerts
a schématy v adresáři/Schemas
Příklad¶
Tento příklad ukazuje nejzákladnější konfiguraci potřebnou pro LogMan.io Alerty:
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
[library]
providers=zk:///library
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
[elasticsearch]
url=http://es01:9200/
[asab:storage]
mongodb_uri=mongodb://mongodb1,mongodb2,mongodb3/?replicaSet=rs0
[auth]
multitenancy=yes
public_keys_url=http://localhost:8081/openidconnect/public_keys
Zookeeper¶
Uveďte umístění Zookeeper serverů v clusteru.
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
Hint
Pro neprodukční nasazení je možné použít jediný Zookeeper server.
Knihovna¶
Uveďte cestu k knihovně, ze které se budou načítat deklarace.
[library]
providers=zk:///library
Hint
Jelikož je schéma ECS.yaml
v adresáři /Schemas
využíváno ve výchozím nastavení, zvažte použití LogMan.io Common Library.
Kafka¶
Uveďte bootstrap servery Kafka clusteru.
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
Hint
Pro neprodukční nasazení je možné použít jediný Kafka server.
Elasticsearch¶
Uveďte URL Elasticsearch master serverů.
Elasticsearch se používá k načítání událostí spojených s ticketem.
[elasticsearch]
url=http://es01:9200/
username=MOJEJMÉNOUTIVATELE
password=MOJEHESLO
MongoDB¶
Uveďte URL MongoDB clusteru s replikací.
Tickety jsou ukládány do MongoDB.
[asab:storage]
type=mongodb
mongodb_uri=mongodb://mongodb1,mongodb2,mongodb3/?replicaSet=rs0
Auth¶
Sekce Auth zajišťuje, že uživatelé mají přístup pouze ke svým přiřazeným tenantům pro nastavení alertů a podporuje multitenance.
Také kontroluje zdroje zmíněné v deklaraci alert/incident workflow.
[auth]
multitenancy=yes
public_keys_url=http://localhost:8081/openidconnect/public_keys
Vstup¶
Mikroslužba Alerty obsahuje Kafka rozhraní, které čte příchozí alerty z topicu lmio-alerts
. Jméno topicu nebo group ID lze změnit pomocí:
[pipeline:TicketPipeline:KafkaSource]
topic=lmio-alerts
group_id=lmio-alerts
Note
Změna vstupního topicu pro alerty se nedoporučuje, aby se předešlo zbytečným komplikacím.
Výstup pro event trigger¶
[pipeline:OutputPipeline:KafkaSink]
topic=lmio-events-complex
Warning
event
trigger by neměl být používán v žádné workflow deklaraci alertů. Použijte raději notifikace.
Workflow¶
Umístění workflow pro alerty a incidenty je vždy /Alerts/Workflow
.
Webová API¶
Alerty poskytují jedno webové API.
Webové API je navrženo pro komunikaci s UI.
[web]
listen=0.0.0.0 8953
Výchozí port veřejného webového API je tcp/8953
.
Tento port je navržen pro využití jako NGINX upstream pro spojení z collectorů.
Workflow¶
Workflow v Alartech¶
TeskaLabs LogMan.io Alerts používá následující workflow:
/Alerts/Workflow/alert.yaml
: Workflow používaný pro tikety s typemalert
/Alerts/Workflow/incident.yaml
: Workflow používaný pro tikety s typemincident
Deklarace¶
Toto je nejjednodušší možný příklad definice workflow, umístěný ve složce /Alerts/Workflow
v Knihovně:
---
define:
type: alerts/workflow
workflow:
open:
label: "Otevřeno"
transitions:
triaged:
resources: lmio:alert:triaged-to-new
closed: {}
triaged:
label: "Tříděno"
transitions:
closed: {}
closed:
label: "Uzavřeno"
trigger:
...
Workflow specifikuje stavy, do kterých může daný tiket vstoupit, přičemž první stav je ten, který je přiřazen nově vytvořenému tiketu.
Každý stav (zde open
, triaged
, a closed
) obsahuje následující atributy:
Popis¶
Atribut label
je řetězec, který se zobrazuje uživateli v uživatelském rozhraní.
Přechody¶
Definuje možné přechody do jiných stavů. Stavy jsou uvedeny níže buď s prázdnou složenou závorkou {}
jako hodnotou, nebo názvem či seznamem zdrojů, ke kterým musí být uživatel přiřazen, aby mohl tiket přesunout do stavu určeného přechodem.
Když tiket změní svůj stav, je volána sekce trigger
(pokud je specifikována).
Taxonomie alertů¶
TeskaLabs LogMan.io poskytuje taxonomii pro organizaci a správu různých artefaktů generovaných v systému, což usnadňuje analytikům kybernetické bezpečnosti prioritizovat jejich pracovní zátěž a efektivně reagovat na bezpečnostní hrozby.
Taxonomie je organizována do následujícího stromu:
- Událost
- Log
- Komplexní
- Ticket
- Alert
- Incident
Zde je vysvětlení každé kategorie a jejich podkategorií:
Událost¶
Události jsou záznamy aktivit, které se vyskytují v síti, systémech nebo aplikacích organizace.
Události lze dále klasifikovat na:
Log¶
Logy jsou základní záznamy generované různými zařízeními, systémy nebo aplikacemi, které ukládají informace o jejich činnosti. Příklady zahrnují logy firewallu, logy serveru nebo logy aplikace. Tyto logy pomáhají analytikům pochopit, co se děje v prostředí organizace, a mohou být použity k detekci bezpečnostních hrozeb a anomálií.
Komplexní¶
Komplexní události se týkají korelovaných nebo agregovaných událostí, které mohou naznačovat bezpečnostní incident nebo vyžadovat další analýzu. Jsou generovány koreláttory a jinými detektory, které shromažďují události z různých zdrojů, analyzují je a vytvářejí alerty na základě předdefinovaných pravidel nebo algoritmů strojového učení.
Ticket¶
Ticket je vytvořen analytiky kybernetické bezpečnosti nebo automatizovanými koreláttory a detektory pro sledování a správu bezpečnostních událostí, které vyžadují pozornost. Ticket může odkazovat na nula, jednu nebo více událostí.
Tickets lze dále klasifikovat na:
Alert¶
Alerty jsou generovány, když je detekována specifická událost, série událostí nebo anomálie, která může naznačovat potenciální bezpečnostní hrozbu. Alerty obvykle vyžadují okamžitou pozornost analytiků kybernetické bezpečnosti k třídění, vyšetřování a určení, zda je ticket skutečným bezpečnostním incidentem.
Incident¶
Incidenty jsou potvrzené bezpečnostní události, které byly prozkoumány a klasifikovány jako skutečné hrozby. Představují vyšší úroveň závažnosti než alerty a často zahrnují koordinovanou reakci od více týmů, jako je odezva na incidenty nebo správa sítě, k zadržení, nápravě a obnově z hrozby.
Lookups
Vyhledávání¶
Vyhledávání jsou slovníky entit s atributy, které jsou relevantní buď pro analýzu, nebo pro detekci kyberbezpečnostních incidentů.
Vyhledávání mohou být:
- Jednoduchý seznam podezřelých IP adres, aktivních VPN připojení, apod.
- Slovníky uživatelských jmen s uživatelskými atributy, jako je user.id, user.email, apod.
- Slovníky složených klíčů, jako jsou kombinace IP adres a uživatelských jmen pro monitorování uživatelské aktivity.
Co dělají vyhledávání?
Vyhledávání, podobná slovníkům, obsahují další užitečné informace o datech, která již máte, což může učinit vaše logy informativnějšími a cennějšími.
Jednoduchý příklad:
Vaše organizace má logy o odeslaných e-mailech, které obsahují e-mailové adresy odesílatelů.
Chcete však, aby logy v uživatelském rozhraní LogMan.io obsahovaly nejen e-mailovou adresu odesílatele, ale i jeho jméno.
Máte tedy vyhledávání, ve kterém je každá položka e-mailová adresa zaměstnance s přiřazeným jménem zaměstnance.
Pokud toto vyhledávání použijete v obohacovací části procesu analýzy, analyzátor „vyhledá“ jméno zaměstnance na základě jeho e-mailové adresy v tomto slovníku a zahrne jméno zaměstnance do logu.
Rychlý start¶
K nastavení vyhledávání:
- Vytvořte deklaraci vyhledávání v Knihovně LogMan.io (popis vyhledávání)
- Vytvořte vyhledávání a jeho obsah v sekci Vyhledávání v UI (obsah vyhledávání)
- Přidejte vyhledávání do relevantních pravidel pro analýzu a/nebo korelaci v Knihovně (aplikace vyhledávání)
Note
Ujistěte se, že všechny relevantní komponenty jsou nasazeny, viz Nasazení.
Deklarace¶
Všechna vyhledávání jsou definována jejich deklaracemi uloženými ve složce /Lookups
.
Názvoslovná konvence pro deklarace je lookupname.yaml
, například myuserlookup.yaml
:
---
define:
type: lookup
name: myuserlookup
keys:
- name: userid
type: str
fields:
username:
type: str
V define
specifikujte typ vyhledávání type
, jméno vyhledávání name
(informace o tenantovi budou přidány automaticky), klíče s jejich jmény (volitelnými) a typy a pole ve výstupní struktuře záznamu. Struktura záznamu NENÍ založena na schématu a NEMĚLA by obsahovat tečky.
Note
Názvy klíčů a polí nesmějí obsahovat speciální znaky, jako je tečka, apod.
Typy vyhledávání¶
Obecné vyhledávání¶
Obecné vyhledávání slouží k vytváření seznamů klíčů nebo párů klíč-hodnota. Typ type
v deklaraci v části define
je prostě lookup
:
---
define:
type: lookup
...
Při analýze mohou být obecná vyhledávání použita pouze ve standardním obohacovači s výrazem !LOOKUP
.
Pro více informací o obecných vyhledáváních viz Obecné vyhledávání.
Vyhledávání IP adres¶
Vyhledávání rozsahu IP adres¶
Vyhledávání rozsahu IP adres používá rozsahy IP adres, jako jsou 192.168.1.1
až 192.168.1.10
, jako klíče.
Deklarace vyhledávání rozsahu IP adres musí obsahovat typ lookup/ipaddressrange
v sekci define
a dva klíče s typem ip
v sekci keys
:
define:
type: lookup/ipaddressrange
name: mylookup
group: mygroup
keys:
- name: range1
type: ip
- name: range2
type: ip
fields:
...
Vyhledávání jedné IP adresy¶
Vyhledávání jedné IP adresy je vyhledávání, které má přesně jeden klíč IP adresy s typem ip
, který může být spojen s volitelným a proměnným počtem atributů definovaných žádnými nebo více hodnotami pod fields
.
Aby bylo možné použít vyhledávání jedné IP adresy spolu s následujícími obohacovači, musí být typ vyhledávání v sekci define
vždy lookup/ipaddress
.
---
define:
type: lookup/ipaddress
name: mylookup
group: mygroup
keys:
- name: sourceip
type: ip
fields:
...
Pro více informací o vyhledávání IP adres viz Vyhledávání IP adres.
Vyhledávání MAC adres¶
Vyhledávání rozsahu MAC adres¶
Vyhledávání rozsahu MAC adres používá rozsahy MAC adres, jako jsou 0c:12:30:00:00:01
až 0c:12:30:00:00:ff
, jako klíče.
Deklarace vyhledávání rozsahu MAC adres musí obsahovat typ lookup/macaddressrange
v sekci define
a dva klíče s typem mac
v sekci keys
:
define:
type: lookup/macaddressrange
name: mylookup
group: mygroup
keys:
- name: range1
type: mac
- name: range2
type: mac
fields:
...
Vyhledávání jedné MAC adresy¶
Vyhledávání jedné MAC adresy je vyhledávání, které má přesně jeden klíč MAC adresy s typem mac
, který může být spojen s volitelným a proměnným počtem atributů definovaných žádnými nebo více hodnotami pod fields
.
Aby bylo možné použít vyhledávání jedné MAC adresy spolu s následujícími obohacovači, musí být typ vyhledávání v sekci define
vždy lookup/macaddress
.
---
define:
type: lookup/macaddress
name: mylookup
group: mygroup
keys:
- name: sourcemac
type: mac
fields:
...
Pro více informací o vyhledávání MAC adres viz Vyhledávání MAC adres.
Nasazení¶
Návrh¶
lmio-watcher
¶
LogMan.io Watcher spravuje obsah lookups v Elasticsearch. Watcher čte lookup události z HTTP(S) API a Kafky.
lmio-lookupbuilder
¶
LogMan.io Lookup Builder zpracovává generický obsah lookups z Elasticsearch a deklarace lookups z Knihovny a vytváří binární soubory lookups. Tyto binární soubory lookups jsou poté používány dalšími mikroslužbami, jako jsou LogMan.io Parsec, LogMan.io Correlator, atd.
lmio-ipaddrproc
¶
LogMan.io IP Address Processor zpracovává obsah IP adresních lookups z Elasticsearch a deklarace lookups z Knihovny a vytváří binární soubory IP lookups. Tyto binární soubory IP lookups jsou poté používány dalšími mikroslužbami, jako jsou LogMan.io Parsec, LogMan.io Correlator, atd. Také stahuje vestavěné lookups z Azure úložiště z internetu.
Krok za krokem¶
Aby bylo možné pracovat s lookups, následujte tyto kroky nasazení. Pro více informací o tom, co jsou lookups a k čemu se používají, přejděte na Lookups.
-
Na každém stroji v rámci LogMan.io clusteru nasadíte jednu instanci LogMan.io Watcher.
-
Na každém stroji v rámci LogMan.io clusteru nasadíte jednu instanci
lmio-lookupbuilder
.Informace o konfiguraci a položkách v Docker Compose jsou uvedeny v sekci Konfigurace.
-
Na každém stroji v rámci LogMan.io clusteru nasadíte jednu instanci
lmio-ipaddrproc
.Informace o konfiguraci a položkách v Docker Compose jsou uvedeny v sekci Konfigurace.
-
Přidáte cestu k složce
/lookups
do sekce svazků Docker Compose každé instance LogMan.io Parsec, LogMan.io Correlator, LogMan.io Alerts a LogMan.io Baseliner. Cesta je ve výchozím nastavení:volumes: - /data/ssd/lookups:/lookups
-
Zahrnete LogMan.io Watcher do konfiguračního souboru každé instance NGINX jako záznam umístění na
/api/lmio-lookups
:location /api/lmio-lookup { auth_request /_oauth2_introspect; rewrite ^/api/lmio-lookup/(.*) /$1 break; proxy_pass http://lmio-watcher; }
Všimněte si proxy_pass, který ukazuje na upstream
lmio-watcher
, který by měl být definován na začátku každého konfiguračního souboru NGINX:upstream lmio-watcher { server HOSTNAME_PRVNIHO_SERVERU_V_CLUSTERU:8952 max_fails=0 fail_timeout=30s; server HOSTNAME_DRUHEHO_SERVERU_V_CLUSTERU:8952 max_fails=0 fail_timeout=30s; server HOSTNAME_TRETIM_SERVERU_V_CLUSTERU:8952 max_fails=0 fail_timeout=30s; }
Nahraďte
HOSTNAME_PRVNIHO_SERVERU_V_CLUSTERU
,HOSTNAME_DRUHEHO_SERVERU_V_CLUSTERU
,HOSTNAME_TRETIM_SERVERU_V_CLUSTERU
hostitelskými jmény serverů, na kterých je LogMan.io Watcher nasazen v prostředí LogMan.io clusteru.To je vše! Nyní jste připraveni vytvářet deklarace lookups a obsah lookups. Vraťte se zpět na Lookups pro další kroky.
Konfigurace¶
lmio-lookupbuilder
¶
LogMan.io Lookup Builder bere generický obsah z Elasticsearch a deklarace lookupů z Library a vytváří binární soubory pro lookupy. Tyto binární soubory jsou následně používány jinými mikroslužbami, jako jsou LogMan.io Parsec, LogMan.io Correlator, atd.
LogMan.io Lookup Builder má následující závislosti:
- Elasticsearch
- Zookeeper
- Library
- Tenanti pro vytváření lookupů
Docker Compose¶
lmio-lookupbuilder:
network_mode: host
image: docker.teskalabs.com/lmio/lmio-lookupbuilder:VERSION
volumes:
- ./lmio-lookupbuilder:/conf
- /data/ssd/lookups:/lookups
restart: always
logging:
options:
max-size: 10m
Konfigurační soubor¶
Toto je nejzákladnější požadovaná konfigurace:
[tenants]
ids=mytenant
[elasticsearch]
url=http://es01:9200/
username=MYUSERNAME
password=MYPASSWORD
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
[library]
providers=zk:///library
Alternativně, místo přímého specifikování id tenantů můžete přidat všechny tenanty z LogMan.io clusteru následující konfigurací:
[tenants]
tenant_url=http://<SEACAT_AUTH_NODE>:3081/tenant
Nahradit <SEACAT_AUTH_NODE>
názvem hostitele, kde běží služba SeaCat Auth.
lmio-ipaddrproc
¶
LogMan.io IP Address Processor bere obsah lookupů IP adres z Elasticsearch a deklarace lookupů z Library a vytváří binární soubory pro lookupy IP adres. Tyto binární soubory jsou následně používány jinými mikroslužbami, jako jsou LogMan.io Parsec, LogMan.io Correlator, atd. Rovněž stahuje vestavěné lookupy z Azure úložiště z internetu.
LogMan.io IP Address Processor má následující závislosti:
- ElasticSearch
- Zookeeper
- Library
- Tenanti pro vytváření lookupů
Docker Compose¶
lmio-ipaddrproc:
network_mode: host
image: docker.teskalabs.com/lmio/lmio-ipaddrproc:VERSION
volumes:
- ./lmio-ipaddrproc:/conf
- /data/ssd/lookups:/lookups
restart: always
logging:
options:
max-size: 10m
Konfigurační soubor¶
Toto je nejzákladnější požadovaná konfigurace:
[tenants]
ids=mytenant
[elasticsearch]
url=http://es01:9200/
username=MYUSERNAME
password=MYPASSWORD
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
[library]
providers=zk:///library
Alternativně, místo přímého specifikování id tenantů můžete přidat všechny tenanty z LogMan.io clusteru následující konfigurací:
[tenants]
tenant_url=http://<SEACAT_AUTH_NODE>:3081/tenant
Nahradit <SEACAT_AUTH_NODE>
názvem hostitele, kde běží služba SeaCat Auth.
Generické lookupy¶
TeskaLabs LogMan.io generické lookupy slouží k vytváření seznamů klíčů nebo dvojic klíč-hodnota. type
v deklaraci v sekci define
je jednoduše lookup
:
---
define:
type: lookup
...
Pokud jde o parsování, generické lookupy mohou být použity pouze ve standardním enricheři s výrazem !LOOKUP
.
Vytváření generického lookupu¶
Existují vždy tři kroky pro povolení lookupů:
- Vytvořte deklaraci lookupu v Knihovně LogMan.io (popis lookupu)
- Vytvořte lookup a jeho obsah v sekci Lookupy v UI (obsah lookupu)
- Přidejte lookup do relevantních parsingových a/nebo korelačních pravidel v Knihovně (aplikace lookupu)
Případ použití: Uživatelský lookup¶
Uživatelský lookup se používá k získání informací o uživateli, jako je uživatelské jméno a email podle ID uživatele.
-
V LogMan.io přejděte do Knihovny.
-
V Knihovně přejděte do složky
/Lookups
. -
Vytvořte novou deklaraci lookupu pro váš lookup, třeba „userlookup.yaml“, přičemž se ujistěte, že soubor má příponu YAML.
-
Přidejte následující deklaraci:
define: type: lookup name: userlookup group: user keys: - name: userid type: str fields: user_name: type: str email: type: str
Ujistěte se, že
type
je vždylookup
.Změňte
name
v sekcidefine
na název vašeho lookupu.group
se používá při procesu obohacení k nalezení všech lookupů, které sdílejí stejnou skupinu. Hodnota je jedinečný identifikátor skupiny (případ použití), zde:user
.Do
fields
přidejte názvy a typy atributů lookupu. Tento příklad používáuser_name
aemail
jako řetězce.V současné době jsou podporovány tyto typy:
str
,fp64
,si32
,geopoint
aip
. -
Uložte deklaraci.
-
V LogMan.io přejděte do Lookupů.
-
Vytvořte nový lookup se stejným názvem jako výše, tj. „userlookup“. Specifikujte ID uživatele jako klíč.
-
Vytvořte záznamy v lookupu s ID uživatele jako klíčem a poli, jak je uvedeno výše.
-
Přidejte následující enricheř do pravidla LogMan.io Parsec, které by mělo využívat lookup:
define: type: enricher/standard enrich: user_name: !GET from: !LOOKUP what: userlookup what: !GET from: !EVENT what: user.id
Tento vzorový enricheř získá
user_name
zuserlookup
na základě atributuuser.id
z parsovaného eventu.
Vyhledávání IP adres¶
TeskaLabs LogMan.io nabízí optimalizované sady vyhledávání pro IP adresy, nazvané IP Lookups.
Existují vždy tři kroky k povolení IP Lookups:
- Vytvořte deklaraci vyhledávání v LogMan.io Library (popis vyhledávání)
- Vytvořte vyhledávání a jeho obsah v sekci Lookups v UI (obsah vyhledávání)
- Přidejte vyhledávání do relevantních pravidel parsování a/nebo korelace v Library (aplikace vyhledávání)
Vyhledání IP adresy na geografickou polohu¶
IP Geo Location
je proces, kdy na základě rozsahu IP adres, jako je 192.168.1.1
až 192.168.1.10
, chcete získat geografickou polohu IP adresy, jako je název města, zeměpisná šířka, délka apod.
Vestavěné vyhledávání IP na geografickou polohu
Když IP adresa z události neodpovídá žádnému z poskytnutých geo
vyhledávání, bude použito výchozí veřejné vyhledávání IP adres poskytované TeskaLabs LogMan.io.
-
V LogMan.io přejděte do Library.
-
V Library, přejděte do složky
/Lookups
. -
Vytvořte novou deklaraci vyhledávání pro vaše vyhledávání, jako například "ipgeolookup.yaml" s příponou YAML
-
Přidejte následující deklaraci:
define: type: lookup/ipaddressrange name: ipgeolookup group: geo keys: - name: range1 type: ip - name: range2 type: ip fields: location: type: geopoint value: lat: 50.0643081 lon: 14.443938 city_name: type: str
Ujistěte se, že
type
je vždylookup/ipaddressrange
.Změňte
name
v sekcidefine
na název vašeho vyhledávání.group
se používá v obohacovacím procesu pro nalezení všech vyhledávání, která sdílí stejnou skupinu. Hodnota je unikátní identifikátor skupiny (use case), zde:geo
.Klíče nechte tak, jak jsou, abyste specifikovali rozsahy.
Do
fields
přidejte názvy a typy atributů vyhledávání. V tomto příkladu je jenom město, ale může být i poloha (zeměpisná šířka a délka) atd.:fields: name: type: str continent_name: type: str city_name: type: str location: type: geopoint
Při použití Elastic Common Schema (ECS) jsou všechny dostupné geo pole, která mohou být použita, specifikována v dokumentaci: https://www.elastic.co/guide/en/ecs/current/ecs-geo.html
Hodnota
value
bude použita jako výchozí.V současnosti jsou podporovány tyto typy:
str
,fp64
,si32
,geopoint
aip
. -
Uložte
-
V LogMan.io přejděte do Lookups.
-
Vytvořte nové vyhledávání se stejným názvem jako výše, tj. "ipgeolookup". Specifikujte dva klíče s názvy:
range1
,range2
. -
Vytvořte záznamy ve vyhledávání s rozsahy jako klíči a poli, jak je uvedeno výše (v příkladu je ve slovníku hodnot uložených ve vyhledávání pouze město).
-
Přidejte následující obohacovač do pravidla LogMan.io Parsec, které by mělo použít vyhledávání:
define: type: enricher/ip group: geo schema: ecs: postfix: geo.
Specifikujte skupinu vyhledávání, která by měla být použita v atributu
group
. Měla by být stejná jako skupina uvedená výše v deklaraci vyhledávání. Tenants jsou řešeni automaticky.Obohacování probíhá na každém poli, které má typ
ip
ve schématu.Postfix specifikuje příponu pro atribut:
Pokud je vstup
source.ip
Pak je výstup
source.geo.<NAME_OF_THE_ATTRIBUTE>
Když jde o výchozí veřejné GEO vyhledávání (viz výše), následující položky jsou vyplněny ve výchozím nastavení:
city_name: type: str country_iso_code: type: str location: type: geopoint region_name: type: str
Vyhledávání rozsahu IP adres¶
Vyhledávání rozsahu IP adres používá rozsahy IP adres, jako je 192.168.1.1 až 192.168.1.10, jako klíče.
Deklarace vyhledávání rozsahu IP adres musí obsahovat typ lookup/ipaddressrange
v sekci define
a dva klíče s typem ip
v sekci keys
:
define:
type: lookup/ipaddressrange
name: mylookup
group: mygroup
keys:
- name: range1
type: ip
- name: range2
type: ip
fields:
...
Případ použití: Obohacení privátní IP adresy do zóny¶
Můžete použít vyhledávání IP-to-zone, když na základě rozsahu IP adres, jako je 192.168.1.1
až 192.168.1.10
, chcete získat název zóny, název podlaží a další informace (např. budova společnosti, zda je to privátní nebo veřejná zóna atd.).
Hint
Použijte vyhledávání IP-to-zone pro obohacování privátní IP adresy.
-
V LogMan.io, přejděte do Library.
-
V Library přejděte do složky
/Lookups
. -
Vytvořte novou deklaraci vyhledávání pro vaše vyhledávání, jako například "ipzonelookup.yaml" s příponou YAML
-
Přidejte následující deklaraci:
define: type: lookup/ipaddressrange name: ipzonelookup group: zone keys: - name: range1 type: ip - name: range2 type: ip fields: location: type: geopoint value: lat: 50.0643081 lon: 14.443938 zone_name: type: str value: myzone floor_name: type: str
Ujistěte se, že typ je vždy
lookup/ipaddressrange
.Změňte
name
v sekci define na název vašeho vyhledávání.group
se používá v obohacovacím procesu pro nalezení všech vyhledávání, která sdílí stejnou skupinu. Hodnota je unikátní identifikátor skupiny (use case), zde:zone
.Klíče nechte tak, jak jsou, abyste specifikovali rozsahy.
Do
fields
přidejte názvy a typy atributů vyhledávání. Zde v příkladu je pouze název podlaží, ale může být i název místnosti, název společnosti atd.:yaml fields: floor_name: type: str
Hodnota
value
bude použita jako výchozí.V současnosti jsou podporovány tyto typy:
str
,fp64
,si32
,geopoint
aip
. -
Uložte
-
V LogMan.io přejděte do Lookups.
-
Vytvořte nové vyhledávání se stejným názvem jako výše, tj. "ipzonelookup". Specifikujte dva klíče s názvy:
range1
,range2
. -
Vytvořte záznamy ve vyhledávání s rozsahy jako klíči a poli, jak je uvedeno výše (v příkladu je ve slovníku hodnot uložených ve vyhledávání pouze podlaží).
-
Přidejte následující obohacovač do pravidla LogMan.io Parsec, které by mělo použít vyhledávání:
define: type: enricher/ip group: floor schema: ecs: prefix: lmio.ipenricher. postfix: zone.
Specifikujte skupinu vyhledávání, která by měla být použita v atributu
group
. Měla by být stejná jako skupina uvedená výše v deklaraci vyhledávání. Tenants jsou řešeni automaticky.Obohacování probíhá na každém poli, které má typ
ip
ve schématu.Prefix specifikuje předponu a postfix specifikuje příponu pro atribut:
Pokud je vstup
source.ip
, pak je výstuplmio.ipenricher.source.zone.<NAME_OF_THE_ATTRIBUTE>
.
Vyhledávání jedné IP adresy¶
Vyhledávání jedné IP adresy je vyhledávání, které má přesně jeden klíč IP adresy s typem ip
, který může být spojen s volitelným a variabilním počtem atributů definovaných žádnými nebo více hodnotami v fields
.
Pro použití single IP vyhledávání spolu s následujícími obohacovači musí být typ vyhledávání v sekci define
vždy lookup/ipaddress
.
---
define:
type: lookup/ipaddress
name: mylookup
group: mygroup
keys:
- name: sourceip
type: ip
fields:
...
Případ použití: Vyhledávání špatných IP adres¶
Můžete použít obohacení špatné IP adresy, když na základě jedné IP adresy, jako je 192.168.1.1
, chcete získat informace o rizikovém skóre IP adresy atd.
-
V LogMan.io, přejděte do Library.
-
V Library, přejděte do složky
/Lookups
. -
Vytvořte novou deklaraci vyhledávání pro vaše vyhledávání, jako například "badips.yaml" s příponou YAML.
-
Přidejte následující deklaraci:
--- define: type: lookup/ipaddress name: badips group: bad keys: - name: sourceip type: ip fields: base: type: si32
Ujistěte se, že typ je vždy
lookup/ipaddress
.Změňte
name
v sekcidefine
na název vašeho vyhledávání.group
se používá v obohacovacím procesu pro nalezení všech vyhledávání, která sdílí stejnou skupinu. Hodnota je unikátní identifikátor skupiny (use case), zde:bad
.Zachovejte jeden klíč v sekci
keys
s typemip
. Název by neměl obsahovat tečky ani jiné speciální znaky.Do
fields
přidejte názvy a typy atributů vyhledávání. Zde v příkladu jebase
jako integer, ale mohou být i jiné bezpečnostní atributy z https://www.elastic.co/guide/en/ecs/current/ecs-vulnerability.html:fields: base: type: si32
V současnosti jsou podporovány tyto typy:
str
,fp64
,si32
,geopoint
, aip
. -
Uložte
-
V LogMan.io přejděte do "Lookups".
-
Vytvořte nové vyhledávání se stejným názvem jako výše, tj. badips. Specifikujte IP adresu jako klíč.
-
Vytvořte záznamy ve vyhledávání s IP adresou jako klíčem a poli, jak je uvedeno výše (v příkladu je v hodnotovém slovníku uloženém ve vyhledávání pouze
base
). -
Přidejte následující obohacovač do pravidla LogMan.io Parsec, které by mělo použít vyhledávání:
define: type: enricher/ip group: bad schema: ecs: # https://www.elastic.co/guide/en/ecs/current/ecs-vulnerability.html prefix: lmio.vulnerability. postfix: score.
Specifikujte skupinu vyhledávání, která by měla být použita v atributu
group
. Měla by být stejná jako skupina uvedená výše v deklaraci vyhledávání. Tenants jsou řešeni automaticky.Obohacování probíhá na všech polích, které mají typ
ip
ve schématu.Prefix je přidán k poli s rozřešenými atributy, které mají být použity pro další mapování:
Pokud je vstup
source.ip
Pak je výstup
lmio.vulnerability.source.score.<NAME_OF_THE_ATTRIBUTE>
-
Na základě atributu a následného mapování může být přidána korelace s výstražným triggerem do
/Correlators
pro notifikaci o špatné IP adrese, jejíž základní skóre je vyšší než prahová hodnota:--- define: name: Bad IP Notification description: Bad IP Notification type: correlator/window predicate: !AND - !IN what: source.ip where: !EVENT - !GT - !ITEM EVENT lmio.vulnerability.source.score.base - 2 evaluate: dimension: [tenant, source.ip] by: "@timestamp" # Název event field s časem události resolution: 60 # jednotka je vteřina saturation: 10 # jednotka je resolution analyze: window: hopping # to je výchozí aggregate: sum # to je výchozí span: 2 # 2 * resolution z evaluate = mé časové okno test: !GE - !ARG - 1 trigger: - event: !DICT type: "{str:any}" with: message: "Bad IP Notification" events: !ARG EVENTS source.ip: !ITEM EVENT source.ip event.dataset: correlation - notification: type: email to: [logman@example.co] template: "/Templates/Email/Notification.md" variables: !DICT type: "{str:any}" with: name: Bad IP Notification events: !ARG EVENTS dimension: !ITEM EVENT source.ip
Případ použití: Obohacení IP adresy do assetu¶
Použijte obohacení IP-to-asset, když na základě jediné IP adresy, jako je 192.168.1.1
, chcete získat informace z připraveného vyhledávání o assetech, zařízeních, hostech atd.
-
V LogMan.io, přejděte do Library.
-
V Library, přejděte do složky
/Lookups
. -
Vytvořte novou deklaraci vyhledávání pro vaše vyhledávání, jako například "ipassetlookup.yaml" s příponou YAML.
-
Přidejte následující deklaraci:
--- define: type: lookup/ipaddress name: ipassetlookup group: asset keys: - name: sourceip type: ip fields: asset: type: str
Ujistěte se, že
type
je vždylookup/ipaddress
.Změňte
name
v sekcidefine
na název vašeho vyhledávání.group
se používá v obohacovacím procesu pro nalezení všech vyhledávání, která sdílí stejnou skupinu. Hodnota je unikátní identifikátor skupiny (use case), zde:asset
.Zachovejte jeden klíč v sekci
keys
s typemip
. Název by neměl obsahovat tečky ani jiné speciální znaky.Do
fields
přidejte názvy a typy atributů vy
Vyhledávání MAC adres¶
TeskaLabs LogMan.io nabízí optimalizovanou sadu vyhledávání pro práci s MAC adresami, nazvanou MAC vyhledávání.
Existují vždy tři kroky k povolení MAC vyhledávání:
- Vytvořte deklaraci vyhledávání v LogMan.io Knihovně (popis vyhledávání)
- Vytvořte vyhledávání a jeho obsah v sekci Vyhledávání v uživatelském rozhraní (obsah vyhledávání)
- Přidejte vyhledávání do relevantních pravidel pro analýzu a/nebo korelaci v Knihovně (aplikace vyhledávání)
Vyhledávání MAC adresy podle výrobce¶
Vyhledávání výrobce MAC
je, když na základě rozsahu MAC adres, jako je 0c:12:30:00:00:01
až 0c:12:30:00:00:ff
, chcete získat informace o výrobci zařízení, kterému je MAC adresa přidělena.
Vestavěné vyhledávání MAC adresy podle výrobce
Když MAC adresa z události neodpovídá žádnému z poskytnutých macvendor
vyhledávání, bude použito výchozí veřejné vyhledávání výrobce MAC poskytované TeskaLabs LogMan.io.
-
V LogMan.io přejděte do Knihovny.
-
V Knihovně přejděte do složky
/Vyhledávání
. -
Vytvořte novou deklaraci vyhledávání pro vaše vyhledávání, například "macvendorlookup.yaml" s příponou YAML.
-
Přidejte následující deklaraci:
define: type: lookup/macaddressrange name: macvendorlookup group: macvendor keys: - name: range1 type: mac - name: range2 type: mac fields: manufacturer: type: str
Ujistěte se, že
type
je vždylookup/macaddressrange
.Změňte
name
v sekcidefine
na název vašeho vyhledávání.group
se poté používá v procesu obohacení k nalezení všech vyhledávání, která sdílejí stejnou skupinu. Hodnota je jedinečný identifikátor skupiny (použití), zde:macvendor
.Zachovejte klíče tak, jak jsou, abyste specifikovali rozsahy.
Do
fields
přidejte názvy a typy atributů vyhledávání.fields: manufacturer: type: str
Atribut
value
bude použit jako výchozí.V současnosti jsou podporovány tyto typy:
str
,fp64
,si32
,geopoint
,ip
amac
. -
Uložte.
-
V LogMan.io přejděte do Vyhledávání.
-
Vytvořte nové vyhledávání se stejným názvem jako výše, tj. "macvendorlookup". Specifikujte dvě klíče s názvy:
range1
,range2
. -
Vytvořte záznamy ve vyhledávání s rozsahy jako klíči a poli, jak je uvedeno výše (v příkladu je v hodnotovém slovníku uložen pouze výrobce).
-
Přidejte následující obohacovač do pravidla Parsec LogMan.io, které by mělo využívat vyhledávání:
define: type: enricher/mac group: macvendor schema: ecs: postfix: device.
Specifikujte skupinu vyhledávání, která má být použita v atributu
group
. Měla by být stejná jako skupina zmíněná výše v deklaraci vyhledávání. Nájemníci jsou automaticky vyřešeni.Obohacení se provádí na každém poli, které má typ
mac
ve schématu.Postfix specifikuje postfix pro atribut:
Pokud je vstup
source.mac
Pak je výstup
source.observer.<NAME_OF_THE_ATTRIBUTE>
.Pokud jde o výchozí veřejné vyhledávání výrobce MAC (viz výše), následující položky jsou vyplněny výchozími hodnotami:
manufacturer: type: str
Vyhledávání rozsahu MAC adres¶
Vyhledávání rozsahu MAC adres používá rozsahy MAC adres, jako je 0c:12:30:00:00:01
až 0c:12:30:00:00:ff
, jako klíče.
Deklarace vyhledávání rozsahu MAC adres musí obsahovat typ lookup/macaddressrange
v sekci define
a dva klíče s typem mac
v sekci keys
:
define:
type: lookup/macaddressrange
name: mylookup
group: mygroup
keys:
- name: range1
type: mac
- name: range2
type: mac
fields:
...
Adaptivní vyhledávání¶
Adaptivní vyhledávání umožňuje komponentám pro zpracování událostí TeskaLabs LogMan.io, jako jsou LogMan.io Parsec, LogMan.io Correlator a LogMan.io Alerts, automaticky aktualizovat vyhledávání pro obohacení dat v reálném čase pomocí pravidel.
Vlastní pravidla mohou dynamicky přidávat nebo odstraňovat položky z těchto vyhledávání na základě poznatků získaných z příchozích logů nebo jiných událostí. To zajišťuje, že vaše strategie detekce a reakce na hrozby zůstávají agilní, přesné a v souladu s neustále se měnícím kybernetickým prostředím, čímž poskytují nezbytnou vrstvu inteligence pro vaše bezpečnostní operace.
Triggery¶
Obsah vyhledávání je manipulován specifickým záznamem v sekci trigger
deklaračního souboru.
To znamená, že může vytvořit (set
), incrementovat (add
), dekrementovat (sub
) a odstranit (delete
) položku ve vyhledávání.
Položka je identifikována pomocí key
, což je jedinečný primární klíč.
Příklad triggeru, který přidává položku do vyhledávání user_list
:
trigger:
- lookup: user_list
key: !ITEM EVENT user.name
set:
event.created: !NOW
foo: bar
Příklad triggeru, který odstraňuje položku z vyhledávání user_list
:
trigger:
- lookup: user_list
delete: !ITEM EVENT user.name
Příklad triggeru, který incrementuje čítač (pole my_counter
) v položce ve vyhledávání user_list
:
trigger:
- lookup: user_list
key: !ITEM EVENT user.name
add: my_counter
Příklad triggeru, který dekrementuje čítač (pole my_counter
) v položce ve vyhledávání user_list
:
trigger:
- lookup: user_list
key: !ITEM EVENT user.name
sub: my_counter
Pro oba add
a sub
, název čítače může být vynechán, a implicitně bude použita výchozí atribut _counter
:
trigger:
- lookup: user_list
key: !ITEM EVENT user.name
sub:
Pokud pole s čítačem neexistuje, je vytvořeno s výchozí hodnotou 0.
Note
Položky z vyhledávání lze přistupovat z deklaračních výrazů pomocí !GET
a !IN
entry.
Lookups API¶
Změny lookupu mohou zahrnovat vytváření nebo mazání celé struktury lookupu, stejně jako přidávání, aktualizaci nebo odstraňování konkrétních položek v lookupu. Položky lze navíc automaticky odstranit při jejich vypršení platnosti. Tyto změny lze provést prostřednictvím UI systému (HTTPS API) nebo prostřednictvím Apache Kafka.
Události lookupu jsou zasílány každou komponentou, která vytváří události lookupu, do témat lmio-lookups
.
Struktura události lookupu¶
Událost lookupu má JSON strukturu se třemi povinnými atributy: action
, lookup_id
a data
. Atributy @timestamp
a tenant
jsou přidávány automaticky spolu s dalšími konfigurovanými meta atributy.
action
¶
Specifikuje akci, kterou událost lookupu způsobila. Akce může být prováděna na celé lookupu nebo jen na jedné z jejích položek. Podívejte se na níže uvedený seznam, který zahrnuje všechny dostupné akce a jejich přidružené události.
lookup_id
¶
ID nebo název lookupu. ID lookupu v událostech lookupu také obsahuje název tenantu po tečce .
, takže každá komponenta ví, pro který tenant je lookup specifický.
data
¶
Specifikace dat lookupu (tj. položky lookupu), která mají být vytvořena nebo aktualizována, stejně jako metainformace (v případě smazání položky).
Položky lookupu obsahují své ID v atributu _id
struktury data
. _id
je řetězec založený na:
Jediný klíč¶
Pokud má lookup pouze jeden klíč (např. userName), _id
je samotná hodnota pro řetězcovou hodnotu.
'data': {
'_id': 'JohnDoe'
}
...
Pokud je hodnota v bajtech, _id
je UTF-8 dekódovaná řetězcová reprezentace hodnoty. Pokud hodnota není ani řetězec, ani bajty, je zpracována stejně jako ID při použití složených klíčů.
Složený klíč¶
Pokud se lookup skládá z více klíčů (např. [userName, location]), _id
je hash reprezentace hodnoty.
Původní hodnoty jsou pak uloženy v atributu _keys
uvnitř struktury data
:
'data': {
'_id': '<INTERNAL_HASH>',
'_keys': ['JohnDoe', 'Company 1']
}
...
Vytvořit lookup¶
Když je lookup vytvořen, je vygenerována následující akce:
{
'@timestamp': <UNIX_TIMESTAMP>,
'tenant': <TENANT>,
'action': 'create_lookup',
'data': {},
'metadata': {
'_keys': ['key1name', 'key2name' ...]
...
},
'lookup_id': 'myLookup.tenant'
}
Metadata obsahují informace o vytvoření lookupu, jako jsou názvy jednotlivých klíčů (např. [userName, location]) v případě složených klíčů.
Smazat lookup¶
Když je lookup smazán, je vygenerována následující akce:
{
'@timestamp': <UNIX_TIMESTAMP>,
'tenant': <TENANT>,
'action': 'delete_lookup',
'data': {},
'lookup_id': 'myLookup.tenant'
}
Vytvořit položku¶
Když je vytvořena položka, je vygenerována následující akce:
{
'@timestamp': <UNIX_TIMESTAMP>,
'tenant': <TENANT>,
'action': 'create_item',
'data': {
'_id': 'newItemId',
'_keys': [],
...
},
'lookup_id': 'myLookup.tenant'
}
Aktualizovat položku¶
Když je položka aktualizována, je vygenerována následující akce:
{
'@timestamp': <UNIX_TIMESTAMP>,
'tenant': <TENANT>,
'action': 'update_item',
'data': {
'_id': 'existingOrNewItemId',
'_keys': [],
...
},
'lookup_id': 'myLookup.tenant'
}
Smazat položku¶
Když je položka smazána, je vygenerována následující akce.
Vypršení platnosti¶
V případě smazání z důvodu vypršení platnosti:
{
'@timestamp': <UNIX_TIMESTAMP>,
'tenant': <TENANT>,
'action': 'delete_item',
'data': {
'_id': 'existingItemId',
'reason': 'expiration'
},
'lookup_id': 'myLookup.tenant'
}
Prosím, vezměte na vědomí: Pokud není volba use_default_expiration_when_update
zakázána (nastavena na false) v metainformacích lookupu, doba platnosti je obnovována při každé aktualizaci položky lookupu (aktuální čas + výchozí doba platnosti). Smazání z důvodu vypršení platnosti se tedy stane pouze v případě, že nebyla provedena žádná aktualizace položky po dobu trvání doby platnosti.
Smazat¶
Z jiných důvodů:
{
'@timestamp': <UNIX_TIMESTAMP>,
'tenant': <TENANT>,
'action': 'delete_item',
'data': {
'_id': 'existingItemId',
'reason': 'delete'
},
'lookup_id': 'myLookup.tenant'
}
Interní mechanismy vyhledávání¶
Služba vyhledávání¶
Služba správy vyhledávání zahrnuje:
- Objekty vyhledávání pouze pro čtení, které mohou fungovat jak v asynchronním, tak synchronním režimu (osvěžením při tiknutí)
- Objekty pro úpravu vyhledávání pouze pro zápis
- Objekty builderu pro synchronní soubory vyhledávání, které budou použity builderovými službami
Tato služba poskytuje rozhraní jak pro BSPump, tak pro SP-Lang.
Typy vyhledávání¶
Synchronní vyhledávání¶
Synchronní vyhledávání jsou vyhledávání načítaná ze souborů, která zahrnují:
- Vyhledávání IP adres
- Vyhledávání v Elasticsearch serializovaná do souborů
Vytvoření synchronních vyhledávání je řízeno pomocí LogMan.io Lookup Builderu (viz konfigurace), jehož výstup je uložen ve složce /lookups
.
Asynchronní vyhledávání¶
Vyhledávání přímo načítaná z Elasticsearch.
Pokud synchronní soubor vyhledávání chybí nebo je poškozen, zpracování je automaticky řešeno pomocí asynchronních vyhledávání.
Asynchronní vyhledávání vyžadují méně nastavení, ale jsou méně optimální než synchronní vyhledávání.
Warden
LogMan.io Warden¶
TeskaLabs LogMan.io Warden je mikroservis, který periodicky provádí předdefinované detekce na zpracovaných událostech uložených v Elasticsearch. Elasticsearch indexy, ze kterých se události načítají, jsou získávány pomocí deklarací event lane pro daného nájemce, které jsou uloženy ve složce /EventLanes/
v knihovně. Detekce vytváří alerty ve službě LogMan.io Alerts.
Dostupné jsou následující detekce:
- Detekce IP, která detekuje IP adresy uložené v lookup
LogMan.io Warden konfigurace¶
LogMan.io Warden vyžaduje následující závislosti:
- Apache ZooKeeper
- Apache Kafka
- Elasticsearch
- SeaCat Auth
- LogMan.io Alerty
- LogMan.io Knihovna se složkami
/EventLanes
a/Lookups/
a schéma ve složce/Schemas
Příklad¶
Toto je nejzákladnější konfigurace potřebná pro každou instanci LogMan.io Warden:
[tenant]
name=default
[ip]
lookup=ipbad
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
[library]
providers=zk:///library
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
[elasticsearch]
url=http://es01:9200/
[auth]
public_keys_url=http://localhost:8081/openidconnect/public_keys
Tenant¶
Specifikujte tenant, ve kterém je LogMan.io Warden nasazen a bude provádět detekce.
[tenant]
name=mytenant
Doporučuje se spustit jednu instanci LogMan.io Warden na tenant.
Detekce¶
IP¶
Specifikujte lookup, který uvádí IP adresy, které by měly být detekovány.
[ip]
lookup=ipbad
Lookup's key MUSÍ být typu ip
ve specifikaci lookup, která je uložena ve složce /Lookups/
v knihovně.
---
define:
type: lookup/ipaddress
name: ipbad
group: bad
keys:
- name: sourceip
type: ip # Typ klíče musí být IP
Zookeeper¶
Specifikujte umístění serveru Zookeeper v clusteru:
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
Hint
Pro neprodukční nasazení je možné použít jeden server Zookeeper.
Knihovna¶
Specifikujte cestu(é) ke Knihovně pro načtení specifikací:
[library]
providers=zk:///library
Hint
Vzhledem k tomu, že schéma ECS.yaml
ve složce /Schemas
je využíváno ve výchozím nastavení, zvažte použití LogMan.io Common Library.
Kafka¶
Definujte bootstrap servery Kafka clusteru:
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
Hint
Pro neprodukční nasazení je možné použít jeden server Kafka.
ElasticSearch¶
Specifikujte URL master uzlů Elasticsearch.
Elasticsearch je nezbytný pro používání lookup, např. jako !LOOKUP
výraz nebo lookup trigger.
[elasticsearch]
url=http://es01:9200
username=MYUSERNAME
password=MYPASSWORD
Exporty
Exporty¶
Funkce exportů jsou zajišťovány mikroslužbou BS-Query, která klientům umožňuje snadno vytvářet, přizpůsobovat a spravovat exporty z databáze do souborů, nabízející různé možnosti, jako je výběr formátu, stahování dat, doručování e-mailem a automatické plánování.
Chcete-li se dozvědět, jak vytvářet a monitorovat exporty, navštivte odpovídající sekci uživatelské příručky zde.
Terminologie¶
Export¶
S výrazem "export" se můžete setkat v různých kontextech.
- Exportovaný soubor
- Především, "export" je data vyextrahovaná ze zdroje dat (typicky databáze). Říkejme mu "exportovaný soubor".
- Export v uživatelském rozhraní
- Export v LogMan.io Web Application je záznam informující o stavu exportu a poskytuje dodatečné informace. Nabízí také rozhraní pro stažení obsahu - "exportovaný soubor".
- Deklarace exportu
- Export v kontextu knihovny (YAML soubory v sekci
Exports
knihovny) je "deklarace exportu" - plán říkající, jak vytvořit nový export. - Exportní objekt
- A v neposlední řadě je "Export" objekt v aplikaci BS-Query a jeho reprezentace na disku. BS-Query Exportní objekt ukládá minimální informace v paměti. Místo toho slouží jako spojení k datovému úložišti.
Datové úložiště¶
Datové úložiště je organizováno následovně:
.
└── data
└── <export_id>.exp
├── content
│ └── <export_id>.json
├── declaration.yaml
└── export.json
└── schedule.json
- Adresář
content
ukládá exportovaná data. Tento adresář může obsahovat žádný nebo pouze jeden soubor. - Soubor
declaration.yaml
ukládá všechny proměnné potřebné pro tento export. Kompletní strukturu deklarace najdete v této kapitole. - Soubor
export.json
ukládá metadata tohoto konkrétního exportu. Mohl by vypadat takto:{"state": "finished", "_c": 1692975120.0054746, "_m": 1692975120.0054772, "export_size": 181610228, "_f": 1692975170.0347197}
- Soubor
schedule.json
je zde pouze pro naplánované exporty. Ukládá časové razítko dalšího spuštění.
Zdroj dat¶
Se "zdrojem dat" nebo i "datasource" se můžete setkat v různých kontextech.
- Zdroj dat
- Zdroj dat. Toto je originální databáze nebo jiná technologie, ze které extrahujeme data.
- Deklarace zdroje dat
- Toto je YAML soubor v sekci
DataSources
knihovny. Je to plán/příručka specifikující připojení k externímu zdroji dat. - Objekt datasource
- Objekt v aplikaci BS-Query zodpovědný za připojení ke zdroji dat/databázi a extrakci dat.
Deklarace¶
Deklarace je manuál nebo plán pro systém, který předepisuje, jak vykonat. Deklarace exportu jednoduše předepisuje, co by mělo být v výsledném exportovaném souboru. Tyto deklarace najdete ve formátu YAML v knihovně. Naučte se, jak číst nebo psát export a deklarace zdrojů dat v této kapitole.
Životní cyklus exportu¶
Každý export má stav. Každý přechod stavu spouští akci.
Vytvořen¶
Nejprve je export vytvořen na základě vstupu. Každý export musí být vytvořen na základě deklarace. Existuje několik způsobů, jak poskytnout deklaraci - jako soubor JSON nebo YAML nebo jako odkaz na Knihovnu.
Je generováno ID exportu a složka <export_id>.exp
se objeví v úložišti dat.
Následně je export přemístěn do stavu "vědění".
Vědění¶
Každá deklarace exportu obsahuje položku "datasource". Toto je odkaz na sekci knihovny /DataSources
.
Ve stavu zpracování BS-Query čte deklaraci zdroje dat z Knihovny a vytváří objekt zdroje dat - toto je specifické připojení k vybrané databázi. Každý objekt exportu vytváří a používá jeden objekt zdroje dat.
Query
je řetězcová proměnná z deklarace exportu určující, která data se mají sbírat.
Při použití dokumentových databází je každý dokument zpracováván jeden po druhém, čímž se vytváří stream, který snižuje využití paměti a zvyšuje výkon.
Každý dokument/záznam prochází transformačními funkcemi. Více se dozvíte o tom, jak transformovat exportovaná data na základě schématu.
Následně je uložen ve formátu zvoleném v sekci output
deklarace exportu.
Ne všechny zdroje dat podporují všechny výstupní formáty.
Komprese¶
Krok komprese je volitelný, na základě deklarace exportu.
Postprocessing¶
V této fázi již není obsah exportu editován, je odeslán na vybrané cíle, přičemž první volbou je e-mail. BS-Query používá ASAB Iris k odesílání exportů prostřednictvím e-mailu.
Dokončeno¶
Existují dvě možnosti. Export byl úspěšně dokončen a je připraven ke stažení nebo došlo k výjimce v životním cyklu exportu a takový export "dokončen s chybou".
Existují známé chyby, kterým lze předcházet poskytnutím lepšího vstupu. Takové chyby jsou navrženy tak, aby poskytovaly dostatek informací na UI. Objekt exportu, který byl dokončen s výjimkou, je uložen spolu s informacemi o chybě. Neznámé chyby jsou označeny kódem GENERAL_ERROR
.
Plánované exporty¶
Plánované exporty nesledují standardní životní cyklus exportu. Namísto toho končí ve stavu scheduled
když jsou vytvořeny.
Existují dva typy plánovaných exportů.
Jednorázové plánované exporty¶
Tyto exporty jsou naplánovány na jeden konkrétní okamžik v budoucnosti. Při vytvoření je budoucí časové razítko uloženo do souboru schedule.json
. Když tento čas nastane, BS-Query vytvoří nový export, který dědí deklaraci plánovaného exportu ALE vynechává položku schedule
. Původní plánovaný export již není potřeba a je odstraněn.
Opakované plánované exporty¶
Tyto exporty obsahují řetězec ve formátu cron v možnosti schedule
deklarace. Tento rozvrh ve formátu cron se používá k výpočtu času dalšího spuštění, když je vytvořen nový export dědící deklaraci plánovaného exportu stejným způsobem jako jednorázové exporty. Plánovaný export není smazán, ale vypočítává nové budoucí časové razítko a cyklus se opakuje.
Varování
Dávejte pozor při řešení problémů s chováním plánovaného exportu. Plánovaný export má vždy alespoň dvě ID. Jedno původního plánovaného exportu a druhé potomka běžícího exportu. Může to být ještě složitější - při úpravě plánovaného exportu je odstraněn a nový export s novým ID je vytvořen. Tímto způsobem má plánovaný export (zobrazený z UI) více ID (jedná se o více exportních objektů v aplikaci BS-Query).
Exports a Knihovna¶
Existují tři typy artefaktů Knihovny, které používá aplikace BS-Query.
DataSources¶
Deklarace datových zdrojů jsou zásadní pro funkčnost BS-Query. Bez datového zdroje nejsou žádné exporty.
Aplikace BS-Query podporuje následující typy deklarací datových zdrojů:
datasource/elasticsearch
datasource/pyppeteer
/DataSources/elasticsearch.yaml
define:
type: datasource/elasticsearch
specification:
index: lmio-{{tenant}}-events*
request:
<key>: <value>
<key>: <value>
query_params:
<key>: <value>
<key>: <value>
define¶
type
: technický název, který pomáhá najít deklaraci datového zdroje v Knihovně.
specification¶
index
: kolekce JSON dokumentů v Elasticsearch. Každý dokument je soubor polí, která obsahují data prezentovaná jako páry klíč-hodnota. Pro podrobnější vysvětlení se podívejte na tento článek.
Existuje také několik dalších položek, které lze konfigurovat v deklaraci DataSource. Jedná se o standardní parametry API Elasticsearch, pomocí kterých můžete doladit šablonu deklarace, abyste určili konkrétní obsah požadovaných dat a/nebo akcí prováděných na nich. Jedním z takových parametrů je size
- počet odpovídajících dokumentů, které mají být vráceny v jednom požadavku.
request¶
Pro více podrobností se podívejte na dokumentaci Elastic.
query_params¶
Pro více podrobností se podívejte na dokumentaci Elastic.
Exports¶
Deklarace exportů specifikují, jak získat data z datového zdroje. YAML soubor obsahuje následující sekce:
define¶
Sekce define obsahuje následující parametry:
name
: Název exportu.datasource
: Název deklarace DataSource v knihovně, uvedený jako absolutní cesta k knihovně.output
: Výstupní formát exportu. Dostupné možnosti jsou "raw", "csv" a "xlsx" pro ES DataSources a "raw" pro Kafka DataSources.header
: Při použití výstupu "csv" nebo "xlsx" musíte specifikovat hlavičku výsledné tabulky jako pole názvů sloupců. Ty se objeví ve stejném pořadí, v jakém jsou uvedeny.schedule
: Existují tři možnosti, jak naplánovat export: - datetime ve formátu "%Y-%m-%d %H:%M" (například 2023-01-01 00:00) - timestamp jako celé číslo (například 1674482460) - cron - pro více informací se podívejte na http://en.wikipedia.org/wiki/Cronschema
: Schéma, ve kterém by měl být export spuštěn.
Schema
Vždy je pro každý tenant konfigurováno jedno schéma (viz sekce Tenants
konfigurace). Deklarace exportu může uvádět schéma, k němuž patří.
Pokud se schéma deklarace exportu neshoduje s konfigurací schématu tenant, export přestane být vykonáván.
target¶
Sekce target obsahuje následující parametry:
type
: Pole typů cílového místa pro export. Možnosti jsou "download", "email" a "jupyter". "download" je vždy vybrán, pokud sekce target chybí.email
: Pro typ cílového místa email musíte specifikovat alespoň poleto
, což je pole e-mailových adres příjemců. Mezi další nepovinná pole patří: -cc
: pole příjemců CC -bcc
: pole příjemců BCC -from
: e-mailová adresa odesílatele (řetězec) -subject
: předmět e-mailu (řetězec) -body
: název souboru (s příponou) uložený ve složce Template knihovny, použitý jako šablona těla e-mailu. Můžete také přidat speciálníparameters
, které mají být použity v šabloně. Jinak použijte libovolné klíčové slovo ze sekce define vašeho exportu jako parametr šablony (pro každý export to je:name
,datasource
,output
, pro specifické exporty můžete také použít parametry:compression
,header
,schedule
,timezone
,tenant
).
query¶
Pole query musí být řetězec.
Tip
Kromě těchto parametrů můžete ve své deklaraci exportu použít klíčová slova specifická pro deklaraci datového zdroje. Pokud dojde ke konfliktům, bude mít přednost deklarace datového zdroje.
schema¶
Můžete přidat částečné schéma, které přepíše běžné schéma nastavené v konfiguraci.
Tato funkce umožňuje převody založené na schématu na exportovaných datech. To zahrnuje:
- Převod z časového razítka na lidsky čitelný formát data, kde schéma specifikuje typ
datetime
- Deidentification
/Exports/example_export.yaml
define:
name: Export e-mail test
datasource: elasticsearch
output: csv
header: ["@timestamp", "event.dataset", "http.response.status_code", "host.hostname", "http.request.method", "url.original"]
target:
type: ["email"]
email:
to:
- john.doe@teskalabs.com
query: >
{
"bool": {
"filter": [{
"prefix": {
"http.version": {
"value": "HTTP/1.1"
}
}
}]
}
}
schema:
fields:
user.name:
deidentification:
method: hash
source.address:
deidentification:
method: ip
Templates¶
Sekce Templates
Knihovny se používá při odesílání Exportů e-mailem. Tělo e-mailu musí být založeno na šabloně. Vložte vlastní šablonu do adresáře Templates/Email
. V těchto souborech můžete použít šablonování jinja. Další informace naleznete v dokumentaci jinja. Všechna klíčová slova z deklarace exportu mohou být použita jako proměnné jinja.
Deidentifikace¶
LogMan.io vám umožňuje exportovat jakákoli data pro vlastní účely, např. pro externí analýzy.
Logy velmi často obsahují citlivé osobní údaje o uživatelích.
Používejte deidentifikaci během exportů, kdykoli poskytujete data třetím stranám.
Deidentifikační algoritmy zachovávají granularitu a jedinečnost dat, což umožňuje analýzu bezpečnostních incidentů bez vystavení osobních informací uživatelů.
Použijte schema k aplikaci deidentifikačních metod na exportovaná data.
Deidentifikační metody¶
hash
-
Používá algoritmus SHA256 k hashování hodnoty.
email
-
Vyhledává emailové adresy pomocí regulárního výrazu
^(.*)@(.*)(\..*)$
(john.doe@company.com) a používá SHA256 k hashování jména a domény zvlášť. Vracínot email
, pokud hodnota neodpovídá regulárnímu výrazu. username
-
Je kombinace metody
hash
aemail
. Aplikuje metodu email, ale vrací hodnotu hash, pokud hodnota neodpovídá regulárnímu výrazu. filepath
-
Hashuje název souboru, ale zachovává příponu. Umožňuje další analýzu na základě typů souborů.
ip
-
Náhodně mění poslední část ipv4 adresy.
drop
-
Zcela vymaže citlivá data z exportu.
Konfigurace BS-Query¶
Běžná konfigurace clusteru¶
Tato konfigurace závisí na dalších clusterových službách a musí odpovídat architektuře clustery.
Umístění Zookeeper serveru v clusteru.
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
Vrstva knihovny.
[library]
providers=zk:///library
Telemetrie.
[asab:metrics]
Datové zdroje¶
Zde jsou některé příkladové konfigurační sekce potřebné pro připojení datového zdroje.
[mongodb]
mongodb_uri=mongodb://mongo-1/?replicaSet=rs0
[elasticsearch]
url=
http://es01:9200
http://es02:9200
http://es03:9200
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
[pyppeteer]
url=http://<example_url>
username=<pyppeteer_username>
password=<pyppeteer_password>
Autorizace¶
[auth]
Specifická konfigurace BS-Query¶
Adresář pro ukládání všech exportů.
[storage]
path=/data/bsquery
Poskytněte URL k ASAB Iris mikroslužbě a výchozí emailovou šablonu nacházející se ve složce /Templates/Email
knihovny.
Limit velikosti souboru je v bytech a výchozí nastavení je 50 MB.
[target:email]
url=http://<example_url>
template=bsquery.md
file_size_limit=52 000 000
Název adresáře sdíleného s Jupyter Notebook. Pro konfiguraci cíle Jupyter, musí Jupyter Notebook a BS-Query sdílet společný adresář v souborovém systému.
[target:juptyer]
path=/data/jupyter
Existuje výchozí limit řádků pro exporty ve formátu Excel o velikosti 50 000 řádků. Buďte si vědomi, že tento limit chrání BS-Query před načítáním příliš velkého množství dat do paměti.
[xlsx]
limit=60000
BS-Query čte vlastní konfiguraci tenanta z ASAB Config. Pokud není konfigurace tenanta k dispozici, používá se tato výchozí konfigurace časového pásma a používaného schématu. Výchozí hodnoty jsou UTC a ECS Schema. Vypršení říká, za kolik dní je dokončený export smazán. Výchozí hodnota je 30 dní.
[default]
schema=/Schemas/ECS.yaml
timezone=UTC
expiration=30
Poskytněte tajný klíč a vypršení odkazu pro stažení v sekundách. Klíč je náhodný řetězec. Udržte vypršení co nejkratší. Doporučuje se výchozí nastavení vypršení.
[download]
secret_key=<custom_secret_key>
expiration=5
Řešení problémů¶
Řešení nejčastěji se vyskytujících problémů:
Speciální znaky v exportním souboru jsou zkreslené / nesprávné¶
Exportní soubory jsou kódovány jako UTF-8
.
Pokud vaše nástroje takové soubory ve výchozím nastavení správně nezpracovávají, je třeba upravit jejich nastavení.
Možná řešení:
-
Nastavte svou Excel aplikaci, aby správně otevírala UTF-8 CSV soubory.
-
Zkontrolujte nastavení kódování vašeho systému (například Windows-1250), abyste našli vhodný konverzní nástroj.
Reporty
ASAB Pyppeteer¶
Microservice ASAB Pyppeteer usnadňuje tvorbu naplánovaných reportů.
ASAB Pyppeteer provozuje bezhlavý prohlížeč Chromium, který může otevírat a generovat reporty. Umožňuje vám využít funkci plánování Exportů k definování, kdy bude report vytvořen a odeslán e-mailem.
Je důležité poznamenat, že každý uživatel může mít různé úrovně přístupu k různým sekcím LogMan.io, včetně reportů. Důsledkem toho musí být naplánované reporty ověřeny a povoleny stejným způsobem jako původní plánovací akce. Pro informace o nastavení autorizace pokračujte do sekce autentizace.
Autorizace plánovaných reportů¶
Plánovaný report obsahuje informace o jeho autorovi. Když nastane čas pro tisk a odeslání reportu, mikroslužba ASAB Pyppeteer zastupuje autora, což zajišťuje, že report je vytvořen z perspektivy a na úrovni přístupu konkrétního uživatele.
Pro správnou konfiguraci BS-Query (Exporty), SeaCat Auth a ASAB Pyppeteer tak, aby umožňovaly kompletní komunikaci mezi službami, postupujte podle těchto kroků:
1. Konfigurace ASAB Pyppeteer¶
Ujistěte se, že instance ASAB Pyppeteer může přistupovat k SeaCat Auth.
[seacat_auth]
url=http://localhost:3081
2. Konfigurace SeaCat Auth¶
Ujistěte se, že konfigurace SeaCat Auth umožňuje vytváření strojových pověření.
[seacatauth:credentials:m2m:machine]
mongodb_uri=mongodb://localhost:27017
mongodb_database=auth
3. Vytvoření pověření pro ASAB Pyppeteer¶
Odkazujte se na uživatelský manuál pro instrukce, jak vytvářet a přiřazovat pověření, zdroje, role a tenancy.
Nejprve vytvořte zdroj authz:impersonate
a globální roli s tímto zdrojem (pojmenovanou např. "impersonator").
Poté vytvořte nová pověření machine
s <pyppeteer_username>
a <pyppeteer_password>
a přiřaďte jim roli "impersonator" a relevantní tenanty.
4. Zadejte pověření pyppeteer do konfigurace BS-Query¶
[pyppeteer]
url=http://localhost:8895
username=<pyppeteer_username>
password=<pyppeteer_password>
Upozornění
Dávejte pozor, že ASAB Pyppeteer nemůže zastupovat superuživatele. Proto uživatel s rolí superuživatele nemůže vytvářet plánované reporty, pokud mu není explicitně přidělena role se zdrojem bitswan:report:access
.
Konfigurace
Branding¶
Zákaznicky specifikovaný branding může být nastaven v aplikaci LogMan.io WebUI.
Statický branding¶
Příklad:
let ConfigDefaults = {
title: "Název aplikace",
brand_image: {
full: "media/logo/header-full.svg",
minimized: "media/logo/header-minimized.svg",
}
};
Dynamický branding¶
Branding lze nakonfigurovat pomocí dynamického nastavení.
Dynamická konfigurace je injektována pomocí ngx_http_sub_module
, jelikož nahrazuje předdefinovaný obsah souboru index.html
(v našem případě).
Více o ngx_http_sub_module
Existují 3 možnosti pro dynamický branding - logo v záhlaví, název a vlastní CSS styly.
Logo v záhlaví¶
Pro nahrazení výchozího loga v záhlaví musí nginx sub_filter
konfigurace dodržovat pravidla nahrazení <meta name="header-logo-full">
a <meta name="header-logo-minimized">
s konkrétním name
. Nahrazení musí mít vlastnost content
, jinak obsah nahrazení nebude propagován. content
musí obsahovat řetězec s cestou k logu.
Velikost obrázků pro branding lze nalézt zde
Full¶
Příklad importu loga v plné velikosti (když není postranní panel aplikace sbalený)
sub_filter '<meta name="header-logo-full">' '<meta name="header-logo-full" content="/<location>/<path>/<to>/<custom_branding>/<logo-full>.svg">';
Minimalizované¶
Příklad importu loga v minimalizované velikosti (když je postranní panel aplikace sbalený)
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 musí dodržovat pravidla nahrazení <meta name="title">
s konkrétním name
. Nahrazení musí mít vlastnost content
, jinak obsah nahrazení nebude propagován. content
musí obsahovat řetězec s názvem aplikace.
sub_filter '<meta name="title">' '<meta name="title" content="Vlastní název aplikace">';
Vlastní CSS styly¶
Příklad importu vlastních CSS stylů, konfigurace musí dodržovat pravidla nahrazení <meta name="custom-css-file">
s konkrétním name
. Nahrazení musí mít vlastnost content
, jinak obsah nahrazení nebude 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 CSS souboru¶
.card .card-header-login .card-header-title h2 {
color: violet !important;
}
.text-primary {
color: yellowgreen !important;
}
Definujte cestu nginx k obsahu dynamického brandingu¶
Aby bylo možné určit umístění dynamického (vlastního) obsahu brandingu, musí být definováno 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>;
}
Kompletní příklad¶
Kompletní příklad konfigurace nginxu s vlastním brandingem
...
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="Vlastní název aplikace">';
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 styly¶
Každý obrázek MUSÍ být poskytován ve formátu SVG (vektorizovaný). Použití pixelových formátů (PNG, JPG, ...) je silně odrazováno. Při tvorbě obrázků pro branding používejte celou šířku/výšku plátna (poměr 3:1 na plnou verzi a 1:1 na minimalizovanou verzi). Pro optimální zobrazení není vyžadováno žádné odsazení.
Obrázky pro branding¶
formát: SVG
Plné:
* vykreslený poměr: 3:1
* vykreslená velikost: 150x50 px
Minimalizované:
* vykreslený poměr: 1:1
* vykreslená velikost: 50x50 px
Branding je umístěn v levém horním
rohu na velkých obrazovkách. Plný
obrázek brandingu je použit, když není postranní panel sbalený a je nahrazen minimalizovanou
verzí při sbalení. Na menších obrazovkách (<768px) branding v postranním panelu zmizí a objeví se pouze plný obrázek brandingu ve středové horní
části stránky.
Logo by mělo být vhodné pro použití v obou režimech - světlém i tmavém.
Logo postranního panelu je vždy umístěno ve spodní
části postranního panelu. Minimalizovaná verze se objeví při sbalení postranního panelu.
Plné:
* vykreslená velikost: 90x30 px
Minimalizované:
* vykreslená velikost: 30x30 px
Poznámka: Plný obrázek je také používán na úvodní obrazovce, 30% šířky obrazovky.
Předávání vlastností konfigurace do aplikace:
```javascript
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'
});
Při používání DiscoverContainer
jako komponenty v kontejneru mohou být vlastnosti předány následujícím způsobem:
<DiscoverContainer type="https://my-project-url/discover/Discover-config.json" />
Statický konfigurační soubor aplikace zůstává prázdný:
module.exports = {
app: {
},
webpackDevServer: {
port: 3000,
proxy: {
'/api/elasticsearch': {
target: "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¶
WebUI LogMan.io poskytuje možnost přizpůsobení jazykových lokalizací. Používá knihovnu pro internalizaci i18n
. Pro podrobnosti se podívejte na: https://react.i18next.com
Import a nastavení vlastní lokalizace¶
WebUI LogMan.io umožňuje předefinovat texty aplikačních komponent a zpráv pro každou sekci aplikace. Jazykové lokalizace jsou uloženy v JSON souborech nazvaných translate.json
.
Vlastní lokalizace mohou být nahrány do aplikace WebUI LogMan.io prostřednictvím konfiguračního souboru.
Soubory jsou nahrávány například z externí složky obsluhované nginx
, kde mohou být uloženy vedle CSS stylování a další konfigurace webu.
Příklad definice ve statickém konfiguračním souboru WebUI LogMan.io:
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 náhradní jazyk
* supportedLngs
jsou podporované jazyky
* debug
pokud je nastaveno na true, zobrazuje ladicí zprávy v konzoli prohlížeče
* backend
je backend plugin pro načítání zdrojů ze serveru
Cesta path/to/external_folder/
je cesta k externí složce s lokální složkou locales
, kterou zpracovává nginx
. Tam musejí být dvě složky odkazující na podporované jazyky. Tyto složky jsou en
a cs
, ve kterých jsou uloženy soubory translate.json
, jak lze vidět v níže uvedené struktuře složek:
* external_folder
* locales
* cs
* translation.json
* en
* translation.json
Příklad vlastního souboru translate.json¶
en
{
"i18n": {
"language": {
"en": "English",
"cs": "Česky"
}
},
"LogConsole": {
"Connection lost": "Connection lost, will reconnect ...",
"Mark": "Mark",
"Clear": "Clear"
},
...
}
cs
{
"i18n": {
"language": {
"en": "English",
"cs": "Česky"
}
},
"LogConsole": {
"Connection lost": "Spojení ztraceno, připojuji se ...",
"Mark": "Označit",
"Clear": "Smazat"
},
...
}
Dashboardy
Configuration overview
### Widgety
Příklad widgetu v konfiguračním souboru:
"Dashboard:widget:somewidget": {
"datasource": "Dashboard:datasource:elastic",
"type": "Value",
"field": "some.variable",
"title": "Nějaký název",
"layout:w": 2,
"layout:h": 1,
"layout:x": 0,
"layout:y": 1
},
...
} ```
Widget s hodnotou¶
Běžně se používá k zobrazení jedné hodnoty, i když může také zobrazit datetime a filtrovaný widget hodnoty najednou. ``` { ...
"Dashboard:widget:valuewidget": {
// Základní nastavení
"datasource": "Dashboard:datasource:elastic",
"type": "Value", // Typ widgetu
"field": "some.variable", // Pole (hodnota) zobrazené ve widgetu
"title": "Nějaký název", // Název widgetu
// Pokročilé nastavení (volitelné)
"onlyDateResult": true, // Zobrazit pouze datum s časem
"units": "GB", // Jednotky hodnoty pole
"displayWidgetDateTime": true, // Zobrazit datum a čas ve widgetu pod hodnotou
"hint": "Nějaká nápověda", // Zobrazit nápovědu widgetu
// Zlidnění hodnoty (může být použito k transformaci hodnot do čitelné formy pro člověka, např. bajty na GB) (volitelné)
"humanize": true, // Povolit komponentu Humanize
"base": 1024, // Základ pro přepočet hodnoty pro komponentu Humanize
"decimals": 3, // Zaokrouhlit hodnotu na n číslic v komponentě Humanize
"displayUnits": true, // Zobrazit prefix jednotky velikosti (např. k, M, T,...) v komponentě Humanize
// Nastavení rozvržení
"layout:w": 2,
"layout:h": 1,
"layout:x": 0,
"layout:y": 1
},
...
} ```
Widget s vícero hodnotami¶
Používá se 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": "Nějaký název", // Název widgetu
// Pokročilé nastavení (volitelné)
"units": "GB", // Jednotky hodnot polí
"displayWidgetDateTime": true, // Zobrazit datum a čas ve widgetu pod hodnotou
"hint": "Nějaká nápověda", // Zobrazit nápovědu widgetu
// Zlidnění hodnoty (může být použito k transformaci hodnot do čitelné formy pro člověka, např. bajty na GB) (volitelné)
"humanize": true, // Povolit komponentu Humanize
"base": 1024, // Základ pro přepočet hodnoty pro komponentu Humanize
"decimals": 3, // Zaokrouhlit hodnotu na n číslic v komponentě Humanize
"displayUnits": true, // Zobrazit prefix jednotky velikosti (např. k, M, T,...) v komponentě Humanize
// Nastavení rozvržení
"layout:w": 2,
"layout:h": 1,
"layout:x": 0,
"layout:y": 1
},
...
} ```
Widget indikátoru stavu¶
Používá se k zobrazení hodnoty a barvy stavu na základě překročení / nedosažení limitních hodnot. Jeho jádro je podobné widgetu hodnoty. Existují 2 typy nastavení - jedno je pro zobrazení barev na základě rozsahu čísel, druhé je založeno 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": "Nějaký název", // Název widgetu
"lowerBound": 4000, // Dolní limit
"upperBound": 5000, // Horní limit
// Pokročilé nastavení (volitelné)
"lowerBoundColor": "#a9f75f", // Barva dolního limitu
"betweenBoundColor": "#ffc433", // Barva mezi limity
"upperBoundColor": "#C70039 ", // Barva horního limitu
"nodataBoundColor": "#cfcfcf", // Barva bez dat
"units": "GB", // Jednotky hodnoty pole
"displayWidgetDateTime": true, // Zobrazit datum a čas ve widgetu pod hodnotou
"hint": "Nějaká nápověda", // Zobrazit nápovědu widgetu
// Nastavení rozvržení
"layout:w": 2,
"layout:h": 1,
"layout:x": 0,
"layout:y": 1
},
...
} ```
Tabulkový widget¶
Používá se 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é ukazuje položky zobrazené v záhlaví tabulky
"title": "Nějaký název", // Název widgetu
// Pokročilé nastavení (volitelné)
"dataPerPage": 5, // Počet dat na stránku
"disablePagination": true, // Zakázat stránkování
"units": "GB", // Jednotky hodnoty pole
"hint": "Nějaká nápověda", // Zobrazit nápovědu widgetu
// Nastavení rozvržení
"layout:w": 3,
"layout:h": 3,
"layout:x": 0,
"layout:y": 1
},
...
} ```
Widget nástrojů¶
Je podobný modulu Nástroje ASAB WebUI, ale transformovaný na widget pro použití v dashboardu. ``` { ...
"Dashboard:widget:toolswidget": {
// Základní nastavení
"type": "Tools", // Typ widgetu
"title": "BitSwan", // Název widgetu
"redirectUrl": "http://www.teskalabs.com", // URL pro přesměrování
"image": "tools/bitswan.svg", // Umístění obrázku Nástrojů (může být také base64 obrázkový řetězec místo cesty k umístění)
// Nastavení rozvržení
"layout:w": 1,
"layout:h": 1,
"layout:x": 0,
"layout:y": 0
},
...
} ```
Markdown widget¶
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 dashboardu pro širší vysvětlení.
Pro úpravy musí mít uživatel alespoň prostředek dashboards:admin
.
```
{
...
"Dashboard:widget:mdwidget": {
// Základní nastavení
"type": "Markdown", // Typ widgetu
"title": "Nějaký název", // Název widgetu
// Pokročilé nastavení (volitelné)
"description": "Nějaký popis", // Zobrazit popis v markdown
"hint": "Nějaká nápověda", // Zobrazit nápovědu widgetu
// Nastavení rozvržení
"layout:w": 2,
"layout:h": 1,
"layout:x": 0,
"layout:y": 1
},
...
} ```
Widgety grafů¶
Používají se k zobrazení hodnot ve formě grafu. Pro více informací o použité knihovně grafů, prosím, následujte tento odkaz
Přesměrování na obrazovku Objevit¶
Widgety PieChart a BarChart nabízejí možnost přesměrování na obrazovku Objevit jako výchozí.
Tato funkce filtruje na vybranou hodnotu v grafu a přesměrovává na obrazovku Objevit. Je dostupná pouze pro seskupená data (nastavení groupBy
v nastavení datasource). Může být zakázána nastavením "disableRedirection": true
ve widgetu.
Když se používá více konfigurací v Objevit, lze ve widgetu specifikovat název konfigurace, který bude použit při přesměrování pro filtrování na správnou konfiguraci. Pokud se v jedné aplikaci používá více konfigurací Objevit, doporučuje se specifikovat názvy konfigurací v rámci widgetů, aby se předešlo přesměrování na nesprávné konfigurace a datasourcy v Objevit. Lze to nastavit pomocí vlastnosti widgetu "configName": "<discover-config-name>"
>>> kde <discover-config-name>
je název souboru konfigurace Objevit bez přípony, např. some-config.json
>>> "configName": "some-config"
.
Poznámka: Přesměrování odstraní všechny předtím filtrované položky a upraví časový rozsah uložený v místním úložišti pro obrazovku Objevit podle vybraného v grafu dashboardu.
Barvy widgetu grafu¶
Všechny grafy nabízejí možnost být zobrazeny s jedním z předdefinovaných barevných schémat.
Barevné spektrum se liší na základě typu grafu.
Pokud není specifikována žádná nebo špatná barva, použije se default
barevné spektrum.
Barva je specifikována proměnnou color
v nastavení widgetu:
"Dashboard:widget:barchartwidget": {
"datasource": "Dashboard:datasource:elastic",
"type": "BarChart",
"title": "Nějaký název",
...
"color": "sunset",
...
},
- PieChart
- pro gradientní barevné spektrum - sunset
, secondary
, safe
, warning
, danger
, default
- pro smíšené barevné spektrum -
cold
, rainbow
, default
- BarChart a ostatní
- jednofarebné spektrum -
sunset
, safe
, warning
, danger
, default
Widget BarChart¶
``` { ...
"Dashboard:widget:barchartwidget": {
// Základní nastavení
"datasource": "Dashboard:datasource:elastic",
"type": "BarChart", // Typ widgetu
"title": "Nějaký název", // Název widgetu
"xaxis": "@timestamp", // Hodnoty zobrazené na ose x
"yaxis": "request.bytes", // Hodnoty zobrazené na ose y
// Pokročilé nastavení (volitelné)
"table": true, // Umožňuje zobrazit tabulku místo grafu (po kliknutí na tlačítko)
"xlabel": "časová značka", // popis osy x, výchozí je datetime
"ylabel": "bajty", // popis osy y
"xaxisUnit": "ts", // jednotky osy x
"yaxisUnit": "byte", // jednotky osy y
"xaxisDomain": ['auto', 'auto'], // Rozsah zobrazení na ose x (výchozí [0, 'auto'])
"yaxisDomain": ['auto', 'auto'], // Rozsah zobrazení na ose y (výchozí [0, 'auto'])
"horizontal": true, // Umožňuje zobrazení grafu horizontálně
"width": "50%", // Šířka grafu ve widgetu
"height": "50%", // Výška grafu ve widgetu
"convertBy": 1000, // Hodnoty grafu budou děleny tímto číslem. Slouží k přepočtu dat na např. MHz, GB atd.
"hint": "Nějaká nápověda", // Zobrazit nápovědu widgetu
"disableRedirection": true, // Zakázat přesměrování na obrazovku Objevit (pouze pro BarChart)
"configName": "config-name", // Název konkrétní konfigurace Objevit (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 zobrazit agregaci v grafu, je třeba ji nastavit v nastavení zdroje dat:
{
...
"Dashboard:datasource:elastic": {
// Základní nastavení
"type": "elasticsearch",
"datetimeField": "@timestamp",
"specification": "es-pattern*",
"aggregateResult": true // Pouze pro grafy - bude žádat ES o agregované hodnoty (volitelné)
},
...
} ```
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
**Skupinový graf**
Nastavení zdroje dat:
"Dashboard:datasource:elastic-stacked": {
// Základní nastavení
"type": "elasticsearch",
"datetimeField": "@timestamp",
"specification": "pattern*",
"groupBy": [
"sender.address",
"recipient.address"
],
"size": 100, // Definujte maximální velikost skupiny (výchozí je top 20)
"stackSize": 100 // Definujte maximální velikost stohovaných událostí (výchozí je top 50)
// Pokročilé nastavení
"matchPhrase": "event.dataset
Příklad konfigurace dashboardu¶
Příklad:
{
"Dashboard:datasource:elastic": {
"type": "elasticsearch",
"datetimeField": "@timestamp",
"specification": "default-events*"
},
"Dashboard:datasource:elastic-aggregation": {
"type": "elasticsearch",
"datetimeField": "@timestamp",
"specification": "default-events*",
"aggregateResult": true
},
"Dashboard:datasource:elastic-size100": {
"type": "elasticsearch",
"datetimeField": "@timestamp",
"specification": "default-events*",
"size": 100
},
"Dashboard:datasource:elastic-stacked": {
"type": "elasticsearch",
"datetimeField": "@timestamp",
"specification": "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": "Tabulka",
"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": "Poslední spuštění",
"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": "Pouze datum",
"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": "Agregace bajtů těla požadavku",
"type": "BarChart",
"xaxis": "@timestamp",
"yaxis": "http.request.body.bytes",
"yaxisDomain": [
"auto",
0
],
"ylabel": "bajty",
"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": "Bajty těla požadavku",
"type": "BarChart",
"hint": "Nějaká nápověda",
"width": "95%",
"xaxis": "@timestamp",
"yaxis": "http.request.body.bytes",
"ylabel": "bajty",
"layout:w": 6,
"layout:h": 3,
"layout:x": 6,
"layout:y": 6
},
"Dashboard:widget:scatterchart": {
"datasource": "Dashboard:datasource:elastic-size100",
"title": "Rozptýlený graf bajtů těla požadavku velikost 100",
"type": "ScatterChart",
"xaxis": "@timestamp",
"xlabel": "datum a čas",
"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": "Agregace rozptýlených bajtů těla požadavku",
"type": "ScatterChart",
"xaxis": "@timestamp",
"yaxis": "http.request.body.bytes",
"xlabel": "datum a čas",
"ylabel": "počet",
"layout:w": 6,
"layout:h": 3,
"layout:x": 0,
"layout:y": 0
},
"Dashboard:widget:areachart": {
"datasource": "Dashboard:datasource:elastic",
"height": "100%",
"title": "Oblast bajtů těla požadavku",
"type": "AreaChart",
"width": "95%",
"xaxis": "@timestamp",
"yaxis": "http.request.body.bytes",
"ylabel": "oblast bajtů",
"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": "Agregace oblasti bajtů těla požadavku",
"type": "AreaChart",
"xaxis": "@timestamp",
"xlabel": "datum a čas",
"yaxis": "http.request.body.bytes",
"ylabel": "počet",
"layout:w": 6,
"layout:h": 3,
"layout:x": 0,
"layout:y": 3
},
"Dashboard:widget:multiplevalwidget": {
"datasource": "Dashboard:datasource:elastic",
"type": "MultipleValue",
"title": "Více hodnot",
"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": "Překročení bajtů",
"field": "http.request.body.bytes",
"units": "bajty",
"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\ntitle A Gantt 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",
"layout:w": 12,
"layout:h": 2,
"layout:x": 0,
"layout:y": 13
},
"Dashboard:widget:markdown": {
"title": "Markdown popis",
"type": "Markdown",
"description": "## Markdown obsah",
"layout:w": 12,
"layout:h": 2,
"layout:x": 0,
"layout:y": 15
},
"Dashboard:widget:barchart-stacked": {
"datasource": "Dashboard:datasource:elastic-stacked",
"title": "Skupinová adresa odesílatele X příjemce",
"type": "StackedBarChart",
"xlabel": "Odesílatel x Příjemce",
"ylabel": "Počet",
"layout:w": 12,
"layout:h": 4,
"layout:x": 0,
"layout:y": 17
}
}
Office 365 přehledový panel¶
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": "Klient 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": "Uživatelská ID",
"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": "Aktivity 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": "Akce",
"type": "BarChart",
"table": true,
"xaxis": "event.action",
"xlabel": "Akce",
"ylabel": "Počet",
"layout:w": 6,
"layout:h": 4,
"layout:x": 0,
"layout:y": 4
}
}
Katalog widgetů¶
Podrobnější pohled na nastavení widgetů.
Pro nastavení Dashboardu a widgetů naleznete informace zde.
Hodnotové widgety¶
Použití hodnotových widgetů je vhodné, když je potřeba zobrazit data v textové formě.
Widget jedné hodnoty¶
Slouží k zobrazení pouze jedné hodnoty.
Hodnota může být typu: string
, boolean
, number
.
Jedna hodnota může zobrazovat pouze datum (převést např. unix timestamp na lidsky čitelné datum), pokud je to potřeba.
Widget více hodnot¶
Slouží k zobrazení n
hodnot v jednom widgetu.
Kromě zobrazení n
hodnot v jednom widgetu obsahuje widget více hodnot stejné funkce jako widget jedné hodnoty.
Hodnoty mohou být typu: string
, boolean
, number
.
Widget indikátoru stavu¶
Widget indikátoru stavu zobrazuje číselnou hodnotu a barevnou indikaci na základě definovaných hranic.
Hodnota může být typu: number
.
Tabulkový widget¶
Tabulkový widget může zobrazovat více hodnot v tabulkové formě.
Hodnoty mohou být typu: string
, boolean
, number
.
Tool widgety¶
Tool widgety slouží jako "tlačítko", které po kliknutí otevře novou kartu v prohlížeči s odkazem (URL adresou) specifikovaným v konfiguraci widgetu. Obrázky pro tool widget mohou být nahrané přímo do složky public
aplikace nebo načtené jako base64
řetězec obrázku.
Grafické widgety¶
Použití grafických widgetů je vhodné, když je potřeba zobrazit data v grafické formě.
Recharts je použita jako knihovna pro vykreslování dat ve formě grafu.
Widget sloupcového grafu¶
Widget sloupcového grafu má 4 typy zobrazení dat:
Widget sloupcového grafu s ukázkovými daty¶
Zobrazení dat na základě určitého klíče
na časové ose.
Widget sloupcového grafu s agregovanými daty¶
Zobrazení počtu dat na základě určitého klíče
na časové ose.
Widget sloupcového grafu s seskupenými daty¶
Zobrazení dat na základě klíče
podle celkového počtu.
Widget sloupcového grafu s tabulkou dat¶
Zobrazení dat grafu v tabulce. Tuto funkci lze povolit v nastavení grafu a aktivujte ji kliknutím na tlačítko v pravém horním rohu widgetu.
Widget plošného grafu¶
Obsahuje stejné funkce jako widget sloupcového grafu, ale zobrazuje data ve formě plochy.
Widget bodového grafu¶
Obsahuje stejné funkce jako widget sloupcového grafu, ale zobrazuje data ve formě bodů.
Widget výsečového grafu¶
Widget výsečového grafu zobrazuje pouze seskupená data ve formě výsečového grafu a tabulky.
Widget výsečového grafu s gradientními barvami¶
V tomto příkladu se nástroj zobrazí pro zobrazení podrobných informací o konkrétní části (nástroj není zobrazen na tomto obrázku).
Widget výsečového grafu s více barvami¶
V tomto příkladu je nástroj nahrazen indikací aktivní části v levém horním rohu widgetu.
Widget blokového schématu¶
Mermaid je použitá jako knihovna pro vykreslování blokových schémat.
Mermaid playground lze najít zde.
Maestro
ASAB Maestro¶
ASAB Maestro je technologie pro správu clusteru.
Je zodpovědná za:
- Instalaci a aktualizaci TeskaLabs LogMan.io
- Správu služeb clusteru
- Monitorování clusteru
ASAB Maestro byl vyvinut k překonání výzev spojených s pracně intenzivní ruční konfigurací clusterů.
Přináší několik výhod:
- Rychlá instalace TeskaLabs LogMan.io
- Snížení lidských chyb
- Konzistence napříč všemi nasazovacími místy
- Monitorování všech vrstev - hardware, kontejnerizace, aplikace
- Snadné aktualizace TeskaLabs LogMan.io
Přehled funkčnosti ASAB Maestro¶
Automatizace¶
TeskaLabs LogMan.io a naše další aplikace jsou obvykle nasazovány on-premises do zákaznických prostředí, označovaných jako míst. ASAB Maestro zajišťuje konzistentní a rychlé nasazování napříč více místy díky rozsáhlé automatizaci. Podpůrné týmy mohou obsluhovat více zákazníků za použití méně zdrojů, protože automatizace je činí vysoce efektivními a všechna místa mají jednotné nastavení.
Systém zaručuje konzistentní konfigurace napříč všemi aplikacemi, technologiemi clusteru (jako Apache Kafka a Elasticsearch) a API bránou (NGINX). ASAB Maestro také zjednodušuje nasazování webových aplikací do clusteru a spravuje nasazování obsahu, jako jsou databázová schémata, počáteční plnění dat a další.
Správa clusteru¶
Správa služeb clusteru je prováděna z TeskaLabs LogMan.io Web UI.
ASAB Maestro vynucuje globální verzi, což představuje komprehenzivní verzi vydání, která určuje verze všech nasazených komponent a potvrzuje jejich kompatibilitu. Výsledkem je snadný postup aktualizace, když je vydána nová verze produktu.
Monitorování¶
ASAB Maestro zahrnuje také centralizované monitorování clusteru. Toto monitorování zahrnuje logování a telemetrii ze všech komponent, které běží v clusteru.
Hlavní komponenty ASAB Maestro¶
Diagram: Příklad 5 uzlového clusteru spravovaného ASAB Maestro.
Kontejnerizace¶
Pod povrchem, ASAB Maestro využívá Docker a konkrétně Docker Compose k správě kontejnerů. Alternativně je kompatibilní i s Podman, což poskytuje další flexibilitu a bezpečnost.
ASAB Maestro jde nad rámec schopností Docker Compose bez složitostí a režijních nákladů, které mohou přicházet se systémy jako Kubernetes.
ASAB Remote Control¶
ASAB Remote Control (asab-remote-control
) je mikroslužba, která je zodpovědná za centrální správu clusteru. Musí běžet alespoň v jedné instanci v clusteru. Doporučené nastavení jsou tři instance, vedle každé instance ZooKeeper.
ASAB Governator¶
ASAB Governator (asab-governator
) je mikroslužba, která lokálně interaguje s Docker technologií. ASAB Governator musí běžet na každém uzlu clusteru. ASAB Governator se připojuje k ASAB Remote Control.
Knihovna ASAB Maestro¶
Knihovna ASAB Maestro je open-source repozitář spravovaný TeskaLabs s popisem mikroslužeb, které mohou být spuštěny v clusteru. Knihovna se nachází na github.com/TeskaLabs/asab-maestro-library.
Poznámka: Další knihovny mohou být přidány na vrch ASAB Maestro Knihovny pro rozšíření sady spravovaných mikroslužeb v clusteru.
Terminologie¶
Cluster¶
Cluster je množina počítačových uzlů, které spolupracují za účelem dosažení vysoké dostupnosti a odolnosti proti chybám, fungující jako jediný systém. Uzly v clusteru mohou hostovat služby a zdroje, které jsou mezi nimi rozděleny. Klustrování je běžný přístup používaný k zlepšení výkonu, dostupnosti a škálovatelnosti softwarových aplikací a služeb.
Clustery mohou být geograficky rozmístěny napříč různými datovými centry, cloudovými poskytovateli, regiony nebo dokonce kontinenty. Toto geografické rozložení pomáhá snížit latenci, zvýšit redundantnost a zajistit lokalitu dat pro zlepšenou výkonnost aplikací a uživatelské zkušenosti.
Jednotlivý cluster se nazývá lokalita (site) a je identifikován pomocí site_id
.
Node¶
Node slouží jako základní stavební jednotka clusteru, představující buď fyzický nebo virtuální stroj (server), který běží na Linuxu a podporuje konteinerizaci pomocí Dockeru nebo Podmanu.
Každému uzlu v clusteru je přiřazen jedinečný identifikátor, node_id
. Tento node_id
nejen rozlišuje každý uzel, ale také slouží jako název hostitele (hostname) uzlu, což usnadňuje síťovou komunikaci a správu uzlu v rámci clusteru.
Uzel je spravován mikroslužbou ASAB Governator.
Tip
node_id
se vždy překládá na IP adresu uzlu v každém místě clusteru.
Core node¶
Core node přispívá k sdílenému konsenzu clusteru. Tento konsenzus je zásadní pro udržení integrity, konzistence a synchronizace dat a operací napříč clusterem.
Core node jsou klíčové pro dosažení konsenzu, což je proces, který zajišťuje, že všechny uzly v clusteru se shodují na stavu dat a pořadí transakcí. Tato dohoda je zásadní pro Data Integrity, Pořadí Transakcí a Odolnost proti Chybám.
Obvykle jsou první tři uzly přidané do clusteru označeny jako core uzly. Tento počet je zvolen pro dosažení rovnováhy mezi potřebou redundantnosti a snahou vyhnout se režii spojené s koordinací velkého počtu uzlů. S třemi core uzly může systém tolerovat selhání jednoho uzlu a stále dosáhnout konsenzu.
Warning
Větším nasazením musí být počet core uzlů konfigurován jako lichý počet, například 5, 7, 9 a tak dále, aby se zabránilo split-brain scénářům a zajistilo se dosažení většiny pro konsenzus.
Peripheral node¶
Peripheral node, na rozdíl od core uzlu, se nepodílí na tvorbě sdíleného konsenzu clusteru. Jeho hlavní funkcí je poskytování služeb dat, provádění výpočtů, hostování služeb nebo jiné doplňkové role, které rozšiřují schopnosti a kapacitu clusteru.
Přestože periferní uzly nepřispívají k tvorbě konsenzu clusteru, udržují si symbiotický vztah s core uzly.
Service¶
Služba (Service) je sbírka mikroslužeb, které poskytují funkčnost napříč celým clusterem. Příkladem je ASAB Library, Zookeeper, Apache Kafka, Elasticsearch a další.
Každá služba má v rámci clusteru svůj jedinečný identifikátor, nazývaný service_id
.
Instance¶
Instance představuje jednotlivý kontejner, který běží danou službu. Pokud je služba naplánována na běh na více uzlech clusteru, každá běžící entita je instance dané služby.
Každá instance má v rámci clusteru svůj jedinečný identifikátor, nazývaný instance_id
. Každá instance má také své číslo, nazývané instance_no
. Každá instance je také označena příslušnými service_id
a node_id
.
Tip
instance_no
může být také řetězec!
Sherpa¶
Sherpa je pomocný kontejner spuštěný vedle instancí některých specifických služeb. Běží pouze krátkou dobu, dokud není úloha sherpa dokončena.
Typickým použitím pro sherpa je počáteční nastavení databáze.
Model¶
Model představuje chtěné uspořádání clusteru.
Je to jeden nebo více YAML souborů uložených v Knihovně (Library).
ASAB Maestro spravuje cluster aplikací modelu. Všechny služby uvedené v modelu jsou spuštěny nebo aktualizovány službami ASAB Remote Control a ASAB Governator.
Název souboru modelu model.yaml
je určen k úpravám. Další soubory jsou vytvářeny automaticky prostřednictvím dalších komponent LogMan.io.
Descriptor¶
Deskriptor je YAML soubor žijící v Knihovně (Library), který určuje, jak by měla být služba, přesněji instance služby, vytvořena a spuštěna.
Application¶
Aplikace je sada deskriptorů a jejich verzí na úrovni clusteru.
Global Version¶
Každá Aplikace může mít více globálních verzí. Každá verze je specifikována ve verzi souboru uloženého v Knihovně, která ukládá verze pro každou službu aplikace.
Tech / Technology¶
Tech znamená technologii. Technologie je specifický typ služby (tj. NGINX, Mongo), která poskytuje nějaké zdroje ostatním službám.
Jak začít
Ve výstavbě
Instalace simulátoru logů¶
Pro instalaci simulátoru logů budete potřebovat běžící TeskaLabs LogMan.io instalaci.
Simulátor logů je součástí LogMan.io Collector. Výchozí konfigurace LogMan.io Collector vám poskytuje simulované logy technologií Microsoft 365, Microsoft Windows Events a ukázkové logy Linuxu ve formátu RFC 3164.
Vytvoření tenant¶
Vytvořte tenant, ve kterém chcete simulovat logy.
- Vytvořte nový tenant v UI (Auth&Roles > Tenants > New tenant)
- Přiřaďte svá pověření novému tenantu
- Přejděte na Maintenance > Configuration a vytvořte novou konfiguraci ve složce
Tenants
s názvem vašeho tenantu. V nové konfiguraci vyberte ECS schema a vaše časové pásmo - Odhlaste se a znovu přihlaste do nového tenantu
Přidejte knihovnu se simulovanými zdroji logů¶
V UI přejděte na Maintenance > Configuration
Přidejte další vrstvu Knihovny.
libsreg+https://libsreg.z6.web.core.windows.net/lmio-collector-library
Přidejte collectorskou službu do modelu¶
Přidejte službu lmio-collector
do sekce services
souboru model.yaml
.
services:
...
lmio-collector:
- <node_id>
Aplikujte změny!
curl -X 'POST' 'http://<node_id>:8891/node/<node_id>' -H 'Content-Type: application/json' -d '{"command": "up"}'
V webovém UI přejděte na obrazovku Collectors a proveďte provision nového collectoru.
Vytvořte event lane a spusťte parsování¶
Jednoduše použijte Event Lane Manager:
curl -X 'PUT' 'http://<node_id>:8954/create-eventlane' -H 'Content-Type: application/json' -d '{"tenant": "<your tenant>", "stream": "microsoft-365-mirage", "node_id": "<node_id>" }'
Bootstrap ASAB Maestro¶
Bootstrap je proces nasazení ASAB Maestro na nový cluster node.
Bootstrap pomocí Dockeru¶
$ docker run -it --rm --pull always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /opt/site:/opt/site \
-v /opt/site/docker/conf:/root/.docker/ \
-v /data:/data \
-e NODE_ID=`hostname -s` \
--network=host \
pcr.teskalabs.com/asab/asab-governator:stable \
python3 -m governator.bootstrap
Bootstrap pomocí Podmanu¶
Nasazení pomocí Podmanu je inherentně bez root, což přidává další vrstvu zabezpečení k nasazení.
Note
Podman verze 4+ je silně doporučena.
Zde je návod na instalaci Podmanu na Ubuntu 22.04 LTS:
$ export ubuntu_version='22.04'
$ export key_url="https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/unstable/xUbuntu_${ubuntu_version}/Release.key"
$ export sources_url="https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/unstable/xUbuntu_${ubuntu_version}"
$ echo "deb $sources_url/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:unstable.list
$ curl -fsSL $key_url | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/devel_kubic_libcontainers_unstable.gpg > /dev/null
$ sudo apt update
$ sudo apt install podman
Konfigurace Podmanu:
$ systemctl --user start podman.socket
$ systemctl --user enable podman.socket
$ sudo ln -s /run/user/${UID}/podman/podman.sock /var/run/docker.sock
$ loginctl enable-linger ${USER}
Příprava layoutu souborového systému OS:
$ sudo mkdir /opt/site
$ sudo chown ${USER} /opt/site
$ mkdir -p /opt/site/docker/conf
$ sudo mkdir /data
$ sudo chown ${USER} /data
Spuštění bootstrap:
$ podman run -it --rm --pull always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /opt/site:/opt/site \
-v /opt/site/docker/conf:/root/.docker/ \
-v /data:/data \
-e NODE_ID=`hostname -s` \
--network=host \
pcr.teskalabs.com/asab/asab-governator:stable \
python3 -m governator.bootstrap
Nastavení knihovny
Knihovna je domovem různých deklarací, které popisují komponenty potřebné pro funkčnost LogMan.io a jejich specifické chování.
Funkčnost Maestra je závislá a řízena několika typy souborů Knihovny:
- Nedílnou součástí je model. Určuje, které komponenty se mají nasadit.
- Deskriptory poskytují instrukce jak nainstalovat každou službu.
- Verze souborů obsahují verze všech softwarových komponent, čímž vytváří globální verzi každé aplikace.
Všechny deklarace a soubory používané v ASAB Maestro se nacházejí v adresáři /Site
. Na nejvyšší úrovni adresáře /Site
vždy naleznete soubory modelu a adresáře aplikací. Všechny deskriptory a verze souborů jsou specifické pro danou aplikaci. Deskriptory, Verze a Webové aplikace jsou probírány v dalších kapitolách.
V každé aplikaci je ještě jedna složka nazvaná jednoduše Files
. Soubory v těchto adresářích jsou tříděny podle služeb, k nimž náleží. Mohou být referencovány v deskriptorech.
ASAB Maestro Model¶
Model je YAML soubor nebo více souborů popisujících požadované uspořádání clusteru. Je hlavním bodem interakce mezi uživatelem a ASAB Maestro. Model je místem, kde lze přizpůsobit instalaci LogMan.io.
Modelový soubor(y)¶
Modelové soubory jsou uloženy v knihovně ve složce /Site/
.
Modelový soubor uživatelské úrovně je /Site/model.yaml
.
Administrátor tento soubor upravuje ručně, tj. v knihovně.
Může existovat více modelových souborů. Zejména spravované modelové části jsou odděleny do specifických souborů. Všechny modelové soubory jsou sloučeny do jedné modelové datové struktury, když je model aplikován.
Varování
Neupravit modelové soubory označené jako automaticky generované.
Struktura modelu¶
Příklad souboru /Site/model.yaml
:
define:
type: rc/model
services:
nginx:
instances:
1: {node: "node1"}
2: {node: "node2"}
2: {node: "node3"}
mongo:
- {node: "node1"}
- {node: "node2"}
- {node: "node3"}
myservice:
instances:
id1: {node: "node1"}
webapps:
/: Moje webová aplikace
/auth: SeaCat Auth WebUI
/influxdb: InfluxDB UI
applications:
- name: "ASAB Maestro"
version: v23.32
- name: "Moje aplikace"
version: v1.0
params:
PUBLIC_URL: https://ateska-lmio
Sekce define
¶
define:
type: rc/model
Určuje typ tohoto YAML souboru uvedením type: rc/model
.
Sekce services
¶
Tato sekce uvádí všechny služby v clusteru. Ve výše uvedeném příkladu jsou služby "nginx", "mongo" a "myservice".
Každý název služby musí odpovídat příslušnému deskriptoru v knihovně.
Sekce services
je předepsána následovně:
services:
<service_id>:
instances:
<instance_no>:
node: <node_id>
<instance-level overrides>
...
<service-level overrides>
Přidání nové instance¶
Sekce instances
záznamu služby v services
musí specifikovat, na kterém uzlu má být každá instance spuštěna.
Toto je kanonická, plně rozšířená forma:
myservice:
instances:
1:
node: node1
2:
node: node2
3:
node2
Služba myservice
je naplánována ke spuštění ve třech instancích (číslo instance 1, 2 a 3) na uzlech node1
a node2
.
Následující formy jsou dostupné pro stručnost:
myservice:
instances: {1: node1, 2: node2, 3: node2}
myservice:
instances: ["node1", "node2", "node2"]
Poslední příklad definuje pouze jednu instanci (číslo 1) služby myservice
, která bude naplánována na uzel node1
:
myservice:
instances: node1
Odstraněné instance¶
Některé služby vyžadují pevný počet instancí po celou dobu životního cyklu clusteru, zejména pokud jsou některé instance odstraněny.
Přejmenování a přesun instancí
Při jakémkoli přejmenovávání nebo přesunu instancí z jednoho uzlu na druhý mějte na paměti, že mezi "starou" a "novou" instancí neexistuje žádná reference. To znamená, že jedna instance je odstraněna a druhá vytvořena. Pokud přesunete instanci služby z jednoho uzlu na druhý, buďte si vědomi, že data uložená na tomto uzlu a spravovaná nebo používaná službou nejsou přesunuta.
ZooKeeper
Číslo instance ve službě ZooKeeper slouží technologii ZooKeeper k identifikaci instance v rámci clusteru. Proto změna čísla instance znamená odstranění jednoho uzlu ZooKeeper ze clusteru a přidání nového.
Odstraněná instance je číslo dvě:
myservice:
instances:
1: {node: "node1"}
# Zde se dříve nacházela další instance, ale nyní je odstraněna
3: {node: "node2"}
Ve zkrácené formě je nutné použít null
:
myservice: ["node1", null, "node2"]
Přepis hodnot z deskriptoru¶
Chcete-li přepsat hodnoty z deskriptoru, můžete zadat tyto hodnoty na označeních <instance-level overrides>
nebo <service-level overrides>
.
V následujícím příkladu je počet cpu
nastaven na 2 v Docker Compose a také sekce asab
z deskriptoru asab-governator
je přepsána na úrovni instance:
services:
...
asab-governator:
instances:
1:
node: node1
descriptor:
cpus: 2
asab:
config:
remote_control:
url:
- http://nodeX:8891/rc
Stejný přepis, ale na úrovni služby:
services:
...
asab-governator:
instances: [node1, node2]
descriptor:
cpus: 2
asab:
config:
remote_control:
url:
- http://nodeX:8891/rc
Přepis verzí¶
Chcete-li přepsat verzi, která je ve výchozím nastavení nastavena v souboru verze, použijte klíčové slovo "version" v modelu.
V následujícím příkladu bude verze instance asab-governator-1
nastavena na v24.36
. Verze v souboru verze bude ignorována.
services:
...
asab-governator:
instances:
- node1
version: v24.36
Sekce webapps
¶
Sekce webapps
popisuje, které webové aplikace mají být do clusteru nainstalovány.
Podívejte se na kapitolu NGINX pro více detailů.
Sekce applications
¶
Sekce aplikací uvádí aplikace z knihovny, které mají být zahrnuty.
applications:
- name: <application name>
version: <application version>
...
Aplikace žije v knihovně ve složce /Site/<application name>/
.
Verze je specifikována v souboru version
ve složce /Site/<application name>/Versions/<application version>.yaml
.
Více aplikací může být nasazeno společně ve stejném clusteru, pokud existuje více záznamů aplikací v sekci applications
modelu.
Soubor verze¶
Příklad souboru verze
/Site/ASAB Maestro/Versions/v23.32.yaml
:
define:
type: rc/version
product: ASAB Maestro
version: v23.32
versions:
zookeeper: '3.9'
nginx: '1.25.2'
mongo: '7.0.1'
asab-remote-control: latest
asab-governator: stable
asab-library: v23.15
asab-config: v23.31
seacat-auth: v23.37-beta
asab-iris: v23.31
Sekce params
¶
Tato sekce obsahuje páry klíč/hodnota pro úrovně clusteru (globální) parametrizaci stránky.
Rozšíření na úrovni modelu¶
Některé technologie umožňují, aby model specifikoval rozšíření jejich konfigurace.
Příklad rozšíření na úrovni modelu NGINX:
define:
type: rc/model
...
nginx:
https:
location /:
- gzip_static on
- alias /webroot/lmio-webui/dist
Více modelových souborů¶
Kromě uživatelské úrovně modelového souboru (/Site/model.yaml
) zde najdete také generované modelové soubory pojmenované podle tohoto vzoru: /Site/model-*.yaml
.
Modelové soubory jsou sloučeny do jednoho velkého modelu těsně před zpracováním pomocí ASAB Remote Control.
ASAB Maestro descriptor¶
Deskriptory jsou soubory YAML žijící v knihovně. Každá aplikace se skládá ze skupiny deskriptorů /Site/<application name>/Descriptors/
.
Descriptor poskytuje podrobné informace o službě a/nebo technologii. Deskriptory slouží jako specifická rozšíření modelu.
Note
Deskriptory jsou poskytovány autory každé aplikace.
Struktura deskriptoru¶
Příklad /Site/ASAB Maestro/Descriptors/mongo.yaml
:
define:
type: rc/descriptor
name: MongoDB dokumentová databáze
url: https://github.com/mongodb/mongo
descriptor:
image: library/mongo
volumes:
- "{{SLOW_STORAGE}}/{{INSTANCE_ID}}/data:/data/db"
- "{{SITE}}/{{INSTANCE_ID}}/conf:/etc/mongo:ro"
command: mongod --config /etc/mongo/mongod.conf --directoryperdb
healthcheck:
test: ["CMD-SHELL", 'echo "db.runCommand(\"ping\").ok" | mongosh 127.0.0.1:27017/rs0 --quiet']
interval: 60s
timeout: 10s
retries: 5
start_period: 30s
sherpas:
init:
image: library/mongo
entrypoint: ["mongosh", "--nodb", "--file", "/script/mongo-init.js"]
command: ["echo", "HOTOVO"]
volumes:
- "{{SITE}}/{{INSTANCE_ID}}/script:/script:ro"
- "{{SITE}}/{{INSTANCE_ID}}/conf:/etc/mongo:ro"
depends_on: ["{{INSTANCE_ID}}"]
environment:
MONGO_HOSTNAMES: "{{MONGO_HOSTNAMES}}"
files:
- "conf/mongod.conf": |
net:
bindIp: 0.0.0.0
port: 27017
replication:
replSetName: rs0
- "script/mongo-init.js"
Šablonování¶
Deskriptory využívají Jinja2 šablony, které se rozšiřují při aplikaci deskriptoru.
Běžné parametry:
{{NODE_ID}}
: Identifikace uzlu / hostname hostitelského stroje (node1
).{{SERVICE_ID}}
: Identifikace služby (tj.mongo
).{{INSTANCE_ID}}
: Identifikace instance (tj.mongo-2
).{{INSTANCE_NO}}
: Číslo instance (tj.2
).{{SITE}}
: Adresář s konfigurací stránek na hostitelském stroji (tj./opt/site
).{{FAST_STORAGE}}
: Adresář s rychlým úložištěm na hostitelském stroji (tj./data/ssd
).{{SLOW_STORAGE}}
: Adresář s pomalým úložištěm na hostitelském stroji (tj./data/hdd
).
Note
Ostatní parametry mohou být specifikovány v rámci deskriptorů, v modelu nebo poskytovány technologiemi.
Technologie¶
Nejen, že jsou složeny vícenásobné knihovní soubory do konečné konfigurace. Existují také technologie hrající své role. Technologie jsou součástí mikroservisu ASAB Remote Control a poskytují další konfiguraci clusteru.
Některé z nich také zavádějí specifické sekce do deskriptorů.
Zjistěte více o Technologiích
Složitelnost¶
Deskriptory mohou být přepsány v nasazení prostřednictvím specifických konfiguračních možností nebo prostřednictvím modelu.
/Site/<application name>/Descriptors/__commons__.yaml
soubor knihovny je společný základ pro všechny deskriptory aplikace. Specificky obsahuje položky pro režim sítě, politiku restartu, logování a další.- Specifický descriptor služby (např.
/Site/<application name>/Descriptors/nginx.yaml
) je vrstvený nad obsahem__commons__.yaml
- Model může přepsat descriptor.
Merge algoritmus
Tato složitelnost je realizována prostřednictvím slučovacího algoritmu. Stejný algoritmus najdete použitý v několika případech, kde kusy z různých zdrojů vedou do funkční konfigurace stránek.
Vrstvení knihovny
Chcete-li získat úplný obraz o knihovně v rámci ASAB Maestro, zjistěte více o vrstvách knihovny ASAB.
Sekce¶
Sekce define
¶
define:
type: rc/descriptor
name: <srozumitelný název>
url: <URL s relevantními informacemi>
type
musí být rc/descriptor
.
Položky name
a url
poskytují informace o službě a/nebo technologii.
Sekce params
¶
Specifikujte parametry pro šablonování tohoto a všech ostatních deskriptorů. Jakýkoli parametr specifikovaný v této sekci může být použit ve dvojitých složených závorkách pro šablonování Jinja2.
define:
type: rc/descriptor
params:
MY_PARAMETER: "ABCDEFGH"
descriptor:
environment: "{{MY_PARAMETER}}"
Sekce secrets
¶
Podobně jako params
, také secrets mohou být použity jako parametry pro šablonování. Jejich hodnota však není specifikována v deskriptoru, ale generována a uložena v Vaultu. Secret můžete přizpůsobit specifikováním type
a length
. Výchozí je "token" o délce 64 bytů.
define:
type: rc/descriptor
secrets:
MY_SECRET:
type: token
length: 32
descriptor:
environment: "{{MY_SECRET}}"
Warning
Části deskriptoru jsou použity přímo k přípravě docker-compose.yaml
. Sekce secrets
může být specifikována také v docker-compose.yaml
. Nicméně, tato funkcionalita Docker Compose je v rámci ASAB Maestro vynechána a plně nahrazena sekcí secrets
deskriptoru.
Sekce descriptor
¶
Sekce descriptor
je šablona pro sekci service
souboru docker-compose.yaml
.
Jsou prováděny následující transformace:
- Šablony Jinja2 proměnných jsou rozšířeny.
- Verze z
../Versions/...
je přidána kimage
, pokud není přítomna. - Specifické technologie provádějí vlastní transformace, které jsou obvykle označeny
null
.
Detaily o volumes
¶
Služba má k dispozici následující tři úložiště pro svá persistní data:
{{SITE}}
: adresář stránek (tj./opt/site/...
){{SLOW_STORAGE}}
: pomalé úložiště (tj./data/hdd/...
){{FAST_STORAGE}}
: rychlé úložiště (tj./data/ssd/...
)
Každá instance může vytvářet podsložku v kterémkoli z výše uvedených umístění pojmenovanou podle svého instance_id
.
Sekce files
¶
Tato sekce specifikuje, které soubory mají být kopírovány do podsložky instance adresáře stránek (tj. /opt/site/...
).
Následně může být tento obsah zpřístupněn kontejneru instance příslušnou položkou volumes
.
Seznam souborů pomocí následujícího schématu:
files:
- destination:
source: file_name.txt
NEBO
files:
- destination:
content: |
Víceřádkový text
který bude zapsán do
cílové cesty.
Cíl¶
Existují tři možné destinace:
- Tato služba
- Jiná služba
- ZooKeeper
1. Tato služba¶
Cesta souboru je relativní k cíli v adresáři stránek.
Například, tento záznam v deskriptoru...
files:
- script/mongo-init.js:
source: some_source_dir/mongo-init.js
...vytvoří soubor /opt/site/mongo-1/script/mongo-init.js
, pokud je INSTANCE ID instance mongo mongo-1
.
2. Jiná služba¶
Použijte URL se schématem service
, abyste zacílili soubor do jiné služby.
Například, tento záznam v JAKÉMKOLI deskriptoru služby v modelu...
files:
- service://mongo/script/mongo-init.js:
source: some_source_dir/mongo-init.js
...vytvoří soubor /opt/site/mongo-1/script/mongo-init.js
, pokud je instance mongo ve modelu také přítomna a její INSTANCE ID je mongo-1
.
3. ZooKeeper¶
Použijte schéma URL zk
, abyste specifikovali cestu v ZooKeeper, kde chcete soubor nahrát. Soubor je v režimu "řízeného". To znamená, že je vždy aktualizován podle aktuálního stavu knihovny.
files:
- zk:///asab/library/settings/lmio-library-settings.json:
source: asab-library/setup.json
V tomto příkladu bude uzel ZooKeeper s cestou /asab/library/settings/lmio-library-settings.json
vytvořen nebo aktualizován, pokud již existuje.
Zdroj¶
Zdroj je relativní cesta k adresáři knihovny přiřazené jako /Site/<application>/Files/<service>/
. Např. pro službu mongo
se odkazuje na /Site/ASAB Maestro/Files/mongo/
.
Zdroj může být jak soubor, tak složka. Cesta složky musí končit lomítkem.
Zkrácené syntaxe zdroje souboru
Pokud zdroj chybí v deklaraci, sdílí stejnou cestu s cílem.
Tento záznam zkopíruje soubor /Site/ASAB Maestro/Files/mongo/script/mongo-init.js
do /opt/site/mongo-1/script/mongo-init.js
, pokud je identifikace instance
mongo-1
:
files:
- "script/mongo-init.js"
Podobný záznam s koncovým lomítkem zkopíruje celý adresář z /Site/ASAB Maestro/Files/mongo/script/conf
do adresáře /opt/site/mongo-1/conf/
.
files:
- "conf/"
Soubory nejsou šablonovány
Na rozdíl od deskriptorů a modelů, soubory uložené v adresáři /Site/<application name>/Files/<service_id>/
nejsou šablonovány. To znamená, že složené závorky s parametry nejsou nahrazeny příslušnými hodnotami. Pokud potřebujete použít šablonování v souboru, vložte soubor přímo do deskriptoru, pomocí operátoru víceřádkového řetězce ("|").
Obsah¶
Definujte obsah souboru přímo v deskriptoru. To je zvláště vhodné pro krátké soubory a/nebo soubory, které vyžadují parametry poskytované maestro.
Literalský styl pomocí trubky (|
) v yaml souboru umožňuje psaní víceřádkových řetězců (blokových scalarů).
files:
- "conf/mongod.conf":
content: |
net:
bindIp: 0.0.0.0
port: 27017
replication:
replSetName: rs0
Klíčové slovo content
může být vynecháno pro stručnost.
files:
- "conf/mongod.conf": |
net:
bindIp: 0.0.0.0
port: 27017
replication:
replSetName: rs0
Sekce sherpas
¶
Sherpas jsou pomocné kontejnery, které jsou spouštěny spolu s hlavními kontejnery instance. Kontejnery sherpa by měly poměrně rychle dokončit a nejsou restartovány. Sherpa kontejnery, které úspěšně skončí (s kódem ukončení 0) jsou okamžitě smazány.
Příklad:
sherpas:
init:
image: library/mongo
entrypoint: ["mongosh", "--nodb", "--file", "/script/mongo-init.js"]
command: ["echo", "HOTOVO"]
volumes:
- "{{SITE}}/{{INSTANCE_ID}}/script:/script:ro"
- "{{SITE}}/{{INSTANCE_ID}}/conf:/etc/mongo:ro"
depends_on: ["{{INSTANCE_ID}}"]
environment:
MONGO_HOSTNAMES: "{{MONGO_HOSTNAMES}}"
Toto definuje init
sherpa kontejner.
Název kontejneru sherpa by byl mongo-1-init
, parametr INSTANCE_ID zůstává mongo-1
.
Obsah sherpa je šablona pro příslušnou část souboru docker-compose.yaml
.
Pokud sherpa nespecifikuje image
, použije se obraz služby včetně verze.
Alternativně doporučujeme použít docker.teskalabs.com/asab/asab-governator:stable
jako obraz pro sherpa, protože tento obraz je vždy přítomen a nemusí být stažován.
Verze v ASAB Maestro¶
Globální verze aplikace je specifikována v sekci applications
modelu:
define:
type: rc/model
services:
zoonavigator:
instances: {1: {node: "lmc01"} }
params:
PUBLIC_URL: "https://maestro.logman.io"
applications:
- name: "ASAB Maestro"
version: v23.47
- name: "LogMan.io"
version: v24.01
Soubory verzí popisující globální verze se nacházejí v adresáři /Site/<jméno aplikace>/Versions
v Knihovně. Například, adresář /Site/ASAB Maestro/Versions
je určen pro aplikaci ASAB Maestro.
Soubor verze v24.01.yaml
může vypadat takto:
define:
type: rc/version
product: ASAB Maestro
version: v24.01
versions:
zookeeper: '3.9'
asab-remote-control: latest
asab-governator: stable
asab-library: v23.15-beta
asab-config: v23.45
seacat-auth: v23.47
asab-iris: v23.31-alpha
nginx: '1.25.2'
elasticsearch: '7.17.12'
mongo: '7.0.1'
kibana: '7.17.2'
influxdb: '2.7.1'
telegraf: '1.28.2'
grafana: '10.0.8'
kafdrop: '4.0.0'
kafka: '7.5.1'
jupyter: "lab-4.0.9"
webapp seacat-auth: v23.29-beta
Sekce define
specifikuje typ souboru a poskytuje více informací o něm. Může také sloužit k uchovávání komentářů a poznámek.
Sekce versions
obsahuje názvy služeb jako klíče a jejich verze jako hodnoty. Jsou to verze příslušných docker image. Speciální záznamy v tomto seznamu jsou webové aplikace. Použijte klíčové slovo webapp
pro přiřazení verze konkrétní webové aplikaci. Pokud není verze specifikována, použije se nejnovější verze.
Webové Aplikace¶
Pro instalaci webové aplikace potřebujete:
- Webová aplikace uvedená v modelu
- Nginx (a SeaCat Auth)
- Příslušný soubor webové aplikace v knihovně
Model¶
Použijte sekci webapps
k určení, které webové aplikace by měly být nainstalovány. Vyberte umístění nginx, kde bude každá webová aplikace sloužena.
Příklad /Site/model.yaml
define:
type: rc/model
services:
zoonavigator:
instances:
1:
node: "lmc01"
nginx:
instances:
1:
node: "lmc01"
mongo:
instances:
1:
node: "lmc01"
seacat-auth:
instances:
1:
node: "lmc01"
applications:
- name: "ASAB Maestro"
version: v23.47
params:
PUBLIC_URL: "https://maestro.logman.io"
webapps:
/: LogMan.io WebUI
/auth: SeaCat Auth WebUI
Závislosti¶
Webové aplikace mohou být slouženy pouze z proxy serveru Nginx.
Ujistěte se, že vaše veřejná URL v sekci params
ve vašem modelu je správná.
Většina webových aplikací vyžaduje autorizační server. Pro úspěšné spuštění LogMan.io web UI nainstalujte také SeaCat Auth a Mongo jako jeho závislosti.
Soubor Webové Aplikace¶
Deklarace webové aplikace obsahuje distribuční bod, specifikaci Nginx a seznam webových aplikací.
- Vyberte mezi
mfe
aspa
- Vyberte server ("https", "http", "internal")
- Specifikujte umístění nginx, kde bude webová aplikace sloužena
- Specifikujte název webové aplikace
Note
mfe
znamená "mikro-frontend" aplikace. LogMan.io Web UI se skládá z mnoha mikrofrontend aplikací.
spa
znamená "jednoduchá aplikace".
Verze každé aplikace je uvedena v souboru versií. Aplikace, které nejsou uvedeny v souborech versií, jsou použity ve své latest
verzi.
Descriptor Webové Aplikace pro MFE¶
define:
type: rc/webapp
name: TeskaLabs LogMan.io WebUI
url: https://teskalabs.com
webapp:
distribution: https://asabwebui.z16.web.core.windows.net/
mfe:
https:
/: lmio_webui
/asab_config_webui: asab_config_webui
/asab_library_webui: asab_library_webui
/asab_maestro_webui: asab_maestro_webui
/asab_tools_webui: asab_tools_webui
/bs_query_webui: bs_query_webui
/lmio_analysis_webui: lmio_analysis_webui
/lmio_lookup_webui: lmio_lookup_webui
Sekce webapp
a klíč distribution
specifikuje základní URL, ze které je aplikace distribuována.
Sekce mfe
obsahuje specifikaci serveru (https
, http
nebo internal
), na který bude instalace provedena.
Uvnitř serveru je slovník "subpath" (/
) a název MFE komponenty (lmio_webui
).
Jedno umístění by mělo být /
, to je vstupní bod do MFE aplikace.
Descriptor Webové Aplikace pro SPA¶
define:
type: rc/webapp
name: TeskaLabs SeaCat Auth WebUI
url: https://teskalabs.com
webapp:
distribution: https://asabwebui.z16.web.core.windows.net/
spa:
https: seacat-auth
Sekce webapp
a klíč distribution
specifikuje základní URL, ze které je aplikace distribuována.
Sekce spa
obsahuje specifikaci serveru (https
, http
nebo internal
), na který bude instalace provedena.
Hodnota seacat-auth
specifikuje název (jedné) SPA komponenty, která bude nainstalována.
Verzování¶
Verze komponent webových aplikací jsou specifikovány v příslušném souboru /Site/<název aplikace>/Versions/v<verze aplikace>.yaml
:
define:
type: rc/version
product: ASAB Maestro
version: v23.32
versions:
...
webapp seacat-auth: 'v23.13-beta'
webapp lmio_webui: 'v23.43'
Webová aplikace má prefix webapp
s připojením mezery.
Pokud verze není specifikována, předpokládá se verze "master".
Tento soubor poskytuje kompatibilní kombinaci verzí komponent webové aplikace a příslušných mikroservis.
Ruční Spuštění Distribuce Webové Aplikace¶
Možná budete potřebovat spustit distribuci webové aplikace ručně, například pro upgrade na novou verzi webové aplikace.
Postup je následující:
$ cd /opt/site
$ ./gov.sh compose up nginx-1-webapp-dist
[+] Running 1/1
✔ Container nginx-1-webapp-dist Created 0.1s
Attaching to nginx-1-webapp-dist
nginx-1-webapp-dist | Installing lmio_webui (mfe) ...
nginx-1-webapp-dist | lmio_webui already installed and up-to-date.
nginx-1-webapp-dist | Installing asab_config_webui (mfe) ...
nginx-1-webapp-dist | asab_config_webui already installed and up-to-date.
nginx-1-webapp-dist | Installing asab_maestro_webui (mfe) ...
nginx-1-webapp-dist | asab_maestro_webui already installed and up-to-date.
nginx-1-webapp-dist | Installing asab_tools_webui (mfe) ...
nginx-1-webapp-dist | asab_tools_webui already installed and up-to-date.
nginx-1-webapp-dist | Installing bs_query_webui (mfe) ...
nginx-1-webapp-dist | bs_query_webui already installed and up-to-date.
nginx-1-webapp-dist | Installing lmio_analysis_webui (mfe) ...
nginx-1-webapp-dist | lmio_analysis_webui already installed and up-to-date.
nginx-1-webapp-dist | Installing lmio_lookup_webui (mfe) ...
nginx-1-webapp-dist | lmio_lookup_webui already installed and up-to-date.
nginx-1-webapp-dist | Installing lmio_observability_webui (mfe) ...
nginx-1-webapp-dist | lmio_observability_webui already installed and up-to-date.
nginx-1-webapp-dist | Installing lmio_parser_builder_webui (mfe) ...
nginx-1-webapp-dist | lmio_parser_builder_webui already installed and up-to-date.
nginx-1-webapp-dist | Installing seacat-auth (spa) ...
nginx-1-webapp-dist | seacat-auth already installed and up-to-date.
nginx-1-webapp-dist exited with code 0
$
Techs
Technologie v ASAB Maestro¶
Technologie je specifický typ služby (např. NGINX, Mongo), která poskytuje prostředky jiným službám.
Kromě své hlavní funkce jako služby mikroslužba ASAB Remote Control rozšiřuje technologie a jejich dopad na konfiguraci clusteru.
Některé konfigurační možnosti vyžadují aktuální znalosti komponent clusteru. Například, pokud mikroslužba potřebuje konfiguraci Kafka serverů, Kafka tech v ASAB Remote Control zjistí, kde běží Kafka a poskytne konfiguraci.
Každá technologie je navržena tak, aby poskytovala jednu nebo více z následujících funkcí:
Parametry¶
Technologie poskytuje parametry, které lze použít v modelu a popisovači během šablonování.
Sekce v popisu¶
Technologie může využívat svou specifickou sekci popisovačů. Například viz Nginx tech.
Konfigurace služeb ASAB¶
ASAB služba je v tomto kontextu rozpoznána tím, že má asab
sekci v popisovači.
Podívejte se na ASAB tech, abyste věděli, jak je vytvořena konfigurace ASAB služby.
Technologie mohou rozšířit konfiguraci ASAB služeb (např. Elasticsearch nebo Kafka techs).
Příklad
define:
type: rc/descriptor
name: ASAB Remote Control
descriptor:
image: docker.teskalabs.com/asab/asab-remote-control
volumes:
- "{{SITE}}/{{INSTANCE_ID}}/conf:/conf:ro"
asab:
configname: conf/asab-remote-control.conf
config: {}
nginx:
api: 8891
Úprava konfigurace služby¶
Některé technologie upraví svou vlastní konfiguraci na základě aktuálního rozložení clusteru.
ASAB Služby v rámci ASAB Maestro¶
Konfigurace služeb ASAB¶
Tato technologie poskytuje každé službě ASAB specifickou konfiguraci.
Sekce asab
musí být specifikována v popisu.
Sekce asab
vyžaduje:
configname
- Název konfiguračního souboru, který odpovídá Dockerfile služby a mapování svazků (Dockerfiles nejsou v ASAB Maestro vůbec pokryty).config
- Specifická konfigurace vyžadovaná nad rámec obecné a generované konfigurace psané ve formátu YAML.
define:
type: rc/descriptor
name: ASAB Remote Control
descriptor:
image: docker.teskalabs.com/asab/asab-remote-control
volumes:
- "{{SITE}}/{{INSTANCE_ID}}/conf:/conf:ro"
asab:
configname: conf/asab-remote-control.conf
config: {}
Konfigurace je složena v tomto pořadí:
- Nejdůležitější je generovaná konfigurace, která přepisuje všechny ostatní. Toto je konfigurace poskytovaná z technologií clusteru.
- Druhá je konfigurace služby řízená ASAB Config, editovatelná z webového rozhraní.
- Obecná konfigurace je také uvnitř ASAB Config a přístupná z webového rozhraní. Tato konfigurace je společná pro všechny služby ASAB. Skládá se z konfigurace Library a SMTP serveru.
- Konfigurace přítomná v modelu. Konfigurace instance přepisuje konfiguraci služby.
- Konfigurace z popisu služby.
- V neposlední řadě je výchozí konfigurace. Zajišťuje, že služba bude připojena k Library.
{ "library": { "providers": [ "zk:///library", "git+https://github.com/TeskaLabs/asab-maestro-library.git", ], } }
ASAB Governator technologie¶
Rozšiřuje konfiguraci instancí ASAB Governator tak, aby poskytovala aktuální URL spojení všech instancí ASAB Remote Control v clusteru. Neovlivňuje to jiné služby.
Část konfigurace ASAB Governator vytvořená technologií:
[remote_control]
url=http://asab-remote-control-1:8891/rc
http://asab-remote-control-2:8891/rc
http://asab-remote-control-3:8891/rc
ASAB Config technologie¶
Deskriptory mohou specifikovat výchozí konfigurace clusteru díky technologii ASAB Config.
Sekce deskriptoru asab-config
¶
Tato technologie čte sekci asab-config
ze všech deskriptorů a vytváří konfiguraci clusteru.
Například deskriptor Kafdrop specifikuje konfigurační soubor Kafdrop.json
pro konfigurační typ Tools
:
define:
type: rc/descriptor
name: Kafdrop
url: https://github.com/obsidiandynamics/kafdrop
descriptor:
image: obsidiandynamics/kafdrop
environment:
SERVER_PORT: 9000 # toto je jediný funkční port
SERVER_SERVLET_CONTEXTPATH: /kafdrop
KAFKA_BROKERCONNECT: '{{KAFKA_BOOTSTRAP_SERVERS}}'
asab-config:
Tools:
Kafdrop:
file:
{
"Tool": {
"image": "media/tools/kafka.svg",
"name": "Kafdrop",
"url": "/kafdrop"
},
"Authorization": {
"tenants": "system"
}
}
if_not_exists: true
Instrukce v deskriptoru je vytvořit konfiguraci Kafdrop
typu Tools
. Uvnitř konfigurace Kafdrop
můžete vidět dvě sekce: file
a if_not_exists
.
- Sekce
file
očekává konfigurační soubor, což je json soubor přímo vložený do deskriptoru (jako zde v příkladu). Druhou možností je specifikovat soubor z adresáře/Site/Files/<service_id>/
Knihovny, podobně jako vefiles
sekci deskriptoru. if_not_exists
umožňuje pouze dvě možnosti:true
nebofalse
. Výchozí jefalse
- to znamená, že konfigurace je nahrána a aktualizována podle deskriptoru pokaždé, když je model aplikován. Když jetrue
, konfigurace je vytvořena pouze pokud ještě neexistuje. To znamená, že taková konfigurace může být změněna manuálně a nebude přepsána automatickými akcemi ASAB Remote Control. Na druhou stranu, taková konfigurace není aktualizována novými verzemi deskriptoru.
Elasticsearch v ASAB Maestro¶
Technologie Elasticsearch rozšiřuje konfiguraci služby Elasticsearch a spojuje Elasticsearch s ostatními službami.
Parametry¶
Seznam parametrů vytvořených technologií Elasticsearch, dostupných modelu a deskriptorům, kdykoli je Elasticsearch přítomen v instalaci.
- ELASTIC_HOSTS_KIBANA
-
Řetězec URL adres všech ElasticSearch master nodů.
"[http://lmc01:9200, http://lmc02:9201, http://lmc03:9202]"
Deskriptor Kibana
define: type: rc/descriptor name: Kibana url: https://www.elastic.co/kibana descriptor: image: docker.elastic.co/kibana/kibana volumes: - "{{SITE}}/{{INSTANCE_ID}}/config:/usr/share/kibana/config" files: - "config/kibana.yml": | # https://github.com/elastic/kibana/blob/main/config/kibana.yml server.host: {{NODE_ID}} elasticsearch.hosts: {{ELASTIC_HOSTS_KIBANA}} elasticsearch.username: "elastic" elasticsearch.password: {{ELASTIC_PASSWORD}} xpack.monitoring.ui.container.elasticsearch.enabled: true server.publicBaseUrl: {{PUBLIC_URL}}/kibana server.basePath: "/kibana" server.rewriteBasePath: true
- ELASTIC_PASSWORD
-
Tajný klíč umožňující přístup a zápis do Elasticsearch.
Konfigurace ASAB služeb¶
Každá ASAB služba obdrží konfigurační sekci elasticsearch
.
[elasticsearch]
url=http://lmc01:9200
http://lmc02:9201
http://lmc03:9202
username=elastic
password=<ELASTIC_PASSWORD>
Konfigurace Elasticsearch¶
Proměnné prostředí¶
Existuje několik proměnných prostředí v deskriptoru Elasticsearch nastavených na null
a nahrazených technologií.
- node.roles
-
Roles jsou načítány z modelu pro každou instanci. Názvy specifikované pro každou instanci (master, hot, warm, cold) jsou přeloženy do node.roles následovně:
- master ->
node.roles=master,ingest
- hot ->
node.roles=data_content,data_hot
- warm ->
node.roles=data_warm
- cold ->
node.roles=data_cold
Jiné názvy a vrstvy nejsou podporovány Elasticsearchem ani ASAB Maestro.
- master ->
- http.port
-
Každá instance Elasticsearchu dostává jedinečný port podle své role. Všechny master instance začínají na 9200, všechny hot instance začínají na 9250, všechny warm instance začínají na 9300, všechny cold instance začínají na 9350.
- transport.port
-
Každá instance Elasticsearchu dostává jedinečný port pro vnitřní (mezi-elastickou) komunikaci. Všechny master instance začínají na 9400, všechny hot instance začínají na 9450, všechny warm instance začínají na 9500, všechny cold instance začínají na 9550.
- cluster.initial_master_nodes
-
Všechny master instance Elasticsearchu.
- discovery.seed_hosts
-
Všechny master nody kromě toho, který je právě konfigurován.
- ES_JAVA_OPTS
-
Pokud není
-Xms
již nastavena, nastaví se na-Xms2g
pro master nody a-Xms28g
pro ostatní nody. Pokud není-Xmx
již nastavena, nastaví se na-Xmx2g
pro master nody a-Xmx28g
pro ostatní nody.
Certifikáty¶
Komunikace mezi instancemi Elasticsearch je zabezpečena certifikáty. Certifikáty jsou generovány ASAB Remote Control, pomocí jeho certifikační autority.
Konfigurace Nginx¶
Porty přiřazené master nodům jsou šířeny do konfigurace Nginx, aby vytvořily záznam upstream
pro službu Elasticsearch.
InfluxDB v ASAB Maestro¶
Rozšiřuje konfiguraci služby InfluxDB a umožňuje ostatním službám se připojit k InfluxDB.
Parametry¶
Parametry Organization
a bucket
v konfiguraci InfluxDB jsou nastaveny striktně následujícím způsobem:
- INFLUXDB_ORG
-
system
- INFLUXDB_BUCKET
-
metrics
Konfigurace ASAB Služeb¶
Každá ASAB služba získává konfigurační sekce asab:metrics
a asab:metrics:influxdb
.
[asab:metrics]
target=influxdb
[asab:metrics:influxdb]
url=http://influxdb:8086/
token=I1x1URqoTP31o6lmnZO1gbm_FkskGoIkRnsVKoJLmLSOd8YQQNoLBkRpDzSxVJR17JoFQ3DvMXcmJn9ItjLoTQ
bucket=metrics
org=system
Proměnné prostředí¶
- DOCKER_INFLUXDB_INIT_USERNAME a DOCKER_INFLUXDB_INIT_PASSWORD
-
ASAB Maestro vytvoří a uloží (ve Vault) správcovský přístup do InfluxDB.
Kafka v ASAB Maestro
¶
Poskytuje připojení ke všem službám prostřednictvím dynamické konfigurace ASAB nebo připojovacího řetězce KAFKA_BOOTSTRAP_SERVERS
.
Parametry¶
- KAFKA_BOOTSTRAP_SERVERS
-
Čárkou oddělené URL adresy ke Kafka instancím
lmc01:9092,lmc02:9092,lmc03:9092
Konfigurace ASAB Služeb¶
Každá ASAB Služba získá sekci konfigurace kafka
.
[kafka]
bootstrap_servers=lmc01:9092,lmc02:9092,lmc03:9092
Mongo DB v ASAB Maestro¶
Umožňuje ostatním službám se připojit k databázi Mongo. Parametry jsou také používány Mongo a SeaCat Auth sherpy.
Parametry¶
- MONGO_HOSTNAMES
-
čárkami oddělené instance ID všech Mongo instancí
mongo-1,mongo-2,mongo-3
- MONGO_URI
-
URI ke všem Mongo instancím
mongodb://mongo-1,mongo-2,mongo-3/?replicaSet=rs0
- MONGO_REPLICASET
- je nastaven na
rs0
Konfigurace ASAB Služeb¶
Každá ASAB Služba získá konfigurační sekci mongo
.
[mongo]
url=mongodb://mongo-1,mongo-2,mongo-3/?replicaSet=rs0
NGINX v ASAB Maestro¶
Technologie NGINX poskytuje:
- Schopnosti aplikační brány
- Vyvažování zátěže
- Průzkumník služeb
- Autorizaci pro další služby v clusteru
Servery¶
ASAB Maestro organizuje konfiguraci NGINX do následující struktury:
- HTTP server:
http
, viz config - HTTPS server:
https
, viz config - Interní HTTP server na portu tcp/8890:
internal
, viz config - Upstreamy
Konfigurace NGINX v deskriptorech¶
Sekce nginx
deskriptoru poskytuje informace o tom, jak očekává příslušná služba, že bude NGINX nakonfigurován.
To znamená, že specifikuje pravidla proxy přeposílání, která zpřístupňují API mikroslužby.
Příklad deskriptoru /Site/.../Descriptors/foobar.yaml
:
define:
type: rc/descriptor
...
nginx:
api:
port: 5678
upstreams:
upstream-foobar-extra: 1234
https:
location = /_introspect:
- internal
- proxy_method POST
- proxy_pass http://{{UPSTREAM}}/introspect
- proxy_ignore_headers Cache-Control Expires Set-Cookie
location /subpath/api/foobar:
- rewrite ^/subpath/api/(.*) /$1 break
- proxy_pass http://upstream-foobar-extra
server:
- ssl_client_certificate shared/custom-certificate.pem
- ssl_verify_client optional
Konverze konfigurace NGINX do YAML
Konfigurace NGINX v ASAB Maestro je přeložena do YAML, aby mohla být zahrnuta v modelu nebo deskriptorech.
Následující úryvek konfigurace NGINX:
location /api/myapp {
rewrite ^/api/myapp/(.*) /myapp/$1 break;
proxy_pass http://my-server:8080;
}
se stane v souborech YAML ASAB Maestro:
location /api/myapp:
- rewrite ^/api/myapp/(.*) /myapp/$1 break
- proxy_pass http://my-server:8080
Podobně můžete přidat konfiguraci do bloku serveru:
server:
- ssl_client_certificate shared/lmio-receiver/client-ca-cert.pem
- ssl_verify_client optional
Sekce api
¶
Sekce api
umožňuje rychlé specifikování "hlavního" API služby.
Klíč port
specifikuje TCP port, na kterém je API vystaveno službou.
Tato položka vygeneruje příslušné položky location
a upstream
.
Plná automatizace
Sekce api
může být snadno jedinou sekcí v části nginx
deskriptoru služby.
Sekce upstream
¶
Definuje specifické upstreamy pro službu. Každá instance služby bude přidána do záznamu upstreamů v konfiguraci NGINX.
Navštivte dokumentaci Nginx, abyste se dozvěděli více o upstream direktivě.
Příklad:
nginx:
upstreams:
upstream-foobar: 1234
Služba foobar
má publikované API na portu tcp/1234
. Další záznam upstream
je definován a pojmenován upstream-foobar
.
Předpokládáme-li tři instance služby foobar
na třech uzlech, výsledná konfigurace upstream
je:
upstream upstream-foobar {
keepalive 32;
server server1:3081;
server server2:3081;
server server3:3081;
}
Pokročilé použití upstreamů
Můžete definovat upstream jako seznam pro přidání dalších konfiguračních možností.
Například SeaCat Auth, server pro autorizaci, vyžaduje, aby požadavky od jednoho uživatele během jedné relace byly odesílány na stejnou instanci služby. NGINX to může zajistit pomocí metody vyvažování ip_hash.
Zde je sekce deskriptoru definující upstreamy pro SeaCat Auth:
nginx:
upstreams:
upstream-seacat-auth-public:
- port 3081
- ip_hash
upstream-seacat-auth-private:
- port 8900
- ip_hash
Předpokládáme-li, že node1
a node2
jsou názvy uzlů v clusteru, výsledná konfigurace NGINX pro upstreamy bude:
upstream upstream-seacat-auth-public {
keepalive 32;
server node1:3081;
server node2:3081;
ip_hash;
}
upstream upstream-seacat-auth-private {
keepalive 32;
server node1:8900;
server node2:8900;
ip_hash;
}
V seznamu můžete specifikovat jakoukoli další konfiguraci, kterou chcete přidat do konfigurace upstream.
Direktiva port
není přímo používána NGINX, ale zpracovává ji Maestro.
Konfigurace server
je přidána pro každou instanci služby (v tomto případě SeaCat Auth) přítomnou v clusteru.
Konfigurace serveru¶
Další možnosti jsou implementovány pro každý server zvlášť (http
, https
, internal
).
Dodatečné lokace mohou být specifikovány pro server.
Sekce location
¶
Typicky, proxy konfigurace konkrétní komponenty nebo lokace staticky obsluhovaného obsahu.
Každá další lokace je přidána do konfigurace nginx jednou za službu, pokud není parametr INSTANCE_ID použit v hlavičce lokace. Pak je lokace zavedena pro každou instanci.
Sekce server
¶
Konfigurace bloku serveru.
Konfigurace NGINX na úrovni modelu¶
Na úrovni modelu můžete specifikovat vlastní konfiguraci NGINX, která přepíše vygenerovanou konfiguraci.
V příkladu přidává extra sekce v model.yaml
location
"/my-special-location" na https
server.
define:
type: rc/model
...
nginx:
https:
location /my-special-location:
- gzip_static on
- alias /webroot/lmio-webui/dist
Můžete také nastavit konfiguraci serveru a upstream. Možnost port
v konfiguraci upstream není podporována v přepsání modelu.
Distribuce webových aplikací¶
Technologie NGINX slouží pro webové aplikace.
sherpa
webapp-dist
stahuje a instaluje webové aplikace definované v modelu.
Webové aplikace budou nasazeny (pokud je to potřeba) pokaždé, když je model aplikován (tj. je vydán příkaz "up").
Příklad model.yaml
:
define:
type: rc/model
...
webapps:
/: Moje webová aplikace
/auth: SeaCat Auth WebUI
/influxdb: InfluxDB UI
...
Sekce webapps
v modelu předepisuje nasazení tří webových aplikací:
- "Moje webová aplikace" bude nasazena do umístění
/
na HTTPS serveru - "SeaCat Auth WebUI" bude nasazena do umístění
/auth
na HTTPS serveru - "InfluxDB UI" bude nasazena do umístění
/influxdb
na HTTPS serveru
Podporované typy webových aplikací:
SeaCat Auth v ASAB Maestro¶
SeaCat Auth je open-source technologie pro kontrolu přístupu vyvinutá v TeskaLabs.
Integrace do ASAB Maestro zajišťuje automatickou introspekci pro všechny api
lokace na https serveru.
"Sherpa obsahu Mongo" služby SeaCat Auth vytváří záznamy v databázi auth
v Mongo. Pomáhá integrovat autorizaci třetích stran.
Další služby mohou přidat dodatečnou konfiguraci instancí SeaCat Auth, pokud je to potřeba.
Sekce deskriptoru seacat-auth
¶
Každý deskriptor může použít sekci seacat-auth
k přidání konfigurační sekce do služby SeaCat Auth a požadovaných dat do databáze auth
v Mongo.
seacat-auth:
config:
"batman:elk":
url: "http://{{NODE_ID}}:9200"
username: elastic
password: "{{ELASTIC_PASSWORD}}"
content:
- "cl.json": |
[{
"_id": "kibana",
"application_type": "web",
"authorize_anonymous_users": false,
"client_name": "Kibana",
"code_challenge_method": "none",
"grant_types": [
"authorization_code"
],
"redirect_uri_validation_method": "prefix_match",
"redirect_uris": [
"{{PUBLIC_URL}}/kibana"
],
"response_types": [
"code"
],
"token_endpoint_auth_method": "none",
"cookie_entry_uri": "{{PUBLIC_URL}}/api/cookie-entry",
"client_uri": "{{PUBLIC_URL}}/kibana"
}]
Sekce seacath-auth:config
¶
Přidá konfiguraci do všech instancí SeaCat Auth ve formátu YAML.
Sekce seacat-auth:content
¶
Stejně jako v sekci files
sekce deskriptoru, toto je seznam záznamů.
Každý záznam je buď název souboru uvnitř adresáře /Site/Files/<service_id>/
nebo záznam klíč:hodnota, kde klíč je název souboru a hodnota je samotný soubor napsaný jako řetězec.
Název souboru musí odpovídat názvu cílové Mongo kolekce.
Interakce s konfigurací NGINX¶
Přítomnost SeaCat Auth v clusteru přidává introspekci do konfigurace NGINX. Introspekční endpoint je přidán a všechny lokace NGINX pocházející z nginx:api
používají tuto introspekci.
S SeaCat Auth v clusteru mohou do backendových služeb projít pouze autorizované požadavky.
Pro interní komunikaci mezi službami použijte internal
HTTP server nginx.
Například, asab-governator
lokace, která vyžaduje introspekční endpoint (zpracovávaný SeaCat Auth)
# GENEROVANÝ SOUBOR!
location /api/asab-governator {
auth_request /_oauth2_introspect;
auth_request_set $authorization $upstream_http_authorization;
proxy_set_header Authorization $authorization;
rewrite ^/api/asab-governator/(.*) /$1 break;
proxy_pass http://upstream-asab-governator-8892;
# GENEROVANÝ SOUBOR!
location = /_oauth2_introspect {
internal;
proxy_method POST;
proxy_set_body "$http_authorization";
proxy_pass http://upstream-seacat-auth-private/nginx/introspect/openidconnect;
proxy_set_header X-Request-URI "$scheme://$host$request_uri";
proxy_ignore_headers Cache-Control Expires Set-Cookie;
proxy_cache oauth2_introspect;
proxy_cache_key "$http_authorization $http_sec_websocket_protocol";
proxy_cache_lock on;
proxy_cache_valid 200 30s;
ZooKeeper v ASAB Maestro¶
ZooKeeper je technologie konsenzu pro ASAB Maestro. Všechny ostatní služby musí komunikovat se ZooKeeperem, aby měly přístup k datům na úrovni clusteru. Proto je řetězec serveru ZooKeeper poskytován jako parametr pro všechny služby a služby ASAB získávají konfigurační sekci [zoookeeper] z technologie ZooKeeper.
Parametry¶
- ZOOKEEPER_SERVERS
-
Adresy všech instancí ZooKeeper, oddělené čárkami. V tříuzlovém clusteru (s uzly pojmenovanými lm1, lm2, lm3) by parametr
ZOOKEEPER_SERVERS
byl nahrazen řetězcemlm1:2181,lm2:2181,lm3:2181
.Příklad
define: type: rc/descriptor name: Webové uživatelské rozhraní ZooKeeper url: https://zoonavigator.elkozmon.com/ descriptor: image: elkozmon/zoonavigator volumes: - "{{SLOW_STORAGE}}/{{INSTANCE_ID}}/logs:/app/logs" environment: HTTP_PORT: "9001" CONNECTION_ZK_NAME: Lokální ZooKeeper CONNECTION_ZK_CONN: "{{ZOOKEEPER_SERVERS}}" AUTO_CONNECT_CONNECTION_ID: ZK BASE_HREF: /zoonavigator
Konfigurace služeb ASAB¶
Každá služba ASAB získává konfigurační sekci zookeeper
.
[zookeeper]
servers=lmc01:2181,lmc02:2181,lmc03:2181
Proměnné prostředí¶
Dostupné pouze pro příslušnou instanci ZooKeeper.
- ZOO_MY_ID
-
Číslo instance každé instance ZooKeeper se stává proměnnou prostředí
ZOO_MY_ID
kontejneru ZooKeeper (Docker). Proto může být přejmenování instancí ZooKeeper v modelu problematické.
Consensus
Konsenzus v ASAB Maestro¶
LogMan.io je klastrová technologie. Tato skutečnost přináší produktu vysokou dostupnost a bezpečnost. Nicméně, také to přináší vyšší složitost systému. Mnoho služeb a mikroslužeb potřebuje komunikovat v rámci klastru a sdílet data. Používáme Apache ZooKeeper jako konsenzuální technologii v distribuovaném systému. V ZooKeeper mají všechny služby přístup ke "společné pravdě" bez ohledu na to, kde v klastru se nacházejí.
Jádro "společné pravdy" je uloženo v /asab
uzlu ZooKeeperu.
Obsah /asab
¶
/asab/ca
- Certifikační autorita/asab/config
- Konfigurace klastru/asab/docker
- uchovává Docker konfiguraci sdílenou v rámci klastru, včetně přihlašovacích údajů pro Docker registry./asab/nodes
- Připojené uzly klastru/asab/run
- data inzerovaná běžícími ASAB mikroslužbami/asab/vault
- úložiště tajemství
Můžete si všimnout, že některé informace o klastru se překrývají. Abychom poskytli spolehlivá data o klastru, používáme vícero zdrojů dat. Můžete si všimnout vícero strategií objevování služeb a víceúrovňového monitoringu.
Certificate Authority¶
ASAB Remote Control vytváří a provozuje interní Certificate Authority (CA).
Technologie využívající CA¶
Elasticsearch¶
Komunikace mezi instancemi Elasticsearch je zabezpečena vlastními certifikáty, které jsou automaticky generovány ASAB Remote Control během instalace ElasticSearch.
Nginx¶
Nginx je ve výchozím nastavení vybaven SSL certifikáty z lokální CA.
Konfigurace Clusteru¶
Ukládá vlastní konfigurační možnosti specifické pro nasazení a velmi často společné pro více služeb v clusteru.
Konfigurace ASAB¶
Microservice ASAB Config je pravděpodobně nejmenší microservice v ekosystému LogMan.io, ačkoli to nesnižuje jeho důležitost. Poskytuje REST API pro obsah konfigurace clusteru, kterou většinou využívá Web UI.
Konfigurace je dostupná a editovatelná z Web UI.
Organizace konfigurace clusteru¶
Konfigurace clusteru je organizována podle konfiguračních typů. Každý typ (např. Průzkumník, Tenants) poskytuje JSON schéma popisující povahu konfiguračních souborů.
Každý konfigurační soubor musí odpovídat JSON schématu svého typu.
Struktura ZooKeeper node /asab/config
:
- /asab/config/
- Průzkumník/
- lmio-system-events.json
- lmio-system-others.json
- Tenants/
- system.json
Příklad JSON schématu asab/config/Tenants
:
{
"$id": "Tenants schema",
"type": "object",
"title": "Tenants",
"description": "Konfigurace dat tenanta",
"default": {},
"examples": [
{
"General": {
"schema": "/Schemas/ECS.yaml",
"timezone": "Europe/Prague"
}
}
],
"required": [],
"properties": {
"General": {
"type": "object",
"title": "Obecná konfigurace tenanta",
"description": "Data specifická pro tenanta",
"default": {},
"required": [
"schema",
"timezone"
],
"properties": {
"schema": {
"type": "string",
"title": "Schéma",
"description": "Absolutní cesta k schématu v knihovně",
"default": [
"/Schemas/ECS.yaml",
"/Schemas/CEF.yaml"
],
"$defs": {
"select": {
"type": "select"
}
},
"examples": [
"/Schemas/ECS.yaml"
]
},
"timezone": {
"type": "string",
"title": "Časová zóna",
"description": "Identifikátor časové zóny, např. Europe/Prague",
"default": "",
"examples": [
"Europe/Prague"
]
}
}
}
},
"additionalProperties": false
}
Příklad /asab/config/Tenants/system.json
:
{
"General": {
"schema": "/Schemas/ECS.yaml",
"timezone": "Europe/Prague"
}
}
Uzly Clusteru¶
Příklad organizace /asab/nodes
:
- /asab/nodes/
- cluster_node_1/
- governator-<uuid>.json
- info.json
- mailbox/
- cluster_node2/
- cluster_node3/
Upozornění
V tomto kapitole je bohužel terminologický rozpor. V ASAB Maestro je slovo "uzel" vyhrazeno pro "clusterový uzel" - typicky izolovaný server připojený k síti s ostatními servery, které tvoří cluster.
Avšak technologie ZooKeeper používá termín "uzel" pro svou strukturu souborů. Uzly ZooKeeper mohou obsahovat jak data, tak i poduzly. V přirovnání k souborovému systému, každý uzel se chová současně jako soubor i adresář. Kde to jen lze, označujeme uzly ZooKeeper jako soubory a adresáře. Když je uzel používán jak k ukládání dat, tak poduzlů, tato zjednodušení nefunguje. Tehdy používáme termíny "clusterový uzel" a "ZooKeeper uzel" pro jasnost.
Clusterový uzel¶
Každý ZooKeeper uzel uvnitř /asab/nodes
(např. cluster_node_1/
) obsahuje IP adresu připojeného clusterového uzlu.
ip:
- 10.25.128.81
Připojení ASAB Governatora¶
Soubor governator-<uuid>.json
obsahuje informace o websocketovém připojení z instance ASAB Governator přítomné na tom clusterovém uzlu.
Každé připojení je označeno uuid pro zamezení překrývání dvou pokusů o připojení. Avšak jeden clusterový uzel by měl vytvořit pouze jedno Remote Control-Governator připojení.
{"address": "10.25.128.81", "rc_node_id": "cluster_node_1"}
Podrobné informace o clusterovém uzlu¶
info.json
obsahuje data o uzlu sesbírané ASAB Governatorem. Aktualizují se pravidelně, ale nejsou uchovávána. Historická data nejsou přítomna. Sledujte místo toho metriky ASAB, InfluxDB a Grafana dashboardy pro získání informací o zdraví clusteru v čase.
Poštovní schránka¶
Adresář mailbox/
pomáhá řídit úkoly mezi dvěma typy služeb.
Instance ASAB Remote Control jsou identické napříč clusterem a mohou se navzájem zastupovat.
Naopak mikroservisy ASAB Governatora jsou pro každý uzel unikátní a nemohou být nahrazeny jinými.
Poštovní schránka (mailbox) funguje jako spojení mezi těmito službami, umožňuje komunikaci a koordinaci úkolů.
Když uživatel odešle instrukce z Web UI, poštovní schránka pomáhá instancím ASAB Remote Control najít a komunikovat s příslušným ASAB Governatorem pro provedení úkolu.
Instance ASAB Remote Control s pokyny od uživatele "odesílá zprávu" instanci ASAB Remote Control s cílovým připojením ASAB Governatora.
Spuštění mikroservis ASAB¶
Každá instance mikroservisy ASAB může aktivně inzerovat data o sobě do konsensu.
Používají se efemérní a sekvenční uzly ZooKeeper. To znamená, že:
- Každá běžící instance vytvoří uzel ZooKeeper.
- Každý uzel je připojen k běžící mikroservise. Když se mikroservisa zastaví, uzel ZooKeeper zmizí.
Co se můžete dozvědět z těchto dat o každé instanci mikroservisy ASAB:
- Instance je spuštěná a běží
- Klastr uzlu, na kterém běží
- Technologie kontejnerizace (Docker, Podman nebo žádná)
- Verze image a kdy a jak byla vytvořena
- Čas, kdy byl kontejner vytvořen a spuštěn
- Port otevřený pro webové požadavky
- Zdravotní stav, pokud taková mikroservisa může indikovat
Tato data inzerovaná běžícími mikroservisami ASAB jsou mezi vstupy monitorování klastru a slouží pro objevování služeb.
Příklad uzlu /asab/run
ZooKeeper:
- /asab/run/
- ASABConfigApplication.0000000108
- ASABConfigApplication.0000000115
- ASABConfigApplication.0000000144
- ASABGovernatorApp.0000000095
- ASABGovernatorApp.0000000098
- ASABGovernatorApp.0000000104
- ASABLibraryApplication.0000000113
- ASABLibraryApplication.0000000114
- ASABLibraryApplication.0000000147
- ASABRemoteControlApp.0000000109
- ASABRemoteControlApp.0000000110
- ASABRemoteControlApp.0000000107
Příklad uzlu /asab/run/ASABConfigApplication.0000000108
:
{
"host": "asab-config-3",
"appclass": "ASABConfigApplication",
"launch_time": "2023-12-19T09:52:46.468038Z",
"process_id": 1,
"instance_id": "asab-config-3",
"node_id": "lmc03",
"service_id": "asab-config",
"containerized": true,
"created_at": "2023-11-06T17:18:54.206827Z",
"version": "v23.45",
"CI_COMMIT_TAG": "v23.45",
"CI_COMMIT_REF_NAME": "v23.45",
"CI_COMMIT_SHA": "cf3be4570f363b8e9ed400ffbaea8babac957688",
"CI_COMMIT_TIMESTAMP": "2023-11-06T17:15:54+00:00",
"CI_JOB_ID": "55305",
"CI_PIPELINE_CREATED_AT": "2023-11-06T17:16:58Z",
"CI_RUNNER_ID": "74",
"CI_RUNNER_EXECUTABLE_ARCH": "linux/amd64",
"web": [
[
"0.0.0.0",
8894
]
]
}
Kontejnery spravované ASAB Maestro¶
Hostname a název kontejneru¶
hostname
a container_name
je nastaven na INSTANCE_ID
(např. mongo-1
).
/etc/hosts
¶
/etc/hosts
je poskytnut ASAB Maestrem s názvy a IP adresami všech instancí v clusteru.
To je používáno pro účely průzkumu služeb.
Příklad /etc/hosts
:
# Tento soubor je generován ASAB Remote Control
# VAROVÁNÍ: NEUPRAVUJTE HO RUČNĚ !!!
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
# Uzly
192.168.64.1 node1
192.168.64.2 node2
# Instance
192.168.64.1 zoonavigator-1
192.168.64.1 nginx-1
192.168.64.1 mongo-1
192.168.64.1 seacat-auth-1
192.168.64.2 zookeeper-1
192.168.64.2 asab-governator-1
192.168.64.2 asab-library-1
192.168.64.2 asab-config-1
Poznámka
Soubor hosts
se nachází na /opt/site/hosts
a je připojen do kontejnerů.
Proměnné prostředí¶
Následující proměnné prostředí jsou dostupné každé instanci:
NODE_ID
SERVICE_ID
INSTANCE_ID
Poznámka
Další proměnné prostředí mohou být poskytnuty technologiemi.
Průzkum Služeb¶
Průzkum služeb v ASAB Maestro představuje skupinu technik, jak nalézt a dosáhnout specifickou službu v síti clusteru.
Identita¶
Každé instanci jsou přiřazeny tři identifikátory:
- NODE_ID - identifikátor uzlu clusteru
- SERVICE_ID - jméno služby
- INSTANCE_ID - identifikátor instance
Tímto způsobem je umožněno hledat služby v různých situacích podle stejných jmen.
NGINX proxy server¶
Možnost nginx:api
v deskriptorech vytváří standardizovanou konfiguraci Nginx.
Příklad deskriptoru ASAB Library:
define:
type: rc/descriptor
name: ASAB Library
descriptor:
image: docker.teskalabs.com/asab/asab-library
volumes:
- "{{SITE}}/{{INSTANCE_ID}}/conf:/conf:ro"
- "{{SLOW_STORAGE}}/{{INSTANCE_ID}}:/var/lib/asab-library"
asab:
configname: conf/asab-library.conf
config: {}
nginx:
api: 8893
Všechny instance jsou dodávány s umístěním uvnitř konfigurace Nginx.
location /api/<instance_id> {
...
}
Navíc, každá služba má své vlastní umístění a odpovídající záznam upstreams. Váš požadavek je proxyován na náhodnou instanci služby.
location /api/<service_id> {
...
}
Tato umístění jsou přístupná na:
- HTTPS serveru za OAuth2 introspekcí (pokud je nainstalován autorizační server jako například SeaCat Auth) určené především pro Web UI,
- a
interním
serveru. Tento server je přístupný z vnitřku clusteru, nesmí být otevřen pro internet a slouží pro interní komunikaci backendových služeb.
PUBLIC_URL
Je klíčové pro funkčnost HTTPS serveru a úspěšné autorizace nastavit parametr PUBLIC_URL v modelu.
define:
type: rc/model
services:
zoonavigator:
instances: {1: {node: "lmc01"} }
params:
PUBLIC_URL: "https://maestro.logman.io"
Vlastní /etc/hosts
¶
Každému běžícímu kontejneru je poskytnuta vlastní a automaticky aktualizovaná konfigurace uvnitř /etc/hosts
. IP adresa každé služby nebo instance je rozřešena pomocí příslušných INSTANCE_ID nebo SERVICE_ID.
Příklad /etc/hosts
uvnitř kontejneru:
# Tento soubor je generován ASAB Remote Control
# UPOZORNĚNÍ: NEMODIFIKUJTE HO RUČNĚ !!!
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
# Uzly
10.35.58.41 lmc02
10.35.58.194 lmc03
10.35.58.88 lmc01
# Instance
10.35.58.88 zoonavigator-1
10.35.58.88 mongo-1
10.35.58.41 mongo-2
10.35.58.194 mongo-3
10.35.58.88 seacat-auth-1
10.35.58.88 nginx-1
10.35.58.88 asab-config-1
10.35.58.41 asab-config-2
10.35.58.194 asab-config-3
10.35.58.88 asab-governator-1
10.35.58.41 asab-governator-2
10.35.58.194 asab-governator-3
10.35.58.88 asab-library-1
10.35.58.41 asab-library-2
10.35.58.194 asab-library-3
10.35.58.88 asab-remote-control-1
10.35.58.41 asab-remote-control-2
10.35.58.194 asab-remote-control-3
10.35.58.88 zookeeper-1
10.35.58.41 zookeeper-2
10.35.58.194 zookeeper-3
# Služby
10.35.58.88 zoonavigator
10.35.58.88 mongo
10.35.58.41 mongo
10.35.58.194 mongo
10.35.58.88 seacat-auth
10.35.58.88 nginx
10.35.58.88 asab-config
10.35.58.41 asab-config
10.35.58.194 asab-config
10.35.58.88 asab-governator
10.35.58.41 asab-governator
10.35.58.194 asab-governator
10.35.58.88 asab-library
10.35.58.41 asab-library
10.35.58.194 asab-library
10.35.58.88 asab-remote-control
10.35.58.41 asab-remote-control
10.35.58.194 asab-remote-control
10.35.58.88 zookeeper
10.35.58.41 zookeeper
10.35.58.194 zookeeper
Konsenzus a data propagovaná běžícími ASAB mikroslužbami¶
Každá ASAB mikroslužba propaguje data o sobě do konsenzu. Tato data obsahují NODE_ID, SERVICE_ID a INSTANCE_ID rozřešené díky vlastnímu /etc/hosts
a portu. ASAB framework také nabízí vzorový kód pro použití aiohttp
klientských požadavků s pouze SERVICE_ID nebo INSTANCE_ID cílové služby. Tímto způsobem má každá ASAB mikroslužba nástroje pro přístup k jakékoliv jiné ASAB mikroslužbě v clusteru.
Příklad python kódu v rámci ASAB aplikace používající Průzkum Služeb
async def proxy_to_iris(self, json_data):
async with self.App.DiscoveryService.session() as session:
try:
async with session.put("http://asab-iris.service_id.asab/send_mail", json=json_data) as resp:
response = await resp.json()
except asab.api.discovery.NotDiscoveredError:
raise RuntimeError("ASAB Iris nemohl být dosažen.")
ASAB Governator¶
ASAB Governator - nebo asab-governator
- je mikroslužba, která musí běžet na každém uzlu clusteru.
Připojení k ASAB Remote Control¶
ASAB Governator je připojen k ASAB Remote Control.
Lokální (tj. localhost
) připojení je preferované pro základní uzly, ale ASAB Governator se připojí k jiným instancím ASAB Remote Control, pokud není přítomna lokální instance.
ASAB Governator se nakonec znovu připojí (pokud je to možné) k lokální instanci.
Údržba¶
ASAB Governator pravidelně plánuje spouštění příkazu docker system prune
k odstranění starých a nepoužívaných obrazů kontejnérů a dalších dat.
Sloučovací algoritmus¶
Tento algoritmus je nedílnou součástí kompozitelnosti v ASAB Maestro.
ASAB Maestro komponuje různé artefakty do konfigurace webu. V příkladech:
- Můžete přepsat popisovač v modelu
- Generovaná konfigurace Elasticsearch je poskytována každému konfiguračnímu souboru každé mikroservisy ASAB.
Každé prohlášení nebo konfigurace může být transformováno do objektu (nebo Python slovníku) nebo pole (nebo Python seznamu) nebo jejich kombinace.
Sloučovací algoritmus bere dva objekty (slovníky) s prioritou. Jeden objekt je vždy "důležitější". Když začnou objekty slučovat dohromady, jejich obsah se porovnává. Pokud je jejich obsah zcela odlišný, výsledný objekt obsahuje všechny informace z obou. Při konfliktu, když oba objekty obsahují stejný klíč, pouze hodnota z "důležitějšího" objektu se zahrne do výsledku. Pokud jsou porovnávány dvě pole, výsledek je součet polí (seznamů).
Event Lane Manager
LogMan.io Správce Event Lane¶
TeskaLabs LogMan.io Správce Event Lane (nebo zkráceně LogMan.io Elman) je mikroslužba zodpovědná za správu event lane.
- Přečtěte si více o event lane a jejich deklaracích v Event Lane.
- Přečtěte si více o funkcionalitě LogMan.io Elman a automatickém vytváření event lane v Streams.
- Pro nasazení mikroslužby LogMan.io Elman viz Konfigurace.
Note
LogMan.io Elman je náhledová funkce, která se v budoucnu stane standardní součástí TeskaLabs LogMan.io.
Konfigurace¶
Závislosti¶
- Apache Zookeeper je použit pro čtení konfigurace tenantů.
- Apache Kafka je použita pro správu Kafka témat a automatickou detekci nových streamů.
- ASAB Remote Control je potřeba pro vytvoření LMIO Parsecs.
- ASAB Library je potřeba pro nahrávání event lanes do knihovny.
Požadovaná konfigurace¶
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
[library]
providers=
zk:///library
# (více vrstev, pokud je potřeba...)
Volitelná konfigurace¶
Volitelně lze počet partišonů a politiku uchovávání konfigurovat v sekci [kafka]
.
[kafka]
enabled=true # Lze vypnout
partitions=6 # (výchozí: 6) Výchozí počet partišonů Kafka přijatých, událostí a dalších témat
retention.ms_max=604800000 # (výchozí: 7 dní) Maximální doba uchovávání Kafka témat, snížena na optimální, pokud je vyšší
retention.ms_min=172800000 # (výchozí: 24 hodin) Minimální doba uchovávání Kafka témat, zvýšena na optimální, pokud je nižší
retention.ms_optimal=259200000 # (výchozí: 3 dny) Optimální doba uchovávání Kafka témat
Event lane¶
Když připojíte nový logovací zdroj do LogMan.io Collector, který je přiřazen k jednomu tenantovi, události se začnou posílat do LogMan.io Archive. LogMan.io Receiver vytvoří nový stream pro tyto události, aby je ukládal v logickém pořadí. Proto každý tenant vlastní několik streamů. Události z konkrétního streamu mohou být (okamžitě nebo později) vytaženy z Archivu pro parsování a ukládání do databáze Elasticsearch pro další analýzu.
K vytvoření logického datového streamu v LogMan.io (z Archivu přes Kafka do Elasticsearch) a propojení přilehlého obsahu v Library (dashboardy, reporty, korelace, atd.), se používá koncept event lane. Event lane je reprezentován deklarací v Library, která určuje:
- Jaká pravidla pro parsování budou aplikována na datový stream
- Jaký obsah z Library je přiřazen k datovému streamu
- Kategorizace datového streamu (např. kategorizace technologie, která produkuje tyto události)
- Jaké schéma je použito pro konečná strukturovaná data
- Jaké další obohacení bude aplikováno na stream
- Konfigurace technologií pracujících s daty (Kafka, Elasticsearch)
Následující obrázek ilustruje proces na příkladu, kde je připojen nový logovací zdroj
(Fortinet FortiGate) (pod operujícím tenantem mytenant
):
- LogMan.io Receiver sbírá přicházející události a ukládá data do Archivu ve streamu
fortinet-fortigate-10110
pro tenantmytenant
. - Tyto události mohou být z Archivu vytaženy zpět pro parsování. Jsou poslány do Kafka topicu
received.mytenant.fortinet-fortigate-10110
. - LogMan.io Elman detekuje tento topic, přiřadí nový event lane a vytvoří jednu nebo více instancí LogMan.io Parsec.
- LogMan.io Parsec konzumuje syrové události z tohoto topicu a posílá úspěšně zparsované události a nezparsované události do Kafka topiců
events.mytenant.fortinet-fortigate-10110
aothers.mytenant
, resp. - LogMan.io Depositor konzumuje události z těchto topiců a ukládá je do Elasticsearch indexů
lmio-mytenant-events-fortinet-fortigate-10110
almio-mytenant-others
.
Deklarace event lane¶
Deklarace event lane je specifikována v YAML souboru v Library.
Následující příklad je deklarace event lane pro logovací zdroj Microsoft 365 a tenant mytenant
:
define:
name: Microsoft 365
type: lmio/event-lane
timezone: UTC
parsec:
name: /Parsers/Microsoft/365/
content:
reports: /Reports/Microsoft/365/
dashboards: /Dashboards/Microsoft/365/
kafka:
received:
topic: received.mytenant.microsoft-365-v1
events:
topic: events.mytenant.microsoft-365-v1
others:
topic: others.mytenant
elasticsearch:
events:
index: lmio-mytenant-events-microsoft-365-v1
others:
index: lmio-mytenant-others
Definice¶
Část define
specifikuje typ deklarace a
vlastnosti event lane použité pro parsování a analýzu dat, jako je použité schéma, časové pásmo a znaková sada.
define:
name: Microsoft 365
type: lmio/event-lane
schema: /Schemas/ECS.yaml # (volitelné, výchozí: /Schemas/ECS.yaml)
timezone: Europe/Prague # (volitelné, výchozí je získáno z konfigurace tenanta)
charset: utf-8 # (volitelné, výchozí: utf-8)
Parsec¶
Sekce parsec
se odkazuje na mikroservisu LogMan.io Parsec. Konkrétně, parsec/name
je adresář pro parsovací pravidla v Library. Musí vždy začínat /Parsers/
:
parsec:
name: /Parsers/Microsoft/365/
Obsah¶
Sekce content
se odkazuje na obsah event lane v Library, jako jsou dashboardy, reporty, korelace, atd.
Když je vytvořen nový event lane, LogMan.io Elman automaticky povolí obsah popsaný v této sekci.
content:
# Celý adresář, popsán jako jeden řetězec
dashboards: /Dashboards/Microsoft/365/
# Více položek popsáno jako seznam
reports:
- /Reports/Microsoft/365/Daily Report.json
- /Reports/Microsoft/365/Weekly Report.json
- /Reports/Microsoft/365/Monthly Report.json
Kafka, Elasticsearch¶
Sekce kafka
a elasticsearch
specifikují vlastnosti Kafka topiců a Elasticsearch indexů, které patří k onomu event lane. Tyto jsou důležité pro LogMan.io Parsec a LogMan.io Depositor.
Nejdůležitější vlastnost je název received
, events
, a others
topiců a lmio-events
a lmio-others
indexů.
Kafka topic následuje pojmenovací konvenci:
<type>.<tenant>.<stream>
Elasticsearch indexy následují pojmenovací konvenci:
lmio-<tenant>-<type>-<stream>
kde:
type
může býtreceived
,events
neboothers
tenant
je název tenantastream
je název logovacího streamu
kafka:
received:
topic: received.mytenant.microsoft-365-v1
events:
topic: events.mytenant.microsoft-365-v1
others:
topic: others.mytenant
elasticsearch:
events:
index: lmio-mytenant-events-microsoft-365-v1
others:
index: lmio-mytenant-others
Poznámka
Každý tenant má pouze jeden others
topic, proto zde není specifikace streamu v topicu a indexu others
.
Dále jsou v sekci elasticsearch
konfigurovány další vlastnosti Elasticsearch (např. počet shardů, životní cyklus indexů atd.). Více se dočtete v dokumentaci LogMan.io Depositor.
Deklarace šablony event lane¶
Pro automatické přiřazení parsovacích pravidel a obsahu z Library se používají šablony event lane. Když je nalezen nový stream, LogMan.io Elman hledá vhodnou šablonu event lane. Když ji najde, nový event lane je automaticky naplněn vlastnostmi z této šablony.
Následující příklad ilustruje šablonu event lane pro logovací zdroj Microsoft 365:
---
define:
type: lmio/event-lane-template
name: Microsoft 365
stream: microsoft-365-v1
timezone: UTC
logsource:
vendor:
- microsoft
product:
- m365
service:
- audit
- activitylogs
parsec:
name: /Parsers/Microsoft/365
content:
dashboards: /Dashboards/Microsoft/365
reports: /Reports/Microsoft/365
Definice¶
define:
type: lmio/event-lane-template
name: Microsoft 365
stream: microsoft-365-v1
timezone: UTC
- name: Člověkem čitelný název pro event lane, odvozený z technologie logovacího zdroje. Používá se např. pro konfiguraci Průzkumníka (Discover).
- stream: Název, který bude shodný s aktuálním streamem.
Může zde být přesná shoda (jako např.
microsoft-365-v1
), ale zástupné znaky (např.*
) jsou povoleny, aby pokryly širokou škálu streamů (např.fortinet-fortigate-*
). - timezone (volitelné): Různé logovací zdroje zasílají události v pevně stanoveném časovém pásmu (např. Microsoft 365 používá vždy UTC). Aby to bylo zohledněno, může zde být předepsáno časové pásmo. Jinak je každá event lane řešena ručně.
Kategorizace¶
Sekce logsource
se používá pro kategorizaci logovacího zdroje připojeného k event lane.
Je odvozena z Sigma pravidel.
logsource:
vendor:
- microsoft
product:
- m365
service:
- audit
- activitylogs
Parsec¶
Možnost parsec/name
je adresář pro parsovací pravidla v Library. Musí vždy začínat /Parsers/
:
parsec:
name: /Parsers/Microsoft/365
Obsah¶
Sekce content
se odkazuje na obsah event lane v Library, jako jsou dashboardy, reporty, korelace, atd.
LogMan.io Elman automaticky deaktivuje každý obsah ze všech šablon event lane. Když je vytvořen nový event lane, jeho obsah je povolen.
content:
# Celý adresář, popsán jako jeden řetězec
dashboards: /Dashboards/Microsoft/365
# Více položek popsáno jako seznam
reports:
- /Reports/Microsoft/365/Daily Report.json
- /Reports/Microsoft/365/Weekly Report.json
- /Reports/Microsoft/365/Monthly Report.json
Streamy v LogMan.io Elman¶
Detekce nových streamů v LogMan.io Elman¶
LogMan.io Elman periodicky detekuje received.*
témata v Kafka clusteru.
Pokud je nalezeno nové received
téma bez existujícího event lane, je vytvořen nový event lane použitím šablon event lane.
Pro známé zdroje existuje šablona event lane, která se primárně používá k výběru pravidel parsování pro daný event lane.
LogMan.io Elman hledá vhodnou šablonu v /Templates/EventLanes/
. Může nastat jedna z následujících situací:
-
Šablona event lane je nalezena v knihovně. Pravidla parsování a další specifický obsah jsou poté zkopírovány do event lane. Poté je vygenerován model pro LogMan.io Parsec v
/Site/
a LogMan.io Elman posílá UP příkaz do ASAB Remote Control. Na závěr je veškerý obsah uvedený v event lane povolen v knihovně. -
Šablona event lane není nalezena v knihovně. Poté je vytvořen event lane, ale cesta pro pravidla parsování není vyplněna, stejně jako další specifický obsah event lane. Model není vytvořen automaticky. Je vyžadován zásah uživatele. Uživatel může vhodná pravidla parsování vyplnit ručně v deklaraci event lane. Nakonec je možné všechny modely ručně aktualizovat z terminálu pomocí curl:
curl --location --request PUT 'localhost:8954/model'
Nakonec se vytvoří jeden nebo více instance LogMan.io Parsec a proces parsování začíná.
Kafka témata¶
LogMan.io Elman aktualizuje vlastnosti Kafka received.*
, events.*
a others.*
témat.
Zejména se zvýší počet oddílů pro každé téma a nastaví se politika uchovávání. Podívejte se na Konfigurace pro více detailů.
Obsah knihovny¶
LogMan.io Elman zakáže každý obsah ze všem šablon event lane v knihovně. Když je vytvořen nový event lane, jeho obsah je automaticky povolen pro tenant daného event lane.
Integrační služba
LogMan.io Integrační Služba¶
TeskaLabs LogMan.io Integrační Služba (LMIO Integ pro zkrácení) umožňuje TeskaLabs LogMan.io být integrován s podporovanými externími systémy prostřednictvím očekávaného formátu zprávy a výstupního/vstupního protokolu.
Konfigurace¶
- Výchozí port:
8959
LMIO Integ vyžaduje pouze minimální konfiguraci:
[zookeeper]
servers=zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181
[kafka]
bootstrap_servers=kafka-1:9092,kafka-2:9092,kafka-3:9092
[library]
providers=/library
Integrace jsou specifikovány v událostních lanech.
Event Lane¶
Integrace jsou deklarovány v event lanech. Každý event lane může poskytovat jednu nebo více integrací. Události jsou vždy odesílány z Kafka events
tématu, které musí být přítomno v deklaraci event lane.
---
define:
type: lmio/event-lane
name: Fortinet FortiGate (10040)
kafka:
events:
topic: events.mytenant.fortinet-fortigate-10040 # (povinné)
others:
topic: others.mytenant
integrations:
arcsight:
output_type: tcp
address: "127.0.0.1 8884"
# další konfigurace pro integraci arcsight
bsd_syslog:
output_type: tcp
address: "127.0.0.1 7999"
# další konfigurace pro integraci bsd syslog
output_type:
- tcp: Odesílá zprávy prostřednictvím TCP protokolu. Vyžaduje address.
- kafka: Odesílá zprávy do vyhrazeného Kafka tématu, ze kterého je může spotřebovat jiná služba.
address: Adresa ve formátu: "cílový port", např. 127.0.0.1 8888
Integrace¶
Micro Focus ArcSight SOAR¶
Integrace s Micro Focus ArcSight SOAR odesílá zpracované události z events
tématu ve formátu ArcSight Common CEF.
Konfigurace:
arcsight:
output_type: tcp
address: "127.0.0.1 8884"
Schéma:
---
define:
type: lmio/schema
deviceEventClassId_field: deviceEventClassId
name_field: name
severity_field: severity
Příklad výstupu
CEF:0|TeskaLabs|LogMan.io|1.0|<deviceEventClassId_field>|<name_field>|<severity_field>| {
"@timestamp": "2024-09-30T02:30:13.343068Z",
"ecs.version": "1.10.0",
"event.action": "high-download-rate",
"event.dataset": "complex",
"event.kind": "alert",
"related.events": [],
"rule.description": "Tento baseliner sleduje protokoly, které naznačují aktivitu stahování souborů, a kontroluje, zda uživatel překračuje očekávanou rychlost stahování. Sledování aktivity stahování probíhá v definovaném období (den) a regionu (Česká republika), analyzující vzorce na základě pracovních dnů, víkendů a svátků. Když rychlost stahování uživatele překročí normální chování o významnou hodnotu (3 směrodatné odchylky nad průměrem), spustí se upozornění pro další vyšetřování.\n",
"rule.id": "",
"rule.name": "Vysoká rychlost stahování",
"rule.ruleset": "lmio-library",
"tenant": "plus",
"threat.indicator.sightings": 22,
"user.id": "dolores_umbridge@hogwarts.uk",
"_id": "9c15c30d30b3b813df94393288310d17ff06364f6e9cb5bb8d374ec1ca6dd6a0"
}
BSD Syslog¶
Integrace, která produkuje události ve formátu BSD Syslog.
Konfigurace:
bsd_syslog:
output_type: tcp
address: "127.0.0.1"
Schéma:
---
define:
type: lmio/schema
raw: event.original
principal_datetime: '@timestamp'
Příklad výstupu
<14> Oct 01 12:43:25 lmio LogMan.io[1]: <30>Oct 01 12:43:13 bradavice-hagrid ntopng[1007416]: ....
Pole¶
Integrace pole produkuje události se specifickým polem.
field:
output_type: tcp
address: "127.0.0.1"
field_name: "event.original"
Příklad výstupu
{
"event.original": <30>Oct 01 12:43:13 bradavice-hagrid ntopng[1007416]: ....
}
Autorizace a Autentizace¶
TeskaLabs LogMan.io používá TeskaLabs SeaCat Auth jako komponentu, která se zabývá autorizací uživatelů, autentizací, řízením přístupu, rolemi, tenanti, vícefaktorovou autentizací, integracemi s jinými poskytovateli identity a podobně.
TeskaLabs SeaCat Auth má svůj vlastní dokumentační web.
Funkce¶
- Autentizace
- Dvoufaktorová autentizace (2FA) / Vícefaktorová autentizace (MFA)
- Podporované faktory:
- Heslo
- FIDO2 / Webauthn
- Jednorázové heslo založené na čase (TOTP)
- SMS kód
- Hlavicka požadavku (X-Header)
-
Stroj-na-stroj
- API klíče
-
Autorizace
- Role
-
Správa identit
- Federace identit
- Podporovaní poskytovatelé:
- Soubor (htpasswd)
- In-memory slovník
- MongoDB
- ElasticSearch
- LDAP a Active Directory
- Vlastní poskytovatel
-
Multitenance včetně správy tenantů pro další služby a aplikace
- Správa relací
- Jednotné přihlášení
- OpenId Connect / OAuth2
- Proof Key for Code Exchange aka PKCE pro veřejné klienty OAuth 2.0
- Backend introspekce autorizace/autentizace pro NGINX
- Audit trail
- Provisioning mód
- Strukturované logování (Syslog) a telemetrie
LogMan.io Velitel¶
LogMan.io Velitel umožňuje spouštět následující užitečné příkazy přes příkazovou řádku nebo API.
Přikaz encpwd
¶
Hesla používaná v konfiguracích mohou být chráněna šifrováním.
Příkaz pro šifrování hesel šifruje heslo(a) do formátu hesla LogMan.io pomocí šifry AES.
Hesla jsou pak použita v deklarativní konfiguraci LogMan.io Kolektora v následujícím formátu:
!encpwd "<LMIO_PASSWORD>"
Konfigurace¶
Výchozí cesta ke klíči AES může být nastavena následujícím způsobem:
[pwdencryptor]
key=/data/aes.key
Použití¶
Docker kontejner¶
Příkazová Řádka¶
docker exec -it lmio-commander lmiocmd encpwd MyPassword
API¶
LogMan.io Velitel také slouží jako API endpoint, takže příkaz encpwd
lze dosáhnout přes HTTP požadavek:
curl -X POST -d "MyPassword" http://lmio-commander:8989/encpwd
Přikaz library
¶
Příkaz Library slouží k vložení struktury složky knihovny se všemi YAML deklaracemi do ZooKeeperu, odkud si ji ostatní komponenty jako LogMan.io Parser a Korrelátor mohou dynamicky stahovat.
Struktura složky může být umístěna v souborovém systému (namontovaná do Docker kontejneru) nebo na URL adrese GIT.
Takto se inicializuje načítání knihovny do ZooKeeper clusteru:
Konfigurace¶
Je nutné správně nakonfigurovat zdrojovou složku a výstupní cestu pro ZooKeeper.
[source]
path=/library
[destination]
urls=zookeeper:12181
path=/lmio
Zdrojová cesta může být cesta GIT repozitáře s předponou git://
:
[source]
path=git://<username>:<deploy_token>@<git_url_path>.git
Tímto způsobem bude knihovna automaticky klonována z GITu do dočasné složky, nahrána do ZooKeeperu a následně dočasná složka smazána.
Použití¶
Docker kontejner¶
Příkazová Řádka¶
docker exec -it lmio-commander lmiocmd library load
S explicitně definovanou konfigurací:
docker exec -it lmio-commander lmiocmd -c /data/lmio-commander.conf library load
API¶
LogMan.io Velitel také slouží jako API endpoint, takže příkaz library
lze dosáhnout přes HTTP požadavek:
curl -X PUT http://lmio-commander:8989/library/load
Podívejte se na oddíl Docker Compose níže.
Přikaz iplookup
¶
Příkaz iplookup
zpracovává databáze IP rozsahů a generuje IP lookup soubory připravené k použití s lmio-parser IP Enricher.
Má dva podpříkazy: iplookup from-csv
pro zpracování obecných CSV souborů a iplookup from-ip2location
pro zpracování CSV souborů IP2LOCATION.
Konfigurace¶
Zdrojové a cílové adresáře lze nastavit v konfiguračním souboru
[iplookup]
source_path=/data
destination_path=/data
iplookup from-csv
¶
Načítá obecný CSV soubor a vytváří soubor lookup IP Enricher.
První řádek souboru by měl obsahovat hlavičku se jmény sloupců.
První dva sloupce musí být ip_from
a ip_to
.
Interface příkazové řádky¶
lmiocmd.py iplookup from-csv [-h] [--separator SEPARATOR] [--zone-name ZONE_NAME] [--gzip] [--include-ip-range] file_name
Povinné argumenty:
file_name
: Vstupní CSV soubor
Volitelné argumenty:
-h
,--help
: Zobrazí tuto nápovědu a ukončí program.-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 reprezentována jako řetězec, např. ::ffff:c000:02eb,ipv4
: standardní quad-dotted IPv4 adresa jako řetězec, např. 192.0.2.235,ipv6-int
: IPv6 adresa jako 128-bitové desetinné celé číslo, např. 281473902969579,ipv4-int
: IPv4 adresa jako 32-bitové desetinné celé číslo, např. 3221226219.-s SEPARATOR
,--separator SEPARATOR
: Oddělovač sloupců CSV.-o LOOKUP_NAME
,--lookup-name LOOKUP_NAME
: Název výstupního lookupu. Používá se jako název zóny lookupu. Ve výchozím nastavení je odvozeno od názvu vstupního souboru.--include-ip-range
: Zahrnout pole ip_from a ip_to do hodnot lookupu.--force-ipv4
: Zabránit mapování IPv4 adres na IPv6. Toto je nekompatibilní s IPv6 vstupními formáty.
Ukázkové 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ý příkazu iplookup from-csv
, ale je speciálně navržen pro zpracování IP2Location™ CSV databází.
V případě IP2LOCATION LITE databází může příkaz odvodit formát vstupních IP a názvy sloupců z názvu souboru.
Nicméně je možné explicitně specifikovat názvy sloupců
Interface příkazové řádky¶
lmiocmd.py iplookup from-csv [-h] [--separator SEPARATOR] [--zone-name ZONE_NAME] [--gzip] [--include-ip-range] file_name
Povinné argumenty:
file_name
: Vstupní CSV soubor
Volitelné argumenty:
-h
,--help
: Zobrazí tuto nápovědu a ukončí program.-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
: Mezery oddělený seznam názvů sloupců k použití. 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 128-bitové desetinné celé číslo, např. 281473902969579,ipv4-int
: IPv4 adresa jako 32-bitové desetinné celé číslo, např. 3221226219.-o LOOKUP_NAME
,--lookup-name LOOKUP_NAME
: Název výstupního lookupu. Používá se jako název zóny lookupu. Ve výchozím nastavení je odvozen z názvu vstupního souboru.-e, --keep-empty-rows
: Nevyřazovat řádky s prázdnými hodnotami (označené '-').--include-ip-range
: Zahrnout pole ip_from a ip_to do hodnot lookupu.--force-ipv4
: Zabránit mapování IPv4 adres na IPv6.
Ukázkové použití¶
S automatickými názvy sloupců a formátem vstupních IP:
lmiocmd iplookup from-ip2location \
--lookup-name ip2country \
--gzip \
IP2LOCATION-LITE-DB1.IPV6.CSV
S explicitními názvy sloupců a formátem vstupních IP (výsledek bude ekvivalentní 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 image LogMan.io Velitele
z TeskaLabs Docker Registry a očekává konfigurační soubor
ve složce ./lmio-commander
.
version: '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 k repozitáři knihovny LogMan.io.
Spustit kontejner¶
docker-compose pull
docker-compose up -d
Deklarativní jazyk SP-Lang¶
TeskaLabs LogMan.io používá SP-Lang jako deklarativní jazyk pro parsery, obohacovače, korelátory a další komponenty.
SP-Lang má svůj vlastní dokumentační web.
Elastic Common Schema (ECS)¶
Pro více informací, viz oficiální dokumentaci.
Tabulka obecných atributů ECS¶
Atribut | Popis | Hodnoty jako příklad |
---|---|---|
@timestamp | Datum/čas, kdy událost vznikla. | 2022-05-23T08:05:34.853Z |
client.ip | IP adresa zařízení použitá při zaznamenání aktivity. IP adresa je zobrazena 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í použitá při zaznamenání aktivity. | 85.162.11.26 |
ecs.version | Verze ECS, které tato událost odpovídá. | 1.0.0 |
event.action | Popis původní události, která spustila vytvoření konkrétního logu. | UserLoggedIn, MessageTrace, FilePreviewed |
event.original | Kompletní a nemodifikovaný log pro auditování. | 10.42.42.42 - - [07/Dec ... |
http.request.method | HTTP požadavek je akce, která má být provedena na zdroj identifikovaný danou URL žádostí. | get |
http.response.body.bytes | Velikost HTTP požadavku v bajtech. | 2571 |
http.response.status_code | Kódy stavu HTTP odpovědí ukazují, zda byl konkrétní HTTP požadavek úspěšně dokončen. | 200 |
http.version | Současná verze Hypertext Transfer Protocolu. | 1.1 |
host.hostname | Hostname hostitele. | webserver-blog-prod |
message | Textová reprezentace významných informací z události pro stručné zobrazení v prohlížeči logů. | "GET /blog HTTP/1.1" 200 2571 |
service.name | Vaše vlastní jméno pro tuto službu. | Company blog |
service.type | Typ služby použité s touto instancí. | apache |
source.geo.* | Pole pro geo-lokaci. | |
url.original | Původní cesta url. | /blog |
user.name | Jméno uživatele. | Albus Dumbledore |
user_agent.* | Pole popisující uživatelský agent. | |
event.dataset | Jméno datové sady. | microsoft-office-365 |
event.id | Unikátní identifikační hodnota. | b4b4c44c-ff30-4ddd-bfbe-44e082570800 |
event.ingested | Časové razítko, kdy událost dorazila 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í, jak s těmito druhy událostí zacházet. | alert, enrichment, event, metric, state, pipeline_error, signal |
log.original | Surový formát logu, který je přijat před realizačním procesem. | <165>Jan 17 12:20:25 hostname %ASA-5-111010: User 'harry', running 'N/A' from IP 192.68.0.2, executed 'write memory' |
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 tenantů v každé události. | default |
user.id | Uživatelská identifikace každé události. | automata@teskalabs.com |
Knihovna v TeskaLabs LogMan.io¶
Knihovna obsahuje deklarace pro analyzátory, obohacovače, korelátory, šablony pro e-maily a instantní zprávy, dashboardy, zprávy a další obsah TeskaLabs LogMan.io.
Organizace knihovny¶
Knihovna je organizována do složek s položkami, podobně jako soubory v souborovém systému.
Následující příklad ilustruje organizaci knihovny se třemi základními složkami /Baselines/
, /Dashboards/
a /Parsers/
:
/Baselines/
Dataset.yaml
Host.yaml
User.yaml
/Dashboards/
Linux/
Common/
Overview.json
/Parsers/
Linux/
Auditd/
10_parser.yaml
20_enricher.yaml
30_mapping_ECS.yaml
Common/
10_parser.yaml
20_parser_process.yaml
30_parser_message.yaml
Pravidla pro cesty knihovny
Vnitřně (v konfiguraci mikroservis atd.) musí cesty knihovny splňovat tato pravidla:
- Každá cesta MUSÍ začínat znakem "/", včetně kořenové cesty. Používají se pouze absolutní cesty, např.
/Parsers/Microsoft/Exchange/
. - Cesta složky MUSÍ končit znakem "/", např.
/Parsers/Microsoft/Exchange/
. - Cesta položky MUSÍ končit příponou (např. ".txt", ".json", ...), např.
/Parsers/Microsoft/Exchange/10_parser.yaml
- Název složky NESMÍ obsahovat ".". Název položky NESMÍ začínat ".".
Note
Uživatel nemůže vytvářet nové složky v nejvyšší složce /
. Některé složky umožňují uživateli přidávat/ upravovat/ mazat soubory a složky uvnitř nich, zatímco některé to neumožňují. Každá složka knihovny má svá vlastní pravidla pro to.
Některé složky knihovny umožňují pouze specifické přípony souborů.
Příklad: Složka /Parsers/
umožňuje vytváření nových složek a pravidel pro analýzu končících na .yaml
uvnitř.
Složka /Homepage/
neumožňuje přidávat další položky (protože existuje pouze jedna domovská stránka).
Složka /Alerts/Workflow/
neumožňuje vytváření nových složek uvnitř, zatímco umožňuje přidávání nebo mazání existujících pracovních postupů upozornění.
Vrstvy knihovny¶
Knihovna je organizována do vrstev. Každá vrstva knihovny se odkazuje na jeden zdroj souborů knihovny a konkrétní technologii úložiště. Vrstvy knihovny jsou "naskládány" do jednoho pohledu (překryty), což spojuje obsah každé vrstvy do jednoho sjednoceného prostoru. Toto vrstvení umožňuje kombinovat obsah z různých zdrojů (tzv. poskytovatelů) do jedné knihovny. Vrstvy knihovny jsou zpočátku konfigurovány v produktu během instalace. Neexistuje žádný limit na počet naskládaných vrstev knihovny.
Schéma: Příklad nastavení vrstev knihovny, uživatel uvidí položky v zeleném rámečku.
Příklad konfigurace implementující výše uvedené schéma.
Knihovna je konfigurována buď centrálně pomocí ASAB Maestro, nebo v každém konfiguračním souboru mikroservisu.
[knihovna]
poskytovatelé:
zk://
libsreg+https://libsreg1.example.com,libsreg2.example.com/my-library#v24.11
git+https://github.com/john/awesome_project.git#deployment
libsreg+https://vendor.example.com/common-library
- Vrstva 0 je v Apache ZooKeeper, znovu využívající konfiguraci ZooKeeper z části
[zookeeper]
. - Vrstva 1 je "my-library" distribuovaná pomocí registru knihoven.
- Vrstva 2 je z Gitu (nebo konkrétněji z GitHubu), sledující větev "deployment".
- Vrstva 3 je "společná knihovna" poskytovatele.
Zapisovatelná vrstva¶
Vrstva 0 je jediná zapisovatelná vrstva. Je určena k vytváření a úpravě vlastního obsahu. Uživatel může upravovat obsah této vrstvy pomocí editoru "Knihovna" v uživatelském rozhraní.
Vyšší vrstvy jsou pouze pro čtení, určené pro jednosměrnou distribuci obsahu knihovny do nasazení.
Pokud uživatel upraví položku, která je přítomna ve vrstvách pouze pro čtení, je uložena ve vrstvě 0, což přepisuje položku se stejnou cestou na vyšších vrstvách. Toto je mechanismus, jak mohou uživatelé měnit obsah dodaný společnými knihovnami a podobně.
Vrstva 0 je dále rozdělena na cíle, což může být globální cíl pro obsah, který je dostupný pro celé nasazení, nebo nájemní cíl, který ukládá obsah pro konkrétní nájemce. To znamená, že obsah specifický pro nájemce, jako jsou Parsers nebo Dashboards, je uložen ve vrstvě 0, v cíli "nájemce".
Typy vrstev knihovny¶
Každá vrstva knihovny je dodávána prostřednictvím poskytovatele.
Apache ZooKeeper¶
Vrstva uložená lokálně v technologii Apache ZooKeeper. Je to distribuovaná a redundantní vrstva prostřednictvím konsensuálního mechanismu v ZooKeeperu. Tato vrstva je typickou volbou pro zapisovatelnou vrstvu 0.
Konfigurační prefix: zk:/
.
Note
Administrátoři mohou také použít nástroj ZooNavigator k prozkoumání a úpravě obsahu vrstvy ZooKeeper.
Repozitář knihoven¶
Obsah v této vrstvě je poskytován prostřednictvím distribučního bodu specifikovaného URI. Distribuční bod je server nebo veřejné cloudové úložiště přístupné přes HTTPS. Je to vrstva pouze pro čtení. Distribuce přes repozitář knihoven je preferovaný způsob distribuce obsahu. Obsah vrstvy je automaticky aktualizován, takže pokud je aktualizovaný obsah dostupný na serverech repozitáře knihoven, bude distribuován do knihoven v nasazeních.
Konfigurační prefix: libsreg:/
.
Příklad: libsreg+https://libsreg1.example.com/my-library
.
Verze¶
Tento poskytovatel podporuje verzování.
Verze je specifikována v fragmentové části URL (po symbolu #
):
Příklad: libsreg+https://libsreg1.example.com/my-library#v24.11
Verze mohou být statické (tj. v24.11
, neměnící se po jejím vydání) nebo rolling (tj. production
nebo main
, změny jsou nepřetržitě propagovány do distribučního bodu a tím do nasazení).
Tip
Verzování je navrženo tak, aby fungovalo s CI/CD procesem na publikátorovi obsahu knihovny. Typicky je "hlavní" nebo zlatá kopie knihovny uložena v Gitu na platformě CI/CD a je nasazena do distribučního bodu automatizací CI/CD.
Odolnost¶
Tento poskytovatel podporuje odolné dodávání obsahu. Můžete specifikovat více než jeden distribuční server v konfiguraci. TeskaLabs LogMan.io bude iterovat na další specifikované servery, pokud požadavek selže.
Příklad: libsreg+https://libsreg1.example.com,libsreg2.example.com/my-library
.
Git¶
Vrstva, která poskytuje (pouze pro čtení) obsah z Git repozitáře. Je určena pro nepřetržitou dodávku obsahu z Git serveru, jako je GitHub nebo GitLab.
Konfigurační prefixy: git+https:/
, git+http:/
nebo git:/
.
Verze v Gitu¶
Tento poskytovatel podporuje verzování.
Verze je specifikována v fragmentové části URL (po symbolu #
):
Příklad: git+https://github.com/john/awesome_project.git#deployment
Výchozí verze je nastavena v konkrétním Git repozitáři.
Typické hodnoty jsou master
nebo main
.
Používá se, když není poskytnut žádný fragment.
Verze mohou být statické (tj. v24.11
, neměnící se po jejím vydání) nebo rolling (tj. production
nebo main
, změny jsou nepřetržitě propagovány do distribučního bodu a tím do nasazení).
Souborový systém¶
Vrstva uložená v souborovém systému.
Warning
Jelikož je souborový systém lokální pro uzel, tento typ vrstvy není vhodný pro použití v clusterech.
Konfigurační prefixy: file:/
nebo /..
(jak v absolutních cestách souborového systému).
Microsoft Azure Storage¶
Vrstva, která poskytuje (pouze pro čtení) obsah z kontejneru umístěného v Microsoft Azure Storage.
Konfigurační prefix: azure+https:/
Note
Pokud není úroveň veřejného přístupu kontejneru nastavena na "Veřejný přístup", pak musí být vytvořena "Politika přístupu" s oprávněním "Číst" a "Seznam" a "Shared Access Signature" (SAS) dotazovací řetězec musí být přidán do URL v konfiguraci:
[knihovna]
poskytovatelé: azure+https://ACCOUNT-NAME.blob.core.windows.net/BLOB-CONTAINER?sv=2020-10-02&si=XXXX&sr=c&sig=XXXXXXXXXXXXXX
Povolení a zakázání obsahu¶
Jakákoli položka obsahu knihovny může být globálně nebo specificky pro nájemce zakázána. Zakázáním souborů mohou administrátoři upravit obsah dostupný uživatelům konkrétního nájemce.
Obsah může být povolen/zakázán z obrazovky "Knihovna" nebo pomocí souboru /.disabled.yaml
umístěného ve vrstvě 0.
Společná knihovna LogMan.io¶
Společná knihovna LogMan.io je distribuovaný obsah, který se nachází na nejvyšších vrstvách knihovny. Reprezentuje výchozí obsah, poskytovaný TeskaLabs nebo partnery.
Plnotextové indexování¶
Obsah knihovny (všechny vrstvy) je automaticky indexován, aby uživatelé mohli rychle vyhledávat konkrétní obsah.
Další informace¶
Technické podrobnosti lze také nalézt zde https://docs.teskalabs.com/asab.
Apache Kafka
Apache Kafka¶
Apache Kafka slouží jako fronta pro dočasné ukládání událostí mezi mikroservisy LogMan.io. Pro více informací viz Architektura.
Apache Kafka v LogMan.io¶
Pojmenování témat v událostních lanech¶
Každý událostní lane má specifikována témata received
, events
a others
.
Každé jméno tématu obsahuje název nájemce a proud událostí lane následujícím způsobem:
received.tenant.stream
events.tenant.stream
others.tenant
received.tenant.stream¶
Téma received
ukládá příchozí protokoly pro příchozího tenant
a proud událostí stream
.
events.tenant.stream¶
Téma events
ukládá analyzované události pro daný událostní lane definovaný tenant
a stream
.
others.tenant¶
Téma others
ukládá neanalyzované události pro daného tenant
.
Interní témata¶
Existují následující interní témata pro LogMan.io:
lmio-alerts¶
Toto téma ukládá vyvolané upozornění a je čteno mikroservisem LogMan.io Alerts.
lmio-notifications¶
Toto téma ukládá vyvolané notifikace a je čteno mikroservisem ASAB IRIS.
lmio-lookups¶
Toto téma ukládá požadované změny v lookupech a je čteno mikroservisem LogMan.io Watcher.
Doporučené nastavení pro 3-uzlový klastr¶
Existují tři instance Apache Kafka, jedna na každém uzlu.
Počet partition pro každé téma musí být alespoň stejný jako počet spotřebitelů (3) a dělitelný 2, proto je doporučený počet partition vždy 6.
Doporučený počet replik je 1.
Každé téma musí mít nastavenou rozumnou dobu uchovávání na základě dostupné velikosti SSD disků.
V prostředí klastru LogMan.io, kde je průměrný EPS nad 1000 událostí za sekundu a prostor na SSD disku je pod 2 TB, je doba uchovávání obvykle 1 den (86400000 milisekund). Viz sekce Příkazy.
Hint
Když je EPS nižší nebo je více místa na SSD, doporučuje se nastavit dobu uchovávání pro Kafka témata na vyšší hodnoty, jako jsou 2 nebo více dnů, aby administrátoři měli více času na řešení potenciálních problémů.
Pro správné vytvoření partition, replik a doby uchovávání viz sekce Příkazy.
Kafka Témata¶
Výchozí témata LogMan.io¶
Následující témata jsou výchozí témata LogMan.io používaná k předávání zpracovaných událostí mezi jednotlivými komponentami.
Kafka téma | Producent | Spotřebitel(é) | Typ uložených zpráv |
---|---|---|---|
received.<tenant>.<stream> |
LogMan.io Receiver | LogMan.io Parsec | surové logy / události |
events.<tenant>.<stream> |
LogMan.io Parsec | LogMan.io Depositor LogMan.io Baseliner | úspěšně zpracované události. |
others.<tenant> |
LogMan.io Parsec | LogMan.io Depositor | neúspěšně zpracované události. |
complex.<tenant> |
LogMan.io Correlator | LogMan.io Watcher | |
lmio-alerts |
LogMan.io Alerts | ||
lmio-lookups |
LogMan.io Lookups | události vyhledávání (informace o aktualizaci položky vyhledávání) | |
lmio-notifications |
|||
lmio-stores |
Témata LogMan.io v rámci Event Lane¶
Po zprovoznění LogMan.io Collector automaticky vytvoří LogMan.io Receiver Kafka téma RECEIVED
na základě tenant a stream.
Tento název má formu received.<tenant>.<stream>
. Toto téma je jedinečné pro každou Event Lane.
LogMan.io Parsec spotřebovává zprávy z tématu RECEIVED
a zpracovává je. Když zpracování uspěje, zpráva je odeslána do tématu EVENTS
, když selže, zpráva je odeslána do tématu OTHERS.
Téma EVENTS
má formu events.<tenant>.<stream>
a je jedinečné pro každou Event Lane.
Téma OTHERS
má formu others.<tenant>
a ukládá všechny nesprávně zpracované zprávy, bez ohledu na Event Lane, je jedinečné pro každého tenanta.
LogMan.io Depositor spotřebovává zprávy z témat EVENTS
a OTHERS
a odesílá je do odpovídajících Elasticsearch indexů.
Example
Předpokládejme, že název tenant je hogwarts
a název stream je microsoft-365
. Poté jsou vytvořena následující témata:
received.hogwarts.microsoft-365
: Téma, kde jsou uloženy surové (nezpracované) události.events.hogwarts.microsoft-365
: Téma, kde jsou uloženy úspěšně zpracované události.others.hogwarts
: Pokud jsou některé události zpracovány neúspěšně, jsou uloženy v tomto tématu.
Příkazy¶
Následující příkazy slouží k vytváření, změně a mazání Kafka témat v prostředí LogMan.io. Všechna Kafka témata spravovaná LogMan.io vedle interních jsou specifikována v deklaracích event lane, které lze nalézt ve složce /EventLanes
v knihovně.
Požadavky¶
Všechny příkazy by měly být spuštěny z Docker kontejneru Kafka. Je velmi pohodlné vytvořit pomocný dočasný kontejner pro administrativní příkazy.
docker run --network=host --rm -it confluentinc/cp-kafka:<version> bash
Tímto se vytvoří nový Kafka kontejner, který bude odstraněn po vašem odchodu a je vybaven rozhraním příkazového řádku Kafka, které je zdokumentováno zde: Nástroje rozhraní příkazového řádku Kafka (CLI)
Vytvoření tématu¶
Pro vytvoření tématu specifikujte název tématu, počet partition a faktor replikace. Faktor replikace by měl být nastaven na 1 a partition na 6, což je výchozí hodnota pro Kafka témata LogMan.io.
/usr/bin/kafka-topics --bootstrap-server localhost:9092 --create --topic "events.<tenant>.<stream>" --replication-factor 1 --partitions 6
Nahraďte events.<tenant>.<stream>
vaším názvem tématu.
Kafka verze nižší než 7.0
Pro Kafka verze nižší než 7.0 příkaz nepoužívá možnost --bootstrap-server
, ale místo toho používá možnost --zookeeper
. Zde je příkaz pro starší verze Kafka:
/usr/bin/kafka-topics --zookeeper localhost:2181 --create --topic "events.<tenant>.<stream>" --replication-factor 1 --partitions 6
Konfigurace tématu¶
Retence¶
Následující příkaz změní retenci dat pro Kafka téma na 86400000
milisekund, což je 1 den. To znamená, že data starší než 1 den budou odstraněna z Kafka, aby se uvolnilo místo na disku:
/usr/bin/kafka-configs --bootstrap-server localhost:9092 --entity-type topics --entity-name "events.<tenant>.<stream>" --alter --add-config retention.ms=86400000
Nahraďte events.<tenant>.<stream>
vaším názvem tématu.
Info
Všechna Kafka témata v LogMan.io by měla mít nastavenou retenci pro data.
Info
Při úpravě nastavení tématu v Kafka by měly být speciální znaky, jako je tečka (.), escapovány lomítkem (\).
Resetování offsetu spotřebitelské skupiny pro dané téma¶
Pro resetování pozice čtení, nebo offsetu, pro dané ID skupiny (spotřebitelské skupiny) použijte následující příkaz:
/usr/bin/kafka-consumer-groups --bootstrap-server localhost:9092 --group "my-console-client" --topic "events.<tenant>.<stream>" --reset-offsets --to-datetime 2020-12-20T00:00:00.000 --execute
Nahraďte events.<tenant>.<stream>
vaším názvem tématu.
Nahraďte my-console-client
daným ID skupiny.
Nahraďte 2020-12-20T00:00:00.000
časem, na který chcete resetovat čtecí offset.
Hint
Pro resetování skupiny na aktuální offset použijte --to-current
místo --to-datetime 2020-12-20T00:00:00.000
.
Mazání offsetu spotřebitelské skupiny pro dané téma¶
Offset pro dané téma může být odstraněn ze spotřebitelské skupiny, čímž by byla spotřebitelská skupina efektivně odpojena od samotného tématu. Použijte následující příkaz:
/usr/bin/kafka-consumer-groups --bootstrap-server localhost:9092 --group "my-console-client" --topic "events.<tenant>.<stream>" --delete-offsets
Nahraďte events.<tenant>.<stream>
vaším názvem tématu.
Nahraďte my-console-client
daným ID skupiny.
Mazání spotřebitelské skupiny¶
Spotřebitelská skupina pro VŠECHNA témata může být odstraněna se svými informacemi o offsetu pomocí následujícího příkazu:
/usr/bin/kafka-consumer-groups --bootstrap-server localhost:9092 --delete --group my-console-client
Nahraďte my-console-client
daným ID skupiny.
Změna tématu¶
Změna počtu partition¶
Následující příkaz zvyšuje počet partition v daném tématu.
/usr/bin/kafka-topics --bootstrap-server localhost:9092 --alter --partitions 6 --topic "events.<tenant>.<stream>"
Nahraďte events.<tenant>.<stream>
vaším názvem tématu.
Specifikujte uzel ZooKeeper
Kafka čte a mění data uložená v ZooKeeperu. Pokud jste nakonfigurovali Kafka tak, aby jeho soubory byly uloženy v konkrétním uzlu ZooKeeper, obdržíte tuto chybu.
Chyba při provádění příkazu tématu: Téma 'events.<tenant>.<stream>' neexistuje, jak se očekávalo
[2024-05-06 10:16:36,207] CHYBA java.lang.IllegalArgumentException: Téma 'events.<tenant>.<stream>' neexistuje, jak se očekávalo
at kafka.admin.TopicCommand$.kafka$admin$TopicCommand$$ensureTopicExists(TopicCommand.scala:539)
at kafka.admin.TopicCommand$ZookeeperTopicService.alterTopic(TopicCommand.scala:408)
at kafka.admin.TopicCommand$.main(TopicCommand.scala:66)
at kafka.admin.TopicCommand.main(TopicCommand.scala)
(kafka.admin.TopicCommand$)
Přizpůsobte argument --zookeeper
podle potřeby. Např. data Kafka jsou uložena v uzlu kafka
ZooKeeperu:
/usr/bin/kafka-topics --zookeeper lm11:2181/kafka --alter --partitions 6 --topic 'events\.tenant\.fortigate'
Zkuste odstranit escape znaky (/
), pokud název tématu stále není rozpoznán.
Smazání tématu¶
Téma může být smazáno pomocí následujícího příkazu. Mějte prosím na paměti, že Kafka témata jsou automaticky vytvářena, pokud jsou do nich produkována/odesílána nová data jakoukoli službou.
/usr/bin/kafka-topics --bootstrap-server localhost:9092 --delete --topic "events.<tenant>.<stream>"
Nahraďte events.<tenant>.<stream>
vaším názvem tématu.
Řešení problémů¶
V ostatních jsou mnohé logy a nemohu najít ty s atributem "interface"¶
Kafka Console Consumer může být použit k získání událostí z více témat, zde ze všech témat začínajících na events.
.
Dále je možné vyhledat pole v dvojitých uvozovkách:
/usr/bin/kafka-console-consumer --bootstrap-server localhost:9092 --whitelist "events.*" | grep '"interface"'
Tento příkaz vám poskytne všechny příchozí logy s atributem "interface"
ze všech event témat.
Přiřazení oddílů Kafka¶
Když je přidán nový uzel Kafka, Kafka automaticky neprovádí přiřazení oddílů. Následující kroky se používají k provedení ručního přiřazení oddílů Kafka pro specifikované téma(y).
-
Vstupte do shellu kontejneru Docker Kafka:
docker exec -it kafka-1 bash
-
Vytvořte
/tmp/topics.json
s tématy, jejichž oddíly by měly být přiřazeny v následujícím formátu:cat << EOF | tee /tmp/topics.json { "topics": [ {"topic": "events.tenant.stream"}, ], "version": 1 } EOF
-
Vygenerujte JSON výstup pro přiřazení z seznamu témat, která mají být migrována. Specifikujte ID brokerů v seznamu brokerů:
/usr/bin/kafka-reassign-partitions --zookeeper localhost:2181 --broker-list "121,122,221,222" --generate --topics-to-move-json-file /tmp/topics.json
Výsledek by měl být uložen v
/tmp/reassign.json
a vypadat následovně, přičemž všechna témata a oddíly mají specifikováno své nové přiřazení:[appuser@lm11 data]$ cat /tmp/reassign.json {"version":1,"partitions":[{"topic":"events.tenant.stream","partition":0,"replicas":[122],"log_dirs":["any"]},{"topic":"events.tenant.stream","partition":1,"replicas":[221],"log_dirs":["any"]},{"topic":"events.tenant.stream","partition":2,"replicas":[222],"log_dirs":["any"]},{"topic":"events.tenant.stream","partition":3,"replicas":[121],"log_dirs":["any"]},{"topic":"events.tenant.stream","partition":4,"replicas":[122],"log_dirs":["any"]},{"topic":"events.tenant.stream","partition":5,"replicas":[221],"log_dirs":["any"]}]}
-
Použijte výstup z předchozího příkazu jako vstup pro provedení přiřazení/převažování:
/usr/bin/kafka-reassign-partitions --zookeeper localhost:2181 --execute --reassignment-json-file /tmp/reassign.json --additional --bootstrap-server localhost:9092
To je vše! Nyní by Kafka měla provést přiřazení oddílů během následujících hodin.
Pro více informací viz Přiřazení oddílů v Apache Kafka Clusteru.
Standardy pojmenování¶
Repozitáře produktů¶
Repozitáře produktů obsahují zdrojové kódy všech komponent LogMan.io (data pumpy, služby, UI atd.).
Názvy repozitářů produktů, které jsou vždy vyvíjeny a udržovány společností TeskaLabs,
vždy začínají předponou lmio-
.
Repozitáře produktů by neměly být upravovány zákazníky ani partnery.
Repozitáře konfigurace serverů¶
Repozitáře konfigurace serverů obsahují konfigurace pro jednotlivé komponenty LogMan.io, základní technologie a soubory Docker Compose pro dané nasazení na daném serveru.
Repozitáře konfigurace serverů mohou být také udržovány partnerem nebo zákazníkem.
Jejich názvy vždy začínají předponou site-
.
Repozitáře partnerů¶
Repozitáře, které udržuje partner nebo zákazník, vždy obsahují název partnera v malých písmenech po předponě, oddělené pomlčkami.
Proto u repozitářů konfigurace serverů formát vypadá následovně:
site-<partner_name>-<location>
Kde location
je místo nasazení (název společnosti, která spravuje server).
Pokud je místo všeobecně známé, může být popsáno jiným explicitním způsobem,
například build-env
pro označení prostředí pro sestavení.
Poznámky¶
Klíčové slovo environment
je vždy zkráceno na env
.
Klíčové slovo encrypt
je vždy zkráceno na enc
.
Multitenance¶
TeskaLabs LogMan.io je produkt založený na multitenanci, který vyžaduje specifikaci identifikace tenantu (zákazníka) v každém logu, což lze provést automaticky pomocí LogMan.io Collectoru.
Každá instance LogMan.io Parseru je specifická pro tenant, stejně jako indexy uložené v ElasticSearch. Tudíž pouze logy patřící danému tenantu jsou zobrazeny danému tenantu v Kibana nebo LogMan.io UI.
Také metriky sledování toku v Grafaně jsou tenantově orientované a tudíž umožňují monitorovat tok logů pro každého jednotlivého zákazníka.
Standard pojmenování¶
Kvůli využití technologie TeskaLabs LogMan.io, všechny identifikace tenantů musí být malým písmem bez jakýchkoliv speciálních znaků (jako jsou #, * atd.).
Nástroje¶
Seznam OpenSource nástrojů třetích stran, které lze integrovat s TeskaLabs LogMan.io. Po zapnutí jsou k dispozici v sekci "Nástroje" 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é úkoly.
Více informací na 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ýzy malwaru atd.
Více informací na misp-project.org
Data science¶
Jupyter Notebook¶
JupyterLab je webové interaktivní vývojové prostředí pro notebooky, kód a data. Jeho flexibilní rozhraní umožňuje uživatelům konfigurovat a uspořádat pracovní postupy v datové vědě, vědeckém výpočetnictví, výpočetní žurnalistice a strojovém učení. Modulární design umožňuje rozšíření funkcionality.
Více informací na Jupyter Notebook
Technická podpora¶
ZooNavigator¶
Prohlížeč a editor ZooKeeper.
https://github.com/elkozmon/zoonavigator
Grafana¶
Platforma pro sledování a vizualizaci dat. Pro vizualizaci metrik.
https://github.com/grafana/grafana
KafDrop¶
Kafka Web UI
Přehled síťových portů¶
Tato kapitola obsahuje přehled síťových portů používaných LogMan.io. Většina portů je interní a přístupná pouze z interní sítě clusteru.
Interní síť¶
Port | Protokol | Komponenta |
---|---|---|
tcp/8890 | HTTP | NGINX (Interní API brána) |
tcp/8891 | HTTP | asab-remote-control |
tcp/8892 | HTTP | asab-governator |
tcp/8893 | HTTP | asab-library |
tcp/8894 | HTTP | asab-config |
tcp/8895 | HTTP | asab-pyppeteer |
tcp/8896 | HTTP | asab-iris |
tcp/8897 | HTTP | asab-discovery |
tcp/8900 | HTTP | seacat-auth (Privátní API) |
tcp/8910 | HTTP | seacat-pki |
tcp/8950 | HTTP | lmio-receiver (Privátní API) |
tcp/8951 | HTTP | lmio-ipaddrproc |
tcp/8952 | HTTP | lmio-watcher |
tcp/8953 | HTTP | lmio-alerts |
tcp/8954 | HTTP | lmio-elman |
tcp/8955 | HTTP | lmio-lookupbuilder |
tcp/8956 | HTTP | lmio-ipaddrproc |
tcp/8957 | HTTP | lmio-correlator-builder |
tcp/8958 | HTTP | lmio-charts |
tcp/8959 | HTTP | lmio-categorix |
tcp/8960 | HTTP | lmio-integ |
tcp/8961 | HTTP | lmio-parser-builder |
tcp/8962 | HTTP | lmio-trex |
tcp/8999 | HTTP | lmio-feeds |
tcp/3443 | HTTPS | lmio-receiver (Veřejné API) |
tcp/3080 | HTTP | lmio-receiver (Veřejné API) |
tcp/3081 | HTTP | seacat-auth (Veřejné API) |
tcp/8790 | HTTP | bs-query |
tcp/8810 | HTTP | ACME.sh |
tcp/9092 | Kafka | Apache Kafka |
tcp/9000 | HTTP | Kafdrop |
tcp/2181 | ZAB | Apache Zookeeper |
tcp/9001 | HTTP | Zoonavigator |
tcp/8086 | HTTP | InfluxDB |
tcp/8888 | HTTP | Jupyter Notebook |
tcp/5601 | HTTP | Kibana |
tcp/3000 | HTTP | Grafana |
tcp/27017 | proprietární | MongoDB |