Baļķu vākŔana no Loki

Baļķu vākŔana no Loki

Mēs Badoo pastāvÄ«gi uzraugām jaunās tehnoloÄ£ijas un izvērtējam, vai tās izmantot savā sistēmā. Mēs vēlamies dalÄ«ties ar kādu no Å”iem pētÄ«jumiem ar sabiedrÄ«bu. Tas ir veltÄ«ts Loki, baļķu apkopoÅ”anas sistēmai.

Loki ir risinājums žurnālu glabāŔanai un apskatei, un Ŕī kaudze nodroÅ”ina arÄ« elastÄ«gu sistēmu to analÄ«zei un datu nosÅ«tÄ«Å”anai uz Prometheus. Maijā tika izlaists vēl viens atjauninājums, kuru veidotāji aktÄ«vi reklamē. MÅ«s interesēja, ko Loki var darÄ«t, kādas funkcijas tas nodroÅ”ina un cik lielā mērā tas var darboties kā alternatÄ«va ELK, ko mēs Å”obrÄ«d izmantojam.

Kas ir Loki

Grafana Loki ir komponentu komplekts pilnÄ«gai reÄ£istrÄ“Å”anas sistēmai. AtŔķirÄ«bā no citām lÄ«dzÄ«gām sistēmām, Loki pamatā ir ideja indeksēt tikai žurnālu metadatus - etiÄ·etes (tāpat kā Prometheus) un paÅ”us žurnālus saspiest blakus atseviŔķos gabalos.

Š”Š¾Š¼Š°ŃˆŠ½ŃŃ стрŠ°Š½ŠøцŠ°, GitHub

Pirms turpināt aprakstÄ«t, ko varat darÄ«t ar Loki, es vēlos precizēt, ko nozÄ«mē "ideja indeksēt tikai metadatus". SalÄ«dzināsim Loki pieeju un indeksÄ“Å”anas pieeju tradicionālajos risinājumos, piemēram, Elasticsearch, izmantojot lÄ«nijas piemēru no nginx žurnāla:

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"

Tradicionālās sistēmas parsē visu rindu, tostarp laukus ar daudzām unikālām user_id un item_id vērtÄ«bām, un visu saglabā lielos indeksos. Å Ä«s pieejas priekÅ”rocÄ«ba ir tā, ka varat ātri izpildÄ«t sarežģītus vaicājumus, jo gandrÄ«z visi dati ir rādÄ«tājā. Bet jums par to ir jāmaksā, jo indekss kļūst liels, kas nozÄ«mē atmiņas prasÄ«bas. Rezultātā žurnālu pilna teksta indekss pēc izmēra ir salÄ«dzināms ar paÅ”iem žurnāliem. Lai ātri to meklētu, indekss ir jāielādē atmiņā. Un jo vairāk žurnālu, jo ātrāk palielinās indekss un patērē vairāk atmiņas.

Loki pieeja paredz, ka no virknes, kuras vērtÄ«bu skaits ir mazs, tiek iegÅ«ti tikai nepiecieÅ”amie dati. Tādā veidā mēs iegÅ«stam nelielu indeksu un varam meklēt datus, filtrējot tos pēc laika un indeksētajiem laukiem, un pēc tam skenējot pārējos, izmantojot regulāras izteiksmes vai apakÅ”virknes meklÄ“Å”anu. Process neŔķiet ātrākais, taču Loki pieprasÄ«jumu sadala vairākās daļās un izpilda tās paralēli, Ä«sā laikā apstrādājot lielu datu apjomu. Shardu un paralēlo pieprasÄ«jumu skaits tajās ir konfigurējams; tādējādi datu apjoms, ko var apstrādāt laika vienÄ«bā, ir lineāri atkarÄ«gs no nodroÅ”ināto resursu apjoma.

