On käsissä sitten WordPress-sivusto tai kokonainen farmi erilaisia palveluja, niin kaksi asiaa jää yleensä hieman huonolle jamalle. Yksi on varmuuskopiointi ja toinen ylipäätään palvelujen seuranta; ovatko sivustot ylhäällä, puhumattakaan niitä rakentavista palveluista, kuten tietokanta tai webserveri. Isot yritykset seuraavat enemmän kuin tarpeeksi (pun intended), mutta meillä pienillä kaloilla asiat tuppaavat jäämään samalla tavalla vaiheeseen kuin uuden talon jalkalistojen asennus. Yleensä syitä löytyy kaksi. Ei tiedetä mitä/miten pitäisi tehdä ja sitten kun jotain löytyy, niin hinta on liian kova. Yksi ratkaisu virtuaaliservereille on Monit.

Webhotellien idea on siinä, että palveluntarjoaja vahtii tekniikkaa. Asiakkaan harteille jää itse sivuston toimivuus ja pääseekö kävijä sinne. Siksi webhotelleissa ei ole tarvetta kuin kahdelle monitoroinnille: onko sivusto pystyssä ja onko levytilaa jäljellä. Ensimmäiseen löytyy muutama vaihtoehto. Jos ratkaisusi on tähän asti ollut Jetpack, niin luovu siitä. Jetpack on riippakivi ja hidastaa sivustoasi ja sen hallintaa. Vaihtoehtoja on olemassa. Levytilan seuranta taasen löytyy cPanelista.

Kun käytössä on tehokkaammat lelut ja ollaan virtuaalipalvelinten aina niin antoisassa maailmassa, niin kaiken joutuu tekemään itse. Myös valvonnan. Jos MySQL-serveri kaatuu, niin ei VPS-yritys ota sinuun yhteyttä, puhumattakaan, että he korjaisivat sen. Sinun täytyy tietää mitä tapahtuu ja miten se korjataan. Ja jos sinä et sitä tee, niin sitten maksat siitä jollekin toiselle. Tuo on tuonut minulle jo joltisenkin asiakkaita, vaikka olen vain valistunut harrastaja. Yksi syy siihen on tietysti se, että olen edullisempi kuin aidot pro-tason propellihatut, jotka ovat unohtaneen enemmän kuin mitä minä ehdin koskaan oppia. Mutta vahva syy on se, että minulla on kokemusta siitä mitä käyttäjä tarvitsee ja miksi, ja miten niitä tarpeita ratkotaan. Kielivalikoimaani ei kuulu nörtti, ainoastaan turkulainen suomi uusmaalaisella vivahduksella, siedettävä englanti ja kehno ruotsi.

Toimintojen valvonta sekä seuranta on yksi sellainen asia, jolle on vahva tarve. Useimmiten ratkaisuksi tarjotaan New Relicin tapaista aitoa ammattilaispalvelua, mutta se on monella tapaa sama kuin ostaisi kymppipyörä-sisun hiabilla ja siirtolavalla, kun tarve on saada muutama postipaketti kuljetetuksi. Onneksi monitorointiin löytyy pakettiautotason ratkaisu.

Monit tekee useita asioita, joiden osan lyhenteitä en edes tunne. Mutta tiedän sen, että

• Monitin saa asennettua helposti
• Monitin määrittely on siedettävää rakentaa ja pienen ihmettelyn jälkeen suurempia ongelmia ei ole
• Monit korvaa Jetpackin (ja muut ulkoiset palvelut) sivustojen kaatumisten vahtimisessa
• Monit vahtii taustalla Apachea, MySQL ja mitä sitten onkaan toiminnassa
• Monit on kevyt eikä rasita serveriä; sen takia ei todellakaan tarvitse ostaa isompaa siivua VPS:ää
• Monit on ilmainen

Tämä ohje on rakennettu oletukselle, että käytössä on Ubuntu, Apache2 tai Nginx, MySQL/MariaDB ja PHP(-FPM). Varnish esitellään kaupan päälle ja suoraan sanottuna sinun kannattaisi ottaa se käyttöön, jos ei vielä ole. Jos/kun sinulla on erilainen järjestelmä, kuten vaikka Debianilla tai muulla Linux-jakelulla oleva virtuaaliserveri, niin perusteet ovat silti samoja. Joudut vain hieman pähkäilemään mitä täytyy muuttaa.

Monit ja asennus

Kuten aina, niin jokainen esimerkki on kirjoitettu oletuksella, että ollaan root-tunnuksella kirjautuneena. Joten jos käytät omaa tunnustasi, niin anna sudo tai su.

Monit asentuu kuten suurin osa Ubuntu-maailmassa, aloittamalla järjestelmän päivityksellä:

apt update

apt dist-upgrade

apt install monit -y

Voit varmistua sen asentumisesta vilkaisemalla version:

monit -V

Asennuksen jälkeen Monit ei tee vielä oikeastaan mitään. Tarvitaan kaksi asiaa:

• Monitin omat asetukset
• monitorit, jotka tekevät valvonnan

Monit ja asettaminen

Monitin asetukset löytyvät tiedostosta /etc/monit/monitrc. Siellä on jonkun verran kommentoitu eri kohtia, mutta koska inforivit, hyödyllisyydestään huolimatta, tekevät tiedoston lukemisen vaikeaksi, niin siirretään alkuperäinen syrjään.

