Autorius: admin

Kodėl log failai yra IT specialisto geriausias draugas

Kiekvienas, kas dirba su serveriais, aplikacijomis ar bet kokia sudėtingesne sistema, anksčiau ar vėliau susiduria su situacija, kai reikia išsiaiškinti, kas nutiko. Kodėl sistema lūžo 3 val. nakties? Kas užkrovė duomenų bazę? Kodėl vartotojai skundžiasi lėtu atsiliepimo laiku? Atsakymai į šiuos klausimus slypi log failuose – tose begalinėse teksto eilučių srovėse, kurios atrodo kaip Matrix kodas pradedantiesiems.

Log failai yra tarsi juodoji dėžė jūsų sistemai. Jie fiksuoja viską – nuo paprasčiausių informacinių pranešimų iki kritinių klaidų, kurios gali sugriaut visą infrastruktūrą. Problema ta, kad šių failų būna daug, labai daug. Vidutiniu dydžiu aplikacija gali generuoti gigabaitus logų per dieną, o jei kalbame apie mikroservisų architektūrą su dešimtimis ar šimtais servisų – skaičiai tampa tiesiog kosminiški.

Čia ir prasideda tikrasis iššūkis. Neužtenka tiesiog turėti logus – reikia mokėti juos analizuoti, stebėti ir, svarbiausia, iš jų išgauti vertingą informaciją. Tai ne tik reaktyvus procesas, kai ieškome problemų priežasčių po fakto, bet ir proaktyvus – kai stebime tendencijas ir pastebime anomalijas prieš joms virštant rimtomis problemomis.

Ką iš tiesų reiškia geras logavimas

Prieš kalbant apie analizę, verta suprasti, kas sudaro gerą logavimo praktiką. Deja, daugelis projektų šią dalį traktuoja kaip antraeilę – tiesiog išmeta console.log() ar print() sakinius kur papuola ir tikisi, kad tai padės ateityje. Spoileris: nepadės.

Geras logavimas prasideda nuo struktūros. Kiekvienas log įrašas turėtų turėti aiškų lygį (level) – DEBUG, INFO, WARNING, ERROR, CRITICAL. Tai ne tik teorinė klasifikacija, bet praktinis įrankis filtruoti ir prioritizuoti informaciją. Produkcijoje jums tikrai nereikia DEBUG lygio logų, kurie užpildo diskus nereikalinga informacija, bet jums tikrai reikia visų ERROR ir CRITICAL įrašų.

Kontekstas – štai kas daro logą iš tiesų naudingą. Pranešimas „Error occurred” yra visiškai nenaudingas. O štai „Failed to connect to database ‘users_db’ at 192.168.1.50:5432, connection timeout after 30s, user: api_service” – tai jau kažkas. Matote skirtumą? Antruoju atveju turite viską, ko reikia pradėti tyrimą: ką bandėte padaryti, kur, kada ir kokiu kontekstu.

Struktūrizuoti logai JSON formatu tapo de facto standartu šiuolaikinėse sistemose. Vietoj:

[2024-01-15 14:23:45] ERROR: User login failed for user [email protected] from IP 203.0.113.42

Geriau turėti:

{
  "timestamp": "2024-01-15T14:23:45.123Z",
  "level": "ERROR",
  "event": "user_login_failed",
  "user_email": "[email protected]",
  "ip_address": "203.0.113.42",
  "reason": "invalid_password",
  "attempt_number": 3
}

Tokį formatą nepalyginamai lengviau parsinti, indeksuoti ir analizuoti automatizuotomis priemonėmis.

Įrankiai, be kurių neišsiversite

Teorija teorija, bet praktikoje reikia konkrečių įrankių. Log analizės ekosistema yra plati, ir pasirinkimas priklauso nuo jūsų poreikių, biudžeto ir infrastruktūros dydžio.

ELK Stack (Elasticsearch, Logstash, Kibana) – tai klasika, kuri veikia ir veikia gerai. Logstash surenka logus iš įvairių šaltinių, apdoroja ir transformuoja juos, Elasticsearch indeksuoja ir saugo, o Kibana suteikia vizualizacijos sąsają. Šis derinys gali apdoroti milžiniškas log sroves, bet reikia žinoti, kad Elasticsearch gali būti išteklių ėdrus – RAM ir diskų jam niekada nebus per daug.

Praktinis patarimas: jei tik pradedate su ELK, naudokite Filebeat vietoj Logstash pradiniam log surinkimui. Filebeat yra daug lengvesnis ir paprastesnis, o Logstash palikite sudėtingesnėms transformacijoms, jei jų iš tiesų reikia.