Å is kompromiss starp lielu ātru indeksu un nelielu paralēlu brutālā spēka indeksu ļauj Loki kontrolēt sistēmas izmaksas. To var elastÄ«gi konfigurēt un paplaÅ”ināt atbilstoÅ”i jÅ«su vajadzÄ«bām.

Loki kaudze sastāv no trim sastāvdaļām: Promtail, Loki, Grafana. Promtail apkopo žurnālus, apstrādā tos un nosÅ«ta uz Loki. Loki tos patur. Un Grafana var pieprasÄ«t datus no Loki un parādÄ«t tos. Kopumā Loki var izmantot ne tikai baļķu glabāŔanai un to meklÄ“Å”anai. Visa kaudze nodroÅ”ina lieliskas iespējas apstrādāt un analizēt ienākoÅ”os datus, izmantojot Prometheus metodi.
InstalēŔanas procesa aprakstu var atrast Ŕeit.

Žurnāla meklÄ“Å”ana

JÅ«s varat meklēt žurnālus Ä«paŔā interfeisā Grafana ā€” Explorer. Vaicājumos tiek izmantota LogQL valoda, kas ir ļoti lÄ«dzÄ«ga Prometheus izmantotajai PromQL valodai. Principā to var uzskatÄ«t par izplatÄ«tu grep.

MeklÄ“Å”anas interfeiss izskatās Ŕādi:

Baļķu vākŔana no Loki

Pats vaicājums sastāv no divām daļām: atlasÄ«tāja un filtra. AtlasÄ«tājs ir meklÄ“Å”ana pēc indeksētiem metadatiem (iezÄ«mēm), kas ir pieŔķirti žurnāliem, un filtrs ir meklÄ“Å”anas virkne vai regexp, kas filtrē atlasÄ«tāja definētos ierakstus. Dotajā piemērā: Iekavās - atlasÄ«tājs, viss pēc tam - filtrs.

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

Tā kā Loki darbojas, pieprasījumus nevar veikt bez atlasītāja, taču etiķetes var padarīt patvaļīgi vispārīgas.

AtlasÄ«tājs ir cirtainajās iekavās esoŔās vērtÄ«bas atslēgas vērtÄ«ba. Varat apvienot atlasÄ«tājus un norādÄ«t dažādus meklÄ“Å”anas nosacÄ«jumus, izmantojot operatorus =, != vai regulārās izteiksmes:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// ŠŠ°Š¹Š“ёт Š»Š¾Š³Šø с Š»ŠµŠ¹Š±Š»Š¾Š¼ instance, ŠøŠ¼ŠµŃŽŃ‰ŠøŠµ Š·Š½Š°Ń‡ŠµŠ½ŠøŠµ kafka-2, kafka-3, Šø ŠøсŠŗŠ»ŃŽŃ‡Šøт dev 

Filtrs ir teksts vai regexp, kas izfiltrēs visus atlasītāja saņemtos datus.

Metrikas režīmā ir iespējams iegūt ad-hoc grafikus, pamatojoties uz saņemtajiem datiem. Piemēram, ieraksta, kurā ir indeksa virkne, sastopamības biežumu varat uzzināt nginx žurnālos:

Baļķu vākŔana no Loki

Pilnu funkciju aprakstu var atrast dokumentācijā LogQL.

Žurnāla parsÄ“Å”ana

Ir vairāki veidi, kā savākt žurnālus:

  • Ar Promtail palÄ«dzÄ«bu, kas ir standarta baļķu savākÅ”anas kaudzes sastāvdaļa.
  • TieÅ”i no doka konteinera, izmantojot Loki Docker mežizstrādes draiveris.
  • Izmantojiet Fluentd vai Fluent Bit, kas var nosÅ«tÄ«t datus uz Loki. AtŔķirÄ«bā no Promtail, tiem ir gatavi parsētāji gandrÄ«z jebkura veida žurnāliem, un tie var apstrādāt arÄ« daudzrindu žurnālus.

Parasti Promtail izmanto parsēŔanai. Tas veic trīs lietas:

  • Atrod datu avotus.
  • Pievienojiet tiem etiÄ·etes.
  • NosÅ«ta datus uz Loki.

