Přeskočit obsah

Sledování výkonu detekcí

Výkon korelací se kontroluje na dvou místech pro dvě různé otázky:

Kde Co kontrolujete Otázka
Grafana Consumer lag Kafka na instanci Correlator (group_id) Která instance zaostává?
LogMan.io UI → Detekce (/detection) Časové metriky na pravidlo (timetotal, P/E/A/T, …) Která pravidla na té instanci jsou nákladná?

Nepoužívejte Grafana k ladění jednotlivých pravidel podle času. correlator.time je pro operátory a plánování kapacity. Analytici optimalizují pravidla pomocí Total time na obrazovce Detekce.

Časové metriky v UI pocházejí z LogMan.io Correlator, agreguje LogMan.io TRex, obnovení přibližně každých 60 sekund.

Viz Correlator, Metriky Correlator a Prometheus monitoring.

Časové metriky na Detekcích (která pravidla?)

Otevřete Detekce ve webové aplikaci. Strom vypisuje korelační pravidla z Knihovny (podle složek a YAML souborů). Každý řádek pravidla může zobrazovat:

Popisek UI Klíč metriky Význam
Total time (stopky) timetotal Kumulativní CPU čas strávený na pravidle (všechny fáze)
P timepredicate Čas ve filtru predicate
E timeevaluate Čas v evaluate (window pravidla)
A timeanalyze Čas v analyze (window pravidla)
T timetrigger Čas v trigger
Ikona zvonku triggerin Spuštění triggeru za poslední hodinu
Ikona šipky predicatehit Zásahy predikátu za poslední hodinu

Fáze s nejvyšším časem je zvýrazněna (varovná barva). Kliknutím na řádek pravidla s metrikami otevřete Discover na complex události pro to pravidlo (poslední hodina).

Řádky složek mohou zobrazovat agregované metriky všech pravidel pod danou cestou.

Typy pravidel

Rozpad P / E / A / T je nejvýznamnější pro window korelační pravidla. Match, sigma, list a další typy correlatoru stále hlásí Total time a počítadla predicate/trigger, ale nemusí používat každou fázi.

Jak číst Total time

Total time není latence jedné události. Je to součet času zpracování, který Correlator strávil na pravidle v okně metrik (v sekundách, tři desetinná místa).

Total time Doporučení
< 1 s Obvykle v pořádku
1–5 s Sledovat; zkontrolujte predikát a objem událostí
≥ 5 s Vysoké: považujte za problém výkonu daného pravidla

Vysoké Total time s vysokým počtem predicate hit často znamená, že pravidlo běží na příliš mnoha událostech. Vysoké Total time s nízkým počtem zásahů ukazuje na nákladný predikát nebo krok analyze na událostech, které projdou.

Porovnejte fáze:

  • Dominuje P → zjednodušte predicate, používejte strukturovaná pole, nevyhledávejte v message.
  • Dominuje E nebo A → zužte okno (predicate, logsource), snižte kardinalitu v evaluate.dimension, zjednodušte analyze.test.
  • Dominuje T → zkontrolujte akce triggeru (šablony, lookupy, objem výstupu).

Correlator vzorkuje časové metriky každé N. události (výchozí N = 10) a škáluje zaznamenanou dobu, aby počítadla zůstala reprezentativní. Administrátoři mohou nastavit [correlator] time_metrics_sample_interval v konfiguraci Correlator.

Kafka consumer lag v Grafana (která instance?)

Každá instance Correlator konzumuje Kafka se vlastní consumer group. Lag ukazuje, zda instance události zpracovává dostatečně rychle.

Typické hodnoty group_id:

  • V konfiguraci: [pipeline:CorrelatorsPipeline:KafkaSource] group_id=... (viz Konfigurace Correlator)
  • Nebo auto-generované: lmio_correlator_{tenant}_{groups} (volitelná přípona sharding)

V Grafana (nebo Prometheus) sledujte:

  • Metrika: kafka.consumer_group.lag
  • Filtr: group =~ /^lmio_correlator.*/: vyberte konkrétní skupinu, která roste

