Elasticsearch čelí mnoho lidí. Co se ale stane, když jej chcete použít k ukládání protokolů „ve zvlášť velkém objemu“? Ano, a bezbolestně přežít selhání některého z několika datových center? Jaká architektura by se měla dělat a na jaká úskalí narazíte?
My v Odnoklassniki jsme se rozhodli vyřešit problém správy protokolů pomocí elasticsearch a nyní sdílíme naše zkušenosti s Habr: jak o architektuře, tak o úskalích.
Jsem Pyotr Zaitsev a pracuji jako správce systému ve společnosti Odnoklassniki. Předtím byl také admin, pracoval s Manticore Search, Sphinx search, Elasticsearch. Možná, že pokud se objeví další …hledání, pravděpodobně s ním budu také pracovat. Dobrovolně se také účastním řady open source projektů.
Když jsem přišel do Odnoklassniki, na pohovoru jsem neuváženě řekl, že bych mohl pracovat s Elasticsearch. Poté, co jsem si na to zvykl a udělal několik jednoduchých úkolů, byl mi předložen velký úkol reformovat systém správy protokolů, který v té době existoval.
Požadavky
Požadavky na systém byly formulovány takto:
- Graylog měl být použit jako frontend. Protože společnost již měla zkušenosti s používáním tohoto produktu, programátoři a testeři jej znali, byl pro ně známý a pohodlný.
- Objem dat: průměrně 50-80 tisíc zpráv za sekundu, ale pokud se něco pokazí, tak provoz není ničím omezen, může to být 2-3 miliony řádků za sekundu
- Po projednání se zákazníky o požadavcích na rychlost zpracování vyhledávacích dotazů jsme si uvědomili, že typický vzorec pro používání takového systému je tento: lidé hledají protokoly svých aplikací za poslední dva dny a nechtějí čekat déle než sekundu. výsledek pro formulovaný dotaz.
- Správci trvali na tom, že systém lze v případě potřeby snadno škálovat, aniž by museli hluboce rozumět tomu, jak funguje.
- Jediným úkolem údržby, který tyto systémy pravidelně potřebovaly, byla výměna nějakého hardwaru.
- Kromě toho má Odnoklassniki velkou technickou tradici: každá služba, kterou spustíme, musí přežít selhání datového centra (náhlé, neplánované a absolutně kdykoli).
Poslední požadavek při realizaci tohoto projektu nám byl dán s největším krveprolitím, o kterém budu hovořit podrobněji.
středa
Pracujeme na čtyřech datových centrech, přičemž datové uzly Elasticsearch lze umístit pouze ve třech (z řady netechnických důvodů).
V těchto čtyřech datových centrech je přibližně 18 tisíc různých zdrojů kulatiny - kusy železa, kontejnery, virtuální stroje.
Důležitá funkce: cluster se spouští v kontejnerech ne na fyzických strojích, ale na . U kontejnerů jsou garantována 2 jádra podobná 2.0Ghz v4 s možností recyklace zbytku jader, pokud jsou nečinná.
Jinými slovy:
Topologie
Celkový pohled na řešení jsem zpočátku viděl takto:
- 3-4 VIP stojí za A-rekordem domény Graylog, to je adresa, na kterou jsou zasílány protokoly.
- každý VIP je vyvažovač LVS.
- Poté jdou protokoly do baterie Graylog, některá data jdou ve formátu GELF, některá ve formátu syslog.
- To vše se pak ve velkých dávkách zapisuje do baterie od koordinátorů Elasticsearch.
- A ty zase posílají požadavky na zápis a čtení na příslušné datové uzly.
Terminologie
Snad ne každý rozumí terminologii do detailu, a tak bych se u ní rád trochu pozastavil.
V Elasticsearch je několik typů uzlů – hlavní, koordinátor, datový uzel. Existují dva další typy pro různé transformace logů a propojení různých clusterů mezi sebou, ale my jsme použili pouze ty uvedené.
Mistr
Pinguje všechny uzly přítomné v clusteru, udržuje aktuální mapu clusteru a distribuuje ji mezi uzly, zpracovává logiku událostí a provádí různé druhy správy celého clusteru.
Koordinátor
Provádí jeden jediný úkol: přijímá požadavky od klientů na čtení nebo zápis a směruje tento provoz. V případě požadavku na zápis se s největší pravděpodobností zeptá mastera, do kterého fragmentu příslušného indexu jej má vložit, a přesměruje požadavek dále.
datový uzel
Ukládá data, provádí vyhledávací dotazy a operace na útržcích, které se na něm nacházejí, a přicházejí zvenčí.
graylog
Je to něco jako sloučení Kibany s Logstashem v ELK stacku. Graylog kombinuje jak uživatelské rozhraní, tak kanál zpracování protokolů. Pod kapotou Graylog provozuje Kafka a Zookeeper, které poskytují připojení k Graylogu jako clusteru. Graylog může ukládat protokoly (Kafka) do mezipaměti v případě nedostupnosti Elasticsearch a opakovat neúspěšné požadavky na čtení a zápis, seskupovat a označovat protokoly podle zadaných pravidel. Stejně jako Logstash má Graylog funkci pro úpravu řetězců před zápisem do Elasticsearch.
Kromě toho má Graylog vestavěné zjišťování služeb, které umožňuje na základě jednoho dostupného uzlu Elasticsearch získat celou mapu clusteru a filtrovat ji podle konkrétní značky, což umožňuje odesílat požadavky do konkrétních kontejnerů.
Vizuálně to vypadá takto:
Toto je snímek obrazovky z konkrétní instance. Zde vytvoříme histogram na základě vyhledávacího dotazu a zobrazíme relevantní řádky.
Indexy
Vrátíme-li se k architektuře systému, rád bych se podrobněji pozastavil nad tím, jak jsme sestavili indexový model, aby vše fungovalo správně.
Ve výše uvedeném diagramu se jedná o nejnižší úroveň: datové uzly Elasticsearch.
Index je velká virtuální entita tvořená úlomky Elasticsearch. Každý ze střípků není sám o sobě ničím jiným než lucenským indexem. A každý index Lucene se zase skládá z jednoho nebo více segmentů.
Při návrhu jsme vycházeli z toho, že abychom splnili požadavky na rychlost čtení velkého množství dat, musíme tato data rovnoměrně „rozmazat“ napříč datovými uzly.
To vedlo k tomu, že počet shardů na index (s replikami) by měl být striktně roven počtu datových uzlů. Za prvé, abychom zajistili replikační faktor dva (to znamená, že můžeme ztratit polovinu clusteru). A za druhé, aby bylo možné zpracovat požadavky na čtení a zápis alespoň na polovině clusteru.
Dobu skladování jsme nejprve určili na 30 dní.
Rozložení střepů lze graficky znázornit takto:
Celý tmavě šedý obdélník je index. Levý červený čtvereček v něm je primární střep, první v indexu. A modrý čtverec je replika střepu. Jsou umístěny v různých datových centrech.
Když přidáme další shard, jde do třetího datového centra. A nakonec získáme takovou strukturu, která poskytuje možnost ztráty DC bez ztráty konzistence dat:
Rotace indexu, tzn. vytvořením nového indexu a smazáním nejstaršího indexu jsme to dorovnali na 48 hodin (podle vzoru používání indexu: nejčastěji se prohledává posledních 48 hodin).
Tento interval rotace indexu je způsoben následujícími důvody:
Když požadavek na vyhledávání dorazí do konkrétního datového uzlu, pak je z hlediska výkonu výhodnější, když je dotazován jeden úlomek, pokud je jeho velikost srovnatelná s velikostí kyčle uzlu. To vám umožní ponechat "horkou" část indexu na hromadě a rychle k ní přistupovat. Pokud existuje mnoho „horkých částí“, rychlost vyhledávání indexu se snižuje.
Když uzel začne provádět vyhledávací dotaz na jednom fragmentu, přidělí počet vláken rovnající se počtu jader fyzického stroje s hypervlákny. Pokud vyhledávací dotaz ovlivňuje velký počet fragmentů, počet vláken úměrně roste. To má špatný vliv na rychlost vyhledávání a negativně ovlivňuje indexování nových dat.
Abychom zajistili potřebnou latenci vyhledávání, rozhodli jsme se použít SSD. Aby bylo možné rychle zpracovat požadavky, musely mít počítače, které tyto kontejnery hostovaly, alespoň 56 jader. Číslo 56 je zvoleno jako podmíněně dostatečná hodnota, která určuje počet vláken, která Elasticsearch vygeneruje během provozu. V Elasitcsearch mnoho parametrů fondu vláken přímo závisí na počtu dostupných jader, což zase přímo ovlivňuje požadovaný počet uzlů v clusteru podle principu „méně jader – více uzlů“.
Výsledkem je, že v průměru jeden úlomek váží asi 20 gigabajtů a na 1 index připadá 360 úlomků. Pokud je tedy střídáme každých 48 hodin, máme jich 15. Každý index obsahuje data za 2 dny.
Schémata pro zápis a čtení dat
Podívejme se, jak jsou data v tomto systému zaznamenávána.
Řekněme, že nějaká žádost přijde od Grayloga koordinátorovi. Například chceme indexovat 2-3 tisíce řádků.
Koordinátor, který obdržel žádost od Grayloga, se ptá velitele: „V žádosti o indexování jsme konkrétně specifikovali index, ale nebylo specifikováno, do kterého fragmentu to zapsat.“
Master odpoví: „Zapište tuto informaci do útržku číslo 71“, poté je odeslána přímo do příslušného datového uzlu, kde se nachází primární úlomek číslo 71.
Poté je protokol transakcí replikován do replika-shard, který je již umístěn v jiném datovém centru.
Od Grayloga přijde koordinátorovi žádost o hledání. Koordinátor jej přesměruje podle indexu, zatímco Elasticsearch rozděluje požadavky mezi primární shard a repliku podle principu round-robin.
Nody v množství 180 reagují nerovnoměrně a při jejich reakci koordinátor hromadí informace, které do něj rychlejší datové uzly již „vyplivly“. Poté, když dorazí buď všechny informace, nebo vyprší časový limit požadavku, předá vše přímo klientovi.
Celý tento systém v průměru splní požadavky na vyhledávání za posledních 48 hodin za 300–400 ms, s výjimkou požadavků, které mají hlavní zástupný znak.
Květiny s Elasticsearch: Nastavení Java
Aby to celé fungovalo tak, jak jsme původně chtěli, strávili jsme velmi dlouhou dobu laděním široké škály věcí v clusteru.
První část objevených problémů se týkala toho, jak je Java standardně předkonfigurována v Elasticsearch.
Problém jedna
Viděli jsme velké množství zpráv, které máme na úrovni Lucene, když běží úlohy na pozadí, sloučení segmentů Lucene selže. Zároveň bylo v logech jasné, že se jedná o chybu OutOfMemoryError. Z telemetrie jsme viděli, že kyčle byla volná, a nebylo jasné, proč tato operace padá.
Ukázalo se, že ke sloučení indexu Lucene dochází mimo kyčel. A kontejnery jsou z hlediska spotřebovaných zdrojů značně omezeny. Do těchto zdrojů se vešla pouze halda (hodnota heap.size byla přibližně rovna RAM) a některé operace mimo haldu padly s chybou alokace paměti, pokud se z nějakého důvodu nevešly do oněch ~ 500 MB, které zůstaly před limitem .
Oprava byla docela triviální: množství paměti RAM dostupné pro kontejner se zvýšilo, poté zapomněli, že jsme takové problémy vůbec měli.
Problém dva
4-5 dní po spuštění clusteru jsme si všimli, že datové uzly začínají periodicky vypadávat z clusteru a vstupují do něj po 10-20 sekundách.
Když na to vylezli, aby na to přišli, ukázalo se, že tato velmi nevyužitá paměť v Elasticsearch není prakticky žádným způsobem ovládána. Když jsme dali kontejneru více paměti, dostali jsme možnost naplnit přímé zásobníky vyrovnávacích pamětí různými informacemi, které byly vyčištěny až poté, co Elasticsearch spustil explicitní GC.
V některých případech tato operace trvala poměrně dlouho a během této doby se clusteru podařilo označit tento uzel jako již uvolněný. Tato problematika je dobře popsána. .
Řešení bylo následující: omezili jsme schopnost Javy používat pro tyto operace většinu paměti mimo haldu. Omezili jsme to na 16 gigabajtů (-XX:MaxDirectMemorySize=16g), čímž jsme zajistili, že explicitní GC bude voláno mnohem častěji a bude zpracováno mnohem rychleji, čímž jsme přestali destabilizovat cluster.
Problém tři
Pokud si myslíte, že problémy s „uzly opouštějícími cluster v nejneočekávanější chvíli“ pominuly, mýlíte se.
Když jsme konfigurovali práci s indexy, rozhodli jsme se pro mmapfs na čerstvých střepech s vysokou členitostí. To byla dost hrubá chyba, protože při použití mmapfs se soubor namapuje do RAM a pak s namapovaným souborem pracujeme. Z tohoto důvodu se ukázalo, že když se GC pokusí zastavit vlákna v aplikaci, přejdeme na velmi dlouhou dobu do bodu bezpečí a na cestě k němu aplikace přestane reagovat na požadavky průvodce, zda je naživu . V souladu s tím se master domnívá, že uzel již není přítomen v našem clusteru. Poté, po 5-10 sekundách, garbage collector funguje, uzel ožije, znovu vstoupí do clusteru a začne inicializovat shardy. To vše silně připomínalo „inscenaci, kterou jsme si zasloužili“ a nehodilo se k ničemu vážnému.
Abychom se tohoto chování zbavili, nejprve jsme přešli na standardní niofs a poté, když jsme migrovali z páté verze Elastic na šesté, jsme zkusili hybridfs, kde se tento problém nereprodukoval. Můžete si přečíst více o typech úložiště .
Problém čtvrtý
Pak tu byl další velmi zábavný problém, který jsme řešili rekordně dlouho. Chytali jsme ji na 2-3 měsíce, protože její vzor byl naprosto nepochopitelný.
Občas naši koordinátoři odjeli na Full GC, většinou někde odpoledne, a už se odtamtud nevrátili. Přitom při logování zpoždění GC to vypadalo takto: všechno nám jde dobře, dobře, dobře a pak jednou - a vše je prudce špatné.
Nejprve jsme si mysleli, že máme zlého uživatele, který spustí nějakou žádost, která vyřadí koordinátora z pracovního režimu. Velmi dlouho jsme zaznamenávali požadavky a snažili jsme se zjistit, co se děje.
Ve výsledku se ukázalo, že ve chvíli, kdy nějaký uživatel spustí obrovský požadavek a ten zasáhne konkrétního koordinátora Elasticsearch, některé uzly reagují déle než jiné.
A zatímco koordinátor čeká na odpověď všech uzlů, kumuluje v sobě výsledky zaslané z uzlů, které již odpověděly. Pro GC to znamená, že náš způsob používání kyčlí se velmi rychle mění. A GC, které jsme použili, se s tímto úkolem nedokázalo vyrovnat.
Jedinou opravou, kterou jsme v této situaci zjistili, jak změnit chování clusteru, je migrace na JDK13 a použití garbage collectoru Shenandoah. Tím se problém vyřešil, naši koordinátoři přestali padat.
Tady skončily problémy s Javou a začaly problémy s šířkou pásma.
"Bobule" s Elasticsearch: propustnost
Problémy s propustností znamenají, že náš cluster je stabilní, ale na vrcholu počtu indexovaných dokumentů a v době manévrů je výkon nedostatečný.
První příznak, na který jsem narazil: během jakýchsi „výbuchů“ ve výrobě, kdy je náhle generováno velmi velké množství protokolů, v Graylogu často bliká chyba indexování es_rejected_execution.
To bylo způsobeno tím, že thread_pool.write.queue na jednom datovém uzlu, dokud není Elasticsearch schopen zpracovat požadavek na index a hodit informace do shardu na disku, ve výchozím nastavení může ukládat do mezipaměti pouze 200 požadavků. A dovnitř o tomto parametru se mluví velmi málo. Je uveden pouze limitní počet vláken a výchozí velikost.
Tuto hodnotu jsme samozřejmě překroutili a zjistili jsme následující: konkrétně v našem nastavení se celkem dobře ukládá do mezipaměti až 300 požadavků a větší hodnota je plná skutečnosti, že opět odlétáme na Full GC.
Navíc, protože se jedná o dávky zpráv, které dorazí v rámci jednoho požadavku, bylo také nutné vyladit Graylog tak, aby nepsal často a v malých dávkách, ale ve velkých dávkách nebo každé 3 sekundy, pokud dávka stále není plná. V tomto případě se ukazuje, že informace, které zapíšeme v Elasticsearch, se zpřístupní ne po dvou sekundách, ale po pěti (což nám docela vyhovuje), ale počet zpětných záznamů, které je třeba provést, aby se dostal velký balík informací klesá.
To je důležité zejména v těch chvílích, kdy se někde něco zhroutilo a zuřivě o tom hlásilo, aby nedošlo k úplnému spamování Elastic a po nějaké době - Graylog uzly, které jsou nefunkční kvůli ucpaným bufferům.
Navíc, když jsme měli tyto exploze ve výrobě, dostali jsme stížnosti od programátorů a testerů: ve chvíli, kdy tyto protokoly opravdu potřebují, jsou jim vydávány velmi pomalu.
Začali si rozumět. Na jednu stranu bylo jasné, že jak vyhledávací dotazy, tak i indexační dotazy se zpracovávají ve skutečnosti na stejných fyzických strojích a tak či onak dojde k určitým výpadkům.
To se ale dalo částečně obejít díky skutečnosti, že v šestých verzích Elasticsearch se objevil algoritmus, který umožňuje distribuovat požadavky mezi relevantní datové uzly nikoli podle principu náhodného round-robin (kontejner, který indexuje a drží primární shard může být velmi zaneprázdněn, nebude možné rychle reagovat), ale přesměrovat tento požadavek do méně zatíženého kontejneru s replikou-shard, který bude reagovat výrazně rychleji. Jinými slovy, skončili jsme s use_adaptive_replica_selection: true.
Obrázek čtení začíná vypadat takto:
Přechod na tento algoritmus nám umožnil znatelně zlepšit dobu dotazování v těch okamžicích, kdy jsme měli velký proud protokolů pro zápis.
Nakonec hlavním problémem bylo bezbolestné odstranění datového centra.
Co jsme chtěli od clusteru ihned po ztrátě komunikace s jedním DC:
- Pokud máme aktuálního mastera v padlém datovém centru, pak bude znovu zvolen a přesunuto jako role do jiného uzlu v jiném DC.
- Master rychle vykopne všechny nepřístupné uzly z clusteru.
- Na základě zbytku pochopí: ve ztraceném datovém centru jsme měli takové a takové primární úlomky, rychle prosadí doplňkové replikové úlomky ve zbývajících datových centrech a budeme pokračovat v indexování dat.
- V důsledku toho se bude plynule zhoršovat šířka pásma clusteru pro zápis a čtení, ale obecně bude vše fungovat, i když pomalu, ale stabilně.
Jak se ukázalo, chtěli jsme něco takového:
A dostal následující:
Jak se to stalo?
V době pádu datového centra se pro nás stal hlavním úzkým hrdlem.
Proč?
Faktem je, že průvodce má TaskBatcher odpovědný za distribuci určitých úkolů a událostí v clusteru. Jakýkoli výstup uzlu, jakékoli povýšení shardu z repliky na primární, jakýkoli úkol vytvořit někde nějaký shard – to vše se nejprve dostane do TaskBatcheru, kde se to zpracuje sekvenčně a v jednom vlákně.
V době stažení jednoho datového centra se ukázalo, že všechny datové uzly v přeživších datových centrech považovaly za svou povinnost informovat master „ztratili jsme takové a takové úlomky a takové a takové datové uzly“.
Přeživší datové uzly zároveň odeslaly všechny tyto informace současnému mistrovi a pokusily se počkat na potvrzení, že je přijal. Nečekali to, protože mistr dostával úkoly rychleji, než stihl odpovědět. Uzly opakovaly požadavky podle časového limitu a master se v té době ani nepokusil na ně odpovědět, ale byl zcela pohlcen úkolem třídit požadavky podle priority.
V terminálové podobě se ukázalo, že datové uzly spamovaly mastera do té míry, že přešel do plného GC. Poté se role mistra přesunula na nějaký další uzel, stalo se mu úplně to samé a v důsledku toho se shluk úplně rozpadl.
Provedli jsme měření a před verzí 6.4.0, kde to bylo opraveno, nám stačilo stáhnout současně jen 10 z 360 datových uzlů, abychom cluster úplně dali.
Vypadalo to nějak takto:
Po verzi 6.4.0, kde byla tato podivná chyba opravena, přestaly datové uzly zabíjet master. Ale to ho neudělalo chytřejším. Konkrétně: když vydáme 2, 3 nebo 10 (libovolný počet jiný než jeden) datových uzlů, master obdrží nějakou první zprávu, která říká, že uzel A odešel, a pokusí se sdělit uzlům B, C, D.
A v tuto chvíli se to dá řešit jedině tak, že se nastaví timeout pro pokusy někomu o něčem říct, rovný někde kolem 20-30 sekund, a tím řídit rychlost stahování datového centra z clusteru.
V zásadě to zapadá do požadavků, které byly v rámci projektu původně stanoveny na výsledný produkt, ale z pohledu „čisté vědy“ jde o chybu. Což se mimochodem podařilo vývojářům ve verzi 7.2 opravit.
Navíc, když vyšel určitý datový uzel, ukázalo se, že šíření informací o jeho výstupu je důležitější, než říkat celému clusteru, že má takový a takový primární shard (za účelem propagace repliky-shardu v jiném datovém centru v primární a mohli psát informace).
Proto, když již vše utichlo, nejsou uvolněné datové uzly okamžitě označeny jako zastaralé. V souladu s tím jsme nuceni čekat, dokud nevyprší časový limit všech pingů, než se uvolní datové uzly, a teprve poté náš cluster začne mluvit o tom, že tam, tam a tam je nutné pokračovat v záznamu informací. Můžete si o tom přečíst více .
Výsledkem je, že operace stažení datového centra nám dnes ve špičce trvá asi 5 minut. Na tak velký a nemotorný kolos je to docela dobrý výsledek.
V důsledku toho jsme dospěli k následujícímu řešení:
- Máme 360 datových uzlů se 700 gigabajtovými disky.
- 60 koordinátorů pro směrování provozu na stejných datových uzlech.
- 40 masterů, které nám zbyly jako jakési dědictví z dob verzí před 6.4.0 - abychom přežili stažení datového centra, byli jsme psychicky připraveni ztratit několik strojů, abychom zaručili kvorum masterů i v nejhorší scénář
- Jakékoli pokusy o zkombinování rolí na jednom kontejneru u nás spočívaly na tom, že uzel dříve nebo později praskl při zatížení.
- Celý cluster používá heap.size rovný 31 gigabajtům: všechny pokusy o zmenšení velikosti vedly k tomu, že těžké vyhledávací dotazy s vedoucím zástupným znakem buď zabily některé uzly, nebo zabily jistič v Elasticsearch samotném.
- Navíc, abychom zajistili výkon vyhledávání, snažili jsme se udržet počet objektů v clusteru co nejmenší, abychom zpracovali co nejméně událostí v úzkém hrdle, které jsme získali v průvodci.
Poslední věc k monitorování
Aby vše fungovalo podle očekávání, sledujeme následující:
- Každý datový uzel hlásí našemu cloudu, že existuje, a jsou na něm takové a takové střípky. Když někde něco uhasíme, cluster po 2-3 sekundách hlásí, že v centru A jsme uhasili uzel 2, 3 a 4 – to znamená, že v jiných datových centrech nemůžeme tyto uzly uhasit, když zbývá jen jeden úlomek.
- Když známe chování mistra, velmi pečlivě se díváme na počet čekajících úkolů. Protože i jeden pověšený úkol, pokud se mu včas nevyprší, teoreticky, v nějaké nouzové situaci, se může stát důvodem, proč nám například nefunguje propagace replikového střepu v primáru, který se zastaví indexování.
- Velmi pozorně sledujeme i zpoždění sběrače odpadků, protože už při optimalizaci jsme s tím měli velké potíže.
- Propojte odmítnutí, abyste předem pochopili, kde je „úzké hrdlo“.
- No, standardní metriky jako halda, RAM a I/O.
Při budování monitorování nezapomeňte vzít v úvahu vlastnosti Thread Pool v Elasticsearch. popisuje nastavení a výchozí hodnoty pro vyhledávání, indexování, ale zcela mlčí o thread_pool.management.Tato vlákna zpracovávají zejména požadavky jako _cat/shards a další podobné, které je vhodné použít při psaní monitoringu. Čím větší cluster, tím více takových požadavků je vykonáno za jednotku času a zmíněný thread_pool.management nejenže není uveden v oficiální dokumentaci, ale je také standardně omezen na 5 vláken, což je velmi rychle využito, po kterém monitorování přestane správně fungovat.
Co chci říci závěrem: povedlo se! Podařilo se nám dát našim programátorům a vývojářům nástroj, který dokáže rychle a spolehlivě poskytnout informace o dění ve výrobě téměř v každé situaci.
Ano, ukázalo se to jako poměrně obtížné, ale přesto se nám podařilo náš Wishlist vměstnat do stávajících produktů, které jsme si zároveň nemuseli opravovat a přepisovat.
Zdroj: www.habr.com