Kolektante ŝtipojn de Lokio

Ni ĉe Badoo konstante kontrolas novajn teknologiojn kaj taksas ĉu uzi ilin aŭ ne en nia sistemo. Ni volas dividi unu el ĉi tiuj studoj kun la komunumo. Ĝi estas dediĉita al Lokio, log-agrega sistemo.

Loki estas solvo por stoki kaj vidi protokolojn, kaj ĉi tiu stako ankaŭ provizas flekseblan sistemon por analizi ilin kaj sendi datumojn al Prometheus. En majo, alia ĝisdatigo estis publikigita, kiu estas aktive reklamita de la kreintoj. Ni interesiĝis pri tio, kion Lokio povas fari, kiajn funkciojn ĝi provizas, kaj kiom ĝi povas funkcii kiel alternativo al ELK, la stako, kiun ni uzas nun.

Kio estas Lokio

Grafana Loki estas aro de komponantoj por kompleta registra sistemo. Male al aliaj similaj sistemoj, Loki baziĝas sur la ideo de indeksado de nur protokolaj metadatumoj - etikedoj (same kiel en Prometheus), kaj kunpremi la protokolojn mem flank-al-flanke en apartajn pecojn.

Hejmpaĝo, GitHub

Antaŭ ol mi ekkomprenos, kion vi povas fari kun Loki, mi volas klarigi, kion signifas "la ideo indeksi nur metadatenojn". Ni komparu la Loki-aliron kaj la indeksan aliron en tradiciaj solvoj, kiel ekzemple Elasticsearch, uzante la ekzemplon de linio de la nginx-protokolo:

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"

Tradiciaj sistemoj analizas la tutan vicon, inkluzive de kampoj kun multaj unikaj user_id kaj item_id valoroj, kaj stokas ĉion en grandaj indeksoj. La avantaĝo de ĉi tiu aliro estas, ke vi povas fari kompleksajn demandojn rapide, ĉar preskaŭ ĉiuj datumoj estas en la indekso. Sed vi devas pagi por tio, ke la indekso fariĝas granda, kio tradukiĝas en memorpostulojn. Kiel rezulto, la plenteksta indekso de protokoloj estas komparebla en grandeco al la protokoloj mem. Por rapide serĉi tra ĝi, la indekso devas esti ŝarĝita en memoron. Kaj ju pli da ŝtipoj, des pli rapide la indekso pliiĝas kaj des pli da memoro ĝi konsumas.

La aliro de Loki postulas, ke nur la necesaj datumoj estu ĉerpitaj el la ĉeno, kies nombro da valoroj estas malgranda. Tiel ni ricevas malgrandan indekson kaj povas serĉi la datumojn filtrante ĝin laŭ tempo kaj indeksitaj kampoj, kaj poste skanante la ceterajn per regulaj esprimoj aŭ subŝnuraj serĉoj. La procezo ne ŝajnas la plej rapida, sed Loki dividas la peton en plurajn partojn kaj efektivigas ilin paralele, prilaborante grandan kvanton da datumoj en mallonga tempo. La nombro da fragmentoj kaj paralelaj petoj en ili estas agordebla; tiel, la kvanto de datenoj kiuj povas esti prilaboritaj per unuo de tempo dependas linie de la kvanto de resursoj disponigitaj.

Ĉi tiu kompromiso inter granda rapida indekso kaj malgranda paralela krudforta indekso permesas al Lokio kontroli la koston de la sistemo. Ĝi povas esti flekseble agordita kaj vastigita laŭ viaj bezonoj.

La Lokio-stako konsistas el tri komponentoj: Promtail, Lokio, Grafana. Promtail kolektas tagalojn, prilaboras ilin kaj sendas ilin al Lokio. Lokio konservas ilin. Kaj Grafana povas peti datumojn de Lokio kaj montri ĝin. Ĝenerale, Lokio povas esti uzata ne nur por stoki protokolojn kaj serĉi tra ili. La tuta stako provizas grandajn ŝancojn por prilabori kaj analizi envenantajn datumojn per la maniero de Prometheus.
Priskribo de la instala procezo troveblas tie.