PaÅ”laik Promtail var nolasÄ«t žurnālus no vietējiem failiem un sistēmas žurnāla. Tas ir jāuzstāda katrā maŔīnā, no kuras tiek savākti baļķi.

Ir integrācija ar Kubernetes: Promtail automātiski noskaidro klastera stāvokli, izmantojot Kubernetes REST API, un apkopo žurnālus no mezgla, pakalpojuma vai pod, nekavējoties ievietojot etiķetes, pamatojoties uz Kubernetes metadatiem (pod nosaukums, faila nosaukums utt.).

Varat arÄ« piekārt etiÄ·etes, pamatojoties uz datiem no žurnāla, izmantojot Pipeline. Cauruļvada Promtail var sastāvēt no četru veidu posmiem. SÄ«kāka informācija - iekŔā oficiālā dokumentācija, uzreiz atzÄ«mÄ“Å”u dažas nianses.

  1. ParsÄ“Å”anas posmi. Å is ir RegEx un JSON posms. Å ajā posmā mēs iegÅ«stam datus no žurnāliem tā sauktajā izvilktajā kartē. Varat iegÅ«t no JSON, vienkārÅ”i kopējot vajadzÄ«gos laukus izvilktajā kartē vai izmantojot regulārās izteiksmes (RegEx), kur nosauktās grupas tiek ā€œkartētasā€ izvilktajā kartē. Izvilktā karte ir atslēgas vērtÄ«bu krātuve, kur atslēga ir lauka nosaukums, bet vērtÄ«ba ir tā vērtÄ«ba no žurnāliem.
  2. Transformācijas posmi. Å ajā posmā ir divas iespējas: transformācija, kurā mēs iestatām transformācijas noteikumus, un avots - datu avots transformācijai no iegÅ«tās kartes. Ja izvilktajā kartē Ŕāda lauka nav, tas tiks izveidots. Tādējādi ir iespējams izveidot etiÄ·etes, kas nav balstÄ«tas uz izvilkto karti. Å ajā posmā mēs varam manipulēt ar datiem iegÅ«tajā kartē, izmantojot diezgan spēcÄ«gu golang veidne. Turklāt mums jāatceras, ka izvilktā karte parsÄ“Å”anas laikā tiek pilnÄ«bā ielādēta, kas ļauj, piemēram, pārbaudÄ«t tajā esoÅ”o vērtÄ«bu: ā€œ{{if .tag}tag value pastāv{end}}ā€. Veidne atbalsta nosacÄ«jumus, cilpas un dažas virknes funkcijas, piemēram, Aizstāt un Apgriezt.
  3. Darbības posmi. Šajā posmā jūs varat kaut ko darīt ar iegūto:
    • Izveidojiet etiÄ·eti no iegÅ«tajiem datiem, kurus Loki indeksēs.
    • Mainiet vai iestatiet notikuma laiku no žurnāla.
    • Mainiet datus (žurnāla tekstu), kas tiks nosÅ«tÄ«ti uz Loki.
    • Izveidojiet metriku.
  4. FiltrÄ“Å”anas posmi. AtbilstÄ«bas posms, kurā mēs varam vai nu nosÅ«tÄ«t ierakstus, kuriem mums nav nepiecieÅ”ams /dev/null, vai nosÅ«tÄ«t tos tālākai apstrādei.

Izmantojot parasto nginx žurnālu apstrādes piemēru, es parādÄ«Å”u, kā jÅ«s varat parsēt žurnālus, izmantojot Promtail.

Pārbaudei ņemsim modificētu nginx jwilder/nginx-proxy:alpine attēlu un nelielu dēmonu, kas var vaicāt pats, izmantojot HTTP kā nginx starpniekserveri. Dēmonam ir vairāki galapunkti, uz kuriem tas var sniegt dažāda lieluma atbildes ar dažādiem HTTP statusiem un ar dažādu aizkavi.