Grafana Loki – tai santykinai naujas žaidėjas, kurį sukūrė Grafana Labs. Skirtingai nei Elasticsearch, Loki neindeksuoja log turinio, o tik metaduomenis (labels). Tai reiškia žymiai mažesnius išteklius, bet ir tam tikrus apribojimus paieškos galimybėse. Jei jau naudojate Grafana metrikoms, Loki natūraliai integruojasi į tą pačią ekosistemą.

Graylog – dar viena populiari open-source alternatyva, kuri siūlo gerą balansą tarp funkcionalumo ir paprastumo. Turi įtaisytą MongoDB metaduomenims ir Elasticsearch logams, plius neblogą web sąsają iš dėžės.

Debesų pasaulyje turime specializuotus sprendimus: AWS CloudWatch Logs, Google Cloud Logging, Azure Monitor. Jie puikiai integruojasi su atitinkamomis platformomis, bet gali tapti brangūs, kai log kiekiai auga. Būtinai sukonfigūruokite retention policies ir filtrus, kad nesaugotumėte visko amžinai.

Kaip iš tiesų analizuoti logus efektyviai

Turite įrankius, logai plaukia – kas toliau? Čia prasideda tikrasis darbas. Pirmiausia – niekada, girdite, NIEKADA nebandykite analizuoti logų tiesiog skaitydami juos teksto redaktoriuje. Tai kelias į beprotnamį, ypač kai failai siekia gigabaitus.

Pradėkite nuo agregatų ir statistikos. Užuot žiūrėję į individualius įrašus, pažiūrėkite į bendrus šablonus. Kiek ERROR lygio pranešimų per valandą? Kaip tai keičiasi laike? Kokios yra dažniausios klaidos? Elasticsearch ir Kibana čia puikiai tinka – galite sukurti agregacijas pagal bet kokį lauką ir vizualizuoti rezultatus.

Pavyzdžiui, jei matote, kad 500 klaidos staiga išaugo 10 kartų, tai akivaizdus signalas. Bet jei jos pamažu auga savaitę, galite to nepastebėti žiūrėdami į individualius įrašus.

Paieškos užklausos – išmokite jas gerai. Elasticsearch naudoja Lucene užklausų sintaksę, kuri labai galinga. Pavyzdžiui:

level:ERROR AND service:payment AND timestamp:[now-1h TO now]

Ši užklausa suranda visas klaidas payment servise per paskutinę valandą. Galite pridėti wildcard simbolius, reguliarias išraiškas, range užklausas – galimybės beveik begalinės.

Koreliacijos – tai sudėtingesnė, bet labai vertinga technika. Dažnai problemos priežastis slypi ne viename servise, o keliuose. Pavyzdžiui, API grąžina timeout, nes duomenų bazė lėta, o duomenų bazė lėta, nes cache servisas neveikia. Norint tai pamatyti, reikia koreliuoti logus iš skirtingų šaltinių.

Čia labai padeda correlation ID – unikalus identifikatorius, kuris perduodamas per visą request chain. Kai vartotojas daro užklausą, ji gauna ID, kuris įrašomas į logus kiekviename servise, per kurį praeina. Vėliau galite surasti visus su ta užklausa susijusius logus visose sistemose.

Alertai ir proaktyvus stebėjimas

Analizė post-factum yra naudinga, bet dar geriau – sužinoti apie problemas iš karto, kai jos atsiranda, arba net prieš joms tampant kritinėmis. Čia į žaidimą įeina alerting sistema.

Pagrindinis principas – ne per daug alertų. Jei gaunate 50 email’ų per dieną apie įvairias smulkmenas, greitai pradėsite juos ignoruoti, ir praleisite tikrą problemą. Alert fatigue yra reali problema daugelyje organizacijų.

Sukurkite alertus tik tikrai svarbiems dalykams:
– Kritinės klaidos, kurios tiesiogiai veikia vartotojus
– Neįprasti kiekių pokyčiai (pvz., klaidų skaičius išaugo 5x per 5 minutes)
– Sistemos išteklių problemos (disko vieta baigiasi, memory leaks)
– Security incidentai (nepavykę login bandymai iš neįprastų vietų)

Naudokite threshold-based ir anomaly-based alertus. Pirmieji suveikia, kai kažkas viršija nustatytą ribą (pvz., >100 klaidų per minutę). Antrieji naudoja machine learning aptikti nukrypimus nuo normalaus elgesio – tai gali pagauti problemas, kurių nenumatėte.

