Ú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

• ElasticSearch / OpenSearch
• Apache Kafka
• BitSwan

Kryptografie

• Transportní vrstva: TLS 1.2, TLS 1.3 a lepší
• Symetrická kryptografie: AES-128, AES-256, AES-512
• Asymetrická kryptografie: RSA, ECC
• 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
• JSON
• XML
• YAML
• Avro
• Vlastní/surový formát logu

A mnoho dalších.

Prodejci a produkty

Cisco

• Cisco Firepower Threat Defense (FTD)
• Cisco Adaptive Security Appliance (ASA)
• Cisco Identity Services Engine (ISE)
• Cisco Meraki (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 (Application 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 (Network Access Control)
• 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

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 (Network Security Visibility)

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

• 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

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

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.

Ended: Úvod

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í:

Tenants

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

1. Klikněte na název vašeho účtu.
2. Klikněte na Změnit heslo.
3. Zadejte své aktuální heslo a nové heslo.
4. 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

1. Klikněte na název vašeho účtu.
2. Klikněte na Spravovat.
3. Zde můžete:
   • Změnit své heslo
   • Změnit svou emailovou adresu
   • Změnit nebo přidat své telefonní číslo
   • Odhlásit se
4. 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

1. Klikněte na název vašeho účtu.
2. Klikněte na Kontrola přístupu, kde uvidíte, jaká oprávnění máte.

Odhlášení

1. Klikněte na název vašeho účtu.
2. Klikněte na Odhlásit se.

Můžete se také odhlásit z obrazovky Spravovat.

Odhlášení ze všech zařízení

1. Klikněte na název vašeho účtu.
2. Klikněte na Spravovat.
3. 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í.

Příklad:

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).

Příklad:

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

1. Vyberte zprávu ze svého seznamu nebo použijte vyhledávací lištu, abyste zprávu našli.
2. 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
• Vytvořit nový export
• Stáhnout export
• Smazat export
• Přidat export do knihovny

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říklad 2023-12-31 23:59 (31. prosince 2023, 23:59).

• Naplánovat opakovaný export:

  • Pro nastavení exportu ke spuštění automaticky v pravidelném intervalu použijte cron syntaxi. Více o cron 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 byl 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í.

Příklad:

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).

Příklad:

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

1. Vyberte report ze svého seznamu, nebo použijte vyhledávací lištu k nalezení vašeho reportu.
2. 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
• Vytvořit nový export
• Stáhnout export
• Smazat export
• Přidat export do knihovny

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říklad 2023-12-31 23:59 (31. prosince 2023, ve 23:59).

• 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. Obnovení 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žce) při kliknutí na složku.

1. Pro přidání položky klikněte na Vytvořit novou položku ve složce (složka).
2. Pojmenujte položku, vyberte příponu souboru z rozbalovací nabídky a klikněte na Vytvořit.
3. 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

1. Klikněte na položku, kterou chcete zkopírovat.
2. Klikněte na tlačítko ... v horní části.
3. Klikněte na Kopírovat.
4. Přejmenujte položku, vyberte příponu souboru z rozbalovací nabídky, a klikněte na Kopírovat.
5. 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ě

1. Klikněte na položku, kterou chcete upravit.
2. Pro úpravu položky klikněte na Upravit.
3. Pro uložení změn klikněte na Uložit, nebo ukončete editor bez uložení kliknutím na Zrušit.
4. 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

1. Klikněte na položku, kterou chcete odstranit.
2. Klikněte na tlačítko ... v horní části.
3. Klikněte na Odstranit a potvrďte Ano, pokud vás váš prohlížeč vyzve.
4. 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í

1. Klikněte na Akce.
2. Klikněte na Obnovit.
3. Vyberte soubor z vašeho počítače. Můžete importovat pouze soubory tar.gz.
4. 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í:

1. Klikněte na Vytvořit vyhledávání.
2. Vyplňte pole: Název, Krátký popis, Podrobný popis a Klíč(e).
3. Pro přidání dalšího klíče klikněte na +.
4. Zvolte, zda chcete přidat nebo nepřidat expiraci.
5. 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í

1. 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í.
2. Klikněte na Upravit vyhledávání ve spodní části.
3. 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í:

1. 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í.

2. 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.

Zdroj

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.

Ended: Přehled vlasností

Ended: Uživatelský manuál

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*

Toto může vrátit výsledky zahrnující:

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")

Panely

Panely jsou vizualizace příchozích logovacích dat. Zatímco TeskaLabs LogMan.io přichází s knihovnou přednastavených panelů, můžete si také vytvořit vlastní. Prohlédněte si přednastavené panely v webové aplikaci LogMan.io v Panely.

Pro vytváření panelu je potřeba napsat nebo zkopírovat panelový soubor do Knihovny.

Vytváření panelového souboru

Panely píšeme v formátu JSON.

Vytvoření prázdného panelu

1. V TeskaLabs LogMan.io, přejděte do Knihovny.
2. Klikněte na Panely.
3. Klikněte na Vytvořit novou položku v Panelech.
4. Pojmenujte položku a klikněte na Vytvořit. Pokud se nová položka neobjeví okamžitě, aktualizujte stránku.

Kopírování existujícího panelu

1. V TeskaLabs LogMan.io, přejděte do Knihovny.
2. Klikněte na Panely.
3. Klikněte na položku, kterou chcete duplikovat, a poté klikněte na ikonu nahoře. Klikněte na Kopírovat.
4. Vyberte nové jméno pro položku a klikněte na Kopírovat. Pokud se nová položka neobjeví okamžitě, aktualizujte stránku.

Struktura panelu

Panely píšeme v JSON a pamatujte, že jsou citlivé na velikost písmen.

Panely mají dvě části:

1. Základ panelu: lišta pro dotazy, výběr času, tlačítko pro obnovení a tlačítko pro možnosti
2. Widgety: vizualizace (graf, grafy, seznam, atd.)

Základ panelu

Tuto sekci ponechejte přesně tak, jak je pro zajištění lišty pro dotazy, výběr času, tlačítko pro obnovení a tlačítko pro možnosti.

{
    "Prompts": {
        "dateRangePicker": true,
        "filterInput": true,
        "submitButton": true

Lišta pro dotazy vykreslená:

Widgety

Widgety jsou tvořeny páry datasource a widget. Při psaní widgetu musíte zahrnout jak sekci datasource, tak sekci widget.

Tipy na formátování JSON:

• Oddělte každou sekci datasource a widget složenou závorkou a čárkou }, s výjimkou posledního widgetu v panelu, který čárku nepotřebuje (viz plný příklad)
• Ukončete každý řádek čárkou ,, s výjimkou poslední položky v sekci

Umístění widgetu

Každý widget má řádky rozvržení, které určují velikost a pozici widgetu. Pokud při psaní widgetu nezahrnete řádky rozvržení, panel je generuje automaticky.

1. Zahrňte rozvrhové řádky s navrhovanými hodnotami z každé šablony widgetu, nebo nezahrňte žádné rozvrhové řádky. (Pokud nezahrnete žádné rozvrhové řádky, ujistěte se, že poslední položka v každé sekci nekončí čárkou.)
2. Přejděte na Panely v LogMan.io a změňte velikost a přesuňte widget.
3. Když přemístíte widget na stránku Panelů, soubor panelu v Knihovně automaticky generuje nebo upravuje rozvrhové řádky. Pokud pracujete v souboru panelu v Knihovně a zároveň přemísťujete widgety v Panelech, ujistěte se, že uložíte a aktualizujete obě stránky po provedení změn na kterékoli stránce.

Pořadí widgetů ve vašem panelovém souboru neurčuje jejich pozici a pořadí se nezmění, když přemístíte widgety v Panelech.

Pojmenování

Doporučujeme dohodnout se na pojmenovacích konvencích pro panely a widgety ve vaší organizaci, abyste předešli zmatkům.

matchPhrase filtr

Pro datové zdroje Elasticsearch použijte Lucene syntaxe dotazů pro hodnotu matchPhrase.

Barvy

Ve výchozím nastavení používají widgety koláčového grafu a sloupcového grafu modré barevné schéma. Chcete-li změnit barevné schéma, vložte "color":"(barevné schéma)" přímo před rozvrhové řádky.

• Modrá: Není potřeba žádné extra řádky
• Fialová: "color":"sunset"
• Žlutá: "color":"warning"
• Červená: "color":"danger"

Řešení problémů s JSON

Pokud dostanete chybovou zprávu o formátování JSON při pokusu o uložení souboru:

• Řiďte se doporučením chybové zprávy, která specifikuje, co JSON "očekává" - může to znamenat, že vám chybí požadovaný klíč-hodnotový pár, nebo je interpunkce nesprávná.
• Pokud chybu nenajdete, zkontrolujte, zda je vaše formátování konzistentní s jinými funkčními panely.

Pokud váš widget nezobrazuje správně:

• Ujistěte se, že hodnota datasource odpovídá jak v sekci datového zdroje, tak v sekci widgetu.
• Zkontrolujte pravopisné chyby nebo problémy s strukturou dotazu v libovolných odkazovaných polích a v polích specifikovaných ve filtru matchphrase.
• Zkontrolujte jakékoli jiné překlepy nebo nesrovnalosti.
• Ujistěte se, že datový zdroj, na který se odkazujete, je připojen.

Použijte tyto příklady jako průvodce. Klikněte na ikony , aby se zobrazily jednotlivé řádky s vysvětlením.

Sloupcové grafy

Sloupcový graf zobrazuje hodnoty svislými sloupci na ose x a y. Délka každého sloupce je úměrná datům, která reprezentuje.

Příklad JSON sloupcového grafu:

    "datasource:office365-email-aggregated": { #(1)
        "type": "elasticsearch", #(2)
        "datetimeField": "@timestamp", #(3)
        "specification": "lmio-{{ tenant }}-events*", #(4)
        "aggregateResult": true, #(5)
        "matchPhrase": "event.dataset:microsoft-office-365 AND event.action:MessageTrace" #(6)
    },
    "widget:office365-email-aggregated": { #(7)
        "datasource": "datasource:office365-email-aggregated", #(8)
        "title": "Odeslané a přijaté e-maily", #(9)
        "type": "BarChart", #(10)
        "xaxis": "@timestamp", #(11)
        "yaxis": "o365.message.status", #(12)
        "ylabel": "Počet", #(13)
        "table": true, #(14)
        "layout:w": 6, #(15)
        "layout:h": 4,
        "layout:x": 0,
        "layout:y": 0,
        "layout:moved": false,
        "layout:static": true,
        "layout:isResizable": false
    },

1. 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.
2. Typ datového zdroje. Pokud používáte Elasticsearch, hodnota je "elasticsearch"
3. 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.
4. 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 za events. Výsledek: Widget zobrazuje data z aktivního tenanta.
5. aggregateResult nastavené na true provádí agregaci dat před jejich zobrazením v panelu. V tomto případě jsou počítány (součty) odeslané a přijaté e-maily.
6. Dotaz, který filtruje konkrétní logy pomocí Lucene syntaxe dotazů. V tomto případě musí jakákoli data zobrazovaná v panelu pocházet z datasetu Microsoft Office 365 a mít hodnotu MessageTrace v poli event.action.
7. widget označuje začátek sekce widgetu a také název widgetu. Název neovlivňuje funkci panelu.
8. 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.)
9. Název widgetu, který se bude zobrazovat v panelu
10. Typ widgetu
11. Pole z logů, jehož hodnoty budou reprezentovány na ose x
12. Pole z logů, jehož hodnoty budou reprezentovány na ose y
13. Popisek pro osu y, který se zobrazí v panelu
14. Nastavení table na true umožňuje přepínání mezi zobrazením grafu a tabulky na widgetu v panelu. Zvolení false zakazuje funkci přepínání mezi grafem a tabulkou.
15. Viz poznámku výše o umístění widgetů pro informace o rozvrhových řádkích.

Sloupcový graf widget vykreslený:

Šablona sloupcového grafu:

Pro vytvoření widgetu sloupcového grafu, zkopírujte a vložte tuto šablonu do panelového souboru v Knihovně a vyplňte hodnoty. Doporučené hodnoty rozvrhu, hodnoty specifikující datový zdroj Elasticsearch a hodnotu organizující sloupcový graf podle času jsou již vyplněny.

    "datasource:Name of datasource": {
        "type": "elasticsearch",
        "datetimeField": "@timestamp",
        "specification": "lmio-{{ tenant }}-events*",
        "aggregateResult": true,
        "matchPhrase": " "
    },
    "widget:Name of widget": {
        "datasource": "datasource:office365-email-aggregated",
        "title": "Widget display title",
        "type": "BarChart",
        "xaxis": "@timestamp",
        "yaxis": " ",
        "ylabel": " ",
        "table": true,
        "layout:w": 6,
        "layout:h": 4,
        "layout:x": 0,
        "layout:y": 0,
        "layout:moved": false,
        "layout:static": true,
        "layout:isResizable": false
    },

Koláčové grafy

Koláčový graf je kruh rozdělený na výseče, přičemž každá výseč představuje procento z celku.

Příklad JSON koláčového grafu:

    "datasource:office365-email-status": { #(1)
        "datetimeField": "@timestamp", #(2)
        "groupBy": "o365.message.status", #(3)
        "matchPhrase": "event.dataset:microsoft-office-365 AND event.action:MessageTrace", #(4)
        "specification": "lmio-{{ tenant }}-events*", #(5)
        "type": "elasticsearch", #(6)
        "size": 20 #(7)
    },
    "widget:office365-email-status": { #(8)
        "datasource": "datasource:office365-email-status", #(9)
        "title": "Status přijatých e-mailů", #(10)
        "type": "PieChart", #(11)
        "tooltip": true, #(12)
        "table": true, #(13)
        "layout:w": 6, #(14)
        "layout:h": 4,
        "layout:x": 6,
        "layout:y": 0,
        "layout:moved": false,
        "layout:static": true,
        "layout:isResizable": false
    },

1. 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.
2. 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.
3. Pole, jehož hodnoty budou reprezentovat každou "výseč" koláčového grafu. V tomto příkladu bude koláčový graf oddělovat logy podle jejich stavu zprávy. Pro každou hodnota stavu jako je "Doručeno", "Rozbaleno", "Karanténa" atd. bude separátní výseč, která ukazuje procentuální výskyt každého stavu zprávy.
4. Dotaz, který filtruje konkrétní logy. V tomto případě budou zobrazeny pouze data z logů datasetu Microsoft Office 365 s hodnotou MessageTrace v poli event.action.
5. 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 za events. Výsledek: Widget zobrazuje data z aktivního tenanta.
6. Typ datového zdroje. Pokud používáte Elasticsearch, hodnota je "elasticsearch"
7. Kolik hodnot chcete zobrazit. Protože tento koláčový graf ukazuje stavy přijatých e-mailů, hodnota size je 20 a zobrazuje top 20 typů stavu. (Koláčový graf může mít maximálně 20 výsečí.)
8. widget označuje začátek sekce widgetu a také název widgetu. Název neovlivňuje funkci panelu.
9. 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.)
10. Název widgetu, který se bude zobrazovat v panelu
11. Typ widgetu
12. Pokud je tooltip nastaveno na true: Když najedete myší na každou výseč koláčového grafu v panelu, zobrazí se malá informační okno s počtem hodnot ve výseči u kurzoru. Pokud je tooltip nastaveno na false: Informační okno se zobrazí v levém horním rohu widgetu.
13. Nastavení table na true umožňuje přepínání mezi zobrazením grafu a tabulky na widgetu v panelu. Zvolení false zakazuje funkci přepínání mezi grafem a tabulkou.
14. Viz poznámku výše o umístění widgetů pro informace o rozvrhových řádcích.