Lag nesmí nepřetržitě růst. Rostoucí lag na jednom group_id znamená, že ta instance Correlator je přetížená nebo její pravidla jsou kolektivně příliš pomalá.

Více instancí Correlator

Velké nasazení rozdělí skupiny pravidel mezi několik instancí Correlator (různé [declarations] groups a často jiné group_id). Optimalizujte pravidla na instanci, jejíž lag v Grafana roste, ne na instanci, která je v pořádku.

Mapování instance → pravidla:

  • [declarations] groups / correlator.groups v modelu vypisuje složky Knihovny, které instance načítá (např. /Correlations/Firewall/).
  • Stejné cesty jsou ve stromu obrazovky Detekce.
  • Pod /Detections/Sigma/ Tenant Rex standardně umisťuje correlatory maximálně tři segmenty cesty pod tím kořenem ([correlator] folder_max_depth). Hlubší Sigma listy se srolují do jedné instance. Ostatní stromy drží jednu instanci na nejbližší / nejhlubší složku, pokud není jinak nastaveno. Operátorská reference: Tenant Rex.

Metriky na pravidlo na Detekcích neobsahují Kafka lag.

Typické příčiny pomalých pravidel

1. Podřetězcové hledání v message místo strukturovaných polí

Vyhněte se filtrování na surovém řádku logu, když existují parsovaná pole:

# Pomalé: prohledává celý text message u každé kandidátní události
predicate:
  - !IN
    what: "failed password"
    where: !ITEM EVENT message

Preferujte rovnost na normalizovaných polích ECS / schématu z Parsec:

# Rychlé: vhodné pro index, odpovídá výstupu parseru
predicate:
  - !EQ
    - !ITEM EVENT event.action
    - "login-failed"
  - !EQ
    - !ITEM EVENT event.outcome
    - "failure"

Pokud zdroj dat nemá vhodné pole, nejdřív rozšiřte mapování parseru, pak pište detekci proti novému poli. Viz Predikáty a Pravidla pro parsování.

2. Příliš široký predikát

  • Chybí filtry event.dataset, event.category, observer.type nebo logsource.
  • !OR s mnoha větvemi místo jednoho !EQ na event.code nebo rule.id.
  • !IN s where: !EVENT jen pro test existence pole; kombinujte s úzkými kontrolami hodnot.

Každá událost, která vstoupí do predikátu, stojí CPU i při miss. Použijte počty zvonku / šipky: velmi vysoký predicate hit s málo triggery může být normální; velmi vysoké zásahy s vysokým časem P znamenají příliš volný filtr.

3. Nákladné window evaluate / analyze

  • Krátký span s vysokou rychlostí událostí → velká okna v paměti.
  • Vysoká kardinalita evaluate.dimension (např. volná textová pole).
  • Nákladný analyze.test (složitý SPLang, mnoho lookupů).

4. Lookupy v predikátu

Každé volání lookupu přidá latenci. Přesuňte lookupy do trigger, když je to možné, nebo předem obohacujte v Parsec.

Praktický postup

  1. Grafana: Najděte consumer group Correlator s rostoucím lagem (kafka.consumer_group.lag, group =~ /^lmio_correlator.*/). Poznamenejte group_id a ke které instanci / groups deklarace patří.
  2. LogMan.io → Detekce: Otevřete strom pravidel pro tenant. Zaměřte se na pravidla pod stejnými složkami Knihovny, které lagující instance načítá.
  3. Najděte pravidla s Total time ≥ 5 s (a zkontrolujte zvýrazněnou fázi P/E/A/T).
  4. Upravte pravidla v Knihovně: zpřísněte predicate, vyhněte se podřetězci v message, snižte náklady okna/analyze (viz níže).
  5. Na Detekcích porovnejte predicate hit vs trigger in, že filtr není příliš široký.
  6. Po nasazení počkejte několik minut: znovu zkontrolujte Total time na Detekcích a lag v Grafana pro dané group_id.

Pokud je lag na všech instancích v pořádku, ale některá pravidla mají stále vysoké Total time, optimalizace se vyplatí (zbytečné CPU), ale není naléhavá kvůli zásobě.

Související dokumentace