Mēs savāksim baļķus no dokera konteineriem, kurus var atrast pa ceļu /var/lib/docker/containers/ / -json.log

Vietnē docker-compose.yml mēs iestatām Promtail un norādām ceļu uz konfigurāciju:

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

Pievienojiet ceļu uz žurnāliem uz promtail.yml (konfigurācijā ir opcija "docker", kas vienā rindā dara to paŔu, taču tas nebūtu tik acīmredzami):

scrape_configs:
 - job_name: containers

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

Kad Ŕī konfigurācija ir iespējota, Loki saņems žurnālus no visiem konteineriem. Lai no tā izvairÄ«tos, mēs mainām testa nginx iestatÄ«jumus docker-compose.yml - pievienojiet reÄ£istrÄ“Å”anu taga laukam:

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

Rediģējiet promtail.yml un iestatiet cauruļvadu. Žurnāli ir Ŕādi:

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

cauruļvada posmi:

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

Mēs izņemam straumes, attrs, attrs.tag laukus (ja tādi ir) no ienākoŔā JSON un ievietojam tos izvilktajā kartē.

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

Ja izvilktajā kartē bija iespējams ievietot tagu lauku, tad, izmantojot regexp izņemam attēla un konteinera nosaukumus.

 - labels:
     image_name:
     container_name:

Mēs pieŔķiram etiÄ·etes. Ja izvilktajos datos ir atrasti atslēgas attēla_nosaukums un konteinera_nosaukums, to vērtÄ«bas tiks pieŔķirtas atbilstoÅ”ajām etiÄ·etēm.

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

Mēs atmetam visus žurnālus, kuriem nav iestatītas etiķetes image_name un konteinera_nosaukums.

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

Visiem žurnāliem, kuru attēla_nosaukums ir vienāds ar nginx.promtail.test, mēs izņemam žurnāla lauku no avota žurnāla un ievietojam to izvilktajā kartē ar rindas taustiņu.

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

Mēs notīrām ievades virkni ar regulārām izteiksmēm un izvelkam nginx virtuālo resursdatoru un nginx žurnāla līniju.

     - 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.]+)")?

Parsēt nginx žurnālu ar regulārām izteiksmēm.

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

Parsēt pieprasÄ«juma_url. Ar regexp palÄ«dzÄ«bu mēs nosakām pieprasÄ«juma mērÄ·i: uz statiku, uz fotoattēliem, uz API un iestatām atbilstoÅ”o atslēgu izvilktajā kartē.

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

Izmantojot nosacÄ«tos operatorus veidnē, mēs pārbaudām instalētos laukus izvilktajā kartē un iestatām vajadzÄ«gās vērtÄ«bas laukam request_type: photo, static, API. Ja neizdodas, pieŔķiriet citu. Tagad request_type satur pieprasÄ«juma veidu.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Mēs iestatījām etiķetes api_request, virtual_host, request_type un status (HTTP statuss), pamatojoties uz to, ko mums izdevās ievietot izvilktajā kartē.

       - output:
           source: nginx_log_row

Mainīt izvadi. Tagad iztīrītais nginx žurnāls no izvilktās kartes nonāk Loki.

Baļķu vākŔana no Loki

Pēc iepriekÅ” minētās konfigurācijas palaiÅ”anas jÅ«s varat redzēt, ka katrs ieraksts ir marķēts, pamatojoties uz datiem no žurnāla.

Ņemiet vērā, ka etiÄ·eÅ”u iegÅ«Å”ana ar lielu vērtÄ«bu skaitu (kardinalitāte) var ievērojami palēnināt Loki darbÄ«bu. Tas ir, indeksā nevajadzētu ievietot, piemēram, user_id. Vairāk par to lasiet rakstāKā etiÄ·etes programmā Loki var padarÄ«t žurnāla vaicājumus ātrākus un vienkārŔākus". Bet tas nenozÄ«mē, ka nevar meklēt pēc user_id bez indeksiem. Meklējot ir nepiecieÅ”ams izmantot filtrus (ā€œgreifersā€ pēc datiem), un indekss Å”eit darbojas kā straumes identifikators.

