Dnevnik strežnika pogosto pokaže tudi zahteve, ki jih statistika obiskov ne prikaže. Analiza dnevnikov spletnega strežnika pokaže, katere strani ali datoteke so bile zahtevane, kdaj je bila zahteva in katero kodo odgovora HTTP je dobila. Koda 200 označuje uspešen dostop, 404 pa zahtevano stran, ki ne obstaja.

Če iščeš napako ali želiš razumeti, kaj pregledujejo iskalni roboti, ti dnevnik spletnega strežnika da podrobne sledi. Vsak vnos lahko zabeleži zahtevo, ki je prišla na strežnik, vključno z zahtevami robotov. Polje user-agent lahko pomaga prepoznati vrsto zahteve, samo po sebi pa ne dokazuje, da jo je res poslal imenovani robot.

V nadaljevanju spoznaš pomembna polja vnosov v dnevnik in pomen najpogostejših kod HTTP ter v čem se dnevnik strežnika razlikuje od spletne analitike. Pregledamo, za kaj ga je mogoče uporabiti pri preučevanju prometa robotov in kdaj je smiselno izbrati preglednico ali orodje za obdelavo dnevnikov. Tako natančneje vidiš, kaj se dogaja na strežniku in katere napake zahtevajo pozornost.

Preverjanje kod odgovora HTTP

Spletni strežnik brskalniku pošlje odgovor HTTP, koda stanja pa sporoča, kaj se je zgodilo z zahtevo. Kodo v dnevniku razlagaj skupaj s prizadetim URL-jem, časom in zahtevo.

Z vidika GDPR lahko naslov IP ali drug identifikator v dnevniku vsebuje osebne podatke. Zato je treba namen obdelave, dostop in hranjenje urejati omejeno in pregledno. Tudi v Sloveniji ti vidiki varstva podatkov usmerjajo ravnanje z dnevniki spletnega strežnika.

Med tveganja hranjenja dnevnikov spadata nepooblaščen dostop in predolgo hranjenje. Zmanjšaj ju z omejitvijo pravic dostopa, zaščito shranjenih podatkov in odstranjevanjem nepotrebnih podatkov dnevnikov.

Odgovori HTTP in kode odgovora

Odgovor HTTP je odgovor strežnika na zahtevo brskalnika ali drugega odjemalca, koda stanja pa povzame njegov izid. Koda 200 pomeni uspešen dostop, 301 trajno, 302 pa začasno preusmeritev. Njihovo preverjanje pomaga ugotoviti, ali uporabnik pride na pričakovano stran ali pa potuje po napačni poti preusmeritev.

Analiza kod napak HTTP

Analiza kod napak HTTP je razkrivanje vrste in pogostosti napačnih zahtev v vnosih dnevnika. Po podatkih organizacije Internet Assigned Numbers Authority (IANA) kode stanja 4xx označujejo napako odjemalca, kode 5xx pa napako strežnika, zato je z njimi mogoče izmeriti porazdelitev napak. Koda 404 označuje zahtevano stran, ki ne obstaja, 503 pa začasno nedosegljiv strežnik. Preveri tudi prizadete URL-je in čase.

V praksi vnose najprej razvrsti po kodi stanja, nato poišči, katere datoteke ali strani se ponavljajo. Odgovor 404 lahko na primer izvira iz tipkarske napake, odstranjene vsebine ali napačne notranje povezave. Ponavljanje odgovorov 503 pa lahko kaže na težavo z dosegljivostjo na strani strežnika. Koda stanja sama po sebi ne razkrije sprožilnega vzroka, zato jo preučuj skupaj s časovnim žigom in prizadeto zahtevo.

Idealna koda odgovora HTTP za strani spletnega mesta je 200 ali 301. Če stari naslov premaknjene strani vrne 404, preveri pravilo preusmeritve. Preusmeritev z meta osvežitvijo z vidika SEO ni priporočljiva, namesto nje je priporočena trajna preusmeritev 301. Slabo usmerjena preusmeritev lahko uporabnika zavede, tudi če koda napake ne nastane, zato preveri tudi ciljno stran.

Dnevniki strežnika Apache HTTP Server

Dnevnik dostopa strežnika Apache HTTP Server je mogoče uporabiti za preučevanje zahtev in odgovorov. V sistemih Debian in Ubuntu je privzeto mesto dnevnika /var/log/apache2/access.log, v sistemih RHEL, Red Hat, CentOS in Fedora pa /var/log/httpd/access_log. V sistemu FreeBSD je datoteka na mestu /var/log/httpd-access.log. Poznavanje prave poti pomaga hitro najti vnos določene zahteve.

