Mentat

Date: Tue, 7 Aug 2018 11:50:12 +0200
From: Pavel Kácha <ph@cesnet.cz>
Subject: Re: [Mentat] Máme víťaza v súťaži o vraha výkonu

- U nás si to můžeme pořešit, pokusil jsem se to udělat (dopsal jsem přímo
na produkci na au1 natvrdo kladivo, které nepřidává zdrojové porty, pokud
jich je víc než 1024, a ukončí kontext a pošle zprávu, pokud už obsahuje
víc než 2000 spojení. Je to nad většinou toho, co vidím v logu, takže by
to mohlo rozlámat jen obří outliery. Vzhledem k tomu, že je to docela
specificky napsaný a časově založený kontextový manager, bylo docela
vyšívání nerozbít něco jiného. Poučení pro Deadbeat.)

- To ale neznamená, že se s podobnými zprávami nezačneme setkávat z jiných
zdrojů (Protective/CTI/Turris anyone?), zpráva je obrovská, ale legitimní,
popisuje poměrně přesně, co se v okně stalo.

Takže bychom
1, neměli utavit databázi
2, neměli utavit apache
3, neměli utavit uživateli browser (a navíc mu podat neprohlédnutelnou stránku)

Ad 3: Asi by bylo rozumné nesnažit se v events/search zobrazit úplně
všechno, ale omezit počet adres na nějaký smysluplný počet (třeba s indikací
počtu, něco jako "195.113.134.228, 195.113.134.229, ... (10 000 IPs)", nebo třeba
"~195.113.134.0/24, ... (10 000 IPs)".

Ad 2: Tohle generování zobrazení by nemělo být náročné. Takže buď velmi
jednoduchý scan a příprava předtím, než se to všechno předá šabloně
(předpokládám, že tam bude bottleneck), nebo předpočítání fallbackovaného
rozsahu, které se dá spojit s (3).

Ad 3: O tom jsme se kdysi bavili s Radkem, že by v tabuli events mohl být
kromě pole zdrojových a pole cílových IP adres vytažen i zdrojový rozsah
(který pokrývá všechny zdrojové IP ve zprávě) a cílový rozsah (ditto).
Dotazy by se mohly rozšířit na AND na tento rozsah, a pokud není postgres
pitomý, mohlo by to pomoci při předfiltrování zpráv podle indexu, na které
následně použije tvrdou podmínku.

A tyto rozsahy by se daly použít i jako předpočítaný fallback pro
zobrazení na webu, když je adres moc.

Ad 3 podruhé: Nevejde se nám do paměti současně index a DB. Ve
skutečnosti máme ale úrovně indexů dvě: skutečné databázové indexya tabuli s
vytaženými daty, která je pro nás forma indexu, a pak skutečná JSONová data.
Nepomohlo by vytáhnout JSONová data do vlastní tabule a nechat prohledávací
tabuli bez nich? Pokud v ní jsou veškerá data, potřebná pro prohledávací
dotazy, dotazů na JSON data by mohlo být minimum - raw (JSON) data
potřebujeme jen pro zobrazení 100 položek výsledků hledání nebo pro
reporter.
Pak by paměť mohla stačit na indexy + prohledávací tabuli, a zřídka
zobrazovaný JSON by mohl kromě právě potřebných stovek smrdět na disku.

Note: Moved from email. Continuation in english, please.

Ad 3 podruhé: Nevejde se nám do paměti současně index a DB. Ve
skutečnosti máme ale úrovně indexů dvě: skutečné databázové indexya tabuli s
vytaženými daty, která je pro nás forma indexu, a pak skutečná JSONová data.
Nepomohlo by vytáhnout JSONová data do vlastní tabule a nechat prohledávací
tabuli bez nich? Pokud v ní jsou veškerá data, potřebná pro prohledávací
dotazy, dotazů na JSON data by mohlo být minimum - raw (JSON) data
potřebujeme jen pro zobrazení 100 položek výsledků hledání nebo pro
reporter.
Pak by paměť mohla stačit na indexy + prohledávací tabuli, a zřídka
zobrazovaný JSON by mohl kromě právě potřebných stovek smrdět na disku.

Original design using a single table for both event metadata and details was based on an assumption of average event record size of ~10kB. This is no longer true as there are isolated event records of ~250kB. Furthermore, average record size is expected to rise considerably as there are multiple sources providing more aggressively aggregated data and this trend will continue with no foreseeable upper limit.
Next, event data was designed to be stored as searchable JSON what proved impractical because of DB limitations (inability to represent NULL byte inside JSON). This was to allow searching on both metadata and event data, but was never used in the end.
Based on these a storage format optimization, as proposed by Pavel Kácha above, is in order. The event metadata table should be stripped of the event bytea column containing encoded JSON event data. The event data should be stored in a different table also containing event id as the PRIMARY KEY (with index, also FOREIGN KEY with ON DELETE CASCADE to make existing event purging code work with no change). This would require slight changes on import and a transition operation but no changes for event search (and only table name change for event detail display). The downsides are that event data would no longer be cached in memory leading to longer event detail display times (with low impact as this is a much rarer operation than originally expected) and a duplication of the event id index (6GB in size, largest of all). A huge advantage are better scaling with event record size (constant for typical event) and better scaling with total number of events stored (as for good performance the events table and its indices should fit into memory).

Radko Krkoš wrote:

Based on these a storage format optimization, as proposed by Pavel Kácha above, is in order. The event metadata table should be stripped of the event bytea column containing encoded JSON event data. The event data should be stored in a different table also containing event id as the PRIMARY KEY (with index, also FOREIGN KEY with ON DELETE CASCADE to make existing event purging code work with no change). This would require slight changes on import and a transition operation but no changes for event search (and only table name change for event detail display). The downsides are that event data would no longer be cached in memory leading to longer event detail display times (with low impact as this is a much rarer operation than originally expected) and a duplication of the event id index (6GB in size, largest of all). A huge advantage are better scaling with event record size (constant for typical event) and better scaling with total number of events stored (as for good performance the events table and its indices should fit into memory).

This has been partially discussed with Mek already, with regard to needed code changes. We'll need:

1. API change, to return incomplete/lightweight/stripped Idea events, constructed only from main table data (so lacking lot of info in original JSON). No JSON conversion would thus be needed, only setting up simple nested dict from result of SELECT *. Filtering done in application (not in db) would thus remain working.
2. API change to allow to enhance/convert stripped events to full format from related db (meant for small event/show and for reporter)

Small question remains - what does ip range type, which is now used for arrays of source/target IPs return in python? What conversions will be needed here?

Pavel Kácha wrote:

Small question remains - what does ip range type, which is now used for arrays of source/target IPs return in python? What conversions will be needed here?

As discussed in teleconference, iprange types are returned as string representations in single address, prefix or arbitrary range (min-max) forms (best match). This is because iprange is a nonstandard extension and the standard connector does not understand its data type. Anyways, there is no native/standard library data type that would fit iprange (not the arbitrary range part at least).