TL;DR: Virun véier Joer hunn ech Google verlooss mat enger Iddi fir en neit Server Iwwerwachungsinstrument. D'Iddi war normalerweis isoléiert Funktiounen an ee Service ze kombinéieren a Log Analyse, Metrik Sammlung, an Dashboards. Ee vun de Prinzipien ass datt de Service wierklech muss sinn séier, déi Devops eng einfach, interaktiv, agreabel Erfahrung ubidden. Dëst erfuerdert d'Veraarbechtung vu Multi-Gigabyte Datesets a Fraktiounen vun enger Sekonn wärend Dir am Budget bleift. Bestehend Logverwaltungsinstrumenter sinn dacks lues a clunky, sou datt mir mat enger gudder Erausfuerderung konfrontéiert waren: Smart en Tool designen fir de Benotzer eng nei Erfahrung ze ginn.
Dësen Artikel beschreift wéi mir bei Scalyr dëse Problem geléist hunn andeems se al Schoulmethoden applizéieren, eng brute Kraaft Approche, eliminéiert onnéideg Schichten a vermeit komplex Datestrukturen. Dir kënnt dës Lektioune fir Är eege Ingenieursprobleemer uwenden.
Old School Power
Loganalyse fänkt normalerweis mat enger Sich un: Fannt all Messagen déi mat engem bestëmmte Muster passen. An Scalyr sinn dëst Zénger oder Honnerte vu Gigabyte vu Logbicher vu ville Serveren. Modern Approche involvéiert als Regel de Bau vun enger komplexer Datestruktur optimiséiert fir d'Sich. Ech hunn dëst sécher op Google gesinn, wou se zimmlech gutt an dëser Zort Saach sinn. Awer mir hu sech op eng vill méi grëndlech Approche niddergelooss: linear Scannen vu Logbicher. An et huet geschafft - mir bidden e sichtbaren Interface deen Uerdnung méi séier ass wéi eis Konkurrenten (kuckt Animatioun um Enn).
De Schlësselinbléck war datt modern Prozessoren wierklech ganz séier bei einfachen, riichtaus Operatiounen sinn. Dëst ass einfach ze verpassen a komplexen, Multi-Layer Systemer déi op I/O Geschwindegkeet an Netzwierkoperatioune vertrauen, an esou Systemer si ganz heefeg haut. Also hu mir en Design entwéckelt deen Schichten an iwwerschësseg Dreck miniméiert. Mat multiple Prozessoren a Server parallel, erreecht d'Sichgeschwindegkeet 1 TB pro Sekonn.
Schlëssel Takeaways aus dësem Artikel:
- Brute-force Sich ass eng liewensfäeg Approche fir real-Welt, grouss Skala Probleemer ze léisen.
- Brute Force ass eng Designtechnik, net eng Aarbechtsfräi Léisung. Wéi all Technik ass et besser fir e puer Probleemer wéi anerer, a ka schlecht oder gutt ëmgesat ginn.
- Brute Kraaft ass besonnesch gutt fir z'erreechen stabil Produktivitéit.
- Effektiv Notzung vu brute Kraaft erfuerdert Code optimiséieren an genuch Ressourcen zur richteger Zäit applizéieren. Et ass gëeegent wann Är Serveren ënner schwéierer Net-Benotzerbelaaschtung sinn a Benotzeroperatioune bleiwen eng Prioritéit.
- D'Performance hänkt vum Design vum ganze System of, net nëmmen vum banneschten Loop Algorithmus.
(Dësen Artikel beschreift d'Sich no Daten am Gedächtnis. Am meeschte Fäll, wann e Benotzer eng Log Sich mécht, hunn d'Scalyr-Server et schonn cachéiert. Den nächsten Artikel wäert d'Sich no uncached Logbicher diskutéieren. Déi selwecht Prinzipien gëllen: effiziente Code, brute Force mat grousse Rechenressourcen).
Brute Force Method
Traditionell gëtt e groussen Datesaz mat engem Schlësselwuertindex gesicht. Wann Dir op Server Logbicher ugewannt gëtt, heescht dat no all eenzegaartegt Wuert am Log ze sichen. Fir all Wuert musst Dir eng Lëscht vun all Inklusiounen maachen. Dëst mécht et einfach all Messagen mat dësem Wuert ze fannen, zum Beispill 'Feeler', 'firefox' oder "transaction_16851951" - kuckt just am Index.
Ech hunn dës Approche bei Google benotzt an et huet gutt geschafft. Awer a Scalyr sichen mir de Logbicher Byte fir Byte.
Firwat? Aus enger abstrakt algorithmescher Siicht sinn Schlësselwuertindexe vill méi effizient wéi brute Force Sichen. Wéi och ëmmer, mir verkafen keng Algorithmen, mir verkafen Leeschtung. A Leeschtung ass net nëmmen iwwer Algorithmen, awer och iwwer Systemtechnik. Mir mussen alles berücksichtegen: Volumen vun Daten, Aart vun der Sich, verfügbar Hardware a Software Kontext. Mir hunn décidéiert datt fir eise besonnesche Problem eppes wéi 'grep' besser passt wéi en Index.
Indexe si super, awer si hunn Aschränkungen. Ee Wuert ass einfach ze fannen. Awer no Messagen mat ville Wierder ze sichen, wéi 'googlebot' an '404', ass vill méi schwéier. Sich no engem Ausdrock wéi 'uncaught Ausnam' erfuerdert e méi ëmständlechen Index, deen net nëmmen all Messagen mat deem Wuert ophëlt, awer och déi spezifesch Plaz vum Wuert.
Déi richteg Schwieregkeet kënnt wann Dir net no Wierder sicht. Loosst eis soen datt Dir wëllt gesinn wéi vill Traffic vu Bots kënnt. Den éischte Gedanken ass d'Logbicher no dem Wuert 'Bot' ze sichen. Dëst ass wéi Dir e puer Bots fannt: Googlebot, Bingbot a vill anerer. Awer hei ass 'Bot' kee Wuert, mee en Deel dovun. Wa mir no 'Bot' am Index sichen, fanne mir keng Posts mam Wuert 'Googlebot'. Wann Dir all Wuert am Index iwwerpréift an dann den Index fir déi fonnt Schlësselwieder scannt, wäert d'Sich staark verlangsamen. Als Resultat erlaben e puer Logprogrammer keng Deel-Wuert Sichen oder (am beschten) erlaabt eng speziell Syntax mat manner Leeschtung. Mir wëllen dat vermeiden.
En anere Problem ass d'Punctuatioun. Wëllt dir all Demanden ze fannen vun 50.168.29.7? Wat iwwer Debugging Logbicher enthalen [error]? Abonnementer iwwersprangen normalerweis Punktuatioun.
Endlech, Ingenieuren gär mächteg Tools, an heiansdo kann e Problem nëmme mat engem reguläre Ausdrock geléist ginn. De Schlësselwuert Index ass net ganz gëeegent fir dëst.
Zousätzlech, d'Index komplex. All Message muss op verschidde Schlësselwuertlëschte bäigefüügt ginn. Dës Lëschte sollen zu all Moment an engem einfach sichtbare Format gehale ginn. Ufroe mat Ausdréck, Wuertfragmenter oder regulär Ausdréck mussen a Multi-Lëscht Operatiounen iwwersat ginn, an d'Resultater gescannt a kombinéiert fir e Resultatset ze produzéieren. Am Kontext vun engem grousse-Skala, Multi-Tenant Service, dës Komplexitéit schaaft Leeschtung Problemer déi net siichtbar sinn wann d'Algorithmen analyséiert.
Schlësselwuert Indexer huelen och vill Plaz an, a Späichere ass eng grouss Käschte an engem Log Management System.
Op der anerer Säit kann all Sich vill Rechenkraaft verbrauchen. Eis Benotzer schätzen High-Speed-Sich no eenzegaartegen Ufroen, awer esou Ufroe gi relativ selten gemaach. Fir typesch Sichufroen, zum Beispill, fir en Dashboard, benotze mir speziell Techniken (mir beschreiwen se am nächsten Artikel). Aner Ufroe sinn selten genuch datt Dir selten méi wéi eng gläichzäiteg muss veraarbechten. Awer dat heescht net datt eis Serveren net beschäftegt sinn: si si beschäftegt mat der Aarbecht fir nei Messagen z'empfänken, ze analyséieren an ze kompriméieren, d'Alarme ze evaluéieren, d'al Daten ze kompriméieren, asw. Also hu mir eng zimlech bedeitend Versuergung vu Prozessoren déi kënne benotzt ginn fir Ufroen auszeféieren.
Brute Force funktionnéiert wann Dir e brute Problem hutt (a vill Kraaft)
Brute Force funktionnéiert am Beschten op einfache Probleemer mat klenge internen Schleifen. Dacks kënnt Dir déi intern Loop optimiséieren fir mat ganz héijer Geschwindegkeet ze lafen. Wann de Code komplex ass, ass et vill méi schwéier et ze optimiséieren.
Eise Sichcode hat ursprénglech eng zimlech grouss bannenzeg Loop. Mir späicheren Messagen op Säiten op 4K; all Säit enthält e puer Messagen (an UTF-8) a Metadaten fir all Message. Metadaten ass eng Struktur déi d'Längt vum Wäert, intern Message ID an aner Felder codéiert. De Sichzyklus huet esou ausgesinn:
Dëst ass eng vereinfacht Versioun vum aktuellen Code. Awer och hei si verschidde Objektplazéierungen, Datekopien a Funktiounsuriff siichtbar. De JVM ass zimmlech gutt fir Funktiounsuriff ze optimiséieren an ephemeral Objeten ze verdeelen, sou datt dëse Code besser funktionnéiert wéi mir et verdéngt hunn. Wärend dem Test hunn d'Clienten et ganz erfollegräich benotzt. Awer schlussendlech hu mir et op den nächsten Niveau geholl.
(Dir kënnt froen firwat mir Messagen an dësem Format mat 4K Säiten, Text a Metadaten späicheren, anstatt mat Logbicher direkt ze schaffen. Text Sich gëtt dacks kombinéiert mat DBMS-Stil Filteren an de Margen nom Log Parsing. Mir kënnen gläichzäiteg vill Dausende vu Logbicher gläichzäiteg sichen, an einfach Textdateien sinn net gëeegent fir eis transaktionell, replizéiert, verdeelt Datemanagement).
Am Ufank huet et geschéngt datt esou Code net ganz gëeegent war fir Brute Force Optimiséierung. "Real Aarbecht" an String.indexOf() huet net mol de CPU Profil dominéiert. Dat ass, dës Method eleng ze optimiséieren géif net e wesentlechen Effekt bréngen.
Et geschitt sou datt mir Metadaten um Ufank vun all Säit späicheren, an den Text vun all Messagen an UTF-8 ass um aneren Enn gepackt. Vun dovunner profitéieren, hu mir d'Loop nei geschriwwen fir d'ganz Säit op eemol ze sichen:
Dës Versioun funktionnéiert direkt op der Vue raw byte[] a sicht all Messagen op eemol iwwer déi ganz 4K Säit.
Dëst ass vill méi einfach fir d'Brute Force Method ze optimiséieren. Déi intern Sichschleife gëtt gläichzäiteg fir déi ganz 4K Säit genannt, anstatt separat op all Post. Et gëtt keng Kopie vun Daten oder Allokatioun vun Objeten. A méi komplex Metadaten Operatioune ginn nëmme genannt wann d'Resultat positiv ass, an net op all Message. Op dës Manéier hu mir eng Tonne Overhead eliminéiert, an de Rescht vun der Laascht ass an enger klenger interner Sichschleife konzentréiert, déi gutt fir weider Optimiséierung gëeegent ass.
Eis aktuellen Sich Algorithmus baséiert op . Et ass ähnlech wéi de Boyer-Moore Algorithmus, iwwerspréngt ongeféier d'Längt vun der Sichstring bei all Schrëtt. Den Haaptunterschied ass datt et zwee Bytes gläichzäiteg kontrolléiert fir falsch Matcher ze minimiséieren.
Eis Ëmsetzung erfuerdert eng 64K Lookup Tabelle fir all Sich ze kreéieren, awer dat ass näischt am Verglach mat de Gigabytes vun Daten déi mir sichen. Déi bannescht Loop veraarbecht e puer Gigabyte pro Sekonn op engem eenzege Kär. An der Praxis ass stabil Leeschtung ronderëm 1,25 GB pro Sekonn op all Kär, an et gëtt Plaz fir Verbesserung. Et ass méiglech e puer vun der Overhead ausserhalb vun der banneschten Loop ze eliminéieren, a mir plangen mat enger bannenzeger Loop am C anstatt Java ze experimentéieren.
Mir benotzen Kraaft
Mir hunn diskutéiert datt d'Logbuch Sich ka "ongeféier" ëmgesat ginn, awer wéi vill "Muecht" hu mir? Zimmlech vill.
1 core: Wann et richteg benotzt gëtt, ass en eenzege Kär vun engem modernen Prozessor zimlech mächteg a sech selwer.
8 core: Mir lafen am Moment op Amazon hi1.4xlarge an i2.4xlarge SSD Server, jidderee mat 8 Cores (16 Threads). Wéi uewen ernimmt, sinn dës Käre normalerweis beschäftegt mat Hannergrondoperatiounen. Wann de Benotzer eng Sich mécht, ginn Hannergrondoperatioune suspendéiert, wat all 8 Käre fir d'Sich befreit. D'Sich ass normalerweis an enger Split-Sekonn ofgeschloss, duerno geet d'Backgroundaarbecht erëm op (de Drosselprogramm suergt dofir datt d'Barrage vu Sichufroen net mat wichtegen Hannergrondaarbecht stéiert).
16 core: fir Zouverlässegkeet organiséieren mir Serveren a Master- / Sklavegruppen. All Master huet eng SSD an een EBS Server ënner sengem Kommando. Wann den Haaptserver crasht, hëlt den SSD Server direkt seng Plaz. Bal déi ganzen Zäit, Master a Sklave funktionnéieren gutt, sou datt all Dateblock op zwee verschiddene Serveren sichtbar ass (den EBS Sklave Server huet e schwaache Prozessor, sou datt mir et net berücksichtegen). Mir deelen d'Aufgab tëscht hinnen, sou datt mir am Ganzen 16 Käre verfügbar hunn.
Vill Kären: An nächster Zukunft wäerte mir Daten iwwer Serveren esou verdeelen datt se all un der Veraarbechtung vun all net-trivial Ufro deelhuelen. All Kär wäert schaffen. [Notiz: mir hunn de Plang ëmgesat an d'Sichgeschwindegkeet op 1 TB / s erhéicht, kuckt Notiz um Enn vum Artikel].
Einfachheet garantéiert Zouverlässegkeet
En anere Virdeel vun der Brute Force Method ass seng zimlech konsequent Leeschtung. Typesch ass d'Sich net ganz empfindlech op d'Detailer vum Problem an den Dateset (ech mengen dofir ass et "grof" genannt).
De Schlësselwuert Index produzéiert heiansdo onheemlech séier Resultater, an aner Mol net. Loosst eis soen datt Dir 50 GB Logbicher hutt an deenen de Begrëff 'customer_5987235982' genau dräimol erschéngt. Eng Sich no dësem Begrëff zielt dräi Plazen direkt aus dem Index a gëtt direkt fäerdeg. Awer komplex Wildcard Siche kënnen Tausende vu Schlësselwieder scannen a laang daueren.
Op der anerer Säit, brute Kraaft Sich Leeschtunge mat méi oder manner der selwechter Geschwindegkeet fir all Ufro. Sich no laange Wierder ass besser, awer och no engem eenzege Charakter ze sichen ass zimlech séier.
D'Einfachheet vun der Brute Force Method bedeit datt seng Leeschtung no bei sengem theoreteschen Maximum ass. Et gi manner Optiounen fir onerwaart Disk-Iwwerlaaschtungen, Sperrkonflikter, Pointer Chasing, an Dausende vun anere Grënn fir Feeler. Ech hunn just d'Ufroe vun de Scalyr Benotzer d'lescht Woch op eisem beschäftegste Server gekuckt. Et goufen 14 Demande. Genee aacht vun hinnen hunn méi wéi eng Sekonn gedauert; 000% bannent 99 Millisekonnen ofgeschloss (wann Dir keng Log Analyse Tools benotzt hutt, vertrau mir: et ass séier).
Stabil, zouverlässeg Leeschtung ass wichteg fir d'Benotzung vum Service. Wann et periodesch lags, wäerten d'Benotzer et als onzouverlässeg gesinn an zréckzéien et ze benotzen.
Log Sich an Aktioun
Hei ass eng kuerz Animatioun déi Scalyr Sich an Aktioun weist. Mir hunn en Demo Kont wou mir all Event an all ëffentleche Github Repository importéieren. An dëser Demo ënnersicht ech eng Woch Wäert vun Daten: ongeféier 600 MB vu roude Logbicher.
De Video gouf live opgeholl, ouni speziell Virbereedung, op mengem Desktop (ongeféier 5000 Kilometer vum Server). D'Performance déi Dir gesitt ass haaptsächlech wéinst , wéi och e séieren an zouverléissege Backend. All Kéier wann et eng Paus ass ouni "Luede" Indikator, et ass ech Paus, sou datt Dir liest wat ech amgaang drécken.
Conclusioun
Wann Dir grouss Quantitéiten un Daten veraarbecht, ass et wichteg e gudden Algorithmus ze wielen, awer "gutt" heescht net "Fantasie". Denkt un wéi Äre Code an der Praxis funktionnéiert. Déi theoretesch Analyse vun Algorithmen léisst e puer Faktoren eraus, déi an der realer Welt vu grousser Wichtegkeet kënne sinn. Méi einfach Algorithmen si méi einfach ze optimiséieren a méi stabil a Randsituatiounen.
Denkt och un de Kontext an deem de Code ausgefouert gëtt. An eisem Fall brauche mir genuch mächteg Serveren fir Hannergrond Aufgaben ze managen. D'Benotzer initiéieren Recherchen relativ selten, sou datt mir e ganze Grupp vu Servere fir déi kuerz Zäit léine kënnen fir all Sich ofzeschléissen.
Mat enger brute Force Method hu mir eng séier, zouverlässeg, flexibel Sich iwwer eng Rei vu Logbicher implementéiert. Mir hoffen dës Iddien sinn nëtzlech fir Är Projeten.
Edit: Den Titel an den Text hu geännert vun "Sich bei 20 GB pro Sekonn" op "Sich bei 1 TB pro Sekonn" fir d'Performanceerhéijungen an de leschte Joren ze reflektéieren. Dës Erhéijung vun der Geschwindegkeet ass haaptsächlech wéinst Ännerungen an der Aart an der Zuel vun den EC2 Serveren déi mir haut opstellen fir eis verstäerkte Clientsbasis ze déngen. Et ginn Ännerungen déi geschwënn kommen, déi eng weider dramatesch Boost an der operationeller Effizienz ubidden, a mir kënnen net waarden fir se ze deelen.
Source: will.com