Koláčový graf widget vykreslený:

Šablona koláčového grafu

Pro

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 parsers, 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í parsers, 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"

A rozdělí a seřadí ho do polí, která jsou snadněji čitelná, pochopitelná a filtrovatelná:

@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í:

1. 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.
2. 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).
3. 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í:

1. 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.
2. 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.
3. 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.

parser_json.yaml

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:

parser.yaml

define:
    name: My Parser
    type: parser/parsec

parse:
    !PARSE.KVLIST
        - ...
        - ...
        - ...

subparser.yaml

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í:

10_parser.yaml

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.

10_parser.yaml

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

20_parser_message.yaml

    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 všechny deklarované pole jsou získány 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:

10_parser.yaml

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:

20_mapping_ECS.yaml

---
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:

1. Vytvořit nové pole v události.
2. 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:

1. Určení datasetu, kde budou logy uloženy v ElasticSearch (přidání pole event.dataset).
2. 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 poli define.

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.

Událost je ve tvaru:

{
  "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:

enricher.yaml

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 ]

Ended: Deklarace

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.

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.

Deklarace
Pro více informací o specifických typech deklarací, viz:

• O deklaracích
• Deklarace analyzátoru
• Deklarace mapování
• Deklarace obohacovače

Vzorové logy

Tento příklad používá tuto sadu logů sesbíraných z různých zařízení Sophos SG230:

<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>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.

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, 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.

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 ' '

nahrazuje

- !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

1. 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.
2. Analyzujte proces: Použijte !PARSE.UNTIL znovu pro analýzu do :. Po dvojtečce ('), je hlavička analyzována.
3. 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 pole MESSAGE 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:

15_parser_process.yaml

---
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>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[

Ended: Parsování

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é ú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ě.

1. 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.

2. 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í.

3. 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:

1. 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.
2. 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íže
• timestamp: Čas, kdy se událost odehrála
• username: 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:

1. Rozhodnout, jakou aktivitu hledáte, a rozhodnout časový rámec, ve kterém je tato aktivita významná.
2. Identifikovat, který zdroj dat produkuje logy, které by mohly spustit pozitivní detekci, a zjistit, jaké informace tyto logy obsahují.
3. 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:

1. Define: Informace, které popisují vaše pravidlo.
2. Predicate: Sekce predicate je filtr, který identifikuje, které logy vyhodnotit, a které logy ignorovat.
3. Evaluate: Sekce evaluate třídí nebo organizuje data k analýze.
4. Analyze: Sekce analyze definuje a hledá požadovaný vzorec v datech setříděných sekcí evaluate.
5. 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
name: "(name)"	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í.
description: "(description)"	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ží.
type: correlator/window	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
evaluate: dimension: [(field1), (field2)]	dimension vytváří řádky v tabulce. V tabulce jsou hodnoty specifikovaných polí seskupeny do jednoho řádku (viz tabulka níže).
by: "@timestamp"	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.
resolution: (integer)	Jednotka resolution je sekundy. Každý časový interval bude počet sekund, které určíte.
saturation: 1	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
analyze: window: (hopping or tumbling)	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: unique count dimension: (field)	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: (integer)	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.)
test: !GE - !ARG VALUE - (integer)	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: "External IP accessing 25+ internal IPs in 2 minutes"
  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: "External IP accessing 25+ internal IPs in 2 minutes"
  type: correlator/window

Položka v pravidle	Co to znamená?
name: "Network T1046 Network Service Discovery"	To je název pravidla. Název je pro uživatele a nemá žádný dopad na samotné pravidlo.
description: "External IP accessing 25+ internal IPs in 2 minutes"	Popis je také pro uživatele. Popisuje, co pravidlo dělá, ale nemá žádný dopad na samotné pravidlo.
type: correlator/window	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á?
predicate: !AND - !OR - !EQ - !ITEM EVENT event.dataset - "fortigate" - !EQ - !ITEM EVENT event.dataset - "sophos"	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.
- !OR - !EQ - !ITEM EVENT event.action - "deny" - !EQ - !ITEM EVENT event.action - "drop"	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.
- !IN co: source.ip kde: !EVENT	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í.
- !NOT co: !STARTSWITH co: !ITEM EVENT source.ip prefix: "193.145"	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.
- !NE - !ITEM EVENT source.ip - "8.8.8.8"	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.
- !IN co: destination.ip kde: !EVENT	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á?
evaluate: dimension: [tenant, source.ip]	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: "@timestamp"	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.
resolution: 60	Jednotkou resolution jsou sekundy, takže hodnota zde je 60 sekund. Každý časový interval bude dlouhý 60 sekund.
saturation: 1	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 interních IP adres nad 25.

Toto je příklad, jak sekce evaluate třídí logy, které prošly filtrem predicate. (Klikněte na tabulku pro zvětšení.) Data z logů jsou silně zjednodušena pro čitelnost (například ID logů v poli _id jsou písmena místo skutečných ID logů a časová razítka jsou zkrácena).

Ended: Detekce

Predikáty

predikát je filtr složený z podmínek vytvořených pomocí SP-Lang výrazů.

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:

Výraz	Význam
!AND	VŠECHNY kritéria vnořená pod !AND musí být splněna, aby byl !AND pravdivý
!OR	Alespoň JEDNO ze kritérií vnořených pod !OR musí být splněno, aby bylo !OR pravdivé
!EQ	"Rovná se". Musí se rovnat nebo odpovídat hodnotě, aby bylo pravdivé
!NE	"Nerovná se", nebo neodpovídá. Musí se NEROVNAT (nesmí odpovídat hodnotě), aby bylo pravdivé
!IN	Hledá hodnotu v množině hodnot (what v where)
!STARTSWITH	Hodnota pole (what) musí začínat specifikovaným textem (prefix), aby byla pravdivá
!ENDSWITH	Hodnota pole (what) musí končit specifikovaným textem (postfix), aby byla pravdivá
!ITEM EVENT	Získává informace z obsahu příchozích logů (umožňuje filtru přistupovat k polím a hodnotám v příchozích logech)
!NOT	Hledá opak výrazu vnořeného pod !NOT (následující what)

Podmínky

Použijte tento průvodce ke správnému strukturování jednotlivých podmínek.

Závorky

Slova v závorkách () jsou náhradní symboly pro ukázku, kam vkládat hodnoty. SP-Lang nepoužívá závorky.

Filtr pro log, který:	SP-Lang
Má specifikovanou hodnotu ve specifikovaném poli	- !EQ - !ITEM EVENT (pole) - "(hodnota)"
Má specifikované pole	- !IN what: (pole) where: !EVENT
NEMÁ specifikovanou hodnotu ve specifikovaném poli	- !NE - !ITEM EVENT (pole) - "(hodnota)"
Má jednu z více možných hodnot v poli	- !OR - !EQ - !ITEM EVENT (pole) - "(hodnota1)" - !EQ - !ITEM EVENT (pole) - "(hodnota2)"
Má specifikovanou hodnotu, která začíná specifikovaným číslem nebo textem (prefixem), ve specifikovaném poli	!STARTSWITH what: !ITEM EVENT (pole) prefix: "(prefix)"
Má specifikovanou hodnotu, která končí specifikovaným číslem nebo textem (postfixem), ve specifikovaném poli	!ENDSWITH what: !ITEM EVENT (pole) prefix: "(postfix)"
NESPLŇUJE podmínku nebo sadu podmínek	- !NOT what: !(SP-Lang výraz/-y)

Příklad

Abyste pochopili, co jednotlivé výrazy znamenají v kontextu tohoto příkladu, klikněte na ikony .

  !AND #(1)
  - !OR #(2)
    - !EQ
      - !ITEM EVENT event.dataset
      - "sophos"
    - !EQ
      - !ITEM EVENT event.dataset
      - "vmware-vcenter"
  - !OR #(3)
    - !EQ
      - !ITEM EVENT event.action
      - "Authentication failed"
    - !EQ
      - !ITEM EVENT event.action
      - "failed password"
    - !EQ
      - !ITEM EVENT event.action
      - "unsuccessful login"
  - !OR #(4)
    - !IN
      what: source.ip
      where: !EVENT
    - !IN
      what: user.id
      where: !EVENT
  - !NOT #(5)
    what:
      !STARTSWITH
      what: !ITEM EVENT user.id
      prefix: "harry"

1. Každý výraz vnořený pod !AND musí být pravdivý, aby log prošel tímto filtrem.
2. V logu musí být v poli event.dataset hodnota sophos nebo vmware-vcenter, aby bylo toto !OR pravdivé.
3. V logu musí být v poli event.action hodnota Authentication failed, failed password nebo unsuccessful login, aby bylo toto !OR pravdivé.
4. Log musí obsahovat pole source.ip nebo pole user.id, aby bylo toto !OR pravdivé.
5. V logu se pole user.id nesmí začínat na harry, aby bylo toto !NOT pravdivé.

Tento filtr hledá logy, které:

• Mají hodnotu sophos nebo vmware-vcenter v poli event.dataset A
• Mají hodnotu Authentication failed, failed password nebo unsuccessful login v poli event.action A
• Obsahují alespoň jedno z polí source.ip nebo user.id A
• Nemají hodnotu začínající harry v poli user.id

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 predicate.

Triggery

Trigger, v alertu nebo detekci, provádí akci. Například v detekci může sekce trigger odeslat e-mail, když je detekována specifikovaná aktivita.

Trigger může:

• Spustit událost: Odešle událost do Elasticsearch, kde je uložena jako dokument. Poté můžete vidět událost jako log v aplikaci TeskaLabs LogMan.io. Můžete vytvořit vlastní dashboard pro zobrazení detekcí korelčních pravidel nebo najít logy v Průzkumník.
• Spustit oznámení: Odešle zprávu přes e-mail

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.

Položka v trigger	Jak zahrnout
trigger: - event:	V triggeru, event znamená, že pravidlo vytvoří událost na základě této pozitivní detekce a odešle ji do datové pipeline přes Elasticsearch, kde je uložena jako dokument. Poté událost projde do TeskaLabs LogMan.io, kde můžete tuto událost vidět v Průzkumník a Dashboards.
!DICT type: "{str:any}" with:	!DICT vytvoří slovník klíčů (polí) a hodnot. type má "st:any" (znamená string), takže jakýkoli typ hodnoty (čísla, slova atd.) může být hodnota v páru klíč-hodnota. with začíná seznam páru klíč-hodnota, které definujete. Toto jsou pole a hodnoty, ze kterých bude událost složena.

Následující with vytvořte seznam páru klíč-hodnota, nebo pole a hodnoty, které chcete v události mít.

      !DICT
      type: "{str:any}"
      with:
        key.1: "value"
        key.2: "value"
        key.3: "value"
        key.4: "value"

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.

Notifikace

Notifikace

Notifikace odesílají zprávy. Můžete přidat sekci notification kamkoliv, kde chcete, aby výstup trigger byl zprávou, například v alertu nebo detekci. V detekci může sekce notification odeslat zprávu při zjištění specifikované aktivity (jako je potenciální hrozba).

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 trigger.

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.

trigger: #(1)
  - notification: #(2)
      type: email #(3)
      template: "/Templates/Email/Notification.md" #(4)
      to: [email@example.com] #(5)
      variables: #(6)
        !DICT #(7)
        type: "{str:any}" #(8)
        with: #(9)
          name: Notifikace z detekce X #(10)
          events: !ARG EVENTS #(11)
          address: !ITEM EVENT client.address #(12)
          description: Detekce X pomocí TeskaLabs LogMan.io #(13)

1. Označuje začátek sekce trigger.

2. Označuje začátek sekce notification.

3. Pro odeslání e-mailu napište email jako type.

4. Toto řekne upozornění, kde získat e-mailovou šablonu. Musíte specifikovat cestu k e-mailové šabloně v Knihovně. V tomto příkladu je šablona v Knihovně, v záložce Templates, v podzáložce Email a jmenuje se Notification.md.

5. Napište e-mailovou adresu, kam chcete, aby e-mail přišel.

6. Začíná sekce, která dává pokyny, jak vyplnit prázdná pole z e-mailové šablony.

7. SP-Lang výraz, který vytváří slovník, abyste mohli použít páry klíč-hodnota v upozornění. (Klíč je první slovo a hodnota je následující.) Vždy zahrňte !DICT.

8. Vždy napište type "{str:any}", aby hodnoty v párech klíč-hodnota mohly být v jakémkoli formátu (čísla, slova, pole, atd.).

9. Vždy zahrňte with, protože to začíná seznam polí z e-mailové šablony. Všechno vnořené pod with je pole z e-mailové šablony.

10. Jméno pravidla detekce, které by mělo být srozumitelné příjemci.

11. events je klíč, nebo název pole, a !ARG EVENTS je SP-Lang výraz, který uvádí logy, které způsobily pozitivní detekci z pravidla detekce.

12. address je klíč, nebo název pole, a !ITEM EVENT client.address získává hodnotu pole client.address z každého logu, který způsobil pozitivní detekci z pravidla detekce.

13. Váš popis události, který musí být velmi jasný a přesný.

Vyplňování e-mailové šablony

name, events, address a description jsou pole v e-mailové šabloně v tomto příkladu. Vždy se ujistěte, že klíče, které píšete v sekci with, odpovídají polím ve vaší e-mailové šabloně.

Pole name a description jsou statické textové hodnoty - zůstávají stejné v každém upozornění.

Pole events a address jsou dynamické hodnoty - mění se podle toho, které logy způsobily pozitivní detekci z pravidla detekce. Můžete psát dynamická pole použitím TeskaLabs SP-Lang.

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 notifikací, aby odeslal email, například jako výsledek pozitivní detekce v detekčním pravidle. Jinja šablonová pole umožňují emailové šabloně mít dynamické hodnoty, které se mění na základě proměnných, jako jsou události zapojené v pozitivní detekci. (Poté, co se naučíte vytvářet emailové šablony, naučte se používat Jinja šablonová pole.)

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

1. V Knihovně, klikněte na Templates, poté klikněte na Email.
2. Vpravo klikněte na Vytvořit novou položku v Email.
3. Pojmenujte svou šablonu, vyberte typ souboru a klikněte na Vytvořit. Pokud se nová položka neobjeví okamžitě, obnovte stránku.
4. Nyní můžete psát šablonu.

Kopírování existující emailové šablony

1. V Knihovně, klikněte na Templates, poté klikněte na Email.
2. Klikněte na existující šablonu, kterou chcete zkopírovat. Kopie, kterou vytvoříte, bude umístěna ve stejné složce jako originál.
3. Klikněte na ikonu v horní části obrazovky a klikněte na Copy.
4. Přejmenujte soubor, vyberte typ souboru a klikněte na Copy. Pokud se nová položka neobjeví okamžitě, obnovte stránku.
5. Klikněte na Edit, abyste provedli změny, a klikněte na Save, abyste uložili své změny.

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:

• Kdo email odesílá
• Proč tento email dostávají
• Co znamená email/alert
• Jak vyšetřit nebo dále postupovat při řešení problému - zahrňte všechny relevantní a užitečné informace, jako jsou ID logů nebo přímé odkazy na zobrazení vybraných logů

Jednoduchý příklad šablony pomocí Markdown:

PŘEDMĚT: {{ name }}

TeskaLabs LogMan.io identifikoval významnou událost ve vaší IT infrastruktuře, která může vyžadovat vaši okamžitou pozornost.
Prosím přezkoumejte následující shrnutí události:

Událost: {{name}}

Popis události: {{description}}

Tato notifikace byla vytvořena na základě originálního logu/logů:  

{% for event in events %}
- {{event}}
{% endfor %}

Notifikace byla vygenerována pro tuto adresu: {{address}}

Doporučujeme, aby jste toto incident rychle přezkoumali a určili další příslušný postup.

Pamatujte, že účinnost jakéhokoli bezpečnostního programu spočívá v rychlé reakci.
Děkujeme za vaši pozornost k této záležitosti.

Zůstaňte v bezpečí,

TeskaLabs LogMan.io

Vytvořeno s <3 od [TeskaLabs](https://teskalabs.com)

Slova ve dvou složených závorkách (jako {{address}}) jsou šablonová pole nebo zástupce. Toto jsou Jinja šablonová pole, která čerpají informace z sekce notifikace v detekčním pravidle. O Jinja šablonách se dozvíte více zde.

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 NULL.

2. Přidejte hodnotu: Chcete-li upravit hodnotu, klikněte na ikonu , která se objeví, když najedete myší vedle hodnoty NULL. Zadejte hodnotu (co chcete, aby se zobrazilo místo pole/zástupce v emailu, který odešlete), a uložte kliknutím na ikonu .

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ů:

{
    "name":"Detection rule 1",
    "description":"Description of Detection rule 1",
    "events":["log-ID-1", "log-ID-2", "log-ID-3"],
    "address":"Example address"
}

Rychlé tipy pro JSON

• Parametry začněte a ukončete složenými závorkami {}
• Každou položku, jak klíče, tak hodnoty, pište do uvozovek ""
• Připojte klíče k jejich hodnotám dvojtečkou : (např.: "key":"value")
• Oddělte páry klíč-hodnota čárkami ,. Můžete také použít mezery a nové řádky pro lepší čitelnost - ve funkci budou ignorovány.
• Pole pište do závorek [] a oddělte položky čárkami (klíč events může mít více hodnot, jak umožňuje výrok Jinja for, takže zde je to napsáno jako pole)

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 notification v detekčním pravidlu pracuje s emailovou šablonou k odeslání zprávy, když je detekční pravidlo spuštěno. Emailová šablona obsahuje pole pro zástupce, a notifikace určuje, co tato zástupná pole v reálném emailu, který příjemce obdrží, vyplní. To je možné díky šablonovacímu jazyku Jinja. (Naučte se psát emailové šablony před tím, než se naučíte o Jinja polích.)

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.

{{fieldname}} NEBO {{ fieldname }}

Pro podrobnější vysvětlení šablonování pomocí Jinja navštivte tento návod.

if výraz

Možná budete chtít použít stejnou emailovou šablonu pro více detekčních pravidel. Vzhledem k tomu, že různá detekční pravidla mohou obsahovat různá data, některé části vašeho emailu mohou být relevantní pouze pro některá detekční pravidla. Můžete použít if, aby se sekce zahrnula pouze tehdy, pokud má určitý klíč v notifikační šabloně hodnotu. To vám pomůže vyhnout se nevyplněným šablonovým polím nebo nesmyslnému textu v emailu.

V tomto příkladu bude vše mezi if a endif zahrnuto v emailu pouze tehdy, pokud má klíč sender hodnotu v notifikační sekci detekčního pravidla. (Pokud není hodnota pro sender, tato sekce se v emailu neobjeví.)

{% if sender %}

Emailová adresa {{ sender }} odeslala podezřelé množství emailů.

{% endif %}

Pro více detailů navštivte tento návod.

for výraz

Použijte for, když máte více hodnot ze stejné kategorie, které chcete zobrazit jako seznam ve vašem emailu.

V tomto příkladu je events skutečné pole šablony, které vidíte v notifikaci, a může obsahovat více hodnot (v tomto případě více log ID). Zde je log pouze dočasná proměnná používaná pouze v tomto for výrazu k reprezentaci jedné hodnoty, kterou notifikace odesílá z pole events. (Tato dočasná proměnná může být jakékoli slovo, protože odkazuje pouze na sebe v emailové šabloně.) Výraz for umožňuje šabloně zobrazit tyto více hodnot jako odrážkový seznam (více instancí).

{% for log in events %}

- {{ log }}

{% endfor %}

Pro více detailů navštivte tento návod.

Link šablonování

Díky TeskaLabs ASAB Iris můžete do svých emailů zahrnout odkazy, které se mění na základě tenanta nebo událostí detekovaných pravidlem.

Odkaz na domovskou stránku tenanta:

{{lmio_url}}/?tenant={{tenant}}#/

Nemusíte zahrnout pole tenant do sekce notification vašeho detekčního pravidla, aby odkaz fungoval.

Odkaz na specifický log:

[{{event}}]({{lmio_url}}/?tenant={{tenant}}#/discover/lmio-{{tenant}}-events?aggby=minute&filter={{event}}&ts=now-2d&te=now&refresh=off&size=40)

Nemusíte zahrnout tenant nebo lmio_url do sekce notification vašeho detekčního pravidla, aby odkaz fungoval.

Použití Base64 obrázků v HTML šablonách e-mailů

Pro pevné zakódování obrázku do e-mailové šablony napsané v HTML použijte Base64. Převod obrázku na Base64 přemění obrázek na dlouhý řetězec textu.

1. Použijte nástroj pro převod obrázku (například tento od Atatus), abyste svůj obrázek převedli na Base64.
2. Pomocí tagů <img> pro obrázek a alt pro alternativní text zkopírujte a vložte Base64 řetězec do své šablony takto:

<img alt="ZDE ALTERNATIVNÍ TEXT" src="ZDE VLOŽTE"/>

Poznámka

Alternativní text je volitelný, ale doporučuje se, protože se zobrazí v případě, že se váš obrázek z nějakého důvodu nenačte.

Ended: Notifikace

Ended: Analytikův manuál

Administrační manuál

Administrátorská příručka TeskaLabs LogMan.io

Vítejte v administrátorské příručce. Použijte tuto příručku k nastavení a konfiguraci LogMan.io pro sebe nebo klienty.

Instalace

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

Danger

TeskaLabs LogMan.io NESMÍ být provozován pod uživatelem root (superuživatel). Porušení tohoto pravidla může vést k významným rizikům kybernetické bezpečnosti.

Předpoklady

• Hardware (fyzický nebo virtualizovaný server)
• OS Linux: Ubuntu 22.04 LTS a 20.04 LTS, RedHat 8 a 7, CentOS 7 a 8 (pro další OS, prosím kontaktujte naši podporu)
• Síťové připojení s povoleným odchozím přístupem na Internet (lze omezit po instalaci); podrobnosti jsou popsány zde
• Přihlašovací údaje k SMTP serveru pro odchozí e-maily
• DNS doména, i interní (potřebná pro nastavení HTTPS)
• Přihlašovací údaje k "docker.teskalabs.com" (kontaktujte naši podporu, pokud je nemáte)

Od Bare Metal serveru k Operačnímu systému

Note

Přeskočte tuto sekci, pokud instalujete na virtuálním stroji, respektive na hostiteli s již nainstalovaným operačním systémem.

Předpoklady

• Server splňující předepsanou organizaci ukládání dat.
• Bootovací USB disk s Ubuntu Server 22.04 LTS; nejnovější verze.
• Přístup k serveru vybavenému monitorem a klávesnicí; alternativně přes IPMI nebo ekvivalentní mimo pásmou správu.
• Síťové připojení s povoleným odchozím přístupem na Internet.

Note

Tyto jsou další předpoklady kromě obecných předpokladů uvedených výše.

Kroky

1) Spusťte server pomocí bootovacího USB disku s Ubuntu Server.

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

Použijte UEFI oddíl na USB disku jako bootovací zařízení.

Vyberte "Try or Install Ubuntu Server" v bootovacím menu.

2) Vyberte "English" jako jazyk

3) Aktualizujte instalátor, pokud je to potřeba