mv /etc/monit/monitrc /etc/monit/monitrc.bak

Luodaan uusi:

nano /etc/monit/monitrc

Kopioi sinne tämä:

Tallennuksen jälkeen laitetaan kirjoitusoikeudet kohdalleen

chmod 0700 /etc/monit/monitrc

Ydinkohdiltaan monitrc on aika yksinkertainen.

Kuinka usein Monit tarkistaa tilanteen; nyt siellä on 60 sekuntia ja osa, kuten minä, käyttää 30 sekuntia. Oletus olisi 120 sekuntia. Tähän ei ole olemassa oikeaa vastausta, vaan se riippuu siitä, kuinka tärkeää sekuntipeli on sinulle. Kuormituksella ei ole merkitystä, joten siltä osin lyhyempääkään aikaa ei tarvitse pelätä, mutta jos oma reaktioaikasi virhetilanteissa mitattaisiin tunneissa, niin turhaahan monitoreita on todella tiheästi pyörittää. Ja joskus lyhyt aika antaa virhehälyn ns. tavallisen hidastelun kanssa. Monitorien asetuksissa puhutaan sykleistä, kuinka monen syklin jälkeen jotain tapahtuu. Tämä aika on yksi sykli.

Kun jotain tapahtuu, niin siitä ilmoitetaan sähköpostitse. Voit asettaa sähköpostin muodon (älä satuile siihen liikaa, sen on tarkoitus olla vain lyhyt ilmoitus), sähköpostipalvelimen asetukset ja mihin osoitteeseen ilmoitus lähetetään. Sähköpostin sisältö ja vastaanottaja voidaan asettaa myös erikseen per monitoroitava tapahtuma (kuten jos tietokannan kaatumisesta pitäisi kertoa eri henkilölle kuin WordPressin keikahtamisesta).

Sähköpostin asetukset riippuvat siitä miten posti kulkee serveriltä. Useimmat VPS-palvelut, kuten DigitalOcean, eivät salli täysiverisen mailipalvelimen köyttöä, mutta postit saa silti ulos. Asennusohjeet Mailgunille löytyy täältä ja Amazon SES:lle (jota itse käytän) täältä. Kannattaa huomata, että pelkästään Monitin lähtevälle sähköpostiliikenteelle et tarvitse Postfixin asentamista. Monit ottaa itse yhteyden ulos. Tarvitset minimissään vain SMTP-palvelimen tunnukset, oli se sitten Gmail, SES tai Mailgun, ja omalta palvelimelta portin 587 auki.

ufw allow 587

http settings koskee monitorointeja esittävää websivua, joka vastaa portissa 2812. Nyt olevat asetukset mahdollistavat sivulle pääsyn millä tahansa selaimelta mistä tahansa osoitteesta ja pääsyä valvotaan tunnus/salasana parilla. En minä halua miettiä koska Elisa vaihtaa IP-osoitettani ja käytän vahvaa salasanaa, joten sallin pääsyn mistä vain. Jos haluat käyttää vain komentorivillä, niin

• kommentoi rivi set httpd port 2812 address 0.0.0.0
• poista kommentointi riveiltä
  set httpd port 2812 and
use address localhost
allow localhost
• vaihda localhost dropletin IP-osoitteeksi

Sinun täytyy avata portti 2812. Jos/kun palomuuri on ufw,  niin tällä saat listattua mitä on jo maailmalle auki;

ufw status verbose

Portin saat auki näin:

ufw allow 2812

Käyttäjätunnus ja salasana koskevat Monitin luomaa websivua. Nyt oletus on käyttäjätunnukselle joedoe ja salasanana on passwd. Vaihda ne! NYT!

Loppu on eräänlaista rauta- ja järjestelmätason perusvalvontaa, ensimmäinen monitori siis.

Monit omalla urlilla

Ainakin minulla webhallinnan osoite http://<ip-osoite>:2812 on hankala muistaa, vaikka selain sitä osoitepalkissa muistinsa mukaisesti tarjoaakin ensimmäisen kerran jälkeen. Suora URL olisi mukavampi. Sen saan hoidettua hyvinkin vaivattomasti, kun hyödynnetään webserverin proxy-ominaisuutta.

Apache2

Tee tämä vain jos sinulla on Apache2 ottamassa vastaan maailman.

• Varmista ensin, että sinulla on tarvittavat modulit otettuna käyttöön:

a2enmod proxy

a2enmod proxy_http

• Jos sinulla on vain yksi domain käytössä, niin annetaan Monitille oma hakemisto helpoimmalla tavalla:

nano /etc/apache2/conf-available/monit.conf

ja sinne lisätään tämä:

ProxyPass /monit/ http://<ip-osoite>:2812/
ProxyPassReverse /monit/ http://<ip-osoite>:2812/
<Location /monit/>
   Order deny,allow
   Allow from all
   ProxyPassReverseCookiePath / /monit/
</Location>

• Tarkistetaan, ettei tullut syntaksivirheitä ja kerrotaan muutokset Apachelle:

apachectl configtest

systemctl reload apache2

Nyt saat hallinnan auki jokotai

• http://<ip-osoite>/monit/
• http://example.com/monit/

Jos hostaat useampaa domainia samalla virtuaaliserverillä, niin käytettävä domain on virtual host-listasi aakkosten ensimmäinen sivusto.

