Zbieranie logov od Lokiho

My v Badoo neustále monitorujeme nové technológie a vyhodnocujeme, či ich v našom systéme použijeme alebo nie. O jednu z týchto štúdií sa chceme podeliť s komunitou. Je venovaný Lokimu, systému agregácie denníkov.

Loki je riešenie na ukladanie a prezeranie protokolov a tento zásobník tiež poskytuje flexibilný systém na ich analýzu a odosielanie údajov spoločnosti Prometheus. V máji vyšla ďalšia aktualizácia, ktorú tvorcovia aktívne propagujú. Zaujímalo nás, čo Loki dokáže, aké príležitosti poskytuje a do akej miery môže pôsobiť ako alternatíva k ELK, zásobníku, ktorý teraz používame.

Čo je Loki

Grafana Loki je sada komponentov pre kompletný logovací systém. Na rozdiel od iných podobných systémov je Loki založený na myšlienke indexovať iba metadáta protokolov - štítky (rovnako ako v Prometheus) a komprimovať samotné protokoly vedľa seba do samostatných častí.

Domovská stránka, GitHub

Predtým, ako sa dostanem k tomu, čo môžete robiť s Lokim, chcem objasniť, čo znamená „myšlienka indexovania iba metadát“. Porovnajme prístup Loki a prístup indexovania v tradičných riešeniach, ako je Elasticsearch, na príklade riadku z denníka nginx:

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

Tradičné systémy analyzujú celý riadok vrátane polí s mnohými jedinečnými hodnotami user_id a item_id a všetko ukladajú do veľkých indexov. Výhodou tohto prístupu je, že môžete rýchlo spúšťať zložité dotazy, pretože takmer všetky údaje sú v indexe. Ale musíte za to zaplatiť, pretože index sa zväčší, čo sa premieta do požiadaviek na pamäť. Výsledkom je, že fulltextový index protokolov je veľkosťou porovnateľný so samotnými protokolmi. Aby ste v ňom mohli rýchlo prehľadávať, index sa musí načítať do pamäte. A čím viac protokolov, tým rýchlejšie sa index zvyšuje a tým viac pamäte spotrebuje.

Prístup Loki vyžaduje, aby sa z reťazca extrahovali iba potrebné údaje, ktorých počet hodnôt je malý. Týmto spôsobom získame malý index a môžeme vyhľadávať údaje filtrovaním podľa času a indexovaných polí a potom skenovaním zvyšku pomocou regulárnych výrazov alebo vyhľadávania podreťazcov. Proces sa nezdá najrýchlejší, ale Loki rozdelí požiadavku na niekoľko častí a tie vykoná paralelne, pričom spracuje veľké množstvo dát v krátkom čase. Počet zlomkov a paralelných požiadaviek v nich je konfigurovateľný; teda množstvo údajov, ktoré je možné spracovať za jednotku času, závisí lineárne od množstva poskytnutých zdrojov.

Tento kompromis medzi veľkým rýchlym indexom a malým paralelným indexom hrubej sily umožňuje Lokimu kontrolovať náklady na systém. Dá sa flexibilne konfigurovať a rozširovať podľa vašich potrieb.

Stoh Loki sa skladá z troch komponentov: Promtail, Loki, Grafana. Promtail zbiera protokoly, spracováva ich a posiela Lokimu. Loki ich drží. A Grafana si môže vyžiadať údaje od Lokiho a ukázať ich. Vo všeobecnosti možno Lokiho použiť nielen na ukladanie protokolov a prehľadávanie v nich. Celý zásobník poskytuje skvelé príležitosti na spracovanie a analýzu prichádzajúcich údajov spôsobom Prometheus.
Popis procesu inštalácie nájdete tu.

Vyhľadávanie denníka

V protokoloch môžete vyhľadávať v špeciálnom rozhraní Grafana — Explorer. Dotazy používajú jazyk LogQL, ktorý je veľmi podobný jazyku PromQL, ktorý používa Prometheus. V princípe si to možno predstaviť ako distribuovaný grep.

Rozhranie vyhľadávania vyzerá takto:

Samotný dotaz pozostáva z dvoch častí: selektor a filter. Selektor je vyhľadávanie podľa indexovaných metadát (označení), ktoré sú priradené k protokolom, a filter je vyhľadávací reťazec alebo regulárny výraz, ktorý filtruje záznamy definované selektorom. V uvedenom príklade: V zložených zátvorkách - selektor, všetko za - filter.

