Uus arendajasõbralikum veebilogide haldamise kord

Veebiserveri logide haldamise kord on Zone tarkvaraplatvormis läbimas ulatuslikku reformi, mis loob meie arendajatest klientidele uusi väärtuslikke võimalusi. Käesolevas blogipostis kirjutan uuest korraldusest lähemalt.

Uue korra kohaselt on Virtuaalserveri teenuse kliendi käsutuses reaalajas uuenevad veebiserveri logid. Kui varasemalt uuenes reaalajas vaid probleemide tuvastamiseks vajalik vealogi (Error Log) ning päringute logi pakkusime arhiivina, siis nüüdsest on klientide käeulatuses reaalajas uuenev päringute logi (Access Log).

Veebiserveri logid leiab klient Virtuaalserveri ‘logs’ kataloogist. Logimisel tehakse vahet turvamata ja turvatud ühendustel, mis salvestatakse eraldi failidesse (apache.ssl.access.log ja apache.access.log).

Virtuaalserveri alamdomeenide vea- ja päringulogid kombineeritakse peadomeeniga. Päringuid on võimalik logis üksteisest eristada sedaläbi, et iga rida algab seda konkreetset päringut teenindanud hosti nimega.

Veebiserveri logi kirje formaat põhineb Apache Combined Log’il. Kasuliku ja unikaalse lisavõimalusena paneme me PHP päringute puhul logisse kirja ka selle unikaalse identifikaatori ning PHP koodi töötlemisele kulunud aja (‘wallclock’ sekundites). Need aitavad arendajatel oma rakenduste jõudlust paremini monitoorida ning meil ühiselt probleeme ‘troubleshoot’-ida.

Juhin tähelepanu asjaolulule, et logiridade kronoloogiline järjestus ei ole absoluutne – aeglasemad päringud võivad järjestuses sattuda oma noorematest, kuid kiirematest sõsaratest tahapoole.

Logisid roteeritakse endiselt Zone poolt, kuid vaikimisi säilitatakse kliendi Virtuaalserveris nüüd viimase nelja päeva logisid. Need asuvad failides mille nimed on kujul apache.ssl.access.log.[1-4].gz. Eelmise päeva logi on seega alati failis apache.ssl.access.log.1.gz.

Kui kliendil on soovi oma logisid arhiveerida, siis on tal võimalik neid endale kopeerida enda seadistatud crontab’i töö abil, mis käivituks näiteks kell 00:10, arhiveeriks nii HTTP kui HTTPS logid ka kustutaks logid mis vanemad kui 30 päeva.

Cron-töö (parameetriks kataloog, mille all asub logs):

[[$D2ND_A]]/logs-archiver.sh [[$D2ND_A]]

logs-archiver.sh skript:

#!/usr/bin/env bash