Log Serĉo

Vi povas serĉi la protokolojn en speciala interfaco Grafana — Esploristo. La demandoj uzas la LogQL-lingvon, kiu tre similas al la PromQL uzata de Prometheus. Principe, ĝi povas esti opiniita kiel distribuita grep.

La serĉinterfaco aspektas jene:

La demando mem konsistas el du partoj: elektilo kaj filtrilo. Elektilo estas serĉo per indeksitaj metadatenoj (etikedoj) kiuj estas asignitaj al la protokoloj, kaj filtrilo estas serĉĉeno aŭ regexp kiu filtras la rekordojn difinitajn de la elektilo. En la donita ekzemplo: En krampoj - la elektilo, ĉio post - la filtrilo.

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

Pro la maniero kiel Lokio funkcias, vi ne povas fari petojn sen elektilo, sed etikedoj povas esti arbitre genraj.

La elektilo estas la ŝlosilvaloro de la valoro en krampoj. Vi povas kombini elektilojn kaj specifi malsamajn serĉkondiĉojn per la =, !=-funkciigistoj aŭ regulaj esprimoj:

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

Filtrilo estas teksto aŭ regexp kiu elfiltros ĉiujn datumojn ricevitajn de la elektilo.

Eblas akiri ad-hoc-grafikaĵojn bazitajn sur la ricevitaj datumoj en la metrika reĝimo. Ekzemple, vi povas ekscii la oftecon de okazo en la nginx-protokoloj de eniro enhavanta la indeksan ĉenon:

Plena priskribo de la funkcioj troveblas en la dokumentado LogQL.

Registro-analizo

Estas pluraj manieroj kolekti ŝtipojn:

• Kun la helpo de Promtail, norma komponanto de la stako por kolekti ŝtipojn.
• Rekte de la docker-ujo uzante Loki Docker Logging Driver.
• Uzu Fluentd aŭ Fluent Bit, kiuj povas sendi datumojn al Loki. Male al Promtail, ili havas pretajn analizilojn por preskaŭ ajna tipo de protokolo kaj ankaŭ povas pritrakti plurliniajn protokolojn.

Kutime Promtail estas uzata por analizado. Ĝi faras tri aferojn:

• Trovas datumfontojn.
• Aligu etikedojn al ili.
• Sendas datumojn al Lokio.

Nuntempe Promtail povas legi protokolojn de lokaj dosieroj kaj de systemd-ĵurnalo. Ĝi devas esti instalita sur ĉiu maŝino de kiu ŝtipoj estas kolektitaj.

Estas integriĝo kun Kubernetes: Promtail aŭtomate malkovras la staton de la areto per la Kubernetes REST API kaj kolektas protokolojn de nodo, servo aŭ pod, tuj afiŝante etikedojn bazitajn sur metadatenoj de Kubernetes (podnomo, dosiernomo, ktp.).

Vi ankaŭ povas pendigi etikedojn bazitajn sur datumoj de la protokolo uzante Pipeline. Pipeline Promtail povas konsisti el kvar specoj de stadioj. Pli da detaloj - en oficiala dokumentaro, mi tuj notos kelkajn el la nuancoj.