4) Vyberte anglické rozložení klávesnice

5) Vyberte typ instalace "Ubuntu Server"

6) Nakonfigurujte síťové připojení

Toto je konfigurace sítě pro instalační účely, konečná konfigurace sítě může být odlišná.
Pokud používáte DHCP server, konfigurace sítě je automatická.

DŮLEŽITÉ: Internetové připojení musí být dostupné.

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

7) Přeskočte nebo nakonfigurujte proxy server

Přeskočte (stiskněte "Done") konfiguraci proxy serveru.

8) Potvrďte vybranou adresu zrcadla

Potvrďte vybranou adresu zrcadla stisknutím "Done".

9) Vyberte "Custom storage layout"

Vlastní uspořádání úložného prostoru systému je následující:

Mount	Velikost	FS	Část.	RAID / Část.	VG / LV
/boot/efi	1G	fat32	1
SWAP	64G		2
/boot	2G	ext4	3	md0 / 1
/	50G	etx4	3	md0 / 2	systemvg / rootlv
/var/log	50G	etx4	3	md0 / 2	systemvg / loglv
Nepoužitý	>100G		3	md0 / 2	systemvg

Legenda:

• FS: Systém souborů (Filesystem)
• Část.: GUID oddíl (Partition)
• RAID / Část.: MD RAID svazek a oddíl na daném RAID svazku
• VG: LVM Volume Group (Skupina logických svazků)
• LV: LVM Logical Volume (Logický svazek)

Note

Nepoužitý prostor bude později použit k instalaci např. Docker kontejnerů.

10) Identifikujte dva systémové úložné disky

Dva systémové úložné disky jsou strukturovány symetricky, aby byla zajištěna redundance v případě selhání jednoho systémového disku.

Note

Rychlé a pomalé úložiště zde není konfigurováno během instalace OS, ale později z nainstalovaného OS.

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

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

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

Další UEFI oddíl je vytvořen na druhém systémovém úložišti.

13) Vytvořte oddíly SWAP na obou systémových úložných discích

Na každém z dvou disků přidejte GPT oddíl velikosti 64G a formát swap.

Vyberte "free space" na příslušném systémovém úložišti a poté "Add GPT Partition".

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

14) Vytvořte GPT oddíl pro RAID1 na obou systémových úložných discích

Na každém z dvou disků přidejte GPT oddíl se zbývajícím volným prostorem. Formát je "Leave unformatted", protože tento oddíl bude přidán do RAID1 pole. Můžete nechat pole "Size" prázdné, aby byl použit veškerý zbývající prostor na zařízení.

Výsledkem je položka "partition" namísto "free space" na příslušných discích.

15) Vytvořte software RAID1

Vyberte "Create software RAID (md)".
Název pole je md0 (výchozí).
Úroveň RAID je "1 (zrcadlený)".

Vyberte dva oddíly z kroku výše, nechte je označené jako "active" a stiskněte "Create".

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

16) Vytvořte BOOT oddíl pro RAID1

Přidejte GPT oddíl na RAID1 md0 z kroku výše.

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 LVM.

Přidejte GPT oddíl na RAID1 md0 pomocí "free space" položky pod zařízením md0.

Použijte maximální dostupný prostor a nastavte formát na "Leave unformatted". Můžete nechat pole "Size" prázdné, aby byl použit veškerý zbývající prostor na zařízení.

18) Nastavte systémovou skupinu svazků LVM

Vyberte "Create volume group (LVM)".
Název skupiny svazků je systemvg.

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

19) Vytvořte root logický svazek

Přidejte logický svazek pojmenovaný rootlv na systemvg (v "free space" položce), velikost je 50G, formát je ext4 a mount je /.

20) Přidejte vyhrazený logický svazek pro systémové logy

Přidejte logický svazek pojmenovaný loglv na systemvg, velikost je 50G, formát je ext4 a mount je "Other" a /var/log.

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

Stiskněte "Done" na spodku obrazovky a případně "Continue" pro potvrzení aplikace změn na systémových úložný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 na konci instalace odstraněno.

23) Nastavení SSH

Vyberte "Install OpenSSH server"

24) Přeskočte instalaci serverových snapů

Stiskněte "Done", žádné serverové snapy nebudou instalovány z této obrazovky.

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

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

Po dokončení instalace, včetně bezpečnostních aktualizací, vyberte "Reboot Now".

26) Při výzvě vyjměte USB disk ze serveru

Stiskněte "Enter" pro pokračování v procesu restartování.

Note

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

27) Bootujte server do nainstalovaného OS

Vyberte "Ubuntu" na obrazovce GRUB nebo počkejte 30 sekund.

28) Přihlaste se jako tladmin

29) Aktualizujte operační systém

sudo apt update
sudo apt upgrade
sudo apt autoremove

30) Nakonfigurujte pomalé úložiště dat

Pomalé úložiště dat (HDD) je připojeno 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 software RAID5 pole na /dev/md1 s ext4 systémem souborů, připojeným na /data/hdd.

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

Note

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

Vytvořte EXT4 systém souborů a mountovací bod:

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ě.

Připojte disk:

sudo mount /data/hdd

Note

Konstrukce RAID pole může trvat značné množství času. Pro sledování postupu můžete použít 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

Tyto rychlostní limity vydrží až do dalšího restartu.

31) Nakonfigurujte rychlé úložiště dat

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

Předpokládáme, že server poskytuje následující disková zařízení /dev/nvme0n1 a /dev/nvme1n1.

Vytvořte software RAID1 pole na /dev/md2 s ext4 systémem souborů, připojený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ě.

Připojte disk:

sudo mount /data/ssd

32) Zachovejte konfiguraci RAID pole

Spusťte:

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf

Příklad výstupu:

ARRAY /dev/md/2 metadata=1.2 name=lmd01:2 UUID=5ac64642:51677d00:20c5b5f9:7de93474
ARRAY /dev/md/1 metadata=1.2 name=lmd01:1 UUID=8b0c0872:b8c08564:1815e508:a3753449

Aktualizujte init ramdisk:

sudo update-initramfs -u

33) Vypněte periodickou kontrolu RAID

sudo systemctl disable mdcheck_continue
sudo systemctl disable mdcheck_start

34) Instalace OS je dokončena

Restartujte server pro ověření správnosti instalace OS.

sudo reboot

Zde je video, které rekapituluje instalační proces:

Od Operačního systému k Dockeru

Předpoklady

• Běžící server s n

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íť: 2x 1Gbps+ Ethernet NIC; nebo 1x dvouportový
• Napájecí zdroj: redundantní 920W
• IPMI nebo ekvivalentní

Poznámka

RAID je implementován v softwaru/OS.

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

Poznámka

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

---

Poslední aktualizace: prosinec 2023

Ú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 server
• raid je náklad na RAID, 1 pro RAID5 a 2 pro RAID6
• capacity 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íť