Kibana, Grafana ir kiti įrankiai turi įtaisytus alerting mechanizmus. Pavyzdžiui, Elasticsearch Watcher leidžia sukurti sudėtingas taisykles:

{
  "trigger": {
    "schedule": { "interval": "5m" }
  },
  "input": {
    "search": {
      "request": {
        "indices": ["logs-*"],
        "body": {
          "query": {
            "bool": {
              "must": [
                { "match": { "level": "ERROR" }},
                { "range": { "@timestamp": { "gte": "now-5m" }}}
              ]
            }
          }
        }
      }
    }
  },
  "condition": {
    "compare": { "ctx.payload.hits.total": { "gt": 50 }}
  },
  "actions": {
    "send_email": {
      "email": {
        "to": "[email protected]",
        "subject": "High error rate detected",
        "body": "Found {{ctx.payload.hits.total}} errors in last 5 minutes"
      }
    }
  }
}

Šis watcher kas 5 minutes tikrina, ar nėra daugiau nei 50 klaidų, ir jei yra – siunčia email.

Log retention ir valdymo strategijos

Logai užima vietą. Daug vietos. Jei nesukonfigūruosite retention politikų, greitai pamatysite, kad jūsų diskai pilni, o sistemos pradeda lūžti. Tai ne teorinė problema – tai nutinka realybėje, ir dažniau nei galite pagalvoti.

Sukurkite tiered retention strategiją:
– Hot tier (greitas prieigos): paskutinių 7-14 dienų logai, saugomi SSD, pilnai indeksuoti
– Warm tier (vidutinis): 15-90 dienų logai, gali būti lėtesniuose diskuose, sumažinta replication
– Cold tier (archyvas): 90+ dienų logai, compressed, galbūt S3 ar panašioje object storage

Ne visi logai vienodai svarbūs. DEBUG lygio logai iš development aplinkos gali būti ištrinti po savaitės. Production ERROR logai turėtų būti saugomi ilgiau – bent kelis mėnesius, o kartais ir metus (priklausomai nuo compliance reikalavimų).

Elasticsearch Index Lifecycle Management (ILM) leidžia automatizuoti šį procesą. Galite sukurti politiką, kuri automatiškai perkelia senus indeksus į warm tier, vėliau į cold, ir galiausiai ištrina:

PUT _ilm/policy/logs_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50GB",
            "max_age": "1d"
          }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "shrink": { "number_of_shards": 1 },
          "forcemerge": { "max_num_segments": 1 }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "freeze": {}
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Saugumo aspektai ir compliance

Logai dažnai turi jautrią informaciją. Vartotojų IP adresai, email’ai, kartais net autentifikacijos tokenai ar kreditinių kortelių duomenys (nors to tikrai neturėtų būti). GDPR ir kiti privatumo reglamentai reikalauja atsakingo požiūrio į tokius duomenis.

Pirmiausia – niekada neloginkite slaptažodžių, tokenų ar kitų credentials. Tai atrodo akivaizdu, bet vis dar matau projektų, kur tai nutinka. Jei jau atsitiko – turite procesą tokiems logams išvalyti ar ištrinti.

Naudokite log masking ar redaction technikas. Daugelis log processing įrankių leidžia automatiškai aptikti ir užmaskuoti jautrius duomenis. Pavyzdžiui, Logstash gali naudoti grok patterns su mutate filter:

filter {
  mutate {
    gsub => [
      "message", "\d{16}", "****-****-****-****",
      "message", "[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}", "***@***.***"
    ]
  }
}

Access control – ne visi turėtų matyti visus logus. Production logai su vartotojų duomenimis turėtų būti prieinami tik tam tikriems žmonėms. Elasticsearch turi role-based access control (RBAC), kurį būtina sukonfigūruoti.

Audit logai – tai meta-logai, kurie fiksuoja, kas prieina prie log sistemų, ką ieško, ką eksportuoja. Jei turite compliance reikalavimus (PCI DSS, HIPAA, SOC2), audit trail yra privalomas.

Realūs scenarijai ir troubleshooting patarimai

Teorija baigėsi, dabar keletas praktinių scenarijų iš realaus gyvenimo.

Scenarijus 1: Lėtas API response

Vartotojai skundžiasi, kad aplikacija lėta. Žiūrite į API logus ir matote, kad response time’ai normalūs. Kur problema? Pradėkite nuo pilno request lifecycle:

1. Patikrinkite load balancer logus – gal problema ten?
2. Pažiūrėkite į aplikacijos logus su timestamp’ais – kiek laiko užtrunka kiekvienas žingsnis?
3. Duomenų bazės logai – gal slow queries?
4. Network latency – gal problema tarp servisų?

Naudokite distributed tracing (Jaeger, Zipkin) kartu su logais. Tai leidžia matyti visą request kelią su timing’ais kiekviename etape.

Scenarijus 2: Intermittent failures

Blogiausias scenarijus – klaida, kuri pasirodo retai ir neprognozuojamai. Čia reikia kantrybės ir metodiškumo:

1. Surinkite VISUS klaidų atvejus per ilgesnį laiką (savaitę ar dvi)
2. Ieškokite šablonų – gal klaida atsiranda tam tikru laiku? Tam tikrais serveriais? Tam tikrais vartotojais?
3. Koreliuokite su kitais įvykiais – deployment’ais, traffic spike’ais, infrastructure changes
4. Pridėkite papildomo logavimo aplink įtartiną kodą

Kartais problema slypi ne kode, o infrastruktūroje – network glitches, disk I/O spikes, memory pressure. Koreliuokite application logus su system metrics.

Scenarijus 3: Security incident

Pastebėjote neįprastą aktyvumą – daug failed login attempts iš skirtingų IP. Kaip reaguoti?

1. Greitai identifikuokite scope – kiek accountų paveikta, iš kur atakuojama
2. Patikrinkite, ar kurie nors bandymai pavyko
3. Pažiūrėkite, ar po sėkmingų login’ų buvo neįprasto aktyvumo
4. Implementuokite rate limiting, jei dar neturite
5. Dokumentuokite viską – incident response reikalauja detalių

Elasticsearch agregacijos čia labai padeda:

GET logs-*/_search
{
  "size": 0,
  "query": {
    "bool": {
      "must": [
        { "match": { "event": "login_failed" }},
        { "range": { "@timestamp": { "gte": "now-1h" }}}
      ]
    }
  },
  "aggs": {
    "by_ip": {
      "terms": { "field": "ip_address", "size": 100 },
      "aggs": {
        "by_user": {
          "terms": { "field": "username", "size": 100 }
        }
      }
    }
  }
}

Kai logai tampa per dideli problemai

Galiausiai, kalbėkime apie tai, kas nutinka, kai jūsų log infrastruktūra išauga iki tokio dydžio, kad pati tampa problema. Tai nutinka dažniau nei galvojate – sėkmingos kompanijos auga, traffic auga, logų auga eksponentiškai.

Sampling – ne visada reikia loginti viską. Jei turite milijonus užklausų per minutę, galbūt užtenka loginti 1% ar 10%? Svarbiausia – loginti visas klaidas ir neįprastus atvejus, bet normalūs success case’ai gali būti samplinami. Daugelis framework’ų palaiko adaptive sampling, kur sample rate priklauso nuo situacijos.

Structured logging libraries – naudokite gerus įrankius. Python’e – structlog, Java – Logback su logstash-logback-encoder, Node.js – winston ar pino. Šie įrankiai padeda išlaikyti konsistenciją ir efektyvumą.

Centralizuotas konfigūravimas – kai turite šimtus servisų, nenorite keisti log level’ų kiekviename atskirai. Naudokite centralizuotą configuration management (Consul, etcd) arba feature flags sistemą, kuri leidžia dinamiškai keisti log settings be redeploy.

Cost optimization – debesų logging servisai gali tapti labai brangūs. Reguliariai peržiūrėkite, ką loginate ir ar tai tikrai reikalinga. Kartais paprasta kodo optimizacija, kuri sumažina verbose logging, gali sutaupyti tūkstančius per mėnesį.

Pagaliau – mokykite komandą. Geriausios logging įrankiai ir praktikos nieko nereiškia, jei developeriai nemoka jų naudoti. Code review turėtų įtraukti logging kokybės vertinimą. Dokumentuokite savo logging standartus ir įsitikinkite, kad visi juos žino.

Log failų analizė ir stebėjimas nėra vienkartinis projektas – tai nuolatinis procesas, kuris evoliucionuoja kartu su jūsų sistema. Pradėkite nuo pagrindų, laipsniškai pridėkite sudėtingesnių dalykų, ir svarbiausia – išmokite skaityti savo sistemą per jos logus. Tai įgūdis, kuris atsipirks šimtus kartų, kai 3 val. nakties reikės išsiaiškinti, kodėl viskas sudužo, ir greitai viską pataisyti.