1. Analizaj etapoj. Ĉi tiu estas la stadio de RegEx kaj JSON. En ĉi tiu etapo, ni ĉerpas datumojn de la protokoloj en la tiel nomatan ĉerpitan mapon. Vi povas ĉerpi el JSON simple kopiante la kampojn, kiujn ni bezonas en la ĉerpita mapon, aŭ per regulaj esprimoj (RegEx), kie nomitaj grupoj estas "mapitaj" en la ĉerpita mapon. Eltirita mapo estas ŝlosilvalora stokado, kie ŝlosilo estas la nomo de la kampo, kaj valoro estas ĝia valoro el la protokoloj.
2. Transformi stadiojn. Ĉi tiu etapo havas du eblojn: transformo, kie ni starigas la transformregulojn, kaj fonto - la datumfonto por la transformo de la ĉerpita mapo. Se ne ekzistas tia kampo en la ĉerpita mapo, tiam ĝi estos kreita. Tiel, eblas krei etikedojn kiuj ne baziĝas sur la ĉerpita mapo. En ĉi tiu etapo, ni povas manipuli la datumojn en la ĉerpita mapo uzante sufiĉe potencan Golang Ŝablono. Krome, ni devas memori, ke la ĉerpita mapo estas plene ŝargita dum analizado, kio ebligas, ekzemple, kontroli la valoron en ĝi: “{{se .tag}tagvaloro ekzistas{fino}}”. Ŝablono subtenas kondiĉojn, buklojn, kaj kelkajn kordfunkciojn kiel Anstataŭigi kaj Trim.
3. Agaj stadioj. En ĉi tiu etapo, vi povas fari ion kun la ĉerpita:
   • Kreu etikedon el la ĉerpitaj datumoj, kiuj estos indeksitaj de Loki.
   • Ŝanĝu aŭ agordu la eventotempon de la protokolo.
   • Ŝanĝu la datumojn (protokolo teksto) kiuj iros al Lokio.
   • Krei metrikojn.
4. Etapoj de filtrado. La matĉostadio, kie ni povas aŭ sendi rekordojn kiujn ni ne bezonas al /dev/null, aŭ sendi ilin por plia prilaborado.

Uzante la ekzemplon pri prilaborado de ordinaraj nginx-protokoloj, mi montros kiel vi povas analizi protokolojn per Promtail.

Por la testo, ni prenu modifitan nginx jwilder/nginx-proxy:alpan bildon kaj malgrandan demonon, kiu povas pridemandi sin per HTTP kiel nginx-proxy. La demono havas plurajn finpunktojn, al kiuj ĝi povas doni respondojn de malsamaj grandecoj, kun malsamaj HTTP-statusoj kaj kun malsamaj prokrastoj.

Ni kolektos protokolojn de docker-ujoj, kiuj troviĝas laŭ la vojo /var/lib/docker/containers/ / -json.log

En docker-compose.yml ni agordas Promtail kaj specifas la vojon al la agordo:

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'
 // ...

Aldonu la vojon al la protokoloj al promtail.yml (estas "docker" opcio en la agordo, kiu faras la samon en unu linio, sed ĝi ne estus tiel evidenta):

scrape_configs:
 - job_name: containers

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

Kiam ĉi tiu agordo estas ebligita, Lokio ricevos protokolojn de ĉiuj ujoj. Por eviti ĉi tion, ni ŝanĝas la agordojn de la testo nginx en docker-compose.yml - aldonu ensalutadon al la etikedkampo:

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

Redaktu promtail.yml kaj agordu Pipeline. La protokoloj estas kiel sekvas:

{"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"}

Fazoj de dukto:

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

Ni ĉerpas la fluon, attrs, attrs.tag-kampojn (se ekzistas) el la envenanta JSON kaj metas ilin en la ĉerpitan mapon.

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

Se eblis meti la etikedkampon en la ĉerpita mapo, tiam uzante la regexp ni ĉerpas la nomojn de la bildo kaj ujo.

 - labels:
     image_name:
     container_name:

Ni atribuas etikedojn. Se la ŝlosiloj bildo_nomo kaj ujo_nomo troviĝas en la ĉerpitaj datumoj, tiam iliaj valoroj estos asignitaj al la taŭgaj etikedoj.

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

Ni forĵetas ĉiujn protokolojn, kiuj ne havas etikedojn bildo_nomo kaj ujo_nomo agordita.

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

Por ĉiuj protokoloj, kies bildo_nomo estas egala al nginx.promtail.test, ni ĉerpas la protokolan kampon el la fonta protokolo kaj metas ĝin en la ĉerpitan mapon per la vicoŝlosilo.

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