User 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.

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.

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ě.

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:prime256v1 \
  -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
        Platnost
            Not Before: Nov 16 11:17:00 2023 GMT
            Not After : Nov 15 11:17:00 2024 GMT
        Subjekt: CN = logman.example.com
        Informace o veřejném klíči subjektu:
            Algoritmus veřejného klíče: id-ecPublicKey
                Veřejný klíč: (384 bit)
                pub:
                    04:79:e2:9f:69:cb:ac:f5:3f:93:43:56:a5:ac:d7:
                    cf:97:f9:ba:44:ee:9b:53:89:19:fd:91:02:0d:bd:
                    59:41:d6:ec:c6:2b:01:33:03:b6:3e:4a:1d:f4:e9:
                    2c:3f:af:49:92:79:9c:00:0b:0b:e3:28:7b:13:33:
                    b4:ac:88:d7:9c:0a:7b:95:90:09:a2:f7:aa:ce:7c:
                    51:3e:3a:94:af:a8:4b:65:4f:82:90:6a:2f:a9:57:
                    25:6f:5f:80:09:4c:cb
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 rozšíření:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                49:7A:34:F8:A6:EB:6D:8E:92:42:57:BB:EB:2D:B3:82:F4:98:9D:17
            X509v3 Authority Key Identifier:
                49:7A:34:F8:A6:EB:6D:8E:92:42:57:BB:EB:2D:B3:82:F4:98:9D:17
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:logman.example.com
    Algoritmus pro podpis: ecdsa-with-SHA256
    Hodnota podpisu:
        30:64:02:30:16:09:95:f4:04:1b:99:f4:06:ef:1e:63:4e:aa:
        1d:21:b0:b1:31:c1:84:9a:a9:55:c6:14:bd:a1:62:c5:14:14:
        35:73:da:8b:a8:7b:f2:f6:4c:8c:b0:6b:72:79:5f:4c:02:30:
        49:6f:ef:05:0f:dd:28:fb:26:f8:76:71:01:f3:e4:da:63:72:
        17:db:96:fb:5c:09:43:f8:7b:3b:a1:b6:dc:23:31:66:5d:23:
        18:94:0b:e4:af:8b:57:1e:c3:3d:93:6f

Vygenerování CSR

Pokud certifikační autorita vyžaduje CSR pro získání SSL certifikátu, postupujte následovně:

1. Vygenerujte soukromý klíč:

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:prime256v1 -out key.pem

Tento příkaz vytvoří key.pem se soukromým klíčem.

2. Vytvořte CSR pomocí vygenerovaného soukromého klíče:

openssl req -new -key key.pem -out csr.pem -subj "/CN=logman.example.com"

Tento příkaz vytvoří soubor csr.pem s žádostí o podepsání certifikátu (Certificate Signing Request).

Nahradit logman.example.com plně kvalifikovaným doménovým jménem nasazení LogMan.io.

3. Podat CSR certifikační autoritě

Certifikační autorita vytvoří certifikát a uloží jej v cert.pem ve formátu PEM.

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ů.

Životní cyklus dat

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

Schéma: Životní cyklus dat v TeskaLabs LogMan.io.

Životní cyklus je řízen funkcí ElasticSearch, která se nazývá Index Lifecycle Management (ILM).

Index Lifecycle Management

Index Lifecycle Management (ILM) v ElasticSearch automaticky uzavírá nebo maže staré indexy (např. s daty staršími než tři měsíce), takže vyhledávací výkon je zachován a datové úložiště je schopné ukládat současná data. Nastavení je uloženo v tzv. ILM politice.

ILM by měl být nastaven před tím, než jsou data pumpována do ElasticSearch, aby nový index našel a přiřadil se k příslušné ILM politice. Pro více informací se podívejte na oficiální dokumentaci: https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-index-lifecycle-management.html

Komponenty LogMan.io, jako je Dispatcher, pak používají specifikovaný ILM alias (lm_) a ElasticSearch automaticky přesouvá data do příslušného indexu přiřazeného k ILM politice.

Hot-Warm-Cold architektura (HWC)

HWC je rozšíření standardní rotace indexů poskytované ElasticSearch ILM a je to dobrý nástroj pro správu dat časových řad. HWC architektura nám umožňuje přidělit specifické uzly pro jednu z fází. Při správném použití, společně s architekturou clusteru, to umožní maximální výkon, využitím dostupného hardware na maximum.

Hot fáze

Obvykle existuje určité časové období (týden, měsíc atd.), kdy chceme intenzivně dotazovat indexy, s cílem na rychlost, spíše než na šetření paměti (a dalších zdrojů). Tady přichází na řadu „Hot“ fáze, která nám umožňuje mít index s více replikami, rozložený a přístupný na více uzlech pro optimální uživatelský zážitek.

Hot uzly

Hot uzly by měly využívat rychlé části dostupného hardware, využívající většinu CPU a rychlejší vstup/výstup.

Warm fáze

Jakmile toto období skončí a indexy už nejsou dotazovány tak často, budeme mít výhodu přesunu do „Warm“ fáze, která nám umožňuje snížit počet uzlů (nebo přejít na uzly s méně dostupnými zdroji) a replik indexů, čímž se snižuje zatížení hardware, zatímco stále zachovává možnost vyhledávání v datech přiměřeně rychle.

Warm uzly

Warm uzly, jak naznačuje jejich název, stojí na křižovatce mezi čistě úložnými uzly, zatímco stále zachovávají nějaký výkon CPU pro občasné dotazy.

Cold fáze

Někdy existují důvody pro uchovávání dat po delší období (diktované zákonem nebo nějakým interním pravidlem). Data se neočekává dotazovat, ale zároveň nemohou být smazána.

Cold uzly

Zde přichází na řadu Cold uzly, mohou být málo, s malými CPU zdroji, nemají potřebu používat SSD disky, jsou naprosto v pořádku s pomalejším (a případně větším) úložištěm.

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

Archivní fáze

Archivní fáze je v návrhu volitelná. Jedná se o offline dlouhodobé úložiště. Nejstarší data z cold fáze mohou být periodicky přesouvána do archivní fáze namísto jejich smazání.

Používají se standardní archivní politiky provozující organizace SIEM. Archivovaná data musí být šifrována.

Je také možné určitá logy přímo z warm fáze posílat do archivní fáze.

Vytvoření ILM politiky

Kibana

K vytváření ILM politiky v ElasticSearch lze použít Kibana verze 7.x.

1.) Otevřete Kibanu

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

3.) V sekci ElasticSearch klikněte na Index LifeCycle Policies

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

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

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

7.) Nastavte maximální věk indexu, např. 10 dní (rollover podle času)

8.) Klikněte na spínač na dolní části obrazovky v sekci Fáze mazání a zadejte čas, po kterém by měl být index smazán, např. 120 dní od rolloveru

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

Použití politiky v šabloně indexu

Úprava šablony indexu

Přidejte následující řádky do šablony indexu JSON:

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

Kibana

K vytváření ILM politiky v ElasticSearch lze použít Kibana verze 7.x.

1.) Otevřete Kibanu

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

3.) V sekci ElasticSearch klikněte na Index Management

4.) Nahoře vyberte Šablonu indexu

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

6.) Klikněte na Upravit

7.) Na obrazovce Nastavení přidejte:

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

8.) Klikněte na Uložit

Vytvoření nového indexu, který bude využívat nejnovější šablonu indexu

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

PUT lm_tenant-000001
{
  "aliases": {
    "lm_": {
      "is_write_index": true
    }
  }
}

Alias bude pak použit ILM politikou pro distribuci dat do příslušného ElasticSearch indexu, takže pumpy se nemusí starat o číslo indexu.

Varování

Předpona a číslo indexu pro ILM rollover musí být odděleny -000001, ne _000001!

Poznámka

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

Zálohování a obnova v Elasticsearch

Snímky

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

Repozitáře

Nejprve je potřeba nastavit repozitář pro snímky. Uveďte umístění, kde se repoziář snímků nachází, např. /backup/elasticsearch. Tato cesta musí být přístupná ze všech uzlů v clusteru. Při spuštění Elasticsearch v dockeru to zahrnuje připojení prostoru uvnitř dockerových kontejnerů a jejich restartování.

Politiky

Pro zahájení pořizování snímků je potřeba vytvořit politiku. Politika určuje předponu názvů snímků, které vytváří, specifikuje repozitář, který bude používat pro tvorbu snímků. Vyžaduje nastavení rozvrhu, indexy (definované pomocí vzorů nebo specifických názvů indexů - např. lmio-mpsv-events-*). Kromě toho může politika určit, zda ignorovat nedostupné indexy, povolit částečné indexy a zahrnout globální stav. Použití těchto nastavení závisí na konkrétním případu, ve kterém bude politika snímků použita, a nejsou doporučeny ve výchozím nastavení. Je také možné nastavit automatické mazání snímků a definovat počet dnů, po kterých budou snímky smazány. Tyto nastavení také závisejí na konkrétní politice, nicméně samotné snímky jsou velmi malé (z hlediska paměti), když neobsahují globální stav, což je očekávané, vzhledem k tomu, že jsou to jen ukazatele na jiné místo, kde jsou skutečná data indexu uložena.

Obnovení snímku

Pro obnovení snímku jednoduše vyberte snímek obsahující index nebo indexy, které chcete obnovit, a vyberte "Restore". Pak musíte určit, zda chcete obnovit všechny indexy obsažené ve snímku, nebo jen část. Můžete přejmenovat obnovené indexy, také můžete obnovit částečně snímky indexů a upravit nastavení indexu při jejich obnovení. Nebo je obnovit na výchozí hodnoty. Indexy jsou pak obnoveny, jak bylo určeno, zpět do clusteru.

Úskalí

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

Plán kontinuity

Matice rizik

Matice rizik definuje úroveň rizika tím, že zohledňuje kategorii "Pravděpodobnost" výskytu incidentu oproti kategorii "Dopad". Obě kategorie dostávají skóre mezi 1 a 5. Násobením skóre "Pravděpodobnost" a "Dopad" dohromady se produkuje celkové skóre rizika.

Pravděpodobnost

Pravděpodobnost	Skóre
Vzácné	1
Nepravděpodobné	2
Možné	3
Pravděpodobné	4
Téměř jisté	5

Dopad

Dopad	Skóre	Popis
Nevýznamný	1	Funkčnost není ovlivněna, výkon není snížen, není potřeba žádný výpadek.
Menší	2	Funkčnost není ovlivněna, výkon není snížen, je potřeba výpadek zasaženého uzlu clusteru.
Střední	3	Funkčnost není ovlivněna, výkon je snížen, je potřeba výpadek zasaženého uzlu clusteru.
Závažný	4	Funkčnost je ovlivněna, výkon je výrazně snížen, je potřeba výpadek clusteru.
Katastrofický	5	Úplná ztráta funkčnosti.

Scénáře incidentů

Úplné selhání systému

Dopad: Katastrofický (5)
Pravděpodobnost: Vzácné (1)
Úroveň rizika: středně vysoká

Snižování rizika:

• Geograficky distribuovaný cluster
• Aktivní používání monitorování a alertů
• Preventivní údržba
• Silná kybernetická bezpečnost

Obnova:

1. Kontaktujte podporu a/nebo dodavatele a konzultujte strategii.
2. Obnovte funkčnost hardwaru.
3. Obnovte systém z zálohy konfigurace stránky.
4. Obnovte data z offline zálohy (začněte s nejnovějšími daty a pokračujte do historie).

Ztráta uzlu v clusteru

Dopad: Střední (4)
Pravděpodobnost: Nepravděpodobné (2)
Úroveň rizika: středně nízká

Snižování rizika:

• Geograficky distribuovaný cluster
• Aktivní používání monitorování a alertů
• Preventivní údržba

Obnova:

1. Kontaktujte podporu a/nebo dodavatele a konzultujte strategii.
2. Obnovte funkčnost hardwaru.
3. Obnovte systém z zálohy konfigurace stránky.
4. Obnovte data z offline zálohy (začněte s nejnovějšími daty a pokračujte do historie).

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

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

Rychlé disky jsou v RAID 1 poli, takže ztráta jednoho disku je nekritická. Zajistěte rychlou výměnu selhaného disku, aby nedošlo k selhání druhého rychlého disku. Selhání druhého rychlého disku bude eskalovat na "Ztrátu uzlu v clusteru".

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba
• Včasná výměna selhaného disku

Obnova:

1. Vypněte zasažený uzel v clusteru
2. Nahraďte selhaný rychlý disk co nejdříve
3. Zapněte zasažený uzel v clusteru
4. Ověřte správnou rekonstrukci RAID1 pole

Poznámka

Hot swap rychlého úložiště je podporován na specifickou žádost zákazníka.

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

Dopad: Střední (3)
Pravděpodobnost: Možné (3)
Úroveň rizika: středně vysoká

Tato situace je problematická, pokud se vyskytne současně na více uzlech clusteru. Používejte nástroje pro monitorování k identifikaci této situace před eskalací.

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba

Obnova:

1. Odstraňte nepotřebná data z rychlého úložiště.
2. Upravením konfigurace životního cyklu tak, aby data byla přesunuta na pomalé úložiště dříve.

Ztráta pomalého disku na jednom uzlu v clusteru

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

Pomalé disky jsou v RAID 5 nebo RAID 6 poli, takže ztráta jednoho disku je nekritická. Zajistěte rychlou výměnu selhaného disku, aby nedošlo k selhání dalšího disku. Selhání druhého disku v RAID 5 nebo třetího disku v RAID 6 bude eskalovat na "Ztrátu uzlu v clusteru".

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba
• Včasná výměna selhaného disku

Obnova:

1. Nahraďte selhaný pomalý disk co nejdříve (hot swap)
2. Ověřte správnou rekonstrukci pole RAID pomalého úložiště

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

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

Tato situace je problematická, pokud se vyskytne současně na více uzlech clusteru. Používejte nástroje pro monitorování k identifikaci této situace před eskalací.

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba
• Včasné rozšíření kapacity pomalého úložiště

Obnova:

1. Odstraňte nepotřebná data z pomalého úložiště.
2. Upravením konfigurace životního cyklu tak, aby data byla odstraněna z pomalého úložiště dříve.

Ztráta systémového disku na jednom uzlu v clusteru

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

Systémové disky jsou v RAID 1 poli, takže ztráta jednoho disku je nekritická. Zajistěte rychlou výměnu selhaného disku, aby nedošlo k selhání druhého rychlého disku. Selhání druhého systémového disku bude eskalovat na "Ztrátu uzlu v clusteru".

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba
• Včasná výměna selhaného disku

Obnova:

1. Nahraďte selhaný rychlý disk co nejdříve (hot swap)
2. Ověřte správnou rekonstrukci RAID1 pole

Nedostatek místa na systémovém úložišti

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

Používejte nástroje pro monitorování k identifikaci této situace před eskalací.

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba

Obnova:

1. Odstraňte nepotřebná data ze systémového úložiště.
2. Kontaktujte podporu nebo dodavatele.

Ztráta síťové konektivity na jednom uzlu v clusteru

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

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba
• Redundantní síťová konektivita

Obnova:

1. Obnovte síťovou konektivitu
2. Ověřte správnou provozní podmínku clusteru

Selhání clusteru ElasticSearch

Dopad: Závažný (4)
Pravděpodobnost: Možné (3)
Úroveň rizika: středně vysoká

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba
• Včasná reakce na zhoršující se stav clusteru ElasticSearch

Obnova:

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

Selhání uzlu ElasticSearch

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

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba
• Včasná reakce na zhoršující se stav clusteru ElasticSearch

Obnova:

1. Sledujte automatické připojování uzlu ElasticSearch zpět do clusteru
2. Kontaktujte podporu/dodavatele, pokud selhání přetrvává několik hodin.

Selhání clusteru Apache Kafka

Dopad: Závažný (4)
Pravděpodobnost: Vzácné (1)
Úroveň rizika: středně nízká

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba
• Včasná reakce na zhoršující se stav clusteru Apache Kafka

Obnova:

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

Selhání uzlu Apache Kafka

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

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba
• Včasná reakce na zhoršující se stav clusteru Apache Kafka

Obnova:

1. Sledujte automatické připojování uzlu Apache Kafka zpět do clusteru
2. Kontaktujte podporu/dodavatele, pokud selhání přetrvává několik hodin.

Selhání clusteru Apache ZooKeeper

Dopad: Závažný (4)
Pravděpodobnost: Vzácné (1)
Úroveň rizika: středně nízká

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba
• Včasná reakce na zhoršující se stav clusteru Apache ZooKeeper

Obnova:

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

Selhání uzlu Apache ZooKeeper

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

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba
• Včasná reakce na zhoršující se stav clusteru Apache ZooKeeper

Obnova:

1. Sledujte automatické připojování uzlu Apache ZooKeeper zpět do clusteru
2. Kontaktujte podporu/dodavatele, pokud selhání přetrvává několik hodin.

Selhání bezstavového mikroservisu datové cesty (kolektor, parser, dispatcher, korelátor, watcher)

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

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba

Obnova:

1. Restartujte selhaný mikroservis.

Selhání bezstavového podpůrného mikroservisu (všechny ostatní)

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

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba

Obnova:

1. Restartujte selhaný mikroservis.

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

Dopad: Střední (3)
Pravděpodobnost: Možné (3)
Úroveň rizika: středně vysoká

Snižování rizika:

• Aktivní používání monitorování a alertů
• Preventivní údržba

Obnova:

1. Identifikujte a odstraňte hlavní příčinu snížení výkonu
2. Kontakujte dodavatele nebo podporu, pokud je potřeba pomoc

Strategie zálohování a obnovy

Offline záloha příchozích logů

Příchozí logy jsou duplikovány do offline záložního úložiště, které není součástí aktivního clusteru LogMan.io (proto je "offline"). Offline záloha poskytuje možnost obnovy logů do LogMan.io po kritickém selhání atd.

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

Příchozí události (logy) jsou kopírovány na archivní úložiště, jakmile vstoupí do 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é okamžitě replikována na jiné uzly v clusteru po jejich příjezdu do clusteru. Z tohoto důvodu není tradiční zálohování doporučeno, ale možné.

Obnova je zajištěna komponentami clusteru replikací dat z jiných uzlů clusteru.

Strategie zálohování pro pomalé datové úložiště

Data uložená na pomalém datovém úložišti jsou VŽDY replikována na jiné uzly clusteru a rovněž uložena v archivu. Z tohoto důvodu není tradiční zálohování doporučeno, ale možné (zvažte obrovskou velikost pomalého úložiště).

Obnova je zajištěna komponentami clusteru replikací dat z jiných uzlů clusteru.

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

Doporučuje se pravidelné zálohování všech souborových systémů 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ší údržbě, inkrementální záloha jednou denně.
• Recovery Time Objective (RTO): 12 hodin.

Poznámka

RPO a RTO jsou doporučeny, předpokládá se vysoce dostupné nastavení clusteru LogMan.io. To znamená tři a více uzlů, aby úplný výpadek jednoho uzlu neovlivnil dostupnost služby.

Obecná pravidla zálohování a obnovy

1. Záloha dat: Pravidelně zálohujte do bezpečného úložiště, jako je cloudová služba, zálohovací pásky, aby se minimalizovala ztráta dat v případě selhání.

2. Plánování záloh: Vytvořte plán záloh, který splňuje potřeby organizace, jako jsou denní, týdenní nebo měsíční zálohy.

3. Ověření zálohy: Pravidelně ověřujte integritu zálohovaných dat, aby bylo zajištěno, že mohou být použity pro obnovu po havárii.

4. Testování obnovy: Pravidelně testujte obnovu zálohovaných dat, aby bylo zajištěno, že zálohovací a obnovovací proces fungují správně a aby byly identifikovány a vyřešeny jakékoli problémy dříve, než se stanou kritickými.

5. Uchování záloh: Vytvořte politiku uchovávání záloh, která vyvažuje potřebu dlouhodobé úschovy dat s náklady na uchovávání zálohovaných dat.

Monitorování a alertování

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

Mikroservisy LogMan.io poskytují OpenMetrics API a/nebo odesílají svou telemetrii do InfluxDB a používají Grafanu jako nástroj pro monitorování.

1. Strategie monitorování: OpenMetrics API se používá k sběru telemetrie ze všech mikroservisů v clusteru, operativního systému a hardwaru. Telemetrie je sbírána jednou

Sběr 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.

1. Stáhněte si obraz virtuálního stroje.

   Zde je odkaz ke stažení.

2. Importujte stažený obraz do vaší virtualizační platformy.

   

3. 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.

4. Spusťte virtuální stroj.

   

5. 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.

   

6. 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".

7. Zadejte identitu collectoru z kroku 4 do pole.

   Poté klikněte na Provision pro připojení collectoru a zahájení sběru logů.

   

8. 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 může být manuálně nainstalován do virtuálního stroje.

Specifikace

• 1 vCPU
• OS Linux, nejlépe Ubuntu Server 22.04.4 LTS, jsou podporovány i další hlavní distribuce
• 4 GB RAM
• 500 GB disk (50 GB pro OS; zbytek je buffer pro sbírané logy)
• 1x NIC, nejlépe 1Gbps

Collector musí být schopen se připojit k instalaci TeskaLabs LogMan.io přes HTTPS (WebSocket) pomocí jeho URL.

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íť

Doporučujeme přidělit statickou IP adresu virtuálnímu stroji, protože bude použit v mnoha konfiguracích zdrojů logů.

Ended: Sběr logů

ElasticSearch Nastavení

Index Šablony

Než se data nahrají do ElasticSearch, měla by být přítomna index šablona, aby byly správné datové typy přiřazeny každému poli.

Toto je obzvláště nutné pro časová pole, která by bez index šablony nefungovala a nemohla by být použita pro třídění a vytváření index vzorů v Kibana.

ElasticSearch index šablona by měla být přítomna v repozitáři site- pod názvem es_index_template.json.

Pro vložení index šablony pomocí PostMan nebo Kibana, vytvořte následující HTTP požadavek na instanci ElasticSearch, kterou používáte:

PUT _template/lmio-
{
  // Nasadit na <SPECIFY_WHERE_TO_DEPLOY_THE_TEMPLATE>
  "index_patterns" : ["lmio-*"],
  "version": 200721, // Zvýšení při každém vydání
  "order" : 9999998, // Snížení při každém vydání
  "settings": {
    "index": {
      "lifecycle": {
        "name": "lmio-",
        "rollover_alias": "lmio-"
      }
    }
  },
  "mappings": {
    "properties": {
      "@timestamp": { "type": "date", "format": "strict_date_optional_time||epoch_millis" },
      "rt": { "type": "date", "format": "strict_date_optional_time||epoch_second" },
      ...
  }
}

Tělo požadavku je obsah es_index_template.json.

Index Životní cyklus Správa

Index Životní cyklus Správa (ILM) v ElasticSearch slouží k automatickému uzavření nebo smazání starých indexů (např. s daty staršími tří měsíců), takže je zachován výkon vyhledávání a datové úložiště je schopné ukládat současná data. Nastavení je přítomno v tzv. ILM politice.

ILM by mělo být nastaveno předtím, než jsou data posílána do ElasticSearch, takže nový index najde a spojí se s příslušnou ILM politikou. Pro více informací odkazujeme na oficiální dokumentaci: https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-index-lifecycle-management.html

LogMan.io komponenty jako Dispatcher pak používají specifikovaný ILM alias (lm_) a ElasticSearch automaticky vkládá data do příslušného indexu přiřazeného k ILM politice.

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

Vytvořit ILM politiku

Kibana

Kibana verze 7.x může být použita pro vytvoření ILM politiky v ElasticSearch.

1.) Otevřete Kibana

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

3.) V sekci ElasticSearch klikněte na Index Životní cyklus Politiky

4.) Klikněte na Modré tlačítko Vytvořit politiku

5.) Zadejte její název, který by měl být stejný jako prefix indexu, např. lm_

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

7.) Nastavte maximální věk indexu, např. 10 dní (čas rollover)

8.) Klikněte na přepínač na dolním obrazovce ve fázi Smazání, a zadejte dobu po které by měl být index smazán, např. 120 dní od rollover

9.) Klikněte na Zelené tlačítko Uložit politiku

Použijte politiku v index šabloně

Upravte index šablonu(y)

Přidejte následující řádky do JSON index šablony:

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

Kibana

Kibana verze 7.x může být použita pro propojení ILM politiky s index šablonou ElasticSearch.

1.) Otevřete Kibana

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

3.) V sekci ElasticSearch klikněte na Správa Indexu

4.) Nahoře vyberte Index Šablona

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

6.) Klikněte na Upravit

7.) Na obrazovce Nastavení přidejte:

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

8.) Klikněte na Uložit

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

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

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

Alias pak bude použit ILM politikou k distribuci dat do příslušného ElasticSearch indexu, takže pumpy se nebudou muset starat o číslo indexu.

//Poznámka: Prefix a číslo indexu pro ILM rollover musí být odděleno -000001, ne _000001!//

Konfigurujte ostatní LogMan.io komponenty

Pumpy nyní mohou používat ILM politiku prostřednictvím vytvořeného aliasu, který je v příkladu výše lm_tenant. Konfigurační soubor by tedy měl vypadat takto:

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

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

//Poznámka: Ujistěte se, že v konfiguraci není žádný index prefix v source, jako v ElasticSearchSink v pipeline. Konfigurace kódu by nahradila konfiguraci souboru.//

Hot-Warm-Cold architektura (HWC)

HWC je rozšířením standardní rotace indexů poskytované ELASTICSEARCH ILM a je to dobrý nástroj pro správu datových časových řad. HWC architektura 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 plný potenciál.

Hot

Obvykle je nějaké období (týden, měsíc, atd.), kdy chceme dotazovat indexy intenzivně, zaměřujíc se na rychlost, spíše než na paměť (a další zdroje) šetření. Právě tehdy přijde vhod fáze „Hot“, která nám umožní mít index s více replikami, rozmístěnými a přístupnými na více uzlech pro optimální uživatelskou zkušenost.

Hot uzly

Hot uzly by měly používat rychlé části dostupného hardwaru, využívající většinu CPU a rychlejší IO.

Warm

Jakmile toto období skončí a indexy nejsou již tak často dotazovány, budeme mít prospěch z přesunu do fáze „Warm“, která nám umožní snížit počet uzlů (nebo přesunout na uzly s méně dostupnými zdroji) a repliky indexů, čímž se sníží zatížení hardwaru, zatímco stále zůstává možnost rozumně rychle vyhledávat data.

Warm uzly

Warm uzly, jak již název napovídá, stojí na křižovatce mezi použitím pouze pro účely úložiště, zatímco stále zachovávají nějakou CPU sílu pro zvládnutí občasného dotazu.

Cold

Někdy existují důvody pro ukládání dat na delší období (diktováno zákonem nebo nějakým interním pravidlem). Data nejsou očekávána, že budou dotazována, ale zároveň nemohou být dosud smazána.

Cold uzly

To je místo, kde přichází Cold uzly, může jich být málo, s malými CPU zdroji, nemají potřebu používat SSD disky, být naprosto v pořádku s pomalejším (a případně větším) úložištěm.

Závěr

Použití HWC ILM funkce na plný efekt vyžaduje určitou přípravu, mělo by být zváženo při stavbě produkčního ElasticSearch clusteru. Přidaná hodnota však může být velmi vysoká, v závislosti na konkrétních případech použití.

Nastavení InfluxDB

Konfigurace Docker-compose.yaml pro Influx v1.x

  influxdb:
    restart: on-failure:3
    image: influxdb:1.8
    ports:
      - "8083:8083"
      - "8086:8086"
      - "8090:8090"
    volumes:
      - /<path_on_host>/<where_you_want_data>:/var/lib/influxdb
    environment:
      - INFLUXDB_DB=<your_db>
      - INFLUXDB_USER=telegraf
      - INFLUXDB_ADMIN_ENABLED=true
      - INFLUXDB_ADMIN_USER=<your_user>
      - INFLUXDB_ADMIN_PASSWORD=<your_password>
    logging:
      options:
        max-size: 10m

Konfigurace Docker-compose.yaml pro Influx v2.x

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

Spuštění InfluxDB kontejneru

docker-compose up -d

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

http://localhost:8086/

Jak zapisovat/mazat data použitím CLI influx:

docker exec -it <influx-container> bash

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

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

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

Nastavení politiky uchovávání dat

Politika uchovávání dat určuje, jak dlouho chcete data v InfluxDB uchovávat. Nastavíte název své politiky, kterou databázi ovlivňuje, jak dlouho budete data uchovávat, replikaci a nakonec skupinu (DEFAULT v níže uvedeném případě). DEFAULT je používán pro všechny zdroje, které při vkládání dat do InfluxDB nedefinují skupinu.

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

Úprava existující politiky

docker exec <container_name> influx -execute ALTER RETENTION POLICY "autogen" on "<dbs>/<affected>" duration 100d

Mazání starých dat

Dbějte na uvozovky delete from "<collection>" where "<field>" = '<value>'

Mazání starých dat v konkrétním poli

Když přeconfigurujete své zdroje, můžete se chtít zbavit některých starých hodnot v konkrétních polích, aby nezahlcovaly vaše vizualizace. Můžete tak učinit použitím následujícího příkazu:

docker exec <container_name> influx -execute DROP SERIES WHERE "<tag_key>" = '<tag_value>'

Snižování podrobností

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

Příklad konkrétních politik retention (telegraf)

Používá se, když chcete nastavit různou retenci pro různé zdroje.

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

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

Průvodce nasazením TeskaLabs LogMan.io pro partnery

Předimplementační analýza

Každé dodání by mělo začít předimplementační analýzou, která uvádí všechny zdroje logů, které by měly být připojeny k LogMan.io. Výstupem analýzy je tabulka, kde každý řádek popisuje jeden zdroj logů, způsob získávání logů (čtení souborů, přesměrování logů na cílový port atd.), kdo je odpovědný za zdroj logů z pohledu zákazníka a odhad, kdy by měl být zdroj logů připojen. Viz následující obrázek:

Na obrázku jsou dva další sloupce, které nejsou součástí předimplementační analýzy a jsou doplněny později během realizace (kafka topic a dataset). Pro více informací viz sekce Event lanes níže.

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

LogMan.io cluster a sběračské servery

Servery

Na konci předimplementační analýzy by mělo být jasné, jak velký objem shromážděných logů (v událostech nebo zprávách za sekundu, zkráceně EPS) by měl být. Logy jsou vždy shromažďovány z infrastruktury zákazníka alespoň jedním serverem vyhrazeným pro sběr logů (takzvaný log collector).

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

• LogMan.io cluster je nasazen v infrastruktuře zákazníka na fyzických nebo virtuálních strojích (on-premise)
• LogMan.io cluster je nasazen v infrastruktuře partnera a je dostupný pro více zákazníků, kde každý zákazník má přiděleného jednoho tenanta (SoC, SaaS atd.)

Viz sekci Specifikace hardwaru pro více informací o konfiguraci fyzických serverů.

Architektura clusteru

V kterémkoliv způsobu nasazení clusteru by měl být k dispozici alespoň jeden server (pro PoC) nebo alespoň tři servery (pro nasazení) pro LogMan.io cluster. Pokud je cluster nasazen v infrastruktuře zákazníka, servery mohou rovněž fungovat jako sběračské servery, takže v tomto případě není třeba mít vyhrazený sběračský server. Architektura tří serverů může sestávat ze tří podobných fyzických serverů nebo dvou fyzických serverů a jednoho malého libovolného virtuálního stroje.