if [ $# -lt 1 ]; then
  echo "Please provide base path"
  exit 2
fi

mkdir -p $1/logs-archive/

cp $1/logs/apache.access.log.1.gz $1/logs-archive/apache.access.log.$(date +%Y%m%d).gz
cp $1/logs/apache.ssl.access.log.1.gz $1/logs-archive/apache.ssl-access.log.$(date +%Y%m%d).gz
find $1/logs-archive/ -mtime +30 -delete

Alates PHP versioonist 7.0 logitakse meil sarnasel printsiibil ka PHP tegevust. Varasematesse PHP versioonidesse sellist logimise tuge meil ei tule, seega on viimane aeg PHP ‘retro’ versioonidest loobuda.

Vana korra järgi seadistatud klientidel on võimalik uuele logide kasutuskorrale üle minna vabatahtlikult Virtuaalserveri seadistuses tehtava valiku kaudu.

Uue logide haldamise korra opt-in

Ühel hetkel lõpetame vana korra toetamise ära, kuid see ajakava ei ole veel paigas.

UPDATE: Tasub veel ära mainimist, et muutunud on ka Apache vealogide (ErrorLog) nimetused on nüüd apache.error.log ja apache.ssl.error.log. Nende roteerimise kohta kehtib kõik ülaltoodu.

Miks mu veeb aeglane on? Vaata BlackFire abil järgi!

Enamus “server on aeglane” hädadest osutub lähemal uurimisel veebirakenduse koodi probleemideks – suur hulk andmebaasipäringuid, välise teenuse järel ootamine, ebaefektiivne tõlkelahendus vms.

Kuidas aga see kitsaskoht üles leida?

Esimene samm: väline monitooring

Minul on kombeks kõiki jõudlusprobleeme asuda lahendama kõige lihtsamast veebilehe monitooringust: pingdom.com teeb iga minut veebipäringu, joonistab vastamiseks kulunud ajast graafiku ning saadab e-postile teavituse, kui saab vea või vastus liiga kaua aega võtab*.

Kuvades lehtede või toodete lisandumisel kuude jooksul aeglasemaks muutuvat rakendust, võib tulemus olla näiteks selline:

Suur hulk probleeme on aga “jalutavad” – ehk enamiku ajast töötab veeb kiiresti, mingite sündmuste koosmõjul läheb aga aeglaseks:

Teine samm: mis toimub koodis?

Veebirakendustel on probleemide leidmiseks sageli omad lisad või pluginad, nt WordPressi puhul aitab Query Monitor kiiresti üles leida probleemsed andmebaasipäringud.

Visuaalsema pildi toimuvast annab aga BlackFire, mille PHP-laienduse saab Zone Virtuaalserveri puhul hõlpsalt sisse lülitada ja oma BlackFire kontoga siduda, kohaks Veebiserver » Peadomeeni Seaded (või Alamdomeenid) » Muuda » PHP laiendused:

Võrreldes rakenduste pidevaks monitooringuks mõeldud teenustega (nt NewRelic, mille saab meil muideks samast kohast aktiveerida) on BlackFire probleemide tuvastamise rollis oluliselt mõistlikuma hinnastusega – 19,90€ eest kuus saab endale “profileerija” konto, mida arendaja saab vabalt kasutada kõigi oma töös olevate (või ootamatult sisse sadavate) projektide puhul.

Kõige lihtsam viis profileerimiseks on Chrome laiendus – kui serveri poolel seadistus tehtud, lähed huvipakkuvale (alam)lehele ja vajutad nuppu. BlackFire kogub serveri poolel inffi ja saadab selle oma teenusesse, kus saad tulemust soovi korral teiste asjaosalistega jagada, näiteks nii.

Kuidas aga saadud tulemust lahti mõtestada? Võtame (anonüümselt) ette mõned reaalse elu juhtumid ja vaatame, kuidas probleemi otsimine käib. Alustuseks üks veeb, mis võiks vabalt olla Pingdomi juures mainitud “jalutava probleemi” graafikul kuvatu.

Probleem 1: veeb ootab välise päringu taga

Esimese asjana vaatan ma ülemist rida. Sedapuhku torkab kohe silma pea 3 sekundit, mis kulunud http-päringutele mingite väliste süsteemide pihta. Probleeme tekitav funktsioon on parempoolsel graafil kenasti punane ja sellele klikkides kuvatakse ka lisa-infot – kes teda kutsus, mida funktsioon tegi ja kelle poole edasi pöördus.

Sedapuhku kulub igal lehekuvamisel aega välise CRM-teenuse peale, kust kahel korral http-päringuga mingit infot laetakse. On seda infot ikka hädasti vaja? Miks tehakse kaks päringut? Miks see teenus aeglane on? Kas oleks võimalik vastust puhverdada? Kas selle päringu võiks teha kasutaja brauser pärast ülejäänud lehesisu laadimist?

3-sekundiline lehelaadimine on aga vaid väike osa probleemist – kui seda teeb server, kuhu külastajaid satub rohkem tulema (õnnestunud kampaania?), saab serveris lubatud PHP-protsesside arv varsti täis ning järgmised päringud peavad ootama eelmiste lõppemist.

Tehes käsurealt top avaneb siis selline pilt:

Virtuaalserveris on kasutajale lubatud kuni 15 PHP protsessi, Nutika Privaatserveri puhul võiks neid lubada niipalju kui klient soovib… aga (a) kui neid on rohkem kui protsessoril tuumasid ei lähe asi kuidagi kiiremaks (b) probleemi juurpõhjust ressurssidega loopimise meetodil ikkagi ei lahenda.

Sellised PHP käivitamise taga ootavad päringud näevad muideks BlackFire’is välja täiesti normaalsete sekundiliste vastustena – sest kuniks veebiserver (Apache) ootab vaba PHPd, ei ole ju ka mingit aega mõõta…

Ja kui PHPs tehtava päringu puhul on jäänud mõistliku pikkusega timeout seadistamata ning mõne lehe kuvamine hoiab PHP protsessi kinni 30 sekundit … siis pole kampaaniat vajagi. Probleemi avastamise teeb raskemaks see, kui aegavõtva päringu põhjustab suvaline alamleht (mida otsimootor parasjagu indekseerida proovib).

See on täpselt see probleem, mida tähistab üleval Pingdomi graafikul kell 14-15 algav küür. “Meie veebil” polnud häda midagi, aga üks teine veebiserver (või selle netiühendus) käis käntsu…

Probleem 2: meeletult SQL-päringuid

Tuhatkond andmebaasi-päringut pole küll mingi rekord – mulle meenub esileht, mille kuvamiseks tehti 12000 – aga väikseks rehkenduseks sobib hästi:

Oletame, et üks kiire andmebaasipäring võtab 2 millisekundit. Kui neid teha 1350 tükki, siis kulub sellega sahmerdamiseks … ligemale 3 sekundit. Lihtne soovitus – pea meeles,  et tuhandega korrutades saab millisekundist sekund.

Ülaloleval pildil on Magento otsingulehe kuvamine ning kuna see pole puhverdatud, siis on suur hulk päringuid paratamatu. Aga kui sa paned kampaania landing‘uks otsingulehe, siis võib see lisakoormus osutuda probleemseks.

Päris ilma cache’ta Magento 1.x kategoorialehe puhul on pilt selline, jõud kulub hulgast XMLidest konfiguratsiooni kokku ehitamisele:

Probleem 3: laeme kogu tabeli mällu ja siis sõõlame seda PHPs

Järgmine probleem on ilmselt esimese Pingdomi graafiku pideva kasvu taga – andmebaasi vastu tehakse küll vähe päringuid, aga küsitakse terve tabeli sisu ning siis asutakse seda PHPs läbi lappama. Näiteks selleks, et kuvada kategoorialehel 20tuh tootest järgmised 10:

Ole inime, ära tapa PHPd tööga, seda saab teha ka elektriga … st SQLiga. Kategooria lappamiseks sobiks nt LIMIT 10 OFFSET 1200.

Probleem 4: imetabased (ent indekseerimata) metaväljad ja andmebaas kui prügimägi

WordPressi puhul on tüüpilisemaks probleemiks pluginad, mis hoiavad oma andmeid post_meta tabelis ning teevad selle pihta imetabaseid päringuid. TOP-3 võiks olla selline:

  • Advanced Custom Fields – mugav viis lisada postitusele lisainfot või kindla vormindusega sisublokke. Aga selle peale ei tasu ehitada suuremat andmebaasilahendust, mis teeb otsinguid meta-väljade sisu kasutades. Mis ei ole vaikimis teps mitte indekseeritud (indeksi lisamine parandab olukorda mõnevõrra, aga mistahes andmetüüpide tekstiväljas hoidmine ei ole parim strateegia muretuks pensionipõlveks)
  • WooCommerce – aga mis oleks, kui me paneks kõik toodete, tellimuste jne kohta käiva informatsiooni nendesse metaväljadesse? Yep, that’s WooCommerce. Jube mõnus tööriist sajakonna tootega poe jaoks, aga pane ennast korraks andmebaasi mootori olukorda – kui kogu su 10tuh tootega pood asub laoruumis mustades prügikottides. “Tahaks M suurust punaseid särke mis ei maksa rohkem kui 12€” – “Juba jooksen!” – “[piinlikult pikk paus, kuulda on ähkimist, kohmitsemist ja kilekottide rebenemist]”.
  • WPML – minu ammune lemmik mitmekeelse veebi tegemiseks, hea mugav lehti ja postitusi tõlkida. Aga WordPressil on olemas väga normaalne .po/.mo failidega tõlkimise tugi, mille asendamiseks pakub WPML mugavusvõimalust need andmebaasi migreerida. Sa püha püss, kus kiirus kukub! Ja kui nüüd paneks juurde WooCommerce metaväljades oleva sisu tõlkimise … (me soovitame “lihtsaks rauaga tapmise lahenduseks” Nutikat Privaatserverit, sest siis püsib kogu see tarbetult keeruline andmebaasimudru kenasti mälus :-).

Mul ei ole hetkel head näite-pilti, lisan kui leian. Või kui sina saadad 🙂

Probleem 5 – visuaalsed jms lehe-ehitajad

BlackFire’s on lisaks funktsiooni-graafile olemas ka väga ilus ajajoon, mis annab aja kulumisest ning funktsioonide seostest isegi parema pildi:

See on üks veidi keerulisem alamleht, kus kuvati 8 … ütleme, et “toodet” ning iga ühe kohta nimistut sellega seotud postitustest. Nimistu kuvamine oli tehtud pluginaga, mis lubas lisada lehele PHP-koodi sisaldava shortcode’i ning koodis oli lihtne get_posts() ja foreach tsükkel … mida jooksutati eval() abil. Tuleb välja, et selline tsükkel on vääääääga aeglane, probleemi lahendab lehe-templiit … või siis oma shortcode, mis võtab parameetriks toote ja siis kuvab mida-vaja.

Teine esile toodud aega kulutav element on mitme-tasemelise menüü ehitamine – WordPressi puhul on ka menüü sisuliselt hulk eritüübilisi postitusi ja neist hierarhia kokkuehitamine misiganes põhjusel aeglane. Kuna menüü sisu eriti sageli ei muutu, siis ma prooviks selle ära cacheda.

* * *

Kui jutt huvi tekitas, siis proovi ise järgi – Zone Virtuaalserveri peal katsetades ei nõua isegi paigaldamine mingeid eriteadmisi. Mina alustasin BlackFire õppimist tasuta Hack plan’iga, siis proovisin Premiumi trialit, aga jäin lõpuks Profiler’i peale pidama.

Send moare freak bugs 🙂

Amsterdamis majutatud serverid kolivad uude andmekeskusesse

Neljapäeva, 26. jaanuari varahommikul kolime Amsterdamis majutatud Pilve- ja Virtuaalserverid uude andmekeskusesse.

Kolimisega kaasneb katkestus kell 01-05 (Eesti aja järgi), kliendid keda see mõjutab said nädal tagasi e-postile ka vastava eelteavituse.

Kuna meie seni kasutatud Amsterdami andmekeskus hakkas kitsaks jääma, oleme umbes pool aastat plaaninud oma serverite kolimist uude andmekeskusesse.

Toide, võrguühendused ning osa võrguseadmetest on seal juba kohal ja testitud, 26. jaanuari varahommikul liiguvad ühest majast teise ka serverid, mida kasutavad Pilveserver PRO SSD kliendid, aga samuti oma asukohaks Amsterdami valinud Pilveserver VPS ja Virutaalserverite kliendid.

Kolimisega kaasneb ca 4h katkestus – aga nagu timelapse-videost näha, oleme me seda juba oluliselt suurema hulga serveritega harjutanud:

Zone teenuste olekut saab reaalajas jälgida status.zone.eu, samast saab ka tellida e-postile teavituse intsidentide kohta.

Uus asukoht Euroopa ühes kaasaegsemas andmekeskuses (Equinix AM6) tõstab meie süsteemide töökindlust, tagades kõrgendatud nõuetele vastavad toite- ja võrgulahendused, võimsama kliimatehnika ja kõrgema turvalisuse. Andmekeskuse sertifitseeringud hõlmavad nii ISAE 3402, ISO27001, ISO 140001, ISO 50001 kui ka PCI DSS standardeid. Mitmekordistub ka meie kohapealse andmesidevõrgu ühenduskiirus.

Kuna uues andmekeskuses avaneb meil võimalus paindlikumalt muuta olemasolevaid ning luua uusi teenuseid, siis oleme huvitatud ka teie ettepanekutest, soovidest ja tagasisidest – muuhulgas on uues kohas juba paigas esimesed Nutikad Privaatserverid.

Turvalisem FTP

Käesolev postitus on loogiline jätk eelmisele postitusele, mis juhtis tähelepanu viiruste poolt tehtavale laastamistööle veebilehtede seas.

Eelmise postituse lühike kokkuvõtte oleks see, et tänapäeval poetavad küberkriminaalid viiruseid ja pahavara ohvrite veebilehtedele lihtsalt läbi veebilehe enda FTP konto.

FTP konto andmed satuvad nende valdusesse aga seetõttu, et kasutajad ei hoolitse piisavalt enda arvuti ja programmide turvalisuse eest.

Samas pole loomulikult aus veeretada kogu süüd tavakasutaja kraesse. FTP programmid on vaikimisi “lõtvade” seadistustega, mis üheltpoolt on muidugi tore, sest siis ühildub FTP programm kohe vaikimisi võimalikult paljude serveritega ning kasutajal pole probleeme programmi kasutuselevõtul.

Teisest küljest tähendab see seda, et FTP ühendus pole vaikimisi krüpteeritud, viirused/troojanid saavad ühendust pealt kuulata ning niiviisi FTP paroole varastada.

FTP krüpteerimismeetodid – FTPS

ftps80-ndatel, kui FTP protokoll koostati ei mõelnud keegi sellele, et suhtlus peaks toimuma krüpteeritult ning tol ajal polnud see ka tähtis. Seetõttu ei sisaldagi FTP protokoll (RFC959) oma ehedal kujul krüpteerimise võimalusi.

Need on lisatud protokolli hiljem nö. laienduste kujul (RFC2228) ning tänapäeval oskavad enamus servereid/klientprogramme ka neid laiendusi kasutada.

Seega väide, et FTP on ebaturvaline on vale. Pigem ei teata FTP turvalisest rezhiimist piisavalt ja ei osata seda kasutada.

Krüpteerimist on võimalik FTP protokollis realiseerida mitmel erineval viisil, mis koonduvad ühise nimetaja alla – FTPS. Erinevad FTP serverid ja kliendid toetavad erinevaid meetodeid ning võivad samu asju ka nimetada pisut erinevalt.

Olles kursis erinevate meetodite tööpõhimõtetega on programmis ka hõlpsam õiget (serveriga ühilduvat) krüptomeetodit valida:

  1. Explicit TLS/SSL – tähendab seda, et ühendus FTP serverisse luuakse standardsesse 21 porti ning suhtlus algab mitte-krüpteeritult. Peale AUTH TLS või AUTH SSL käsu saatmist aktiveeritakse alles krüpteering. Mõnikord saab FTP klientprogrammis ka eraldi valida, kumba käsku kasutada ning sellisel juhul oleks eelistatud valik AUTH TLS. Explicit TLS/SSL võidakse nimetatakse lühidalt ka FTPES-iks.
  2. Implicit SSL – SSL krüpteering aktiveeritakse kohe kui FTP serveriga ühendus luuakse. Oluline on teada, et ühendus käib läbi pordi 990 mitte enam tavalise 21 kaudu, sest mõned FTP programmid vajavad Implicit SSL aktiveerimisel ka eraldi pordi numbri muutmist.

Kumba siis valida?

Valida (või vähemalt esmajärjekorras proovida) soovitan Explicit rezhiimi, mis on paindlikum ja tagasiühilduvam, kuna suhtlus käib üle standardse pordi (21) ning samuti saab klientprogramm valida, kui suures ulatuses ta andmeid krüpteerib – kas turvatakse ainult käsukanal (control-channel) või turvatakse lisaks ka andmekanal (data-channel).

Vajadusel saab käsukanalilt krüpteeringu maha võtta kohe kui kasutajatunnus ja parool on turvaliselt serverile edastatud, et kliendi tulemüürid oskaks sissetulevaid FTP DATA porte automaatselt lahti teha. Aga ka seda pole vaja kui kasutada FTP PASSIVE rezhiimi (kui tulemüür väljaminevate ühenduste porte ei piira).

Lisaks peetakse Implicit rezhiimi aegunuks kuna ta on mitte standardne.

SFTP

Tihti aetakse FTPS segamini SFTP-ga, kuid SFTP protokollil pole FTPS-ga peale nimetuse (SSH File Transfer Protocol) midagi muud ühist.

SFTP on üle SSH kanali töötav eraldi binaarprotokoll, mille kasutamise põhiargument on see, et suhtlus FTP kliendi<->serveri vahel on täies ulatuses krüpteeritud. Ehk siis tegelikult seesama, mida võimaldab ka FTPS.

Kui SFTP eeliseid loetleda, siis oleksid need näiteks:

  1. suurem funktsionaalsus käskude näol
  2. standardne kataloogi listingu formaat, mida SFTP kliendid ühte moodi tõlgendada oskavad
  3. suhtlus toimub ainult ühe ühenduskanali kaudu – vastupidiselt FTP protokollile, kus vajatakse ühendust 21 porti ja lisaks DATA porti

FTPS toetavad programmid

FTPS kasutamiseks on vaja, et ka FTP server krüpteerimist toetaks. Kui su veebiteenuse pakkuja FTP server ei toeta FTPS-i, siis nõua seda temalt julgelt 🙂

Alljärgnevalt on enamlevinud FTP klientprogrammide kaupa ära toodud, kuidas saab olemasoleval FTP kontol krüpteeringut aktiveerida:

SmartFTP (4.0)

  1. Vali menüüst Favourites
  2. Tee soovitud konto peal parem klikk ja vali Properties
  3. Määra Protocol väärtuseks FTP over SSL explicit

smart_ftp

CuteFTP (8.3)

  1. Vali menüüst Tools » Site manager » Display site manager
  2. Kliki soovitud konto peal
  3. Vali paremalt Type lehekülg
  4. Määra Protocol type väärtuseks FTP with TLS/SSL (AUTH TLS – Explicit)

cute_ftp

FileZilla (3.3.0.1)

  1. Vali menüüst Fail » Saidihaldur (või File » Site Manager inglise keelses)
  2. Kliki soovitud konto peal
  3. Määra Serveri tüüp (Servertype) väärtuseks FTPES – FTP üle otsese (explicit) TLS/SSL-i

filezilla

WS_FTP Home (12.2)

  1. Vali Connections » Site manager
  2. Kliki soovitud konto peal ja vajuta nuppu Edit…
  3. Vali vasakult Advanced
  4. Määra Server type väärtuseks FTP/SSL (AUTH SSL)

ws_ftpTotal Commander (7.50a) *

  1. Vali menüüst Net » FTP Connect…
  2. Kliki soovitud konto peal ja vajuta nuppu Edit…
  3. Märgista SSL/TLS valik

total_commander

* Total Commander võib SSL/TLS jaoks vajada eraldiseisvat OpenSSL paigaldust. Selle saab siit.

Core FTP LE (v2.1)

  1. Vali menüüst Sites » Site Manager
  2. Kliki soovitud konto peal
  3. Määra Connection väärtuseks AUTH TLS

coreftp

FlashFXP (3.6.0)

  1. Vali menüüst Sites » Site manager
  2. Kliki soovitud konto peal
  3. Vali paremalt SSL lehekülg
  4. Secure Socket Layer grupist vali Auth TLS

flashfxp

Cyberduck OS X (3.3) *

  1. Vali bookmark-itud konto ja vajuta Edit
  2. Vali FTP protokollide nimekirjast FTP-SSL (Explicit AUTH TLS)

cyberduck2* Mac OS X-i jaoks

Transmit *

  1. Vali Protocol lahtrisse FTP with TLS/SSL

transmit2* Mac OS X-i jaoks

Kui arvad, et siit nimekirjast on mõni populaarne programm puudu, siis kommentaarides saab sellest teada anda.

test.asdasd.eu

Mastaapne IP vahetus

See nädal toob kaasa ühe suuremat sorti IP vahetuse, millest on varem meie blogis ka põgusalt juttu olnud.

Nimelt muudame neljapäeva öösel vastu reedet (27. nov) veebiserverites ära umbes 130 erinevat IP-d, mis omakorda avaldab mõju üle kümne tuhande .EE lõpulise domeeniga veebileheküljele. Muudatuse mõju on kõigi eelduste kohaselt positiivne, sest selle eesmärk on pakkuda kiiremat ja töökindlamat andmesideühendust virtuaalserverites olevate kodulehekülgedeni.

Loe edasi “Mastaapne IP vahetus”