Tuo ei ole aina haluttua, joten periaatteessa jos et teekään erillistä monit.conf tiedostoa, vaan kopypeistaat suoraan virtual hostin konffiin, niin Monit olisi saatavilla sen domainin /monit hakemistosta. Periaatteessa siksi, että en ole kokeillut tuon toimivuutta.

Nginx

Nginx on helpompi, eräällä tavalla. Avaa sen virtual hostin conf-tiedosto, jonka alla haluat Monitin näkyvän.

nano /etc/nginx/sites-available/example.com

• Kopioi sinne tämä, esimerkiksi 443 lohkon alle, jolloin saat SSL:n käyttöön. Voit muuttaa hakemiston haluamaksesi, jos et pidät muodosta /monit. Älä tee oikeasti hakemistoa webhakemistoosi.

location /monit/ {
   rewrite ^/monit/(.*) /$1 break;
   proxy_ignore_client_abort on;
   proxy_pass http://<ip-osoite>:2812;
   proxy_redirect http://<ip-osoite>:2812 /monit;
   proxy_cookie_path / /monit/;
}

• Varmistetaan, ettei tullut kirjoistusvirheitä ja ladataan Nginx uudestaan:

nginx -t

systemctl reload nginx

IP-osoitteella SSL webhallintaan

Jos käytät Monitia IP-osoitteella ja pelkäät jonkun vakoilevan dataa oman koneesi ja serverin välillä, kun vilkuilet webhallinnasta onko kaikki mittarit vihreällä, niin voit ottaa SSL:n käyttöön.

Monit haluaa hyvinkin omintakeisesti, että monitrc-tiedostossa määritelty pem-tiedosto pitää sisällään Let’s Encryp malliin ajatellen privkey.pem ja fullchain.pem -tiedot sekä lisäksi tuossa järjestyksessä. Let’s Encrypt vaan tekee ne erillisinä ja niiden yhdistäminen niin, että SSL-sertifikaatin uusimisen jälkeenkin homma toimii, vaatii kikkailua. Siksi itseallekirjoitettu SSL on helpompi tehdä – ja hankalampi käyttää.

Tehdään sertifikaatti OpenSSL:llä. Se on luultavasti serverillä jo asennettuna, mutta jos ei ole:

apt install openssl -y

• Tehdään sertifikaatille hakemisto.

mkdir /var/certs

• Tehdään vuoden voimassaoleva sertifikaatti. Sinulta kysytään muutamia asioita ja voit vastata niihin jos haluat tai ohittaa enterillä.

openssl req -new -x509 -days 365 -nodes -out /var/certs/monit.pem -keyout /var/certs/monit.pem

• Laitetaan tiedosto-oikeudet kohdalleen.

chmod 0700 /var/certs/monit.pem

• Avaa monitrc ja otta kommentointi pois riveiltä enable ssl ja pemfile.

nano /etc/monit/monitrc

• käynnistä Monit uudestaan

systemctl restart monit

Nyt saat webhallinnan auki urlilla https://<ip-osoite:2812/ ja kaupan päälle hirvittävän urputuksen surkeasta SSL-sertifikaatista. Selaimesta riippuen voit asettaa turvallisuuspoikkeuksen, jolloin aiheesta ei enää vinguta, tai et saa, jolloin valitus tulee vastaan joka kerta.

Selaimesi ja serverin välillä ei kulje mitään sellaista tietoa, joista talojakomoon tai puhelinoperaattorin mastoon ujuttautunut salakuuntelija (tai ilmaisia wifin hotspotteja hyödyntävä roisto) tulisi hullua hurskaammaksi. Tai saa, webhallinnan käyttäjätunnuksen ja salasanan, jolla mustahattu saa kytkettyä monitoroinnin päälle tai pois. En pidä tuota riskinä, ja OpenSSL:n aiheuttama vaiva selaimessa on niin ärsyttävä, että itse en käyttäisi SSL:ää tässä.

Let’s Encrypt on mahdollista virittää Monitin käyttöön. Tarvitset scriptin, joka yhdistää tarvittavat kaksi pem-tiedostoa ja certbot haluaa pari hookia käyttöönsä. En selitä miten tuo tehdään, koska se ylittää jo tämän jutun idean. Mutta tarvitsemasi scripti voisi olla tällainen:

#!/bin/bash

for domain in $RENEWED_DOMAINS
do
case $domain in
example.com)
cat $RENEWED_LINEAGE/privkey.pem $RENEWED_LINEAGE/fullchain.pem > /etc/monit/pemfile-$domain.pem
chmod 600 /etc/monit/pemfile-$domain.pem
;;
done

Ja certbot renew kaipaa jotain tämän tyyppistä:

• --deploy-hook '/polku/scriptiin/script.sh'
• --post-hook 'systemctl restart monit'

Googleta lisää hookien käytöstä certbotin kanssa. Tässä jutussa on selitetty miten hieman vastaavaa käytetään Hitchin kanssa; https://www.eksis.one/varnish/hitch-varnish-ja-apache2-ssl-ja-https/

Monit ja peruskommennot

Järjestelmän suhteen Monit käyttäytyy kuten muutkin:

• systemctl start monit käynnistää
• systemctl stop monit sammuttaa
• systemctl enable monit sallii Monitin käynnistämisen automaattisesti serverin rebootissa
• systemctl restart monit uudelleenkäynnistää
• systemctl reload monit lataa sen uudestaan käynnistämättä; en tiedä mihin tätä käytetään
• systemctl status monit kertoo miten Monit voi; vihreä pallukka on hyvä, punainen paha