Menší nebo nekritická nasazení jsou možná na konfiguracích s jedním serverem.

Pro více informací o organizaci LogMan.io clusteru viz sekci Architektura clusteru.

Datové úložiště

Každý fyzický nebo ne-arbitrární server v LogMan.io clusteru by měl mít dostatek dostupného diskového úložiště, aby mohl uchovávat data po požadovanou dobu z předimplementační analýzy. Mělo by být k dispozici alespoň jedno rychlé (pro aktuální nebo jednodenní logy a Kafka topics) a jedno pomalejší (pro starší data, metadata a konfigurace) datové úložiště připojené k /data/ssd a /data/hdd. Protože všechny LogMan.io služby běží jako Docker kontejnery, složka /var/lib/docker by měla být rovněž připojena k jednomu z těchto úložišť.

Pro podrobnější informace o organizaci diskového úložiště, montáži atd. navštivte sekci Datové úložiště.

Instalace

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

Názvy hostitelů LogMan.io serverů v LogMan.io clusteru by měly dodržovat notaci lm01, lm11 atd. Pokud jsou použity oddělené sběračské servery (viz výše), není pro jejich názvy hostitelů žádné omezení. Pokud je součástí dodávky TeskaLabs, měl by být vytvořen uživatel tladmin s povoleními sudoer.

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

Odkazujte na Manuální instalaci pro komplexní průvodce.

Všechny služby jsou pak vytvořeny a spuštěny pomocí příkazu docker-compose up -d z adresáře, do kterého je naklonováno repozitář site (viz následující sekce):

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

Přístupové údaje k Dockeru jsou partnerovi poskytovány týmem TeskaLabs.

Site repozitář a konfigurace

Každý partner má přístup k TeskaLabs GitLab, kde spravuje konfigurace pro nasazení, což je doporučený způsob, jak uložit konfigurace pro budoucí konzultace s TeskaLabs. Nicméně každý partner může také použít svůj vlastní GitLab nebo jakýkoli jiný Git repozitář a poskytnout týmu TeskaLabs vhodné (alespoň čtecí) přístupy.

Každé nasazení pro každého zákazníka by mělo mít samostatný site repozitář, bez ohledu na to, zda je instalován celý LogMan.io cluster nebo jen sběračské servery. Struktura site repozitáře by měla vypadat následovně:

Každý serverový uzel (server) by měl mít samostatnou podsložku na vrcholu GitLab repozitáře. Dále by měla být složka s LogMan.io library, která obsahuje deklarace pro parsování, korelace atd. skupiny, config, která obsahuje konfiguraci Průzkumníka v UI a dashboardů a složku ecs s šablonami indexů pro ElasticSearch.

Každý partner má přístup k referenčnímu site repozitáři se všemi konfiguracemi včetně parserů a nastavení Průzkumníka, které jsou připravené.

ElasticSearch

Každý uzel v LogMan.io clusteru by měl obsahovat alespoň jeden ElasticSearch master uzel, jeden ElasticSearch data_hot uzel, jeden ElasticSearch data_warm uzel a jeden ElasticSearch data_cold uzel. Všechny ElasticSearch uzly jsou nasazeny pomocí Docker Compose a jsou součástí site /konfiguračního repozitáře. Libovolné uzly v clusteru obsahují pouze jeden ElasticSearch master uzel.

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

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

Pro více informací o ElasticSearch včetně vysvětlení hot (nedávná, jednodenní data na SSD), warm (starší) a cold uzly viz sekci ElasticSearch Setting.

ZooKeeper & Kafka

Každý serverový uzel v LogMan.io clusteru by měl obsahovat alespoň jeden ZooKeeper a jeden Kafka uzel. ZooKeeper je metadata úložiště dostupné v celém clusteru, kde Kafka ukládá informace o topic konzumentech, názvech topiků atd., a kde LogMan.io ukládá aktuální library a config soubory (viz níže). Nastavení Kafka a ZooKeeper může být zkopírováno z referenčního site repozitáře a konzultováno s vývojáři TeskaLabs.

Služby

Následující služby by měly být k dispozici alespoň na jednom z LogMan.io uzlů a zahrnují:

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

Pro více informací o SeaCat Auth a jeho správě v UI LogMan.io viz Dokumentace TeskaLabs SeaCat Auth.

Pro informace o tom, jak nahrát library z site repozitáře do ZooKeeper, odkazuji na Průvodce LogMan.io Commander.

UI

Následující uživatelská rozhraní by měla být nasazena a zpřístupněna přes nginx. První implementace by měla být vždy konzultována s vývojáři TeskaLabs.

• LogMan.io UI (viz LogMan.io Uživatelské rozhraní)
• Kibana (Průzkumník, vizualizace, dashboardy a monitorování nad ElasticSearch)
• Grafana (telemetrické dashboardy nad daty z InfluxDB)
• ZooKeeper UI (správa dat uložených v ZooKeeper)

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

Nasazení LogMan.io UI

Nasazení LogMan.io UI je částečně poloautomatický proces, pokud je správně nastavené. Takže existuje několik kroků k zajištění bezpečného nasazení UI:

• Nasazení artefaktu UI by mělo být staženo přes azure site repozitář poskytnutý vývojáři TeskaLabs. Informace o tom, kde je uložená konkrétní aplikace UI, lze získat z CI/CD obrazu repozitáře aplikace.
• Doporučuje se používat tagované verze, ale mohou nastat situace, kdy je požadována master verze. Informace o tom, jak ji nastavit, lze nalézt v docker-compose.yaml souboru referenčního site repozitáře.
• UI aplikace musí být sladěny se službami, aby byla zajištěna co nejlepší výkonnost (obvykle nejnovější tagované verze). Pokud si nejste jisti, kontaktujte vývojáře TeskaLabs.

Vytvoření tenanta

Každý zákazník je přiřazen jednomu nebo více tenantům. Tenanty jsou názvy v malých ASCII písmenech, které označují data/logy patřící uživateli a ukládají data každého tenanta do samostatného indexu ElasticSearch. Všechny event lanes (viz níže) jsou také specifické pro tenanty.

Vytvoření tenanta v SeaCat Auth pomocí LogMan.io UI

Pro vytvoření tenanta se přihlaste do LogMan.io UI s rolí superuživatele, což lze provést prostřednictvím provizionování. Pro více informací o provizionování viz sekci Provizionovací režim dokumentace SeaCat Auth.

V LogMan.io UI přejděte do sekce Auth v levém menu a vyberte Tenants. Jakmile tam budete, klikněte na možnost Create tenant a napište název tenanta. Pak klikněte na modré tlačítko a tenant by měl být vytvořen:

Poté přejděte do Credentials a přiřaďte nově vytvořeného tenanta všem relevantním uživatelům.

Indexy ElasticSearch

V Kibana by měl mít každý tenant šablony indexů pro lmio-tenant-events a lmio-tenant-others indexy, kde tenant je název tenanta (viz referenční site repozitář poskytnutý TeskaLabs). Šablony indexů lze vložit přes Dev Tools v levém menu Kibana.

Po vložení šablon indexů by měla být manuálně vytvořena ILM (index life cycle management) politika a první indexy, přesně jak je specifikováno v ElasticSearch Setting průvodci.

Kafka

V Kafce není žádné specifické vytvoření tenanta kromě event lanes níže. Nicméně vždy se ujistěte, že jsou správně vytvořeny topic lmio-events a lmio-others. Následující příkazy by měly být spuštěny v kontejneru Kafka (například: docker exec -it lm11_kafka_1 bash):

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

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

Každý Kafka topic by měl mít alespoň 6 partitionů (což může být automaticky použito pro paralelní konzumaci), což je vhodný počet pro větš

Připojení nového log source k LogMan.io

Předpoklady

Tenant

Každý zákazník má přiřazeno jednoho nebo více tenantů.

Název tenantu musí být malými písmeny v ASCII formátu, který označuje data/logy náležející uživateli a ukládá data každého tenantu do samostatného indexu v ElasticSearch. Všechny Event Lanes (viz níže) jsou také specifické pro tenanty.

Vytvoření tenantu v SeaCat Auth pomocí LogMan.io UI

Pro vytvoření tenantu se přihlaste do LogMan.io UI s rolí superuživatele, což lze provést prostřednictvím provisioning. Pro více informací o provizionování prosím odkázat na sekci Provisioning mode v dokumentaci SeaCat Auth.

V LogMan.io UI přejděte do sekce Auth v levém menu a vyberte Tenants. Jakmile tam budete, klikněte na možnost Create tenant a zadejte název tenantu. Poté klikněte na modré tlačítko a tenant by měl být vytvořen:

Poté přejděte do Credentials a přiřaďte nově vytvořený tenant všem relevantním uživatelům.

Šablony indexů v ElasticSearch

V Kibana by měl mít každý tenant šablony indexů pro indexy lmio-tenant-events a lmio-tenant-others, kde tenant je název tenantu (odkazujte na referenční site- repo poskytované TeskaLabs), takže každému poli jsou přiřazeny správné datové typy.

To je zvláště nutné pro časově založená pole, která by nefungovala bez šablony indexu a nemohla by být použita pro třídění a vytváření šablon indexů v Kibana.

Šablona indexu ElasticSearch by měla být přítomna v site- repo pod názvem es_index_template.json.

Šablony indexů lze vložit pomocí Dev Tools v Kibaba z levého menu.

Politika životního cyklu indexů v ElasticSearch

Index Lifecycle Management (ILM) v ElasticSearch slouží k automatickému uzavření nebo smazání starých indexů (např. s daty staršími než tři měsíce), takže performance hledání je zachována a úložiště dat je schopné ukládat aktuální data. Nastavení je přítomno v tzv. ILM politice.

ILM by měla být nastavena předtím, než jsou data napumpována do ElasticSearch, takže nový index najde a přiřadí se správné ILM politice. Pro více informací prosím odkázat na oficiální dokumentaci: https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-index-lifecycle-management.html

Komponenty LogMan.io jako Dispatcher pak používají specifikální ILM alias (lmio-) a ElasticSearch automaticky přiřadí data do správného indexu přiřazeného k ILM politice.

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

Vytvoření ILM politiky

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

1.) Otevřete Kibana

2.) Klikněte na Management v levém menu

3.) V sekci ElasticSearch klikněte na Index Lifecycle Policies

4.) Klikněte na tlačítko Create policy

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

6.) Nastavte max velikost indexu na požadovanou velikost pro otočení, např. 25 GB (velikost pro otočení)

7.) Nastavte maximální věk indexu, např. 10 dní (čas pro otočení)

8.) Klikněte na přepínač na dolní obrazovce u fáze Delete a zadejte čas po kterém má být index smazán, např. 120 dní od otočení

9.) Klikněte na tlačítko Save policy

Použití politiky v šabloně indexu

Přidejte následující řádky do JSON šablony indexu:

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

Indexy v ElasticSearch

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

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

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

2.) Vytvořte index pro neparsované a chybové události/logy:

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

Alias je pak použit ILM politikou pro distribuci dat do správného indexu ElasticSearch, takže pumpy se nemusí starat o počet indexů.

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

Event Lane (dráha událostí)

Event Lane v LogMan.io definuje, jak jsou logy z konkrétního zdroje dat pro dodaného tenanta odesílány do clusteru. Každá event lane je specifická pro sesbíraný zdroj. Každá event lane se skládá z jedné lmio-collector služby, jedné lmio-ingestor služby a jednoho nebo více instancí lmio-parser služby.

Collector

LogMan.io Collector by měl běžet na collector serveru nebo na jednom nebo více serverech LogMan.io, pokud jsou součástí stejné interní sítě. Ukázka konfigurace je součástí referenčního site- repo.

LogMan.io Collector je schopný prostřednictvím YAML konfigurace otevřít TCP/UDP port pro získávání logů, číst soubory, otevřít WEC server, číst z Kafka témat, Azure účtů atd. Komplexní dokumentace je dostupná zde: LogMan.io Collector

Následující ukázka konfigurace otevírá 12009/UDP port na serveru, kde je collector nainstalován, a přesměrovává sesbíraná data přes WebSocket na server lm11 na port 8600, kde by měl běžet lmio-ingestor:

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

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

url je buď hostname serveru a port Ingestoru, pokud jsou Collector a Ingestor nasazeny na stejném serveru, nebo URL s https://, pokud je použit collector server mimo interní síť. Poté je nutné specifikovat HTTPS certifikáty, prosím viz sekci output:WebSocket v LogMan.io Collector Outputs průvodce pro více informací.

tenant je název tenantu, k němuž patří logy. Název tenantu je pak automaticky propagován k Ingestoru a Parseru.

Ingestor

LogMan.io Ingestor přijímá log zprávy od Collectoru spolu s metadaty a ukládá je do Kafka do tématu, které začíná předponou collected-tenant-, kde tenant je název tenantu, ke kterému logy patří a technology je název technologie, z které data pocházejí jako například microsoft-windows.

Následující sekce v souborech CONF by vždy měly být nastavovány rozdílně pro každou event lane:

# Výstup
[pipeline:WSPipeline:KafkaSink]
topic=collected-tenant-technology

# Web API
[web]
listen=0.0.0.0 8600

Port v sekci listen by měl odpovídat portu v YAML konfiguraci Collectoru (pokud je Collector nasazen na stejném serveru) nebo nastavení v nginx (pokud jsou data sbírána z collector serveru mimo interní síť). Prosím, odkazujte na referenční site- repo poskytované vývojáři TeskaLabs.

Parser

Parser by měl být nasazen ve více instancích pro škálování výkonu. Parsuje data z původních bajtů nebo řetězců do slovníku ve specifikovaném schématu jako ECS (ElasticSearch Schema) nebo CEF (Common Event Format), přičemž používá parserovou skupinu z knihovny načtené v ZooKeeper. Je důležité specifikovat Kafka téma, ze kterého číst, což je stejné téma jako uvedeno v konfiguraci Ingestoru:

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

# Pipeline
[pipeline:ParsersPipeline:KafkaSource]
topic=collected-tenant-technology
group_id=lmio_parser_collected
auto.offset.reset=smallest

Parsers/parsing-group je umístění parsingové skupiny z knihovny načtené v ZooKeeper prostřednictvím LogMan.io Commander. Nemusí existovat na první pokus, protože všechna data pak jsou automaticky odeslána do lmio-tenant-others indexu. Když je parsingová skupina připravena, parsing proběhne a data mohou být viděna v dokumentovém formátu v lmio-tenant-events indexu.

Kafka témata

Než jsou všechny tři služby spuštěny příkazem docker-compose up -d, je důležité zkontrolovat stav specifického Kafka tématu collected-tenant-technology (kde tenant je název tenantu a technology je název připojené technologie/typu zařízení). V kontejneru Kafka (např.: docker exec -it lm11_kafka_1 bash), by měly být spuštěny následující příkazy:

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

Parsingové skupiny

Pro nejběžnější technologie již TeskaLabs připravila parsingové skupiny do ECS schématu. Prosím, spojte se s vývojáři TeskaLabs. Vzhledem k tomu, že všechny parsers jsou napsány v deklarativním jazyce, všechny parsingové skupiny v knihovně mohou být snadno upraveny. Název skupiny by měl být stejný jako název atributu dataset napsaný v deklaraci parse skupin.

Pro více informací o našem deklarativním jazyce prosím odkazujte na oficiální dokumentaci: SP-Lang