V dnevniku Apache poišči prizadeti čas, URL in kodo stanja HTTP ter jih primerjaj s podobnimi zahtevami. Če na primer ista stran večkrat vrne 404, preveri, ali se je naslov strani spremenil ali je datoteka res dostopna. Med drugim lahko tudi časovni vzorec ponavljajočih se odgovorov 5xx pomaga ločiti občasno napako od trajne težave s strežnikom.

Prepoznavanje iskalnih robotov in omejitve user-agenta

Spletni strežnik sprejema in obdeluje zahteve HTTP, ki prihajajo nanj, nato pa odjemalcu pošlje odgovor. Iz vnosov v dnevnik lahko preučiš, katere strani so zahtevali iskalni roboti, kako pogosto so se vračali in koliko časa je trajalo pregledovanje.

Obhod spletnega mesta z iskalnimi roboti

Preučevanje obhoda spletnega mesta z iskalnimi roboti pomeni pregled zahtev, ki jih roboti pošiljajo strežniku. Pokaže, katere URL-je obhodijo, in pomaga opaziti, če pomembna vsebina izpade ali je pozornost usmerjena na napačne naslove. Dnevnik lahko zabeleži vsako zahtevo, ki dejansko doseže strežnik, tudi zahteve robotov.

Vnose poišči po polju user-agent, nato primerjaj časovne žige in zahtevane URL-je. Če robot na primer redno zahteva isti naslov, preveri, ali je stran dostopna in ali strežnik vrne pričakovani odgovor. Če dnevnik vsebuje tudi zahteve brskalnikov uporabnikov, lahko narava in ponavljanje zahtev pomagata razlikovati promet.

Analiza pregledovanja z iskalnimi roboti

Analiza pregledovanja pokaže vzorec obhoda na podlagi strani, ki so jih zahtevali roboti, pogostosti zahtev in časa obdelave. To je koristno, ker pokaže, čemu robot namenja pozornost in kje se lahko pojavi tehnična ovira. V dnevniku je lahko trajanje pregledovanja navedeno tudi v milisekundah.

Zahteve razvrsti po družinah URL-jev, na primer po straneh izdelkov, slikah ali rezultatih iskanja. Nato preveri, ali se roboti vračajo na iste strani in ali pridejo do pomembnih vsebin. Če v dnevniku vidiš veliko neveljavnih ali malo vrednih naslovov, lahko iz vnosov ugotoviš, na katere URL-je so usmerjene zahteve. Vzorec pokaže tudi, ali je obhod sestavljen iz hitrih, kratkih zahtev ali daljših postopkov streženja.

Omejitve user-agenta

User-agent je besedilni identifikator v zahtevi HTTP, ki imenuje brskalnik ali programsko opremo, ki se predstavlja kot robot. Je koristno merilo za filtriranje, samo po sebi pa ne potrjuje pravega izvora zahteve. Besedilo »Googlebot« v vrstici dnevnika je zato le namig, ne verodostojen dokaz, da je zahtevo res poslal Googlov robot.

Pri ocenjevanju ne upoštevaj le tega polja. Primerjaj pot, časovno porazdelitev in odgovore strežnika za zahteve, označene s tem identifikatorjem. Če user-agent kaže na robota, zahteve pa ponavljajo nenavadne strani, to obravnavaj kot promet, ki ga je treba posebej preučiti. Iz dnevnika je mogoče zanesljivo ugotoviti, kakšno zahtevo HTTP je spletni strežnik prejel in kakšen odgovor je dal, ne pa nujno, kdo je stal za zahtevo.

S programom za analizo dnevnikov lahko hkrati filtriraš vrednosti user-agent, URL-je in časovne žige. Tako lahko zahtevo, prepoznano kot robot, primerjaš z dejansko zahtevano stranjo in odzivnim časom. Analiza dnevnikov spletnega strežnika omogoči pregled vzorcev obhoda, identifikatorje pa je še vedno treba razlagati previdno.

Orodja za obdelavo dnevnikov: preglednice, Splunk, Sumo Logic in Elastic Stack

Za analizo dnevnikov Apache in Nginx najprej poišči pravo datoteko, nato izberi orodje, ki ustreza količini dnevnika. Manjše datoteke lahko filtriraš tudi s preglednico; za obdelavo velike količine podatkov o dostopu do spletnega strežnika je smiseln sistem za analizo dnevnikov.