Monitin omat komennot ovat kohtuullisen loogisia:

• monit -t tarkistaa tekemiesi asetustiedostojen syntaksin ja sitä kannattaa aina käyttää ennen Monitin uudelleenkäynnistystä, kun muuttaa jotain
• monit reload tekee saman kuin systemctl reload monit
• monit start/stop/restart <monitori|all> käynnistää tai sammuttaa nimetyn monitorin tai kaikki
• monit status näyttää kaikkien tilat ja tiedot, siis samat asiat kuin webhallintakin
• monit status <monitori> näyttää määrätyn seurannan tiedot
• monit summary näyttää taulukkomuodossa jokaisen seurannan tilan ja tyypin
• monit unmonitor <monitori|all> pysäyttää  seurannan
• monit monitor <monitor|all> käynnistää seurannan

Monitorien asettaminen

Asennuksen myötä Monit ei seuraa kuin muutamaa serverin arvoa. Voi niistäkin olla jotain iloa jollekin, mutta suurin osa varmaan haluaa enemmän varmuutta sivustojen ja erilaisten palveluiden toiminnan suhteen. Kaatumiset ja saavuttamattomuudet eivät ole juhlaa, mutta niiden selviäminen viiveellä syö miestä vahvemmin.

Monit ei ole mitään helppo käytettävyyden huipentuma, valitettavasti. Jokainen ohjaus tehdään tekstimuodossa ja komentojen rakenne pitäisi tuntea. Mutta jos tarve on tärkeimpien toimintojen kaatumisesta tuleva ilmoitus tai tieto, että sivusto on saavuttamattomissa, niin ne on helppo asentaa,

Asetustiedostot

Monitin asetuksissa voi asettaa hakemistot. joista monitorien tiedot haetaan automaattisesti. Aiemmin tarjotussa (toimivana) esimerkkinä olevassa monitrc-tiedostossa on määritelty kaksi paikkaa:

• /etc/monit/conf.d/
• /etc/monit/conf-enabled/ (ja konffitiedostot  usein rakennetaan hakemistoon /etc/monit/conf-available/)

Vaikka jälkimmäinen noudattaa samaa tapaa kuin esimerkiksi Apache2, niin se on turhan vaikea. Ei ole olemassa mitään suoraa, selvää ja tarkkaa komentoa, jolla monitori otetaan käyttöön ja käytöstä pois. Käyttöön otettavat siirretään linkityksellä conf-available hakemistosta ja ne sitten tarpeen mukaan sammutetaan Monitin komennolla. Ei tuossa ole mitään järkeä kuin tiedostojen varastona, jos tekee töitä SSH:lla.

Kun käyttää conf.d hakemistoa, niin monitori on heti käytössä ja aivan samalla tavalla sammuttamiseen käytetään Monitin komentoa. Toki voi käyttää suoraan conf-enabled hakemistoa, jos se tuntuu helpommalta muistaa. Tai käyttää ihan mitä tahansa hakemistoa, kunhan se on määritelty monitrc-tiedostossa.

Oma työnkuva on kuitenkin vahvasti FTP:n ja SSH:n sekoitusta, joten käytän kumpaakin. Kun haluan jonkun monitorin käyttöön, niin raahaan sen conf-enabled tai conf.d hakemistoon. Kun en enää tarvitse sitä, niin raahaan sen takaisin conf-available hakemistoon. En siis leiki symbolisten linkkien kanssa, koska koen moisen suunnattoman hankalana. Kahden erillisen aktiivisten monitoreiden kansion käytössä ei ole kuitenkaan suuremmin järkeä. Muutamista omista syistäni johtuen niin kuitenkin olen alkanut tekemään ja se on jäänyt.

• conf-available hakemisto on varastona konffeille, jotka olen joskus tehnyt tai saanut, mutta jotka eivät ole käytössä
• conf-enabled hakemistossa on kaikki palvelut
• conf.d hakemistossa on sivustot

Monitorien määrittelyt voi koota kaikki yhteen tiedostoon, jakaa niitä erilaisiin tiedostoihin vaikka aiheen mukaan tai tehdä jokaisesta omansa. Ei mitään väliä, kunhan ne löytyvät edellä asetetuista hakemistoista. Tiedostot saa myös nimetä ihan miten haluaa.

Omat tarpeet

Itse käytän systeemiä, jossa

• Nginx on keulilla ja hoitaa SSL:n ja HTTP/2:sen
• Varnish on reverse proxynä hoitamassa välimuistin
• Apache2 on taustalla backendinä ja pitää huolta sivustoista
• MariaDB hoitaa tietokannan
• Nginx vaatii, ja Apache hyödyntää, webpalveluiden PHP-laajennoksen PHP-FPM:n
• Redis cacheaa PHP-kutsut ja muut objektit
• Fail2ban torjuu roskat, botit ja script kiddiet
• Postfix liikuttaa sähköpostit Amazon SES palvelun kautta

Monitorit

Löydät tismalleen samat, tai pienillä muutoksilla, joka puolelta Googlella. Nämä ovat kuitenkin sellaisia, jotka ovat minulla koko ajan käytössä ja siltä osin eräällä tavalla taatusti toimivia – ainakin omassa ympäristössäni.