Žurnāla vizualizācija

Baļķu vākŔana no Loki

Loki var darboties kā datu avots Grafana diagrammām, izmantojot LogQL. Tiek atbalstītas Ŕādas funkcijas:

  • likme - ierakstu skaits sekundē;
  • skaitÄ«t laika gaitā - ierakstu skaits dotajā diapazonā.

Ir arÄ« apkopoÅ”anas funkcijas Sum, Avg un citas. Varat izveidot diezgan sarežģītas diagrammas, piemēram, HTTP kļūdu skaita grafiku:

Baļķu vākŔana no Loki

Loki noklusējuma datu avots ir nedaudz mazāk funkcionāls nekā Prometheus datu avots (piemēram, jÅ«s nevarat mainÄ«t leÄ£endu), bet Loki var savienot kā Prometheus tipa avotu. Es neesmu pārliecināts, vai tā ir dokumentēta uzvedÄ«ba, taču, spriežot pēc izstrādātāju atbildes "Kā konfigurēt Loki kā Prometheus datu avotu? Ā· Izdevums #1222 Ā· grafana/lokiā€, piemēram, tas ir pilnÄ«gi likumÄ«gs, un Loki ir pilnÄ«bā savietojams ar PromQL.

Pievienojiet Loki kā datu avotu ar tipu Prometheus un pievienojiet URL /loki:

Baļķu vākŔana no Loki

Un jūs varat izveidot grafikus, it kā mēs strādātu ar Prometheus metriku:

Baļķu vākŔana no Loki

Domāju, ka funkcionalitātes neatbilstība ir īslaicīga un izstrādātāji to turpmāk novērsīs.

Baļķu vākŔana no Loki

Metrika

Loki nodroÅ”ina iespēju no žurnāliem iegÅ«t skaitliskos rādÄ«tājus un nosÅ«tÄ«t tos Prometheus. Piemēram, nginx žurnālā ir norādÄ«ts baitu skaits vienā atbildē, kā arÄ«, veicot noteiktas standarta žurnāla formāta izmaiņas, laiks sekundēs, kas bija nepiecieÅ”ams, lai atbildētu. Å os datus var iegÅ«t un nosÅ«tÄ«t Prometheus.

Pievienojiet vēl vienu sadaļu vietnei 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

Å Ä« opcija ļauj definēt un atjaunināt metriku, pamatojoties uz datiem no iegÅ«tās kartes. Å ie rādÄ«tāji netiek nosÅ«tÄ«ti uz Loki ā€” tie tiek rādÄ«ti galapunktā Promtail /metrics. Prometheus ir jākonfigurē, lai saņemtu datus no Ŕī posma. IepriekÅ” minētajā piemērā par request_type="api" mēs apkopojam histogrammas metriku. Izmantojot Ŕāda veida metriku, ir ērti iegÅ«t procentiles. Statikai un fotoattēliem mēs apkopojam baitu summu un rindu skaitu, kurās saņēmām baitus, lai aprēķinātu vidējo.

Lasiet vairāk par metriku Ŕeit.

Atveriet Promtail portu:

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

Mēs pārliecināmies, ka ir parādījusies metrika ar prefiksu promtail_custom:

Baļķu vākŔana no Loki

Prometeja iestatīŔana. Pievienot darba piedāvājumu:

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

Un uzzīmējiet grafiku:

Baļķu vākŔana no Loki

Tādā veidā jÅ«s varat uzzināt, piemēram, četrus lēnākos pieprasÄ«jumus. Varat arÄ« konfigurēt Å”o metrikas uzraudzÄ«bu.

MērogoÅ”ana