Pri pregledu dnevnikov Apache in Nginx najprej prepoznaj datoteko, nato izberi obdobje, filtriraj po URL-jih ali kodah stanja in na koncu primerjaj ponavljajoče se vnose. Pri Apachu je mesto dnevnika odvisno od sistema, pri Nginxu pa je privzeta mapa var/log/nginx/.

Manjše datoteke dnevnikov lahko obdelaš in razčleniš tudi v Excelu. Splunk, Sumo Logic in Elastic Stack so orodja za obdelavo dnevnikov, ki lahko pomagajo pri pregledu večjih količin podatkov. Izbira je odvisna od velikosti dnevnika ter od potrebnih filtrov, iskanj in povzetkov.

Preglednica za majhne datoteke. Če oblika to dopušča, polja dnevnika v Excelu razporedi v stolpce. Nato vrstice filtriraj na primer po URL-ju ali kodi stanja HTTP in povzemi ponovitve. Tako hitro pregledaš, kateri vnosi se nanašajo na izbrano datoteko ali stran. Pri veliki datoteki postaneta ročno razvrščanje in filtriranje okorna, zato je smiselno uporabiti specializiran analizator dnevnikov.

Specializirani sistemi za večje nabore podatkov. Splunk, Sumo Logic in Elastic Stack je mogoče uporabiti za iskanje, filtriranje in pregleden prikaz dnevnikov. Če na primer iščeš določen URL, lahko primerjaš zahteve, zabeležene v dnevnikih Apache ali Nginx. Filtriranje po kodi stanja pomaga ločiti napačne odgovore od uspešnih. Pri izbiri orodja upoštevaj, kako pridejo podatki vanj, po katerih poljih zna iskati in katere povzetke potrebuješ.

Način obdelave je odvisen tudi od oblike datoteke. V preglednici lahko napačno razumevanje ločil polj ali narekovajev zamakne podatke. Na podlagi nekaj izvirnih vrstic dnevnika preveri, ali so čas, zahtevani naslov in koda odgovora v ločenih poljih. V iskalnih sistemih enotna imena polj omogočajo primerjavo vnosov Apache in Nginx.

Analizo začni z ozkim vprašanjem: katere zahteve so prišle za določeno stran in kakšen odgovor jim je dal spletni strežnik? Nato iskanje razširi na druge URL-je ali obdobja. Tako lahko napako, opaženo v brskalniku, primerjaš s pripadajočo vrstico dnevnika in opažanje lažje povežeš s konkretnim odgovorom strežnika.

Način obdelave prilagodi velikosti dnevnika. Manjše datoteke dnevnikov lahko prebereš in razčleniš tudi z običajnimi programi za obdelavo podatkov, na primer z Excelom. Najprej preveri, ali so polja pravilno ločena, nato podatke razvrsti in filtriraj po merilu, povezanem s preučevanim vprašanjem. Pregled ostane obvladljiv, če iskanja ne razširiš takoj na vse vnose, temveč se osredotočiš na izbrani URL, kodo odgovora ali obdobje. Rezultate primerjaj tudi z izvirnimi vrsticami dnevnika, tako lažje opaziš, če si polja razumel napačno. Pri veliki količini podatkov o dostopu do strežnika namesto ročne analize potrebuješ specializirano orodje. Njegove možnosti iskanja in filtriranja lahko pomagajo pri pregledu podatkov, enotna imena polj pa olajšajo primerjavo vnosov Apache in Nginx. Preden se lotiš širše analize, oblikuj, na katero vprašanje pričakuješ odgovor, in preveri, ali izbrana polja zanj dajo dovolj informacij. Če ne, spremeni iskanje ali povzetek in znova preglej ustrezne vnose. Tako metodo prilagodiš velikosti dnevnika in namenu analize.

Razumevanje polj formata Common Log Format

Analiza dnevnikov spletnega strežnika je preučevanje vnosov zahtev v dnevnik, ki pokaže, katere podatke je strežnik postregel. Datoteke dnevnika lahko zabeležijo datum, čas, zamik časovnega pasu, naslov IP ali DNS, zahtevo, kodo odgovora in velikost podatkov. Obisk lahko oceniš s povzemanjem zahtev; odzivni čas lahko meriš le, če dnevnik vsebuje tudi to polje. Stopnjo napak izračunaš s primerjavo napačnih in vseh zahtev.

Polja formata Common Log Format