Po nasazení parsingové skupiny prostřednictvím LogMan.io Commander, by měl být restartován příslušný Parser(y).

Nasazení

Na serverech LogMan.io jednoduše spusťte následující příkaz ve složce, kde je naklonované site- repo:

docker-compose up -d

Sběr logů lze poté zkontrolovat v Docker kontejneru Kafka prostřednictvím Kafka konzolového konzumenta:

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

Data jsou nasávána Parserem z témata collected-tenant-technology do témat lmio-events nebo lmio-others a poté v Dispatcher (lmio-dispatcher) do indexů lmio-tenant-events nebo lmio-tenant-others v ElasticSearch.

Kafka

Kafka

Apache Kafka slouží jako fronta pro dočasné uchovávání událostí mezi mikroslužbami LogMan.io. Pro více informací, viz Architektura

Kafka v LogMan.io

Pojmenování témat v event lanes

Každý event lane má specifikované témata received, events a others.

Každý název tématu obsahuje název tenanta a stream event 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í logy pro příchozího tenanta a stream event lane.

events.tenant.stream

Téma events ukládá parsované události pro daný event lane definovaný tenantem a streamem.

others.tenant

Téma others ukládá neparsované události pro daného tenanta.

Interní témata

Pro LogMan.io existují následující interní témata:

lmio-alerts

Toto téma ukládá spuštěné alerty a je čteno mikroslužbou LogMan.io Alerts.

lmio-notifications

Toto téma ukládá spuštěná oznámení a je čteno mikroslužbou ASAB IRIS.

lmio-lookups

Toto téma ukládá požadované změny v lookupech a je čteno mikroslužbou LogMan.io Watcher.

Doporučené nastavení pro cluster se 3 uzly

Existují tři instance Apache Kafka, jedna na každém uzlu.

Počet oddílů pro každé téma musí být alespoň stejný jako počet konzumentů (3) a dělitelný 2, proto doporučený počet oddílů je vždy 6.

Doporučený počet replik je 1.

Každé téma musí mít rozumně nastavenou dobu uchování na základě dostupné velikosti SSD disků.

V prostředí LogMan.io clusteru, kde je průměrná EPS nad 1000 událostí za sekundu a velikost SSD disků je pod 2 TB, je doba uchování obvykle 1 den (86400000 milisekund). Viz sekci Příkazy.

Hint

Když je EPS nižší nebo je dostupného více místa na SSD, doporučuje se nastavit dobu uchová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í oddílů, replik a uchovávání, viz sekci Příkazy.

Příkazy

Následující příkazy slouží k vytvoření, úpravě a odstraně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 *.yaml v event lane uvnitř složky /EventLanes v knihovně.

Předpoklady

Všechny příkazy by měly být spouštěny z Docker kontejneru s Kafkou, který lze přistupovat následujícím příkazem:

docker exec -it kafka_container bash

Příkaz využívá Command Line Interface (CLI) pro Kafka, který je dokumentován zde: Kafka Command-Line Interface (CLI) Tools

Vytvoření tématu

Pro vytvoření tématu uveďte název tématu, počet oddílů (partitions) a replikační faktor. Replikační faktor by měl být nastaven na 1 a počet oddílů na 6, což je výchozí hodnota pro Kafka témata v LogMan.io.

/usr/bin/kafka-topics --zookeeper locahost:2181 --create --topic "events.tenant.fortigate" --replication-factor 1 --partitions 6

Nahraďte events.tenant.fortigate názvem vašeho tématu.

Konfigurace tématu

Retence

Následující příkaz změní dobu uchovávání dat pro Kafka téma na 86400000 milisekund, což je 1 den. To znamená, že data starší než 1 den budou z Kafka odstraněna kvůli úsporě úložného prostoru:

/usr/bin/kafka-configs --bootstrap-server localhost:9092 --entity-type topics --entity-name "events\.tenant\.fortigate" --alter --add-config retention.ms=86400000

Nahraďte events\.tenant\.fortigate názvem vašeho tématu.

Info

Všechna Kafka témata v LogMan.io by měla mít nastavenou dobu uchovávání dat.

Info

Při úpravě nastavení tématu v Kafce by měly být speciální znaky jako tečka (.) upraveny lomítkem (\).

Resetování offsetu spotřebitelské skupiny pro dané téma

Pro resetování čtecí pozice, nebo offsetu, pro dané ID skupiny (spotřebitelskou skupinu), použijte následující příkaz:

/usr/bin/kafka-consumer-groups --bootstrap-server localhost:9092  --group "my-console-client"  --topic "events\.tenant\.fortigate"  --reset-offsets --to-datetime 2020-12-20T00:00:00.000 --execute

Nahraďte events\.tenant\.fortigate názvem vašeho 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.

Smazání offsetu spotřebitelské skupiny pro dané téma

Offset pro dané téma může být smazán ze spotřebitelské skupiny, což znamená, že spotřebitelská skupina bude fakticky odpojena od 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\.fortigate" --delete-offsets

Nahraďte events\.tenant\.fortigate názvem vašeho tématu.

Nahraďte my-console-client daným ID skupiny.

Smazání spotřebitelské skupiny

Spotřebitelská skupina pro VŠECHNA témata může být smazána spolu s 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.

Úprava tématu

Změna počtu oddílů

Následující příkaz zvýší počet oddílů v rámci daného tématu.

/usr/bin/kafka-topics --zookeeper locahost:2181 --alter -partitions 6 --topic "events\.tenant\.fortigate"

Nahraďte events\.tenant\.fortigate názvem vašeho tématu.

Specifikujte uzel ZooKeeper

Kafka čte a mění data uložená v ZooKeeper. Pokud jste nakonfigurovali Kafku tak, že její soubory jsou uloženy v konkrétním uzlu ZooKeeper, obdržíte tuto chybu.

Error while executing topic command : Topic 'events.tenant.fortigate' does not exist as expected
[2024-05-06 10:16:36,207] ERROR java.lang.IllegalArgumentException: Topic 'events.tenant.fortigate' does not exist as expected
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$)

Upravte podle toho argument --zookeeper. Například data Kafka jsou uložena v uzlu kafka ZooKeeper:

/usr/bin/kafka-topics --zookeeper lm11:2181/kafka --alter --partitions 6 --topic 'events\.tenant\.fortigate'

Zkuste odstranit únikové 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 na paměti, že Kafka témata jsou automaticky vytvářena, pokud jsou na ně jakoukoli službou produkována/odesílána nová data.

/usr/bin/kafka-topics --zookeeper locahost:2181 --delete --topic "events\.tenant\.fortigate"

Nahraďte events\.tenant\.fortigate názvem vašeho tématu.

Řešení problémů

Je zde mnoho logů v jiných 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é grepovat 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řicházející logy s atributem "interface" ze všech event témat.

Přesunutí Particí v Kafka

Když je přidán nový uzel Kafka, Kafka automaticky nepřeřazuje partici. Následující kroky se používají k manuálnímu přeřazení particí Kafka pro specifikované téma (témata):

1.) Přejděte do kontejneru Kafka

docker exec -it kafka_container bash

2.) Vytvořte /tmp/topics.json s tématy, jejichž particie by měly být přeřazeny ve formátu:

cat << EOF | tee /tmp/topics.json
{
"topics": [
{"topic": "events.tenant.stream"},
],
"version": 1
} 
EOF

3.) Vytvořte výstup reassignment JSON ze seznamu témat, která budou migrována, a 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 ve /tmp/reassign.json a vypadat následovně, se všemi tématy a partici s novým přidělením:

[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"]}]}

4.) Použijte výstup z předchozího příkazu jako vstup pro provedení přeřazení/vyvážení:

/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řeřazení particí během následujících hodin.

Pro více informací, viz Přesunutí partící v Apache Kafka Clusteru .

Ended: Kafka

Monitorová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:

1. V LogMan.io, přejděte na Nástroje.

1. 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.

2. Klikněte na tlačítko menu a přejděte na Dashboardy.

3. 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.

Manuál pro profylaktické kontroly

Profylaktická kontrola je systematické preventivní hodnocení pro ověření, že systém funguje správně, a pro identifikaci a zmírnění potenciálních problémů, než se eskalují do závažnějších nebo kritických problémů. Pravidelným prováděním profylaktických kontrol můžete proaktivně udržovat integritu, spolehlivost a efektivitu svého systému TeskaLabs LogMan.io a minimalizovat riziko neočekávaných selhání nebo přerušení, které by mohly nastat, pokud by se nechaly nevyřešené.

Podpora

Pokud potřebujete další informace nebo podporu nad rámec toho, co zde vidíte, kontaktujte svůj Slack kanál podpory TeskaLabs LogMan.io nebo pošlete e-mail na support@teskalabs.com. Rádi vám pomůžeme.

Provádění profylaktických kontrol

Důležité

Provádějte profylaktické kontroly v konzistentních intervalech, ideálně ve stejný den v týdnu a přibližně ve stejnou dobu. Pamatujte, že objem a načasování příchozích událostí se mohou lišit v závislosti na dni v týdnu, pracovní době a svátcích.

Během profylaktických kontrol se ujistěte, že provedete komplexní přehled všech dostupných tenantů.

Prozkoumejte každý z následujících komponent vašeho instalace TeskaLabs LogMan.io podle našich doporučení a v případě potřeby hlaste problémy.

Funkčnosti TeskaLabs LogMan.io

Umístění: Postranní panel TeskaLabs LogMan.io

Cíl: Zajištění, že každá funkčnost aplikace TeskaLabs LogMan.io funguje správně

V rámci přiřazeného tenantu důkladně prozkoumejte každý komponent uvedený v postranním panelu (Průzkumník, Dashboardy, Exporty, Vyhledávání, Reporty atd.), abyste zajistili jejich správný provoz. Problémy zjištěné v této části by měly být hlášeny vašemu kanálu podpory TeskaLabs. To může zahrnovat problémy jako vyskakovací chyby při otevírání sekce z postranního panelu, ztrátu dostupnosti některých nástrojů nebo například nemožnost otevřít Dashboardy.

Hlášení problémů: Pro obecné hlášení použijte Slack kanál podpory.

Monitorování zdroje logů

Umístění: Obrazovka Průzkumník TeskaLabs LogMan.io nebo dedikovaný dashboard

Cíl: Zajištění, že každý zdroj logů je aktivní a funguje podle očekávání a že nejsou nalezeny žádné anomálie (například výpadek, špice nebo něco neobvyklého). Toto je také zásadní pro viditelnost zdroje logů.

Poznámka: Zvažte začlenění základních linií jako další možnost pro kontrolu zdrojů logů.

Monitorování zdroje logů lze provádět individuálním přezkoumáním každého zdroje logu nebo vytvořením přehledového dashboardu vybaveného widgety pro vizuální sledování aktivity každého zdroje logu. Doporučujeme vytvoření dashboardu s čárovými grafy.

Vyšetřování by mělo vždy pokryt vzorek dat mezi každou profylaktickou kontrolou.

Hlášení problémů: V případě neaktivního zdroje logů proveďte další šetření a nahlaste to na kanál podpory TeskaLabs LogManio Slack.

Časová pásma logů

Umístění: Obrazovka Průzkumník TeskaLabs LogMan.io

Cíl: Zajištění, že nejsou žádné nesrovnalosti mezi vaším časovým pásmem a časovým pásmem přítomným v logách

Zjistěte, zda se v logách nacházejí nějaké s hodnotou @timestamp, která je časově budoucí. To můžete provést filtrováním časového rozsahu od současnosti do 2 hodin (nebo více) od současnosti.

Hlášení problémů: Pro obecné hlášení použijte Slack podporu projektu.

Pokud se problém jeví jako spojený s nastavením logovacího zařízení, prosím prozkoumejte to dále ve své vlastní síti.

Ostatní události

Umístění: Obrazovka Průzkumník TeskaLabs LogMan.io, index lmio-others-events

Cíl: Zajištění, že všechny události jsou správně parsovány pomocí Parsec nebo Parser.

Ve většině instalací shromažďujeme chybové logy z následujících oblastí:

• Parser

• Parsec

• Dispatcher

• Depositor

• Nestrukturované logy

Logy, které nejsou správně parsovány, spadají do others index. Ideálně by žádné logy neměly být přítomny v others index.

Hlášení problémů: Pokud jsou v others index nalezeny nějaké logy, jako jsou ty, které indikují chyby nesprávného parsování, obecně to není závažný problém vyžadující okamžitou pozornost. Prozkoumejte tyto logy dále a hlaste to na kanál podpory TeskaLabs LogMan.io Slack.

Systémové logy

Umístění: TeskaLabs LogMan.io - Systémový tenant, index Události & Ostatní.

Cíl: Zajištění, že systém funguje správně a že nejsou žádné neobvyklé nebo kritické systémové logy, které by mohly signalizovat interní problém

Hlášení problémů: V této sekci může být nalezena řada typů logů. Hlášení může být provedeno buď prostřednictvím Slack kanálu podpory TeskaLabs LogMan.io nebo ve vaší infrastruktuře.

Baseliner

Note

Baseliner je zahrnut pouze v pokročilých nasazeních LogMan.io. Pokud byste chtěli upgradovat LogMan.io, kontaktujte podporu a rádi vám pomůžeme.

Umístění: Obrazovka Průzkumník TeskaLabs LogMan.io filtrováním event.dataset:baseliner

Cíl: Zajištění, že funkce Baseliner funguje správně a detekuje odchylky od vypočítané základní aktivity.

Hlášení problémů: Pokud Baseliner není aktivní, ohlaste to na Slack kanál podpory TeskaLabs LogMan.io.

Elasticsearch

Umístění: Grafana, dedikovaný Elasticsearch dashboard

Cíl: Zajištění, že nejsou žádné poruchy spojené s Elasticsearch a službami s ním spojenými.

Hodnocení by mělo být vždy založeno na vzorku dat za posledních 24 hodin. Tento operační dashboard poskytuje indikaci správné funkce Elasticsearch.

Klíčové ukazatele:

• Neaktivní uzly by měly být na nule.

• Systémové zdraví by mělo být zelené. Jakýkoliv indikace žluté nebo červené by měla být okamžitě eskalována na Slack kanál podpory TeskaLabs LogMan.io.

• Nepřiřazené shardy by měly být na nule a označeny zeleně. Jakákoli hodnota v žluté nebo vyšší si zaslouží monitorování a hlášení.

Hlášení problémů: Pokud jsou zjištěny nějaké problémy, zajistěte jejich rychlou eskalaci. Další šetření klastru Elastic může být provedeno v Kibana/Stack monitoringu.

Uzly

Podrobné informace o zdraví uzlů lze nalézt v Elasticsearch. JVM Heap monitoruje využití paměti.

Přehled

Aktuální EPS (události za sekundu) celého klastru Elastic je viditelný.

Monitorování velikosti indexů a životního cyklu

Umístění: Kibana, Stack monitoring nebo Stack management

Postupujte podle těchto kroků pro analýzu indexů ohledně abnormální velikosti:

1. Přistupte k sekci "Indexy".
2. Přistupte k filtrování sloupce "Data", řadící od největšího po nejmenší.
3. Prozkoumejte indexy, abyste identifikovali ty, které vykazují výrazně větší velikost ve srovnání s ostatními.

Přijatelná velikost indexu je předmětem diskuse, ale obecně se za přijatelnou považují indexy do 200 GB.

Jakékoliv indexy přesahující 200 GB by měly být hlášeny.