{image_name="nginx.promtail.test"} |= "index"

Vzhľadom na spôsob, akým Loki funguje, nemôžete zadávať požiadavky bez selektora, ale štítky môžu byť ľubovoľne všeobecné.

Selektor je kľúč – hodnota hodnoty v zložených zátvorkách. Pomocou operátorov =, != alebo regulárnych výrazov môžete kombinovať selektory a špecifikovať rôzne podmienky vyhľadávania:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev 

Filter je text alebo regulárny výraz, ktorý odfiltruje všetky údaje prijaté selektorom.

V režime metrík je možné získať ad-hoc grafy na základe prijatých údajov. Môžete napríklad zistiť frekvenciu výskytu v protokoloch nginx položky obsahujúcej reťazec indexu:

Úplný popis funkcií nájdete v dokumentácii LogQL.

Analýza denníka

Existuje niekoľko spôsobov, ako zbierať protokoly:

• S pomocou Promtail, štandardného komponentu stohu na zber guľatiny.
• Priamo z dokovacieho kontajnera pomocou Logovací ovládač Loki Docker.
• Použite Fluentd alebo Fluent Bit, ktorý môže posielať dáta Lokimu. Na rozdiel od Promtailu majú pripravené parsery pre takmer akýkoľvek typ logu a poradia si aj s viacriadkovými logami.

Na analýzu sa zvyčajne používa Promtail. Robí tri veci:

• Vyhľadá zdroje údajov.
• Prilepte k nim štítky.
• Odošle údaje Lokimu.

V súčasnosti môže Promtail čítať protokoly z lokálnych súborov a zo systemd journalu. Musí byť nainštalovaný na každom počítači, z ktorého sa zbierajú protokoly.

Existuje integrácia s Kubernetes: Promtail automaticky zistí stav klastra prostredníctvom Kubernetes REST API a zhromažďuje protokoly z uzla, služby alebo pod, pričom okamžite uverejňuje štítky na základe metadát z Kubernetes (názov podu, názov súboru atď.).

Môžete tiež zavesiť štítky na základe údajov z denníka pomocou Pipeline. Pipeline Promtail môže pozostávať zo štyroch typov etáp. Viac podrobností - v oficiálna dokumentácia, Okamžite si všimnem niektoré nuansy.

1. Etapy analýzy. Toto je fáza RegEx a JSON. V tejto fáze extrahujeme údaje z protokolov do takzvanej extrahovanej mapy. Z JSON môžete extrahovať jednoduchým skopírovaním polí, ktoré potrebujeme, do extrahovanej mapy alebo prostredníctvom regulárnych výrazov (RegEx), kde sú pomenované skupiny „mapované“ do extrahovanej mapy. Extrahovaná mapa je úložisko párov kľúč – hodnota, kde kľúč je názov poľa a hodnota je jeho hodnota z protokolov.
2. Fázy transformácie. Táto fáza má dve možnosti: transformácia, kde nastavujeme pravidlá transformácie a zdroj – zdroj údajov pre transformáciu z extrahovanej mapy. Ak v extrahovanej mape takéto pole nie je, potom sa vytvorí. Takto je možné vytvárať štítky, ktoré nie sú založené na extrahovanej mape. V tejto fáze môžeme manipulovať s údajmi v extrahovanej mape pomocou pomerne výkonného golang šablóna. Okrem toho musíme pamätať na to, že extrahovaná mapa sa počas analýzy plne načíta, čo umožňuje napríklad skontrolovať v nej hodnotu: „{{if .tag}hodnota značky existuje{end}}“. Šablóna podporuje podmienky, cykly a niektoré funkcie reťazcov, ako napríklad Nahradiť a Orezať.
3. Akčné štádiá. V tejto fáze môžete niečo urobiť s extrahovaným:
   • Vytvorte štítok z extrahovaných údajov, ktorý bude indexovať Loki.
   • Zmeňte alebo nastavte čas udalosti z denníka.
   • Zmeňte údaje (text protokolu), ktoré prejdú Lokimu.
   • Vytvorte metriky.
4. Fázy filtrovania. Fáza zápasu, kde môžeme záznamy, ktoré nepotrebujeme, poslať do /dev/null, alebo ich poslať na ďalšie spracovanie.