Ni purigas la enigan ĉenon per regulaj esprimoj kaj elprenas la virtualan gastiganton nginx kaj la protokollinion 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.]+)")?

Analizu nginx-protokolo kun regulaj esprimoj.

    - 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>[^/?.]+).*$

Analizu request_url. Helpe de regexp, ni determinas la celon de la peto: al statiko, al fotoj, al API kaj fiksas la respondan ŝlosilon en la ĉerpita mapo.

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

Uzante kondiĉajn operatorojn en Ŝablono, ni kontrolas la instalitajn kampojn en la ĉerpita mapo kaj agordas la postulatajn valorojn por la kampo de peto_tipo: foto, statika, API. Asignu alian se malsukcesis. Nun request_type enhavas la petotipon.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Ni starigas la etikedojn api_request, virtual_host, request_type kaj statuso (HTTP-stato) surbaze de tio, kion ni sukcesis meti en la ĉerpita mapon.

       - output:
           source: nginx_log_row

Ŝanĝi eliron. Nun la purigita nginx-protokolo de la ĉerpita mapo iras al Lokio.

Post rulado de la supra agordo, vi povas vidi, ke ĉiu eniro estas etikedita surbaze de datumoj de la protokolo.

Memoru, ke ĉerpi etikedojn kun granda nombro da valoroj (kardinaleco) povas signife malrapidigi Lokion. Tio estas, vi ne enmetu la indekson, ekzemple, user_id. Legu pli pri tio en la artikoloKiel etikedoj en Lokio povas fari protokolojn pli rapide kaj pli facilaj". Sed ĉi tio ne signifas, ke vi ne povas serĉi per user_id sen indeksoj. Necesas uzi filtrilojn dum serĉado ("kapti" laŭ la datumoj), kaj la indekso ĉi tie funkcias kiel fluo-identigilo.

Log-bildigo

Lokio povas funkcii kiel datumfonto por Grafana-diagramoj uzante LogQL. La sekvaj funkcioj estas subtenataj:

• rate - nombro da registroj por sekundo;
• kalkulu laŭlonge de la tempo - la nombro da rekordoj en la donita gamo.

Ekzistas ankaŭ agregaciaj funkcioj Sumo, Avg kaj aliaj. Vi povas konstrui sufiĉe kompleksajn grafeojn, ekzemple, grafeon de la nombro da HTTP-eraroj:

La defaŭlta datumfonto de Lokio estas iom malpli funkcia ol la Prometheus-datumfonto (ekzemple, vi ne povas ŝanĝi la legendon), sed Lokio povas esti konektita kiel Prometheus-tipa fonto. Mi ne certas ĉu ĉi tio estas dokumentita konduto, sed se juĝante laŭ la respondo de la programistoj "Kiel agordi Lokion kiel Prometheus-datumfonton? · Afero n-ro 1222 · grafana/loki”, ekzemple, ĝi estas tute laŭleĝa kaj Lokio estas plene kongrua kun PromQL.

Aldonu Lokion kiel datumfonton per tajpu Prometheus kaj aldonu URL /loki:

Kaj vi povas fari grafikaĵojn, kvazaŭ ni laborus kun metrikoj de Prometheus:

Mi pensas, ke la diferenco en funkcieco estas provizora kaj la programistoj riparos ĝin estonte.

Metriko

Lokio disponigas la kapablon ĉerpi nombrajn metrikojn el protokoloj kaj sendi ilin al Prometheus. Ekzemple, la nginx-protokolo enhavas la nombron da bajtoj per respondo, kaj ankaŭ, kun certa modifo de la norma protokolo-formato, la tempo en sekundoj, kiun ĝi bezonis por respondi. Ĉi tiuj datumoj povas esti ĉerpitaj kaj senditaj al Prometheus.

Aldonu alian sekcion al 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