Common Log Format je standard beleženja, ki ga uporabljajo spletni strežniki in zahteve prikazuje v enotnem vrstnem redu polj. Zato lahko poiščeš, kdo, kdaj in katero vsebino je zahteval, nato pa zahtevo primerjaš z odgovorom strežnika.

V vnosu je naslov lahko naslov IP ali DNS, čas pa se lahko prikaže z zamikom časovnega pasu. Polje zahteve lahko vsebuje pot in uporabljeni protokol. Poleg kode odgovora je lahko navedena tudi velikost postreženega objekta v bajtih. Če ta polja preučuješ skupaj, lahko na primer ločiš zahtevo strani od prenosa večje datoteke.

Pri branju formata pojdi od leve proti desni: najprej prepoznaj čas in zahtevani naslov, nato kodo odgovora. Nato preveri velikost podatkov. Če v vrstici vidiš nepričakovano veliko vrednost, poglej, katera stran ali datoteka spada k njej. Natančen nabor polj je lahko odvisen tudi od nastavitev beleženja.

Vsebina dnevnikov spletnega strežnika

Dnevnik spletnega strežnika je sestavljen iz posameznih vrstic zahtev s časovnim žigom, zato pokaže dostop do strani in datotek na strani strežnika. To olajša iskanje napak, saj je vnose mogoče analizirati tudi brez kode JavaScript in piškotkov.

Dnevnik lahko vsebuje naslov IP ali DNS obiskovalca, čas zahteve, zahtevani vir, protokol prenosa, količino prenesenih podatkov in vrsto brskalnika. Beleženje spletnega strežnika lahko zabeleži tudi datoteke, shranjene na strežniku in nato prenesene. Tako je na primer mogoče preveriti, ali je strežnik postregel sliko ali dokument.

Vnosa v dnevnik ni nujno mogoče pripisati eni osebi ali enemu obisku. Isti naslov IP lahko uporablja več obiskovalcev, dinamični naslov IP pa se lahko sčasoma spremeni. Poleg tega se dostop iz predpomnilnika brskalnika ali prek posredniškega strežnika ne pojavi nujno v dnevniku, ki beleži neposredne dostope do strežnika. Zato število vrstic dnevnika samo po sebi ne pokaže števila edinstvenih obiskovalcev.

Obisk, odzivni čas in stopnja napak

Iz dnevnika je mogoče povzeti število in porazdelitev zahtev, kar daje pogled na obisk s strani strežnika. Skupno število zahtev pa ni enako številu edinstvenih obiskovalcev, saj lahko nalaganje ene strani sproži več zahtev po datotekah.

Za analizo odzivnega časa je potrebno polje dnevnika, ki beleži trajanje streženja. Med osnovnimi polji formata Common Log Format takšnega podatka ni, zato preveri, ali ga beleži razširjeno beleženje spletnega strežnika. Če je trajanje v dnevniku, je z razvrščanjem po URL-jih mogoče razkriti, katere strani se strežejo dlje.

Za stopnjo napak primerjaj število napačnih odgovorov s številom vseh zahtev v istem obdobju. Kode 4xx označujejo napako odjemalca, kode 5xx napako strežnika. Ločen povzetek odgovorov 404 in vseh zahtev na primer pokaže, v kolikšnem deležu se je pojavila stran, ki je ni bilo mogoče najti. Rezultat razčleni naprej po URL-ju in času, da vidiš, ali je napaka vezana na en sam naslov ali na več strani.

Razlike med dnevniki strežnika in podatki spletne analitike

Dnevnik strežnika beleži posamezne zahteve, ki prihajajo na spletni strežnik, spletna analitika pa povzema vedenje obiskovalcev. Dnevniki dajo neposredne podatke o vsebinah, ki jih je postregel strežnik, zato se v njih lahko pojavijo tudi zahteve robotov in prenosi datotek. Analitično merjenje pa pogosto uporablja kodo JavaScript ali piškotke.

Dnevnike strežnika hrani, dokler so potrebni za iskanje napak in upravljanje. Potreba po prostoru raste s prometom in količino zabeleženih zahtev. Na spletnih straneh z velikim obiskom lahko datoteke hitro rastejo, zato utegne biti potreben dodaten vir za shranjevanje podatkov.

Vira podatkov odgovarjata na različna vprašanja. Dnevnik kaže, kakšno zahtevo je spletni strežnik prejel in kakšen odgovor je dal nanjo. Spletna analitika lahko prikaže tudi vedenjske kazalnike, kot je stopnja obiskov ene strani, ki je dnevnik strežnika sam po sebi ne poda. Dnevniki zato dopolnjujejo analizo, niso pa edini vir za preučevanje vedenja obiskovalcev.