Na príklade spracovania bežných protokolov nginx ukážem, ako môžete analyzovať protokoly pomocou Promtail.

Na test si vezmime upravený obrázok nginx jwilder/nginx-proxy:alpine a malého démona, ktorý sa dokáže dopytovať cez HTTP ako nginx-proxy. Démon má niekoľko koncových bodov, ktorým môže dávať odpovede rôznej veľkosti, s rôznymi stavmi HTTP a s rôznym oneskorením.

Budeme zbierať protokoly z docker kontajnerov, ktoré nájdete pozdĺž cesty /var/lib/docker/containers/ / -json.log

V docker-compose.yml nastavíme Promtail a zadáme cestu ku konfigurácii:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

Pridajte cestu k protokolom do promtail.yml (v konfigurácii je možnosť "docker", ktorá robí to isté v jednom riadku, ale nebolo by to také zrejmé):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

Keď je táto konfigurácia povolená, Loki dostane protokoly zo všetkých kontajnerov. Aby sme tomu zabránili, zmenili sme nastavenia testovacieho nginx v docker-compose.yml - do poľa značky pridajte protokolovanie:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

Upravte promtail.yml a nastavte Pipeline. Záznamy sú nasledovné:

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

etapy potrubia:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

Extrahujeme polia stream, attrs, attrs.tag (ak existujú) z prichádzajúceho JSON a vložíme ich do extrahovanej mapy.

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

Ak bolo možné vložiť pole značky do extrahovanej mapy, potom pomocou regulárneho výrazu extrahujeme názvy obrázka a kontajnera.

 - labels:
     image_name:
     container_name:

Prideľujeme štítky. Ak sa v extrahovaných údajoch nájdu kľúče image_name a container_name, ich hodnoty budú priradené k príslušným štítkom.

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

Zahodíme všetky denníky, ktoré nemajú nastavené štítky názov_obrázku a názov_kontajnera.

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

Pre všetky protokoly, ktorých názov_obrázku sa rovná nginx.promtail.test, extrahujte pole protokolu zo zdrojového protokolu a vložte ho do extrahovanej mapy pomocou kľúča riadku.

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

Vyčistíme vstupný reťazec regulárnymi výrazmi a vytiahneme virtuálneho hostiteľa nginx a riadok protokolu nginx.

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

Analyzujte denník nginx s regulárnymi výrazmi.

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

Analyzujte request_url. Pomocou regexpu určíme účel požiadavky: na statiku, na fotky, na API a nastavíme zodpovedajúci kľúč v extrahovanej mape.

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

Pomocou podmienených operátorov v šablóne skontrolujeme nainštalované polia v extrahovanej mape a nastavíme požadované hodnoty pre pole request_type: photo, static, API. Ak zlyhá, priraďte iné. Teraz request_type obsahuje typ požiadavky.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Nastavili sme štítky api_request, virtual_host, request_type a status (HTTP status) na základe toho, čo sa nám podarilo vložiť do extrahovanej mapy.

       - output:
           source: nginx_log_row

Zmeňte výstup. Teraz vyčistený denník nginx z extrahovanej mapy ide Lokimu.

Po spustení vyššie uvedenej konfigurácie môžete vidieť, že každá položka je označená na základe údajov z denníka.

Majte na pamäti, že extrahovanie štítkov s veľkým počtom hodnôt (kardinalita) môže Lokiho výrazne spomaliť. To znamená, že by ste do indexu nemali vkladať napríklad user_id. Prečítajte si o tom viac v článkuAko môžu štítky v Loki zrýchliť a zjednodušiť dotazy na protokoly". To však neznamená, že nemôžete vyhľadávať podľa user_id bez indexov. Pri vyhľadávaní je potrebné používať filtre („uchopiť“ podľa údajov) a index tu funguje ako identifikátor toku.

Vizualizácia denníka

Loki môže fungovať ako zdroj údajov pre grafy Grafana pomocou LogQL. Podporované sú nasledujúce funkcie:

• rýchlosť - počet záznamov za sekundu;
• počet za čas - počet záznamov v danom rozsahu.

Nechýbajú ani agregačné funkcie Sum, Avg a iné. Môžete vytvoriť pomerne zložité grafy, napríklad graf počtu chýb HTTP:

Predvolený zdroj údajov Loki je o niečo menej funkčný ako zdroj údajov Prometheus (napríklad nemôžete zmeniť legendu), ale Loki môže byť pripojený ako zdroj typu Prometheus. Nie som si istý, či je to zdokumentované správanie, ale súdiac podľa reakcie od vývojárov “Ako nakonfigurovať Loki ako zdroj údajov Prometheus? · Vydanie #1222 · grafana/loki“, napríklad je to úplne legálne a Loki je plne kompatibilný s PromQL.

Pridajte Loki ako zdroj údajov s typom Prometheus a pripojte adresu URL /loki:

A môžete vytvárať grafy, ako keby sme pracovali s metrikami z Prometheus:

Myslím si, že rozpor vo funkčnosti je dočasný a vývojári ho v budúcnosti opravia.

Metriky

Loki poskytuje možnosť extrahovať numerické metriky z protokolov a posielať ich spoločnosti Prometheus. Napríklad protokol nginx obsahuje počet bajtov na odpoveď a tiež, s určitou úpravou štandardného formátu protokolu, čas v sekundách, ktorý trvala odpoveď. Tieto údaje možno extrahovať a odoslať spoločnosti Prometheus.

Pridajte ďalšiu sekciu do promtail.yml:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

Táto možnosť vám umožňuje definovať a aktualizovať metriky na základe údajov z extrahovanej mapy. Tieto metriky sa neposielajú Loki – zobrazujú sa v koncovom bode Promtail /metrics. Prometheus musí byť nakonfigurovaný na príjem údajov z tejto fázy. Vo vyššie uvedenom príklade pre request_type="api" zhromažďujeme metriku histogramu. Pri tomto type metrík je vhodné získať percentily. Pre statiku a fotografie zhromažďujeme súčet bajtov a počet riadkov, v ktorých sme dostali bajty, aby sme vypočítali priemer.

Prečítajte si viac o metrikách tu.

Otvorte port na Promtail:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

Zabezpečujeme, aby sa zobrazili metriky s predponou promtail_custom:

Nastavenie programu Prometheus. Pridať pracovný promtail:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

A nakreslite graf:

Takto môžete zistiť napríklad štyri najpomalšie dotazy. Môžete tiež nakonfigurovať monitorovanie pre tieto metriky.

Škálovanie

Loki môže byť v jednoduchom binárnom režime aj v rozdelenom (horizontálne škálovateľný režim). V druhom prípade môže ukladať údaje do cloudu a časti a index sú uložené oddelene. Vo verzii 1.5 je implementovaná možnosť ukladania na jedno miesto, no zatiaľ sa neodporúča používať ju vo výrobe.

Časti môžu byť uložené v úložisku kompatibilnom s S3 a na ukladanie indexov možno použiť horizontálne škálovateľné databázy: Cassandra, BigTable alebo DynamoDB. Ostatné časti Loki – Distribútori (na písanie) a Querier (na dotazy) – sú bezstavové a tiež horizontálne.

Na konferencii DevOpsDays Vancouver 2019 jeden z účastníkov Callum Styan oznámil, že s Lokim má jeho projekt petabajty protokolov s indexom menším ako 1 % z celkovej veľkosti: „Ako Loki koreluje metriky a protokoly - a šetrí vám peniaze".

Porovnanie Lokiho a ELKa

Veľkosť indexu

Na otestovanie výslednej veľkosti indexu som vzal protokoly z kontajnera nginx, pre ktorý bol nakonfigurovaný Pipeline vyššie. Log súbor obsahoval 406 624 riadkov s celkovým objemom 109 MB. Protokoly boli vygenerované za hodinu, približne 100 záznamov za sekundu.

Príklad dvoch riadkov z denníka:

Pri indexovaní ELK to poskytlo veľkosť indexu 30,3 MB:

V prípade Lokiho to dalo asi 128 KB indexu a asi 3,8 MB dát v kusoch. Stojí za zmienku, že denník bol vytvorený umelo a neobsahoval širokú škálu údajov. Jednoduchý gzip na pôvodnom protokole Docker JSON s údajmi dal kompresiu 95,4 % a vzhľadom na to, že samotnému Lokimu bol odoslaný iba vyčistený protokol nginx, je kompresia na 4 MB pochopiteľná. Celkový počet jedinečných hodnôt pre štítky Loki bol 35, čo vysvetľuje malú veľkosť indexu. Pre ELK bol denník tiež vyčistený. Loki teda komprimoval pôvodné dáta o 96 % a ELK o 70 %.

