Be Lazy & Scale
Download as PPTX, PDF0 likes439 views
The document discusses using Elasticsearch's percolator to store queries in an index and then retrieve matching queries by indexing documents. It provides an example of storing queries for terms like "bad protocol" and then percolating a log message to return matching queries. The document also describes techniques for optimizing percolation performance like rewriting queries and messages into a shared sparse vector space for faster matching.
![reverse mapping checking getaddrinfo for xxxxx [xxx.xxx.xxx.xxx]
failed - POSSIBLE BREAK-IN ATTEMPT!
pam_unix(sshd:session): session opened for user xxxxxx by
(uid=0)
Bad protocol version identification 'root' from xxx.xx.xxx.xx
port xxxxx
reverse mapping checking getaddrinfo for xxxxx [xxx.xxx.xxx.xxx]
failed - POSSIBLE BREAK-IN ATTEMPT!
Bad protocol version identification 'root' from xxx.xx.xxx.xx
port xxxxx
pam_unix(sshd:session): session opened for user xxxxxx by
(uid=0)](https://image.slidesharecdn.com/full-texttaggingbillionsofmessages-151218135611/85/Be-Lazy-Scale-4-320.jpg)
![Percolator
Traditionally you design documents based on your data, store them into an
index, and then define queries via the search API in order to retrieve these
documents. The percolator works in the opposite direction. First you store
queries into an index and then, via the percolate API, you define documents
in order to retrieve these queries.
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-percolate.html
reverse mapping checking
getaddrinfo for xxxxx
[xxx.xxx.xxx.xxx] failed -
POSSIBLE BREAK-IN ATTEMPT!
reverse mapping checking
getaddrinfo for xxxxx
[xxx.xxx.xxx.xxx] failed -
POSSIBLE BREAK-IN ATTEMPT!
"possible break-in attempt!"
"bad protocol version identification"
"session opened"](https://image.slidesharecdn.com/full-texttaggingbillionsofmessages-151218135611/85/Be-Lazy-Scale-6-320.jpg)
![[0, 1, 2, 3]"POSSIBLE BREAK-IN ATTEMPT!"
connect*
version
Query Term Index
possible --> 0
break --> 1
in --> 2
attempt --> 3
version --> 4
Query Clauses Rewritten Clauses
connect*
4](https://image.slidesharecdn.com/full-texttaggingbillionsofmessages-151218135611/85/Be-Lazy-Scale-17-320.jpg)
![Query Term Index
possible --> 0
break --> 1
in --> 2
attempt --> 3
version --> 4
reverse mapping checking getaddrinfo for xxxxx [xxx.xxx.xxx.xxx] failed -
POSSIBLE BREAK-IN ATTEMPT!
Raw Message
[reverse, mapping, checking, getaddrinfo, for, xxxxx, xxx, xxx, xxx, xxx,
failed, possible, break, in, attempt]
Analyzed Message
[-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3]
Message Rewritten in Query Space
true
true
true
true
false
Query Term Presence Bitset](https://image.slidesharecdn.com/full-texttaggingbillionsofmessages-151218135611/85/Be-Lazy-Scale-18-320.jpg)
![[reverse, mapping, checking, getaddrinfo, for, xxxxx, xxx, xxx, xxx, xxx,
failed, possible, break, in, attempt]
[-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3]
Analyzed Message
Message Rewritten in Query Space
true
true
true
true
false
Query Term Presence Bitset
[0, 1, 2, 3]"POSSIBLE BREAK-IN ATTEMPT!"
Quick Check / Early
Termination
Actual Check
~ contains](https://image.slidesharecdn.com/full-texttaggingbillionsofmessages-151218135611/85/Be-Lazy-Scale-19-320.jpg)
![[reverse, mapping, checking, getaddrinfo, for, xxxxx, xxx, xxx, xxx, xxx,
failed, possible, break, in, attempt]
[-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3]
Analyzed Message
Message Rewritten in Query Space
true
true
true
true
false
Query Term Presence Bitset
connect*connect*
Brute Force /
startsWith (FAST!)](https://image.slidesharecdn.com/full-texttaggingbillionsofmessages-151218135611/85/Be-Lazy-Scale-20-320.jpg)
![[reverse, mapping, checking, getaddrinfo, for, xxxxx, xxx, xxx, xxx, xxx,
failed, possible, break, in, attempt]
[-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3]
Analyzed Message
Message Rewritten in Query Space
true
true
true
true
false
Query Term Presence Bitset
4version
Simple Lookup](https://image.slidesharecdn.com/full-texttaggingbillionsofmessages-151218135611/85/Be-Lazy-Scale-21-320.jpg)
Be Lazy & Scale
- 1. Be Lazy & Scale Full-Text Tagging Billions Of Messages
- 4. reverse mapping checking getaddrinfo for xxxxx [xxx.xxx.xxx.xxx] failed - POSSIBLE BREAK-IN ATTEMPT! pam_unix(sshd:session): session opened for user xxxxxx by (uid=0) Bad protocol version identification 'root' from xxx.xx.xxx.xx port xxxxx reverse mapping checking getaddrinfo for xxxxx [xxx.xxx.xxx.xxx] failed - POSSIBLE BREAK-IN ATTEMPT! Bad protocol version identification 'root' from xxx.xx.xxx.xx port xxxxx pam_unix(sshd:session): session opened for user xxxxxx by (uid=0)
- 6. Percolator Traditionally you design documents based on your data, store them into an index, and then define queries via the search API in order to retrieve these documents. The percolator works in the opposite direction. First you store queries into an index and then, via the percolate API, you define documents in order to retrieve these queries. https://www.elastic.co/guide/en/elasticsearch/reference/current/search-percolate.html reverse mapping checking getaddrinfo for xxxxx [xxx.xxx.xxx.xxx] failed - POSSIBLE BREAK-IN ATTEMPT! reverse mapping checking getaddrinfo for xxxxx [xxx.xxx.xxx.xxx] failed - POSSIBLE BREAK-IN ATTEMPT! "possible break-in attempt!" "bad protocol version identification" "session opened"
- 9. /0-10 /173
- 11. $$$ $$$
- 12. Bad protocol version identification ... "bad protocol"Phrase Query versionTerm Query ident*Prefix Query Boolean Query AND, OR, NOT
- 13. 105s 1 Big OR +3.8% 109s 160 500000 ~ 33% Tags (real life) Runs (based on real messages) Matches -8.5% 96s Using single char message 'a'
- 14. 105s Trivial 1 Term clause / tag -72.8% 28.6s 160 ~ 295 500000 ~ 33% Tags (real life) Terminal Clauses Runs (based on real messages) Matches -41% 62.7s Keep only 1 clause / tag
- 15. Perco. Queries Index Register Queries In-Memory Index Bad protocol ... Bad protocol ... Perco. Req. Bad protocol ... Perco. Resp. Execute Each Query
- 17. [0, 1, 2, 3]"POSSIBLE BREAK-IN ATTEMPT!" connect* version Query Term Index possible --> 0 break --> 1 in --> 2 attempt --> 3 version --> 4 Query Clauses Rewritten Clauses connect* 4
- 18. Query Term Index possible --> 0 break --> 1 in --> 2 attempt --> 3 version --> 4 reverse mapping checking getaddrinfo for xxxxx [xxx.xxx.xxx.xxx] failed - POSSIBLE BREAK-IN ATTEMPT! Raw Message [reverse, mapping, checking, getaddrinfo, for, xxxxx, xxx, xxx, xxx, xxx, failed, possible, break, in, attempt] Analyzed Message [-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3] Message Rewritten in Query Space true true true true false Query Term Presence Bitset
- 19. [reverse, mapping, checking, getaddrinfo, for, xxxxx, xxx, xxx, xxx, xxx, failed, possible, break, in, attempt] [-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3] Analyzed Message Message Rewritten in Query Space true true true true false Query Term Presence Bitset [0, 1, 2, 3]"POSSIBLE BREAK-IN ATTEMPT!" Quick Check / Early Termination Actual Check ~ contains
- 20. [reverse, mapping, checking, getaddrinfo, for, xxxxx, xxx, xxx, xxx, xxx, failed, possible, break, in, attempt] [-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3] Analyzed Message Message Rewritten in Query Space true true true true false Query Term Presence Bitset connect*connect* Brute Force / startsWith (FAST!)
- 21. [reverse, mapping, checking, getaddrinfo, for, xxxxx, xxx, xxx, xxx, xxx, failed, possible, break, in, attempt] [-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3] Analyzed Message Message Rewritten in Query Space true true true true false Query Term Presence Bitset 4version Simple Lookup
- 22. AND/OR/NOT
Editor's Notes
- #2: Bonsoir à tous. Je me présente, je suis Emmanuel, co-fondateur et CTO de logmatic. Tout d'abord je souhaiterais tous vous remercier, au nom de l'équipe Logmatic, d'être parmis nous ce soir. Cela nous fait très plaisir de vous accueillir. De toute évidence, si vous êtes là ce soir c'est que vous ê des passionnés de data. Souvent qd on parle de data, on s’intéresse aussi à la performance et la scalabilité. C’est de cela que je veux vous parler ce soir. Je veux vous partager une histoire de scalabilité tout droit issue des tranchées de la R&D logmatic. Et souvent quand on parle de scalabilité on parle de serveurs, de cpus, de RAM... mais moi je voulais vous montrer que parfois pour scaler il suffit de bien connaître son problème et d’être feignants. C’est à dire faire tous les efforts pour éviter de travailler pour accomplir plus...
- #3: Avant de commencer je voudrais vous présenter le contexte, planter le décor. Chez Logmatic, nos clients nous envoient en permanence d'important volumes d'évenements, de métriques, de lignes de log… et on les parse, on les enrichi, on les re-travaille, pour que l'utilisateur puisse les faire parler dans l'interface, pour qu'il puisse répondre aux questions qui sont importantes pour lui. La fonctionalité dont je veux vous parler on l'appelle la catégorisation. C'est l'idée de marquer les logs, les événements, de les tagguer en fonction de critères définis par l'utilisateurs. Un exemple, si vous avec des logs d'un web serveur contenant un temps de réponse, peut-être que vous voulez les tagguer/catégoriser par classe de temps de réponse, de 0 à 500ms, de 500ms à 1s etc.
- #4: Du coup vous pouvez produire un graph comme celui ci, la répartition du nb d'appel par classe de temps de réponse. Cela dit c'est relativement simple, ce ne sont que des nombres.
- #5: Plus compliqué: détecter des expressions full-text e.g. les logs sshd Ici 3 lignes de logs du démon ssh, que l'on trouve en standard sur linux. La première ligne typiquement -> probable tentative d'intrusion, courant… tagguer ces messages être avertit quand ils sont très nombreux La deuxième ligne -> le client utilise une version inattendue du protocole SSH -> typiquement ce qui peut être le fruit d'un virus qui essaye de se propager -> alerte La troisième ligne -> une simple connection -> reporting La le pattern que l'on identifie c'est du texte, c'est nettement plus complexe.
- #6: Comment on implémente ça. Don't over-engineer, Don't reinvent the wheel → Have a look in your toolbox
- #7: On est fan d'ES Introduire la notion de percolation (montrer doc) Puis cacher et faire apparaitre le schema de principe on enregistre les requetes d'intéret le message est soumis a ES (percolation) ils nous retourne les requetes qui matchent Tout cela fonctionne parfaitement et on est très content! … Jusqu à ce que...
- #8: puis tout a basculé
- #9: Ca commence par un petit message dans slack… notre plateforme logmatic (qui permet de monitorer logmatic…) nous dit qu'un client a sa latence qui augmente En effet sur la plateforme on voit la latence qui grimpe On se demande pquoi… On voit que CPU sur une machine est saturé!!!!
- #10: We don't need much digging to find the issue -> we have always thought that we'd have from 0 to 10 categories per customer…. but one of the customers decided otherwise ...
- #11: Comment on se sort de ce pétrin?? Analyser, analyser, analyser -> comprendre les leviers que l on a à disposition -> il faut impérativement bien comprendre son problème pour pouvoir agir donc prendre le temps d'analyser ⇒ il faut du sang froid et de la patience
- #12: 2 leviers. Le premier niveau machine Scalabilité verticale (grosse machine) Scalabilité horizontale (plusieurs machines) On est dans le cloud donc c "facile" Mais -> cher, pas économiquement viable sur ce cas particulier gut feeling on peut le rendre plus rapide
- #13: Avant d aller plus loin un peu de détail For our client and in 95% des categories = AND, OR, Phrase, Term, Prefix (focus on that) -> the rest can be left to ES in a 1st phase Analysis is fast
- #14: On part de la data client (avec son accord) 160 de ses categories 3 de ses messages 500000 runs -> 105s c'est notre base line Analysons en blackbox. On change les inputs, on mesure l impact. Impact du message -> on essaye un message trivial 'a' => sensiblement mm perf dc ca depend peu du message Impact du nombre de tags -> On merge toutes les requetes en un seul gros OR => sensiblement mm perf dc ca depend pas vraiment du nombre de tags
- #15: En fait si on regarde les tags de près ils sont faits de clauses multiple assemblées par des opérateurs booléens. Au total ~295 clauses (phrase, term, prefix) dans notre cas. On garde une seule clause (la première) pour chaque tag, donc seulement 160 clauses -> on a enlevé ~50% des clauses et la perf s'est améliorée d'autant Puis on trivialise ces clauses en term clause donc en gros chaque tag est la recherche d'un mot… Encore nette améliorations. Sentiment: Tout se joue dans le nb de clauses et leur complexité.
- #16: Schéma de percolation ES, index in memory et run queries one at a time… donc en fait quand on fait 500000 match avec 160 tags on fait 80,000,000 de requetes ce qui est excellent (>762,000/s sur mon mac)! mais pas suffisant pour nous! En regardant de plus pret au profiler on peut grater 10/15% mais pas plus… le pb n'est pas dans la performance du code mais dans la maniere de faire En particulier, le savoir a priori des requetes enregistrees n'est pas utilisé dans le processus
- #17: Maintenant on sait qu'il faut qu'on travaille sur la résolution des clauses Pas de "free lunch" -> on doit tout matcher Again don't overthink it! -> pas de partage/caching/… Plain and simple bruteforce matching BUT we will use the "a priori" knowledge of the registered queries Thanks to this knowledge we can: implement fast code do early termination to limit work as much as possible
- #18: Indexing/Rewriting queries
- #19: upon tagging we rewrite the message, taking all our new knowledge into account -> analyse -> rewrite in query term space -> build bitset of terms we met
- #20: Exec of a phrase clause
- #21: prefix is bruteforce
- #22: term lookup is just presence bitset
- #23: boolean queries → early termination, nothing fancy (no cost analysis, …) !
- #25: Result -> 14.4% faster Impact of adding clauses is much smaller We double the categories (register twice) Good news… because today our client has 370 categories…. Next steps->analysis