Loki var bÅ«t gan vienā binārajā režīmā, gan sadalÄ«tā (horizontāli mērogojamā režīmā). Otrajā gadÄ«jumā tas var saglabāt datus mākonÄ«, un gabali un indekss tiek glabāti atseviŔķi. 1.5 versijā ir ieviesta iespēja glabāt vienuviet, taču pagaidām to nav ieteicams izmantot ražoÅ”anā.

Baļķu vākŔana no Loki

Dabas var glabāt ar S3 saderÄ«gā krātuvē, indeksu glabāŔanai izmantojiet horizontāli mērogojamas datu bāzes: Cassandra, BigTable vai DynamoDB. Citas Loki daļas ā€” IzplatÄ«tāji (rakstÄ«Å”anai) un Querier (vaicājumiem) ā€” ir bezvalsts un arÄ« tiek mērogoti horizontāli.

DevOpsDays Vancouver 2019 konferencē viens no dalÄ«bniekiem Callum Styan paziņoja, ka viņa projektā ar Loki ir žurnālu petabaiti, kuru indekss ir mazāks par 1% no kopējā lieluma: ā€œKā Loki korelē metriku un žurnālus ā€” un ietaupa jÅ«su naudu".

Loki un ELK salīdzinājums

Indeksa izmērs

Lai pārbaudÄ«tu iegÅ«to indeksa lielumu, es paņēmu žurnālus no nginx konteinera, kuram tika konfigurēts iepriekÅ” minētais cauruļvads. Žurnāla failā bija 406 624 rindiņas ar kopējo apjomu 109 MB. Žurnāli tika Ä£enerēti stundas laikā, aptuveni 100 ieraksti sekundē.

Divu rindiņu piemērs no žurnāla:

Baļķu vākŔana no Loki

Kad ELK indeksēja, indeksa lielums bija 30,3 MB:

Baļķu vākŔana no Loki

Loki gadÄ«jumā tas deva aptuveni 128 KB indeksa un aptuveni 3,8 MB datu gabalos. Ir vērts atzÄ«mēt, ka žurnāls tika mākslÄ«gi Ä£enerēts un tajā nebija daudz dažādu datu. VienkārÅ”s gzip oriÄ£inālajā Docker JSON žurnālā ar datiem nodroÅ”ināja saspieÅ”anu par 95,4%, un, ņemot vērā, ka paÅ”am Loki tika nosÅ«tÄ«ts tikai iztÄ«rÄ«tais nginx žurnāls, saspieÅ”ana lÄ«dz 4 MB ir saprotama. Kopējais unikālo vērtÄ«bu skaits Loki etiÄ·etēm bija 35, kas izskaidro indeksa mazo izmēru. ELK arÄ« baļķis tika notÄ«rÄ«ts. Tādējādi Loki saspieda sākotnējos datus par 96%, bet ELK - par 70%.

Atmiņas patēriņŔ

Baļķu vākŔana no Loki

Ja salÄ«dzina visu Prometeja un ELK kaudzÄ«ti, tad Loki "ēd" vairākas reizes mazāk. Ir skaidrs, ka Go pakalpojums patērē mazāk nekā Java pakalpojums, un Heap Elasticsearch JVM lieluma un Loki pieŔķirtās atmiņas salÄ«dzināŔana ir nepareiza, taču tomēr ir vērts atzÄ«mēt, ka Loki patērē daudz mazāk atmiņas. Tā CPU priekÅ”rocÄ«ba nav tik acÄ«mredzama, taču tā ir arÄ« klāt.

Ātrums

Loki ātrāk "aprij" baļķus. Ātrums ir atkarÄ«gs no daudziem faktoriem - kādi žurnāli, cik sarežģīti mēs tos parsējam, tÄ«kls, disks utt. - bet tas noteikti ir lielāks nekā ELK (manā testā - apmēram divas reizes). Tas izskaidrojams ar to, ka Loki indeksā ievieto daudz mazāk datu un attiecÄ«gi mazāk laika pavada indeksÄ“Å”anai. Å ajā gadÄ«jumā situācija ir pretēja ar meklÄ“Å”anas ātrumu: Loki ievērojami palēninās datiem, kas ir lielāki par dažiem gigabaitiem, savukārt ELK meklÄ“Å”anas ātrums nav atkarÄ«gs no datu lieluma.