Spotreba pamäte

Ak porovnáme celý zásobník Prometheus a ELK, potom Loki "zje" niekoľkonásobne menej. Je jasné, že služba Go spotrebuje menej ako služba Java a porovnanie veľkosti Heap Elasticsearch JVM a pridelenej pamäte pre Lokiho je nesprávne, no napriek tomu stojí za zmienku, že Loki využíva oveľa menej pamäte. Jeho výhoda CPU nie je taká zrejmá, ale je tiež prítomná.

Rýchlosť

Loki rýchlejšie „požiera“ polená. Rýchlosť závisí od mnohých faktorov - aké protokoly, ako sofistikovane ich analyzujeme, sieť, disk atď. - ale určite je vyššia ako rýchlosť ELK (v mojom teste asi dvakrát). Vysvetľuje to skutočnosť, že Loki vkladá do indexu oveľa menej údajov, a preto trávi menej času indexovaním. V tomto prípade je situácia opačná s rýchlosťou vyhľadávania: Loki citeľne spomaľuje dáta väčšie ako niekoľko gigabajtov, zatiaľ čo pre ELK rýchlosť vyhľadávania nezávisí od veľkosti dát.

Vyhľadávanie denníka

Loki je výrazne horší ako ELK, pokiaľ ide o možnosti vyhľadávania protokolov. Grep s regulárnymi výrazmi je silná vec, ale je nižšia ako databáza pre dospelých. Nedostatok dotazov na rozsah, agregácia iba podľa štítkov, nemožnosť vyhľadávania bez štítkov - to všetko nás obmedzuje pri hľadaní informácií, ktoré nás zaujímajú v Loki. To neznamená, že pomocou Loki nemožno nič nájsť, ale definuje tok práce s protokolmi, keď najprv nájdete problém v grafoch Prometheus a potom pomocou týchto štítkov hľadáte, čo sa stalo v protokoloch.

rozhranie

Po prvé, je to krásne (prepáč, nedalo sa odolať). Grafana má pekne vyzerajúce rozhranie, ale Kibana je oveľa funkčnejšia.

Loki plusy a mínusy

Z plusov možno poznamenať, že Loki sa integruje s Prometheusom, respektíve dostávame metriky a upozornenia hneď po vybalení. Je vhodný na zhromažďovanie protokolov a ich ukladanie pomocou Kubernetes Pods, pretože má objav služby zdedený z Prometheus a automaticky pripája štítky.

Z mínusov - slabá dokumentácia. Niektoré veci, ako sú funkcie a možnosti Promtailu, som objavil až v procese štúdia kódu, výhody open-source. Ďalšou nevýhodou sú slabé možnosti analýzy. Loki napríklad nedokáže analyzovať viacriadkové protokoly. Medzi nevýhody patrí aj skutočnosť, že Loki je relatívne mladá technológia (vydanie 1.0 bolo v novembri 2019).

Záver

Loki je 100% zaujímavá technológia, ktorá je vhodná pre malé a stredné projekty a umožňuje vám riešiť mnohé problémy s agregáciou protokolov, vyhľadávaním protokolov, monitorovaním a analýzou protokolov.

Lokiho na Badoo nepoužívame, pretože máme ELK stack, ktorý nám vyhovuje a ktorý za tie roky prerástol rôznymi zákazkovými riešeniami. Pre nás je kameňom úrazu hľadanie v logoch. S takmer 100 GB denníkov za deň je pre nás dôležité, aby sme dokázali nájsť všetko a ešte trochu viac a urobiť to rýchlo. Na vytváranie grafov a monitorovanie používame iné riešenia, ktoré sú prispôsobené našim potrebám a sú navzájom integrované. Loki stack má hmatateľné výhody, ale nedá nám viac, ako máme, a jeho výhody nebudú presne prevyšovať náklady na migráciu.

A hoci sa po prieskume ukázalo, že Lokiho nemôžeme použiť, dúfame, že vám tento príspevok pomôže pri výbere.

Úložisko s kódom použitým v článku sa nachádza tu.

Zdroj: hab.com