V případě indexů spojených s ILM (index lifecycle management) je klíčové ověřit stav indexu. Pokud indexu chybí řetězec čísel na konci názvu, znamená to, že není propojen s ILM politikou a může růst bez automatického přehazování. K potvrzení toho, přezkoumejte vlastnosti indexu, abyste zjistili, zda spadá pod kategorii hot, warm nebo cold. Když indexy nejsou spojené s ILM, mají tendenci zůstávat ve stavu hot nebo vykazovat nepravidelné přesuny mezi stavy hot, cold a warm.

Mějte na paměti, že vyhledávání nemají ILM a měly by být vždy považovány za ve stavu hot.

Hlášení problémů: Hlášení na dedikovaný Slack kanál podpory projektu. Taková hlášení by měla být brána s nejvyšší vážností a okamžitě eskalována.

Přehled na systémové úrovni

Umístění: Grafana, dedikovaný System Level Overview dashboard

Hodnocení by mělo být vždy založeno na vzorku dat za posledních 24 hodin.

Klíčové metriky ke sledování:

• Využití disku: Všechny hodnoty nesmí přesáhnout 80 %, kromě /boot, který by neměl přesáhnout 95 %.

• Zátěž: Hodnoty nesmí přesáhnout 40 %, a maximální zatížení by mělo odpovídat počtu jader.

• IOWait: Označuje zpracování dat a měla by pouze registrovat jako malé procento, což znamená, že zařízení čeká na načtení dat z disku.

• Využití RAM: Další úvahy by měly být učiněny ohledně nastavení prahových hodnot vysoké hodnoty.

V případě více serverů zajistěte, že hodnoty jsou kontrolovány pro každý z nich.

Hlášení problémů: Hlášení na dedikovaný Slack kanál podpory projektu.

Burrow Consumer Lag

Umístění: Grafana, dedikovaný Burrow Consumer Lag dashboard

Pro monitorování Kafka, pečlivě přezkoumejte tento dashboard pro consumerGroup, se specifickým zaměřením na:

• lmio dispatcher

• lmio depositor

• lmio baseliner

• lmio correlator

• lmio watcher

Rostoucí hodnota zpoždění v průběhu času signalizuje problém, který je potřeba okamžitě řešit.

Hlášení problémů: Pokud se zpoždění zvyšuje ve srovnání s předchozí profylaxe, okamžitě to nahlaste na Slack kanál podpory.

Monitorování Depositoru

Umístění: Grafana, dedikovaný Depositor dashboard.

Klíčové metriky ke sledování:

• Neúspěšné bulky - Musí být zelené a rovné nule

• Velikost výstupní fronty bulků

• Pracovní cyklus

• EPS IN & OUT

• Úspěšné bulky

• Neúspěšné bulky

Hlášení problémů: Hlášení na dedikovaný Slack kanál podpory projektu.

Metriky

Systémové monitorovací metriky

Když logy a události procházejí systéme 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:

1. V webové aplikaci LogMan.io přejděte na Nástroje.
2. 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.

1. 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.
2. V prvním boxu vyberte bucket. (Váš bucket metrik bude pravděpodobně pojmenován buď metrics nebo podle vaší organizace.)
3. 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.
4. V dalším filtru vyberte _measurement z rozbalovacího menu, abyste viděli seznam skupin metrik. Vyberte skupinu, kterou chcete vidět.
5. V dalším filtru vyberte _field z rozbalovacího menu, abyste viděli seznam dostupných metrik. Vyberte metriky, které chcete vidět.
6. 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.
7. 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.
8. Změňte časový rámec, pokud je to potřeba.
9. 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.

Pipeline metriky

Pipeline metriky, nebo měření, monitorují propustnost logů a událostí v pipeline mikroslužeb. Můžete použít tyto pipeline metriky 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:

• Collector
• Ingestor
• Parser/Parsec
• Dispatcher
• Correlator
• Watcher
• Integrace služby
• Mirage

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.
• Pipeline metriky jsou produkovány pro mikroslužby (tag appclass) a mohou být dále filtrovány pomocí dodatečných tagů host a pipeline.
• Každá jednotlivá metrika (například event.in) je hodnota v tagu field.

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
• TcpExtTCPTSReorder
• TcpExtTCPTimeWaitOverflow
• TcpExtTCPTimeouts
• TcpExtTCPToZeroWindowAdv
• TcpExtTCPWantZeroWindowAdv
• TcpExtTCPWinProbe
• TcpExtTW
• TcpExtTWKilled
• TcpExtTWRecycled
• TcpInCsumErrors
• TcpInErrs

---

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 souborovým zálohováním.
• nr_active_file: Počet aktivních souborovým zálohováním.
• 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 a pipeline.
• Každá jednotlivá metrika (například eps.in) je hodnotou v tagu field.

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 atributem cnt 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 a host.
• Každá jednotlivá metrika (například in) je hodnota v tagu field.

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 roven in mínus out.

Ended: Metriky

Ended: Monitorování systému

Ended: Administrační manuál

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 logů

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.

• Než budete pokračovat, podívejte se na Konfigurace pro pokyny k nastavení.
• Pro nastavení sběru událostí z různých zdrojů logů, viz podtéma Log zdroje.
• Pro podrobné možnosti konfigurace, viz Inputs, Transformace a Outputs.
• Pro simulaci logů, viz Mirage.
• Pro detaily komunikace mezi Kolektorem a Receiver, viz dokumentace LogMan.io Receiver.

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

/conf/lmio-collector.conf

[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:

etc/lmio-collector.yaml

# 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 IPv6
• 0.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 IPv6
• 1.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:

docker-compose.yml

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:

/xml-logs/log.xml

...
<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:

/MicrosoftExchangeServer/DNSLOG.log

#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:

input:SmartFile:DHCP-Server-Input:
    path: /DHCPServer/*.log
    protocol: w3c_dhcp
    extract_source: file_path
    extract_regex: ^(?P<file_path>.*)$

Příklad obsahu logového souboru DHCP serveru:

```title="/DHCPServer/log1.log" DHCP Service Activity Log Event ID Význam 00 Log byl spu

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

Meta informace 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 klienta
• key: Cesta k privátnímu klíči SSL certifikátu klienta
• password: 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>:
  ...

Zdroje logů

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: input 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í 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

Jak vytvořit téma v projektu

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

Jak vytvořit účet služby

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ů.

• Jak povolit Syslog přes TCP na ADC

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 systému BIG-IP pro logování na vzdálený syslog server

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:

• FortiAnalyzer Log Forwarding Setting

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 Log Forwarding 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í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í output: # Kam posílat příchozí události

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)

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álne 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.

Pokračovat na nastavení WEC.

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.

Pokračovat na Windows agenta.

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énem lmio-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, tcp/88, udp/750 a tcp/750 porty (Kerberos authentication)
• Všechny Windows servery odesílající logy MUSÍ být schopny dosáhnout na tcp/5985 TeskaLabs LogMan.io Collector pro WEF a udp/88, tcp/88, udp/750 a tcp/750 porty (Kerberos authentication)

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í.

Tip

Nastavení DNS můžete ověřit pomocí příkazu ping.

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říkladě 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říkladě 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.

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

• Detaily konfigurace
• Ruční instalace

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 aplikace
• System pro systémové logy
• Security pro bezpečnostní logy atd.

Ended: Microsoft Windows

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

Ř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

1. Přihlaste se do své OCI konzole.

2. Zvolte Nastavení uživatele z nabídky v pravém horním rohu.

   

3. Přejděte na Zdroje, vyberte API klíče a klikněte na Přidat API klíč.

   

4. 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.

   

5. 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.

   

6. 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.

~ Když Oracle obdrží požadavek, 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:

lmio-collector.yaml

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 sbírá historii a události.
• Zdroj Zabbix Security sbírá alerty a události.

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:

1. Vytvořte CSV soubor se seznamem typů metrik, každou na samostatném řádku:

conf/items.csv

Uptime
Number of processes
Number of threads
FortiGate: System uptime
VMware: Uptime
CPU utilization
CPU user time
...

1. 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šechny 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.

1. Přihlašte se jako superuser (Administrátor) do ESET Business Account.

2. Otevřete Správu uživatelů a klikněte na tlačítko Nový uživatel dole.

   

3. Vytvořte účet s oprávněním read-only a zapněte přepínač Integrace.

   

4. 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 organizovaná 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.

Ended: Zdroje logů

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

1. Vytvořte nový repozitář pro sběr logů nebo klonujte stávající.
2. Vytvořte nový adresář. Pojmenujte adresář po zdroji logů.
3. 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.

1. Ve vašem logu vyberte pole, které byste chtěli mít s proměnnými hodnotami. Nahraďte hodnoty pole za ${nazevPole}, kde nazevPole je to, čím budete pole ve vašem seznamu nazývat.

   "user.name":${user.name}, "id":${id}, "msg":${msg}

2. Vytvořte soubor nazvaný values.yaml ve vašem adresáři zdrojů logů.

3. V novém souboru values.yaml uveďte možné hodnoty pro každé šablonované pole. Pole ve vašem souboru values.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
  ...

Virtuální stroj

TeskaLabs LogMan.io Collector může být nasazen na dedikovaný virtuální stroj.

Specifikace

• 1 vCPU
• OS Linux, nejlépe Ubuntu Server 22.04.4 LTS, jsou podporovány také další hlavní distribuce
• 4 GB RAM
• 500 GB disk (50 GB pro OS; zbytek je pufr pro shromažďované logy)
• 1x NIC, nejlépe 1Gbps

Kolektor musí být schopen připojit se k instalaci TeskaLabs LogMan.io přes HTTPS (WebSocket) pomocí jeho URL.

Note

Pro prostředí s vyšším zatížením by měl být virtuální stroj odpovídajícím způsobem škálován.

Síť

Doporučujeme přiřadit statickou IP adresu virtuálnímu stroji s kolektorem, protože bude použita v mnoha konfiguracích zdrojů logů.

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	10800 10819	devolutions
ESET	Protect	10840 10859	eset-protect
	F5	10860 10879	f5
	FileZilla	10880 10899	filezilla
Gordic	Ginis	10900 10919	gordic-ginis
IceWarp	Mail Center	10920 10939	icewarp
	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 Controller	11200 11219	ubiquiti-unifi-controller
Ubiquiti	UniFi Cloud Key	11240 11259	ubiquiti-unifi-cloud-key
Ubiquiti	Unifi Switch	11220 11239	ubiquiti-unifi-switch
VMware	vCenter	11300 11319	vmware-vcenter
VMware	vCloud Director	11320 11339	vmware-vcloud-director
VMware	ESXi	11340 11359	vmware-esxi
ZyXEL	CEF	11440 11459	zyxel-cef
ZyXEL	GS2210	11460 11479	zyxel-gs2210
Sophos	Standard Syslog Protocol	11500 11519	sophos-standard-syslog-protocol
Sophos	Syslog Devide Standard Format	11520 11539	sophos-device-standard-format
Sophos	Unstructured Format	11540 11559	sophos-unstructured
	Custom	14000 14099	custom

Ended: Kolektor logů

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 rebalance the 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.

Removing the collector

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/
...

Option 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.

Option 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.

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átu
• key: Cesta k privátnímu klíči klientského SSL certifikátu
• password: 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é)
• 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či
• received_at: Datum a čas přijetí logu na přijímači
• source: 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

1. Příjem nových logů do hot fáze.
2. Po jednom týdnu přesunout partici z hot do warm fáze.
3. Ihned po uzavření příjmu zkopírovat partici do cold fáze.
4. Smazat partici po 6 měsících.
5. Partici komprimovat okamžitě po příchodu do cold fáze.
6. 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ém age do specifikované phase.
• copy: Zkopírovat partici ve specifikovaném age do specifikované phase.
• delete: Smazat partici ve specifikovaném age.

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ýden
• d: den
• h: hodina
• m: 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říjmu
• rotate_size: maximální velikost partice; postfixy T, G, M a k 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 je vydáván interním Certifikačním úřadem (CA). Certifikát certifikačního úřadu je dostupný v ZooKeeperu na /lmio/receiver/ca/cert.der.

Ověření digitálního podpisu

Můžete ověřit digitální podpis pomocí následujících příkazů OpenSSL:

```shell $ openssl x509 -inform der -in signing-cert

Odesílání do Kafka

Pokud je Apache Kafka konfigurováno v nastavení, každý přijatý log událost je přeposlán 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 uzle těch clusterů, 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;
    }

}

1. Odkazuje na lokálně běžící lmio-receiver, veřejný Web API port. Toto je primární destinace, protože šetří síťový provoz.

2. Záložní odkazy na receivery běžící na jiných uzlech clusteru, které běží lmio-receiver, v tomto příkladu node-2 a node-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.

3. Toto je dedikovaný HTTPS server běžící na https://recv.logman.example.com.

4. Musíte poskytnout SSL serverový klíč a certifikát. Můžete použít samopodepsaný certifikát nebo certifikát poskytovaný certifikační autoritou.

5. Certifikát client-ca-cert.pem je automaticky vytvořen lmio-receiver. Viz část "Client CA certificate".

6. Toto ověřuje SSL certifikát klienta (lmio-collector) a předává tuto informaci lmio-receiver.

7. lmio-collector může nahrávat části buffered logů.

8. 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;
}

Sbírka se spojí s příjemcem 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. Sbírka 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, sběratelé 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.

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 v rámci streamu.

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 souboru col-<column name>.pos.

• col-<column name>.pos: Počáteční bajtové pozice každého vstupu v odpovídajícím souboru col-<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 do col-<column name>.data. N-té celé číslo v souboru col-<column name>.pos označuje počáteční pozici N-tého vstupu v souboru col-<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 souboru col-<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:

1. Otevřete oba soubory col-<column name>.pos a col-<column name>.data. Přečtěte první 32bitové celé číslo ze souboru col-<column name>.pos. Inicializujte aktuální pozici s hodnotou 0.

2. 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.

3. 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.

4. Opakujte kroky 2 a 3 pro čtení dalších řádků. 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:

1. 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).

2. 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 souboru col-<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.

3. 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.

4. 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:

1. Otevřete soubor col-<column name>.data.
2. 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.
3. Opakujte krok 2, dokud nedosáhnete konce souboru, což znamená, že jste přečetli všechna časová razítka.
4. Zavřete soubor.

Náhodný Přístup k Datům

Pro přístup k časovému razítku na specifické pozici řádku (Nth pozice):

1. 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.
2. 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 a col-<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:

1. Otevřete soubor col-<column name>.data. Tento soubor obsahuje 16bitová nezáporná celá čísla, která slouží jako indexy do seznamu tokenů.
2. Přečtěte 16bitové nezáporné celé číslo ze souboru col-<column name>.data. To je index vašeho tokenového řetězce.
3. Použijte "Náhodný přístup k datům" z typu sloupce string na souborech col-<column name>-token.data a col-<column name>-token.pos k získání textové hodnoty.
4. 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.
5. 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):

1. 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.
2. Přečtěte 16bitové celé číslo ze souboru col-<column name>.data. Toto je váš indexový záznam pro N-tý řádek.
3. Použijte "Náhodný přístup k datům" z typu sloupce string na souborech col-<column name>-token.data a col-<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áště vhodný pro sloupce, které mají mnoho sekvencí opakujících se hodnot.

Stejně jako typ token, token:rle kóduje textové hodnoty na celé číselné tokeny. Namísto ukládání každého z těchto celých číselných tokenů samostatně využívá RLE k tomu, aby sloučil sekvence opakujících se

Ended: Receiver

Parsec