tavis nörttimaailmassa

EksisONE - artikkeleita ja ohjeita nörttimaailmasta

Monit: järjestelmän seuranta ja monitori

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ä:

set daemon 60 #check services every 60 seconds
set logfile /var/log/monit.log
set idfile /var/lib/monit/id
set statefile /var/lib/monit/state
#Event queue
set eventqueue
basedir /var/lib/monit/events # set the base directory where events will be stored
slots 100 # optionally limit the queue size
#Mail settings
set mail-format {
from: monit@$HOST
subject: monit alert -- $EVENT $SERVICE
message: $EVENT Service $SERVICE
Date: $DATE
Action: $ACTION
Host: $HOST
Description: $DESCRIPTION
Your faithful employee,
Monit }
# set mailserver email-smtp.eu-west-1.amazonaws.com port 587 # depends of region, this is EU (Ireland)
# set mailserver smtp.gmail.com port 587
# set mailserver smtp.mailgun.org
# username "postmaster@example.com" password "very-difficult-one"
# using TLSV1 with timeout 30 seconds # AWS SES needs that, Mailgun doesn't, Gmail IDK
set alert user@example.com not on { instance, action } #email address which will receive monit alerts
#http settings
set httpd port 2812 address 0.0.0.0 # allow port 2812 connections on all network adapters
# ssl enable # use OpenSSL if you like
# pemfile /var/certs/monit.pem
# allow 0.0.0.0/0.0.0.0 # allow all IPs, can use local subnet too
# allow www.example.tld # allow dynamicdns address to connect
#set httpd port 2812 and
# use address localhost
# allow localhost
allow joedoe:"passwd" # require user joedoe with password passwd
check system <ip-address>
if loadavg (1min) > 4 then alert
if loadavg (5min) > 2 then alert
if memory usage > 75% then alert
if swap usage > 25% then alert
if cpu usage (user) > 70% then alert
if cpu usage (system) > 30% then alert
if cpu usage (wait) > 20% then alert
check filesystem rootfs with path / #Alert if low on disk space.
if space usage > 90% then alert
#allow modular structure
include /etc/monit/conf.d/*
include /etc/monit/conf-enabled/*
view raw monitrc hosted with ❤ by GitHub

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

check process nginx with pidfile /var/run/nginx.pid
group www
group nginx
start program = "/etc/init.d/nginx start"
stop program = "/etc/init.d/nginx stop"
# if failed port 80 protocol http request "/" then restart ; I'm redirecting to 443 in Nginx, so no need to monitor
if 5 restarts with 5 cycles then timeout
depend nginx_bin
depend nginx_rc
check file nginx_bin with path /usr/sbin/nginx
group nginx
include /etc/monit/templates/rootbin
check file nginx_rc with path /etc/init.d/nginx
group nginx
include /etc/monit/templates/rootbin
view raw nginx hosted with ❤ by GitHub

Varnish

# Varnish
check program varnishpanic with path "/bin/varnishadm panic.show"
if status != 1 then alert
check process varnish with pidfile /var/run/varnish.pid
#start program = "/etc/init.d/varnish start" with timeout 30 seconds
#stop program = "/etc/init.d/varnish stop"
start program = "/usr/bin/systemctl start varnish" with timeout 30 seconds
stop program = "/usr/bin/systemctl stop varnish"
if failed host 127.0.0.1 port 81 protocol http
and request "/monit-zxcvb"
then restart
if 3 restarts within 5 cycles then timeout
view raw varnish hosted with ❤ by GitHub

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

#Apache2
check process apache with pidfile /var/run/apache2/apache2.pid
group www
start program = "/usr/sbin/service apache2 start"
stop program = "/usr/sbin/service apache2 stop"
if cpu is greater than 60% for 2 cycles then alert
if cpu > 80% for 5 cycles then restart
if totalmem > 2 GB for 5 cycles then restart
if children > 250 then restart
if 3 restarts within 5 cycles then timeout
view raw apache2 hosted with ❤ by GitHub

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

 

MariaDB ja MySQL

check process mysqld with pidfile /var/run/mysqld/mysqld.pid
group database
group mysql
start program = "/etc/init.d/mysql start"
stop program = "/etc/init.d/mysql stop"
if failed host localhost port 3306 protocol mysql with timeout 15 seconds for 3 times within 4 cycles then restart
if failed unixsocket /var/run/mysqld/mysqld.sock protocol mysql for 3 times within 4 cycles then restart
if 5 restarts with 5 cycles then timeout
depend mysql_bin
depend mysql_rc
check file mysql_bin with path /usr/sbin/mysqld
group mysql
include /etc/monit/templates/rootbin
check file mysql_rc with path /etc/init.d/mysql
group mysql
include /etc/monit/templates/rootbin
view raw mysql hosted with ❤ by GitHub

PHP-FPM

# PHP-FPM
check process php7.3-fpm with pidfile /var/run/php/php7.3-fpm.pid
start program = "/usr/sbin/service php7.3-fpm start" with timeout 60 seconds
stop program = "/usr/sbin/service php7.3-fpm stop"
if failed unixsocket /var/run/php/php7.3-fpm.sock then restart
if 2 restarts within 2 cycles then timeout
view raw php-fpm hosted with ❤ by GitHub

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

Redis

# Redis
check host redis.host with address 127.0.0.1
if failed port 6379 protocol redis then alert
check process redis-server with pidfile "/var/run/redis/redis-server.pid"
start program = "/etc/init.d/redis-server start"
stop program = "/etc/init.d/redis-server stop"
if failed host 127.0.0.1 port 6379 then restart
if totalmem > 100 Mb then alert
if children > 255 for 5 cycles then stop
if cpu usage > 95% for 3 cycles then restart
if failed host 127.0.0.1 port 6379 then restart
if 5 restarts within 5 cycles then timeout
view raw redis hosted with ❤ by GitHub

Fail2ban

Fail2ban
check process fail2ban with pidfile /var/run/fail2ban/fail2ban.pid
group services
start program = "/etc/init.d/fail2ban force-start"
stop program = "/etc/init.d/fail2ban stop || :"
if failed unixsocket /var/run/fail2ban/fail2ban.sock then restart
if 5 restarts within 5 cycles then timeout
check file fail2ban_log with path /var/log/fail2ban.log
if match "ERROR|WARNING" then alert
view raw fail2ban hosted with ❤ by GitHub

Postfix

# Postfix
check process postfix with pidfile /var/spool/postfix/pid/master.pid
group mail
start program = "/etc/init.d/postfix start"
stop program = "/etc/init.d/postfix stop"
if failed host YOUR-RELAY-HOST port 587
type tcp protocol smtp using tls
with timeout 15 seconds
then alert
if 3 restarts within 5 cycles then timeout
depends on postfix_rc
depend postdrop_bin
depend postqueue_bin
depend master_cf
depend main_cf
check file postfix_rc with path /etc/init.d/postfix
group mail
if failed checksum then unmonitor
if failed permission 755 then unmonitor
if failed uid root then unmonitor
if failed gid root then unmonitor
check file postdrop_bin with path /usr/sbin/postdrop
group mail
if failed checksum then unmonitor
if failed permission 2555 then unmonitor
if failed uid root then unmonitor
if failed gid postdrop then unmonitor
check file postqueue_bin with path /usr/sbin/postqueue
group mail
if failed checksum then unmonitor
if failed permission 2555 then unmonitor
if failed uid root then unmonitor
if failed gid postdrop then unmonitor
check file master_cf with path /etc/postfix/master.cf
group mail
include /etc/monit/templates/rootrc
check file main_cf with path /etc/postfix/main.cf
group postfix
include /etc/monit/templates/rootrc
view raw postfix hosted with ❤ by GitHub

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

check process crond with pidfile /var/run/crond.pid
group system
group crond
start program = "/etc/init.d/cron start"
stop program = "/etc/init.d/cron stop"
if 5 restarts with 5 cycles then timeout
depend cron_bin
depend cron_rc
depend cron_spool
check file cron_bin with path /usr/sbin/cron
group crond
include /etc/monit/templates/rootbin
check file cron_rc with path "/etc/init.d/cron"
group crond
include /etc/monit/templates/rootbin
check directory cron_spool with path /var/spool/cron/crontabs
group crond
if failed permission 1730 then unmonitor
if failed uid root then unmonitor
if failed gid crontab then unmonitor
view raw cron hosted with ❤ by GitHub

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

# Hitch
check process hitch with pidfile /var/run/hitch.pid
start program = "/usr/bin/systemctl start hitch" with timeout 30 seconds
stop program = "/usr/bin/systemctl stop hitch"
if failed host 127.0.0.1 port 443 type tcpSSL protocol http
and request /index.html with timeout 5 seconds for 2 times within 2 cycles
then restart
if 2 restarts within 2 cycles then timeout
view raw hitch hosted with ❤ by GitHub

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.

### eksis.one
check host eksis.one with address www.eksis.one
# ICMP check
if failed icmp type echo
for 2 times within 2 cycles
then alert
# HTTPS check
if failed port 443 type tcpSSL protocol http
with http headers [Host: www.eksis.one, Cache-Control: no-cache]
and request /pong/ with content = "www.eksis.one"
then alert
view raw host hosted with ❤ by GitHub
  • 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.