La opcio permesas vin difini kaj ĝisdatigi metrikojn surbaze de datumoj de la ĉerpita mapo. Ĉi tiuj metrikoj ne estas senditaj al Lokio - ili aperas en la Promtail /metrics finpunkto. Prometheus devas esti agordita por ricevi datumojn de ĉi tiu etapo. En la supra ekzemplo, por request_type="api" ni kolektas histograman metrikon. Kun ĉi tiu tipo de metrikoj estas oportune akiri procentojn. Por statiko kaj fotoj, ni kolektas la sumon de bajtoj kaj la nombro da vicoj, en kiuj ni ricevis bajtojn por kalkuli la mezumon.

Legu pli pri metrikoj tie.

Malfermu havenon sur Promtail:

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

Ni certigas, ke la metrikoj kun la promtail_custom prefikso aperis:

Starigante Prometeon. Aldonu laborprogramon:

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

Kaj ni desegnas grafeon:

Tiel vi povas ekscii, ekzemple, la kvar plej malrapidajn petojn. Vi ankaŭ povas agordi monitoradon por ĉi tiuj metrikoj.

Skalo

Lokio povas esti en kaj ununura binara reĝimo kaj sharded (horizontale-skalebla reĝimo). En la dua kazo, ĝi povas konservi datumojn al la nubo, kaj la pecoj kaj indekso estas konservitaj aparte. En versio 1.5, la kapablo stoki en unu loko estas efektivigita, sed ankoraŭ ne rekomendas uzi ĝin en produktado.

Pecoj povas esti stokitaj en S3-kongrua stokado, por stoki indeksojn, uzu horizontale skaleblajn datumbazojn: Cassandra, BigTable aŭ DynamoDB. Aliaj partoj de Lokio - Distribuiloj (por skribado) kaj Demando (por demandoj) - estas sennaciaj kaj ankaŭ skalas horizontale.

En la konferenco DevOpsDays Vancouver 2019, unu el la partoprenantoj Callum Styan anoncis, ke kun Loki lia projekto havas petabajtojn da ŝtipoj kun indekso malpli ol 1% de la tuta grandeco: "Kiel Lokio Korelacias Metrikojn kaj Protokolojn — Kaj Ŝparas al Vi Monon".

Komparo de Lokio kaj ELK

Indeksa grandeco

Por testi la rezultan indeksan grandecon, mi prenis protokolojn el la nginx-ujo, por kiu la Pipeline supre estis agordita. La protokoldosiero enhavis 406 liniojn kun totala volumeno de 624 MB. Registroj estis generitaj ene de unu horo, proksimume 109 rekordoj je sekundo.

Ekzemplo de du linioj de la protokolo:

Se indeksite fare de ELK, tio donis indeksgrandecon de 30,3 MB:

En la kazo de Lokio, ĉi tio donis ĉirkaŭ 128 KB da indekso kaj proksimume 3,8 MB da datumoj en partoj. Indas noti, ke la protokolo estis artefarite generita kaj ne havis diversajn datumojn. Simpla gzip sur la originala Docker JSON-protokolo kun datumoj donis kunpremadon de 95,4%, kaj pro tio, ke nur la purigita nginx-protokolo estis sendita al Loki mem, la kunpremo al 4 MB estas komprenebla. La tuta nombro de unikaj valoroj por Loki-etikedoj estis 35, kio klarigas la malgrandan grandecon de la indekso. Por ELK, la ŝtipo ankaŭ estis forigita. Tiel, Lokio kunpremis la originajn datumojn je 96%, kaj ELK je 70%.

Memorkonsumo

Se ni komparas la tutan stakon de Prometeo kaj ELK, tiam Lokio "manĝas" plurfoje malpli. Estas klare, ke la Go-servo konsumas malpli ol la Java-servo, kaj kompari la grandecon de la Heap Elasticsearch JVM kaj la asignitan memoron por Lokio estas malĝusta, sed tamen indas noti, ke Loki uzas multe malpli da memoro. Ĝia CPU-avantaĝo ne estas tiel evidenta, sed ĝi ankaŭ ĉeestas.