Nginx

Varnish

Varmistetaan, että Varnish tekee pid-tiedoston, jota seurataan. Uudemmat versiot eivät nimittäin tee sitä automaattisesti, koska lienee sinällään tarpeeton. Tai jotain.

ls /var/run

Jos löydät tiedostot varnish.pid tai varnishd.pid tai hakemiston varnish, josta vastaava löytyy (hakemisto varnishncsa ei kelpaa), niin kaikki on hyvin. Jos ja kun ei löydy, niin tehdään sellainen.

systemctl edit --full varnish

• Siellä on rivi, joka alkaa:

ExecStart=/usr/sbin/varnishd

• Lisää tuon jälkeen tämä:

-P /var/run/varnish.pid

Huomaa, että vain lisäät tuon väliin, älä poista muita määreitä.

• Käynnistä Varnish uudestaan:

systemctl restart varnish

Nyt sinulta löytyy /var/run/varnish.pid

monit-zxcvb

Monit kyselee localhostin portin 80 kautta tiedoston monit-zxcvb olemassaoloa ja jos se löytyy, niin kaikki on hyvin. Jos ei löydy, eli Varnish on kaatunut, niin Monit yrittää käynnistää Varnishin. Jos se epäonnistuu kolmessa yrityksessä viidestä, niin Monit toteaa, että ei tästä tule mitään ja lopettaa yrittämisen.

Käytetty tiedosto täytyy olla sellainen, jota ei varmasti kysellä normaalissa web-liikenteessä. Sille tehdään nimittäin pieni jekku. Keksi siis joku omituinen nimi. Tiedoston sijannissa on pieni koukku, joka johtuu Apachesta. Jos sinulla on vain yksi domain/sivusto käytössä, niin tee tiedosto sen public_html hakemiston juureen. Jos sen sijaan hostaat useampaa, niin se täytyy olla aakkosissa ensimmäisen domainin public_html hakemiston juuressa.

• Tehdään tiedosto. Muuta esimerkin polku oikeaksi.

touch /var/www/html/monit-zxcvb

Varnishiin ei tarvitse sinällään tehdä mitään muutoksia, mutta tehdään yksi viritys, joka helpottaa elämää juuri tehdyn ”tarkistustiedoston” kanssa. Jos tarkistaisit pelkän tiedoston, niin sen saavuttamattomuus voi kohtua myös Apachesta. Joten tehdään säätö, jonka takia Varnishin täytyy tehdä jotain mitattavaa – ja jos se ei onnistu, niin Varnish on kaatunut.

nano /etc/varnish/monit.vcl

Lisää sinne tämä:

sub vcl_recv {
   if (req.url == "/monit-zxcvb") {
   return(synth(200, "OK"));
   }
}

Kun tuolle sivulle menee selaimella, niin saa ruudulle Varnishin tekemän virheilmoituksen, joka ei siis ole aito virhe, vaan ihan normaali 200 OK ilmoitus. Mutta Varnish joutuu sen tekemään. Jos se ei onnistu, niin Varnish on alhaalla ja Monit rupeaa töihin. Jos olisit laittanut tuohon vaikka wp-config.php tiedoston, niin tämän annetaan-ok-errorina-tempun takia WordPress kaatuisi välittömästi.

• Varnishille täytyy kertoa, että käytössä on uusi vcl-tiedosto.

nano /etc/varnish/default.vcl