Žurnāla meklÄ“Å”ana

Loki ir ievērojami zemāks par ELK žurnālu meklÄ“Å”anas iespēju ziņā. Grep ar regulārām izteiksmēm ir spēcÄ«ga lieta, taču tā ir zemāka par pieauguÅ”o datu bāzi. Diapazona vaicājumu trÅ«kums, apkopoÅ”ana tikai pēc etiÄ·etēm, nespēja meklēt bez etiÄ·etēm - tas viss ierobežo mÅ«s interesējoŔās informācijas meklÄ“Å”anā Loki. Tas nenozÄ«mē, ka, izmantojot Loki, neko nevar atrast, bet tas nosaka darba plÅ«smu ar žurnāliem, kad vispirms Prometheus diagrammās atrodat problēmu un pēc tam meklējat žurnālos notikuÅ”o, izmantojot Ŕīs etiÄ·etes.

interfeiss

Pirmkārt, tas ir skaists (atvainojiet, nevarēju pretoties). Grafana ir jauks interfeiss, bet Kibana ir daudz funkcionālāka.

Loki plusi un mīnusi

No plusiem var atzīmēt, ka Loki integrējas ar Prometheus, attiecīgi mēs iegūstam metriku un brīdinājumus no kastes. Tas ir ērti, lai savāktu žurnālus un uzglabātu tos ar Kubernetes Pods, jo tam ir no Prometheus mantotais pakalpojumu atklājums un tas automātiski pievieno etiķetes.

No mÄ«nusiem - slikta dokumentācija. Dažas lietas, piemēram, Promtail funkcijas un iespējas, es atklāju tikai koda izpētes procesā atvērtā koda priekÅ”rocÄ«bas. Vēl viens trÅ«kums ir vājās parsÄ“Å”anas iespējas. Piemēram, Loki nevar parsēt vairākrindu žurnālus. Pie trÅ«kumiem var minēt arÄ« to, ka Loki ir salÄ«dzinoÅ”i jauna tehnoloÄ£ija (1.0 izlaidums bija 2019. gada novembrÄ«).

Secinājums

Loki ir 100% interesanta tehnoloÄ£ija, kas piemērota maziem un vidējiem projektiem, ļaujot atrisināt daudzas baļķu apkopoÅ”anas, baļķu meklÄ“Å”anas, baļķu uzraudzÄ«bas un analÄ«zes problēmas.

Mēs Badoo neizmantojam Loki, jo mums ir ELK kaudze, kas mums ir piemērota un kas gadu gaitā ir apaugusi ar dažādiem pielāgotiem risinājumiem. Mums klupÅ”anas akmens ir meklÄ“Å”ana baļķos. Ar gandrÄ«z 100 GB žurnālu dienā mums ir svarÄ«gi, lai mēs varētu atrast visu un nedaudz vairāk un izdarÄ«t to ātri. Diagrammu veidoÅ”anai un uzraudzÄ«bai mēs izmantojam citus risinājumus, kas ir pielāgoti mÅ«su vajadzÄ«bām un ir savstarpēji integrēti. Loki kaudzei ir taustāmas priekÅ”rocÄ«bas, taču tas mums nedos vairāk par to, kas mums ir, un tā priekÅ”rocÄ«bas precÄ«zi neatsvērs migrācijas izmaksas.

Un, lai gan pēc izpētes kļuva skaidrs, ka mēs nevaram izmantot Loki, mēs ceram, ka Ŕī ziņa palÄ«dzēs jums izvēlēties.

Repozitorijs ar rakstā izmantoto kodu atrodas Ŕeit.

Avots: www.habr.com

Pievieno komentāru