Datoteka dnevnika je sestavljena iz posameznih vrstic zahtev s časovnim žigom. Odprtje ene same strani lahko ustvari več vrstic, saj lahko brskalnik pošlje ločeno zahtevo na primer za slike, slogovne datoteke in druge datoteke. Zato število vrstic ali zahtev samo po sebi ni enako številu ogledov strani ali edinstvenih obiskovalcev. V dnevniku spletnega strežnika se lahko pojavijo tudi zahteve robotov.

Dnevnik lahko pokaže tudi dogodke na strani strežnika, ki jih merjenje na osnovi JavaScripta ne zabeleži. Pregled postreženih datotek in neposrednih zahtev lahko na primer pomaga ugotoviti, ali je strežnik postregel dokument PDF ali sliko. Dostopi iz predpomnilnika brskalnika ali prek posredniškega strežnika pa se ne pojavijo nujno v dnevniku, ki beleži neposredne dostope do strežnika.

Tudi dinamična dejanja na strani se ne pojavijo vedno kot ločen vnos v dnevnik. Dejanje AJAX lahko pride v dnevnik strežnika, če sproži dejansko zahtevo na strežnik; sprememba, izvedena le v brskalniku, ne pomeni novega dostopa do strežnika. Za popolnejše razumevanje dejanj obiskovalcev je zato vredno dnevnik in podatke spletne analitike razlagati skupaj.

Tudi na podlagi naslovov IP ni mogoče vedno natančno določiti števila obiskovalcev. Dinamični naslovi IP se lahko spreminjajo, isti naslov IP pa lahko uporablja več uporabnikov. Povzetke obiskovalcev, izdelane iz prometa v dnevniku, je zato vredno razlagati previdno. Za zanesljivo razlago podatkov ločeno obravnavaj zahteve, obiske in ocene, ki se nanašajo na edinstvene uporabnike.

Pri praktični preiskavi najprej določi, ali želiš analizirati tehnično napako, streženje datotek ali vedenje obiskovalcev. Nato izberi ustrezen vir podatkov: za preučevanje kod napak in zahtev na strežnik uporabi dnevnik, za vedenjske kazalnike pa spletno analitiko. Z uskladitvijo obdobja in prizadetih strani lahko oba pogleda primerjaš, ne da bi število zahtev štel za število obiskovalcev.

Pri analizi dnevnikov spletnega strežnika je pomembno imeti v mislih, da število zahtev ni enako številu edinstvenih obiskovalcev. Dejanja AJAX na strani se ne pojavijo nujno v datoteki dnevnika, če niso povezana z dejansko zahtevo na strežnik; pri dinamičnih naslovih IP ali več obiskovalcih z istim naslovom IP so lahko podatki o prometu iz datotek dnevnika netočni, kar opažajo tudi strokovnjaki aWh.

aWh: spletno gostovanje

aWh ponuja spletno gostovanje za delovanje spletnih strani. Če moraš na podlagi analize dnevnikov preveriti okolje streženja ali razpoložljive vire, je lahko naslednji korak tudi izbira ustreznega gostovanja.

Prava rešitev je odvisna od potreb. Za delovanje spletne strani je lahko pomembno spletno gostovanje, KVM VPS pa zagotavlja drugačno strežniško okolje. V ponudbi aWh sta na voljo tudi registracija domen in Windows VPS. Pri izbiri upoštevaj, v kakšnem okolju teče tvoja spletna stran in katere naloge želiš opravljati.

Oglej si rešitve spletnega gostovanja aWh ali obišči stran www.awh.hu.

Naredi analizo dnevnikov za sledljivo prakso

Analiza dnevnikov spletnega strežnika pomaga pri odločitvah, če iz opažanj sledi konkretna naloga. Zapiši, katere napake se ponavljajo, katere zahteve so nenavadne in kako se vzorec dnevnika spremeni po posamezni spremembi. Tako lahko primerjaš delovanje strežnika in ciljno iščeš vzroke težav.

Vzpostavi postopek, v katerem imajo do dnevnikov dostop le pooblaščeni, analiza pa se prilagaja namenu upravljanja. Če bi na podlagi rezultatov preveril tehnično okolje svoje spletne strani, razmisli, katere vire in nastavitve potrebuješ za stabilno delovanje.