Laita alkuun vcl 4.1; määrittelyn jälkeen ja ennen backend default { asettelua tämä:

# Monit
include "/etc/varnish/monit.vcl";

• Ja lopuksi:

systemctl restart varnish

Apache2

Tämä seuraa vain Apachen kuormaa ja muistinkäyttöä. Webpalvelimen ylipäätään saavutettavuus vahditaan sivustojen kautta.

 

MariaDB ja MySQL

PHP-FPM

Muista varmistaa, että PHP:n versio on oikein.

Redis

Fail2ban

Postfix

Tarkistan Postfixin toiminnan ulkoisen SMTP-palvelimen mail relayn kautta. Muuta YOUR-RELAY-HOST palvelimen nimeksi; Amazon SES:llä se olisi email-smtp.eu-west-1.amazonaws.com (jos region on EU (Ireland)) ja Gmaililla smtp.gmail.com.

Cron

Cronia ei varsinaisesti seurata siksi, että se kaatuisi – jota cron ei oikeastaan koskaan tee. Sitä seurataan muistin kulutuksen takia. Joku rikkinäinen PHP tai liian hitaasti suoritettava scripti saattaa syödä äkkiäkin kaiken RAM:n ja siinä vaiheessa kaatuu kaikki. Moinen tilanne syntyi minulle ja cron valtasi noin neljässä tunnissa koko muistitilan itselleen.

Ilman Monitin seurantaa olisin yrittänyt etsiä vikaa aivan muualta. Itseasiassa juuri tämä monitori on pelastanut nahkani paremmin kuin vaikka sivustojen seuranta, vaikka onkin mukavaa tietää, että joku WordPress tai Woocommerce on kaatunut.

Hitch

Käytin Hitchiä aikaisemmin hoitamaan SSL:n ja HTTP/2:den. Se on kevyt, nopea ja tehokas, mutta hankala, vaikea ja epäluotettava. Pienikin ongelma SSL-sertfikaattin kanssa, niin Hitch kaatoi kaikki sivustot. Toimiessaan se oli kuitenkin hyvä, mutta sain taistella sen kanssa viikoittain.

Hitch on varmasti vaivansa väärtti, jos hostaa tuhansia suosittuja sivustoja. Noin 10 000 käynnillä päivässä kuudella eri sivustolla Hitch ei antanut yhtään mitään etua Nginxiin verrattuna.

Ero on siinä, että Nginxillä saa tehtyä paljon muutakin, kuten suljettua sivuston heti boteilta ja muilta tunkeilijoilta. Toki samaa saa tehtyä Varnishissakin tehokkaasti, mutta se maksaa hiukan RAM:ia.

Uskallan väittää, että koska olet täällä, niin et tarvitse Hitchiä mihinkään.

Sivustojen seuranta

Voit tehdä jokaiselle hostaamallesi sivustolle oman tiedoston tai tehdä kuten minä ja koota kaikki yhteen paikkaan. Itse käytän conf.d hakemistoa sivustojen monitoreille.

Kopioi alla oleva jokaiselle domainille ja vaihda eksis.one oikeaksi.

• ICMP (Internet Control Message Protocol) on laitteiden väliseen kommunikaatioon liittyvä protokolla. Googleta, jos olet utelias. Minun ymmärtääkseni tässä se pingaa annettua hostia ja jos juttelu ei onnistu, niin se ei ole hyvä asia.
• HTTPS kokeilee SSL:n tarvitseman portin 443 kautta josko sivustolla oleva tiedosto pong löytyy
• Jos vastaus on error 400 tai suuremmalla virhekoodilla, niin sivusto on alhaalla ja varoitusmailia liikkuu.

Jos sinulla on sivustoja jollain muulla virtuaaliserverillä, niin saat seurattua niitä aivan samalla tavalla. Voit käyttää samaa asetustiedostoa ulkoisten sivustojen seurantaan, jos haluat. Itse valvon muutamia asiakkaiden sivuja, niin virtuaaliservereillä kuin webhotelleissakin, ja käytän siihen työhön nimenomaan tätä tapaa.

WordPress/Drupal/vastaavat CMS:t ja pong

Jos tehtäisiin erillinen tiedosto, jota seurataan, niin silloin tutkittaisiin vain tiedoston löytymistä ja Apachea; onko serveri ylhäällä ja virtual host olemassa. Jos käytössä on WordPress (tai mikä tahansa julkaisujärjestelmä, vaikka Drupal), niin erillinen tiedosto ei tiedä onko se pystyssä. WordPress voi tarjota kuoleman valkoista ikkunaa ja erillisen tiedoston takia Monit väittäisi iloisesti sivuston olevan elossa ja pirteänä. Täytyy siis tehdä viritys, jonka toimivuus riippuu WordPressin tilasta.

Tee Worpdressissä sivu, anna sille nimeksi vaikka pong ja laita sinne (varmuuden vuoksi) tällainen teksti, muokattuna itsellesi sopivaksi:

Tekninen sivu, joten www.example.tld ping

Tuolla saadaan varmistettua kaksi asiaa. Löytyy taatusti tutkittava content merkkijono ja jos sivulle kuitenkin joku kävijä harhautuu, niin hän ei hämäänny turhaan tyhjästä sivusta. Jos haluat olla oikein filmaattinen, niin käytät aitoa sisältöä tarjoavaa sivua – kunhan muistat, että jos muutat sen urlia, niin Monit herjaa kaatuneesta sivustosta.

Kun julkaiset sivun, niin estä sen näkyminen sivustokartassa. Vaikka sivu löytyisikin sitemapissä, niin ei siitä haittaa ole, mutta moista on ihan turha tarjota julkisena Googlelle ja muille hakukoneille. Samasta syystä sivu kannattaa varustaa no-index ja no-archive tageilla. Hyvä SEO-lisäosa hoitaa tuon homman ja sillä alalla toimivin on Rank Math.

Saat testattua toiminnan helposti. Avaa wp-config.php tiedosto ja ota joltain komentoriviltä puolipiste pois. Tallennuksen jälkeen, syklin pituudesta riippuen, saat ilmoituksen sivuston kaatumisesta ja että sitä ei löydy portista 443. Johtuu siitä, että virheellinen wp-config.php kaataa WordPressin ja näyttää error 500 virheen. Palauta puolipiste, tallenna ja Monit kertoo sivuston palanneen linjoille.

Itse kokeilin samaa poistamalla .php-tunnisteen komentamalla SSH:ssa mv wp-config.php wp-config. Koska wp-config.php puuttui, niin sivu kaatui (muutoin huono tapa testata, koska WordPress tarjoaa kävijälle mahdollisuuden asettaa WordPress). Palautin tiedoston oikealle nimelleen, mutta sivusto tarjosi edelleenkin error 500. Syynä oli omistajan vaihtuminen, koska olen aina root-tunnuksella liikkeellä. Kun vaihdoin omistajaksi Apachen komennolla chown -R www-data:www-data /var/www/html, niin sivusto palautui takaisin linjalle. Todella omituista, koska minusta omistajuuden ei pitäisi vaikuttaa.

Pongin välimuisti

Olen saanut viritettyä itselleni Varnishin todella tehokkaaksi, ainakin sisältösivustojen suhteen. Woocommercet ovat omilla alidomaineillaan poissa Varnishin ulottuvilta. Verkkokaupan cacheaminen kun ei tuo kuin ongelmia. Kun domainiin sisältyvä sisältösivusto on omalla serverillään ja kauppa omallaan, niin vaikka kaataisin sisältöpuolen jollain sen lukemattomista plugineista, niin rahaa tuova kauppa pysyy pystyssä.

Varnishin käyttö välimuistina aiheuttaa sen, että vaikka joku virtual host kaatuisikin, niin sisältö tulee silti cachesta jonkun aikaakin – oma asetus on muistaakseni neljä tuntia. Tuo tarkoittaa sitä, että vaikka seuraisinkin WordPress-sivustojen tilaa, niin saisin tiedon kaatumisesta viiveellä. Parempi vaihtoehto on, että sivuston kaatumisesta tulisi heti tieto. Silloin saattaisi korjaus onnistua ilman, että kukaan kävijöistä huomaa mitään – heillehän sisältö tulee koko ajan välimuistista.

Siihen on olemassa yksinkertainen kikka. Ei laiteta välimuistiin pong-sivua, joka juoruaa sivuston tilasta Monitille.

Avaa Varnishin default.vcl tiedosto ja etsi osiosta vcl_recv tämä:

if (req.url ~ "/wp-(login|admin|comments-post.php|cron)" || req.url ~ "preview=true" || req.url ~ "xmlrpc.php") {
   return (pass);
}

Se pitäisi löytyä kohtuullisen heti sub vcl_recv { lausekkeen jälkeen ennen muita return-lausekkeita (jos ei löydy, niin ihmettelen jos sinulla toimii WordPressin visual editor). Lisää sen jälkeen tämä:

if (req.url ~ "/pong") {
   return (pass);
}

Sitten systemctl reload varnish ja Monit saa seurattua reaaliajassa sivustoasi.

Muut sivustot

Jos WordPressin kaltainen ratkaisu ei ole mahdollinen, niin seuraa joko juurihakemistoa (merkitse silloin pelkkä /) tai teet erillisen tiedoston:

nano /var/www/example.tld/public_html/pong

Lisää sinne tämä, itsellesi oikeaksi muokattuna:

www.example.tld

Ulkoiset sivustot

Minulla on muutamakin asiakkaan sivusto, joita valvon. Ne ovat omilla virtuaaliservereillään. Samaten minulla on omat Moodle-verkkokoulutukset sekä Woocommerce-verkkokaupat omilla virtuaaliservereillään. Noihin kaikkiin voisi asentaa oman Monitin, mutta on einen helpompaa valvoa kaikkea keskitetysti. Joten teen sen samasta kuin omienkin sivustojen valvonnan, mutta olen selvyyden takia tehnyt niille oman konffitiedoston sites-ext. Sivustot asennetaan kuten omatkin, koska ne haetaan URL:lla.

Tässä on pieni ongelma. Monit ei tietenkään salli muualla olevalla serverillä palveluiden käynnistämisiä ja sammuttamisia. Ilmiselvä turvallisuuskysymys. Silti olisi mukava, että tuo ratkaistaisiin joskus. Nyt pystytään ainoastaan seuraamaan sivustojen toimintaa ja jos ne kaatuvat, niin täytyy arvata mikä palvelu on kaatunut. Jos seuraan sivuston juurta, niin en tiedä onko ongelma Apachessa vai WordPressissä. Plus jos uudelleenkäynnistys toisi tolkun, niin se täytyy mennä erikseen tekemään, kun taasen omalla serverillä uudelleenkäynnistykset tehdään automaattisesti Monitin toimesta.

Riippuu tapauksesta onko tuo aito ongelma. Jos on, niin sitten täytyy asentaa kohteeseen oma Monit ja hyödyntää sitä. Jos ei, niin voi tehdä vastaavan purkkavirityksen kuin mitä minä käytän.

• jos portti 443 ei toimi, mutta 80 toimii, niin Apache on pystyssä, mutta SSL-terminaation tekevä, kuten vaikka Hitch, on kaatunut
• sivustolle tehdään erillinen tyhjä tiedosto ja jos sitä ei löydy kummallakaan portilla, niin Apache2 on kaatunut
• WordPressiin tehdään seurattava sivu ja jos sitä ei löydy, niin WordPress on kaatunut

Testaus

Ensin varmistetaan, että kaikki muutokset ovat Monitin tiedossa:

systemctl restart monit

Jos et saa sähköpostia, niin kaikki on sinällään jo hyvin. Jos saat ilmotuksen virheistä, niin mene asetukset läpi ja yritä hahmottaa virheilmoituksen perusteella mikä tekee kiusaa. Monitin logi /var/log/monit.log kannattaa aina vilkaista.

• Jos haluat katsella livenä login seurantaa (ctrl-c päästää pois):

tail -f /var/log/monit.log

• Jos haluat etsiä määrättyä asiaa:

grep apache2 /var/log/monit.log

Nginx

Nginxin seuranta voidaan testata parillakin tavalla.

• Voit sammuttaa sen:

systemctl stop nginx

Hetken kuluttua saat sähköpostin (oikeammin kaksi, koska myös PHP-FPM meni nurin) ja siitä vähän ajan kuluttua webserverin pitäisi olla uudestaan toiminnassa.

• Voit poistaa tai uudelleennimetä tiedoston, jota Nginx seuraa ja Apache ylläpitää, kuten sivustoille rakennettu pong-sivu. Samalla selviää toimiiko sivun seuranta

Varnish

Mene tekemääsi tiedostoon (esim. monit-zxcvb) selaimella. Kokeile urlia sillä domainilla, jonka juureen tarkastustiedoston teit. Minulla se olisi silloin http://www.eksis.cloud/monit-zxcvb ja koska se tarjoaa Varnishin tuottaman 200 OK ilmoituksen, niin ainakin tiedosto on oikeassa paikassa.

Yksinkertaisin tapa testata Monitin reaktiota kaatuneeseen Varnishiin on sammuttaa Varnish.

systemctl stop varnish

Ensin pitäisi tulla ilmoitus, että Varnish ei toimi. Siitä hetken kuluttua tulee uusi ilmoitus, että Varnish toimii taas. Koska Varnishin paniikkia seurataan myös, niin minuutin sisällä Varnishin sammuttamisesta tulee mailiin huolestunut kysymys, että onko Varnish ylipäätään käynnissä. Eihän se ole, koska se sammutettiin.

Sammuttamisen kiusa

Palvelun sammuttaminen on helpoin tapa tarkistaa osaako Monit ilmoittaa kaatumisesta ja käynnistää palvelun uudestaan. Samalla selviää pieni ongelma, joka on hyvä muistaa tulevaisuudessa. Tuo tarkoittaa periaatteessa sitä, että et pysty enää sammuttamaan Nginxiä, Apachea, Varnishia tai mitään muutakaan seurattua, vaikka olisi tarve, koska Monit innokaana käynnistää sen uudestaan.

Sinulla on kaksi vaihtoehtoa:

• sammutat myös Monitin
• käsket Monitin olla valvomatta haluttua palvelua

Ei Monitin sammuttaminen niin suuri ongelma ole, ainakaan minulle. Mutta valvomattomuus onnistuu myös helposti. Voit mennä Monitin webhallintaan http://<ip-osoite>:2812, klikata palvelun nimeä, vaikka Varnishia, ja sen jälkeen sivun alareunasta klikkaat Disable monitor.  Saat monitorin takaisin päälle samasta paikasta klikkaamalla Enable monitoring.

Tai koska olet luultavasti jo shellissä niin komento

monit unmonitor varnish

pysäyttää valvonnan Varnishin osalta.

Ja komento

monit monitor varnish

käynnistää sen uudelleen.

Virheitä

Aina kaikki ei mene putkeen ja Monitin logeista löytyy erroreita tai muista ihmeellisyyksiä. Nämä ovat minulle tulleet vastaan.

’postfix’ error — unknown resource ID: [5]

Vanhemmissa ohjeissa mm. Postfixin kohdalta löytyy rivi:

if loadavg(5min) greater than 10 for 8 cycles then stop

Monitin toimintaa muutettiin yhdessä vaiheessa ja kuorman seuraaminen poistettiin (tarpeettomana?) osasta, kuten Postfixin yhteydestä. Poista rivi, lataa Monit uudestaan ja virhe on poistuu.

Monit vai ulkoinen palvelu

Monit on ilmainen ja paljon tässä ilmoitettua laajempi. Googleta ohjeita lisää tai lue dokumentaatio (joka on hieman hankala ja man-sivut antavat enemmän tietoa). Mutta Monitissa on omat rajoitteensa eikä se on helpoimmasta päästä. Toki kaikessa on oppimiskäyränsä, mutta käytännön vinkkejä löytyy netin syövereistä aika vähän kuitenkin. Näillä ohjeilla pääset toki liikkeelle, ja kohtuullisen hyvin matkallekin, mutta jos sinulle tulee poikkeuksellimpi tarve, niin KVG tulee hyvinkin tutuksi – ja silti joutuu kokeilemaan ja pähkäilemään melkoisen tovin.

Minulla kesti päivän verran selvittää (oikeasti), että sivuston seurantaan ei ole edellä esitettyä helpompaa tapaa, eikä useamman virtual hostin systeemissä päästä yli eikä ympäri aakkosten ensimmäisen domainin käyttämisestä – joka on minusta melkoinenkin kiusa aika ajoin. Mutta noita asioita selvitellessä opin paljon muutakin, enkä pelkästään Monitin sielunelämästä.

Muutoin Monitin virittely ei ole sen kummallisempaa kuin minkä tahansa uuden asian opettelu. Eivätkä ne ulkoiset graafisemmat ja maksulliset palvelut ole paljonkaan helpompia.

Jos tarvitset todella ammattimaisia raskaan kaluston työkaluja, niin Monit ei ole todellakaan sinulle suunnattu. Silloin kannattaa tähystää New Relicin ja vastaavien suuntaan.

Monit on tehty sellaisille, jotka haluvat tai joutuvat tekemään itse ja laskevat euroja. Tai vaikka 5 – 15 euroa kuukaudessa ei olisikaan liian paljon, niin sen maksaminen vain siitä, että saa korvattua Jetpackin, on aika turhaa. Nämä ohjeet tekevät aivan saman ja jonkun verran enemmän. Ja taas kerran, jos olet webhotellissa, niin sinulla ei ole vaihtoehtoja ja joudut tyytymään ulkoisiin palveluihin (nekään kaikki eivät toimi webhotelleissa). Tai sitten pidät Jetpackin hidastamassa sivuston latausnopeutta.