Rapido

Lokio "voras" ŝtipojn pli rapide. La rapideco dependas de multaj faktoroj - kiaj protokoloj, kiom altnivelaj ni analizas ilin, reto, disko, ktp. - sed ĝi estas certe pli alta ol tiu de ELK (en mia testo - ĉirkaŭ dufoje). Ĉi tio estas klarigita per la fakto, ke Loki metas multe malpli da datumoj en la indekson kaj, sekve, pasigas malpli da tempo por indeksado. Samtempe, la situacio inversiĝas kun la serĉrapideco: Lokio rimarkeble malrapidiĝas sur datumoj pli grandaj ol kelkaj gigabajtoj, dum por ELK, la serĉrapideco ne dependas de la datumgrandeco.

Log Serĉo

Lokio estas signife malsupera ol ELK laŭ protokolaj serĉkapabloj. Grep kun regulaj esprimoj estas forta afero, sed ĝi estas pli malalta ol plenkreska datumbazo. La manko de gamo-demandoj, agregado nur per etikedoj, la nekapablo serĉi sen etikedoj - ĉio ĉi limigas nin en serĉado de interesaj informoj en Lokio. Ĉi tio ne implicas, ke nenio troveblas uzante Lokio, sed ĝi difinas la fluon de laboro kun protokoloj, kiam vi unue trovas problemon sur la Prometheus-diagramoj, kaj tiam serĉas kio okazis en la protokoloj uzante ĉi tiujn etikedojn.

interfaco

Unue, ĝi estas bela (pardonu, mi ne povis rezisti). Grafana havas belaspektan interfacon, sed Kibana estas multe pli funkcia.

Avantaĝoj kaj malavantaĝoj de Loki

El la plusoj, oni povas rimarki, ke Lokio integriĝas kun Prometheus, respektive, ni ricevas metrikojn kaj atentigon el la skatolo. Ĝi estas oportuna por kolekti ŝtipojn kaj stoki ilin per Kubernetes Pods, ĉar ĝi havas servo-malkovron hereditan de Prometheus kaj aŭtomate almetas etikedojn.

De la minusoj - malbona dokumentado. Iuj aferoj, kiel la funkcioj kaj kapabloj de Promtail, mi malkovris nur en la procezo de studado de la kodo, la avantaĝon de malferma fonto. Alia malavantaĝo estas la malfortaj analizaj kapabloj. Ekzemple, Lokio ne povas analizi plurliniajn protokolojn. Ankaŭ, la malavantaĝoj inkluzivas la fakton, ke Lokio estas relative juna teknologio (eldono 1.0 estis en novembro 2019).

konkludo

Loki estas 100% interesa teknologio, kiu taŭgas por malgrandaj kaj mezaj projektoj, ebligante vin solvi multajn problemojn pri protokolo-agregado, protokolo-serĉo, monitorado kaj analizo de protokoloj.

Ni ne uzas Lokion ĉe Badoo, ĉar ni havas ELK-stakon kiu konvenas al ni kaj kiu estis superkreskita per diversaj kutimaj solvoj tra la jaroj. Por ni, la falilo estas la serĉo en la ŝtipoj. Kun preskaŭ 100 GB da protokoloj tage, gravas por ni povi trovi ĉion kaj iom pli kaj fari ĝin rapide. Por mapado kaj monitorado, ni uzas aliajn solvojn, kiuj estas adaptitaj al niaj bezonoj kaj integritaj unu kun la alia. La Loki-stako havas palpeblajn avantaĝojn, sed ĝi ne donos al ni pli ol tio, kion ni havas, kaj ĝiaj avantaĝoj ne ĝuste superpezos la koston de migrado.

Kaj kvankam post esploro evidentiĝis, ke ni ne povas uzi Lokion, ni esperas, ke ĉi tiu afiŝo helpos vin elekti.

La deponejo kun la kodo uzata en la artikolo troviĝas tie.

fonto: www.habr.com