Če želiš pregledati naslednji tehnični korak, stopi v stik z aWh. Dosledno iskanje napak, ki izhaja iz vnosov v dnevniku, ti lahko pomaga načrtovati bolj utemeljeno.

Pogosta vprašanja o dnevnikih strežnika

Kako delujejo dnevniki strežnika?

Spletni strežnik beleži dogodke dohodnih zahtev, upravljavec pa jih lahko uporabi za iskanje napak ali preučevanje vzorcev delovanja. Če si po napaki naredil spremembo, zapiši njen čas, nato primerjaj vnose, nastale pred njo in po njej. Enoten časovni pas in beleženje sprememb olajšata povezovanje dogodkov.

Kje so dnevniki?

Dnevnike najdeš v nadzorni plošči gostovanja, v datotečnem sistemu strežnika ali v vmesniku za beleženje okolja delovanja. Poišči dnevnike dostopa in napak, nato preveri, ali so poleg trenutne datoteke tudi arhivirane ali stisnjene datoteke. Starejši dnevniki so pogosto shranjeni v ločeni datoteki. Če uporabljaš nadzorno ploščo, lahko razpoložljive vnose pokaže njen pregledovalnik dnevnikov.

Kaj je datoteka dnevnika (log file)?

Datoteka dnevnika je podatkovna datoteka, ki beleži dogodke za poznejši pregled. V okolju spletnega strežnika lahko nastaneta ločen dnevnik dostopa in dnevnik napak: prvi pomaga pregledati sledi zahtev, drugi pa težave, sporočene med delovanjem. Pri iskanju napak se najprej odloči, kateri dogodek iščeš, nato izberi ustrezen dnevnik. Kopija izvirne datoteke ohrani izhodiščno stanje preiskave.

Kaj hočejo roboti?

Namen robotov je odvisen od njihovega delovanja: nekateri zbirajo vsebino za indeks iskalnika, drugi samodejno preverjajo ali zahtevajo podatke. Iz dnevnika samega ni vedno mogoče ugotoviti namena avtorja, zato raje preuči vpliv na spletno mesto. Spremljaj, ali zahteve preobremenjujejo vire ali zadevajo poti, ki ne bi smele biti javne.

Katera orodja in programe je mogoče uporabiti za analizo dnevnikov spletnega strežnika?

Orodje prilagodi obliki dnevnika in načinu obdelave. V preglednici najprej preveri, ali so polja ustrezno ločena, nato uporabi filtre in razvrščanje. Pri Splunku, Sumo Logicu ali Elastic Stacku poenotenje polj olajša iskanje. Pri timskem delu so pomembni tudi upravljanje pravic, deljenje poizvedb in možnost iskanja po arhiviranih podatkih.

Kako poiščeš napake HTTP 4xx in 5xx in kateri so njihovi najpogostejši vzroki?

V dnevniku poišči zahteve, ki pripadajo napačnim odgovorom, in jih razvrsti po poti, času ali prizadeti funkciji. Ponavljajoč se odgovor 404 lahko na primer kaže na staro povezavo ali odstranjeno vsebino; preveri, ali se je naslov spremenil. Če napako vrne več strani hkrati, primerjaj njen pojav s posodobitvami konfiguracije ali vsebine, tako zožiš možne vzroke.

Kako na podlagi dnevnikov prepoznaš robote, napade in sumljiv promet?

Sumljive vzorce preuči s primerjavo več virov dnevnikov, na primer spletnih zahtev z dogodki preverjanja pristnosti. Posebno pozornost si zasluži, če v kratkem času veliko poskusov zadeva zaščitene funkcije ali če se po nenavadni zahtevi pojavi niz napak. Shrani izvirni dnevnik preučevanega obdobja, omeji dostop in opažanja dokumentiraj s časovnim žigom.

Katere brezplačne in plačljive storitve za analizo dnevnikov so na voljo in koliko stanejo?

Med orodji so preglednice in specializirani sistemi za obdelavo dnevnikov, na primer Splunk, Sumo Logic in Elastic Stack. Ne izbiraj le po imenu orodja: pretehtaj, kako pridejo dnevniki vanj, katere oblike je treba obdelati in kdo ima dostop do njih. Vredno je vnaprej določiti tudi potrebe po iskanju, arhiviranju in opozorilih, da se orodje ujema z vsakdanjim upravljanjem.

• nadzor
• napake http
• varstvo podatkov
• upravljanje strežnikov
• vodniki