Tartalom
- oldal: Alapfeltételek áttekintése és a tárhely előkészítése a Matomo számára
- oldal: Matomo letöltése és telepítése
- oldal: Követőkódok elhelyezése WordPress rendszerű oldalakon
- oldal: Követőkódok elhelyezése Drupal rendszerű oldalakon
- oldal: Követőkódok elhelyezése és testreszabása egyedi fejlesztésű oldalakon
- oldal: A telepítés utáni fontos beállítások elvégzése
- oldal: GeoIP 2 (PHP) alapú geolokációs rendszer beüzemelése
- oldal: Matomo teljes rendszer átállítása PHP-FPM alapú szerver API működésre
A 6. oldal tartalma
Folytatás
Az előző oldalon áttekintettük az egyedi weboldalakba illesztendő JavaScript kódokat, itt pedig elvégezzük a Matomo (Piwik) webanalitikai rendszer telepítése után szükséges beállításokat.
Megbízható weboldal beállítása
A Matomo feltelepítése előtti előkészületeknél már láthattuk, hogy a webstatisztikai rendszer számára elkészített tárhelyet többféleképpen is el tudjuk érni. Ezt a Matomo is támogatja – így bármelyik domain nevünk alól elérhető a felület, ahonnan a tárhely is –, azonban ha nem végezzük el az ehhez szükséges beállítást, akkor egy ilyen figyelmeztető oldalba botlunk, amikor egy új domain név alól szeretnénk elérni a Matomo példányunkat:
A telepítéskor a szerver IP-címén keresztül léptem be a felületre, ezért azt regisztrálta elsőként, így most az új wordpress.vm domain név még ismeretlen a rendszer számára.
Ezzel nincs is semmi gond, mert ez csak egy biztonsági figyelmeztetés. Ennek elhárításához – a figyelmeztetésben leírtaknak is megfelelően – nyissuk meg a config.ini.php fájlt a telepítési könyvtárban (root-ként):
nano /opt/matomo/config/config.ini.php
És itt a [General] szekciónál adjuk hozzá az alábbi sorokat (amennyiben www-vel és anélkül is szeretnénk használni a Matomo rendszert):
trusted_hosts[] = "wordpress.vm" trusted_hosts[] = "www.wordpress.vm"
Természetesen helyettesítsük be a saját domain nevünket.
Ezután a figyelmeztető oldalra frissítve, már jön is a beléptető panel:
Tehát ha egy újabb weboldalba kötjük be a Matomo-t, ahonnan szintén el szeretnénk érni a /matomo alkönyvtárból a statisztikákat, minden esetben be kell tenni a beállításokba a megbízható hosztok közé az új domain nevet.
További szükséges beállítások
Belépve a Matomo rendszerbe, a jobb felső sarokban lévő fogaskerék ikonra kattintás után bejön a fő beállítások panel. Itt felül lehet pár figyelmeztetés, de most a rendszerellenőrzés részt nyitjuk meg, ahol részletes információt kaphatunk a különböző rendszer szükségletekről. Ehhez kattintsunk a Rendszerellenőrzés panelen lévő részletek linkre. Itt a felső részen minden rendben, viszont legörgetve a legaljára, már előbukkan néhány hiba, hiányosság:
Itt láthatunk négy hibát, a továbbiakban ezeket fogjuk orvosolni. Sorban haladva vegyük is az elsőt: az automatikus archiváló scriptet.
Automatikus archiválás a cron-ból
A Matomo kétféleképpen tudja elkészíteni a különböző összesítéseket, jelentéseket: a felületre történő lépéskor a panelek betöltésekor generálja őket le, vagy pedig a háttérben periodikusan futtatjuk le az összesítő scriptjét a cron-ból. Az első megoldás ideig, óráig elmegy, viszont ahogy gyűlnek az adatok, és ahogy az oldalakon is nő a forgalom, ez a módszer lassúvá válik, így nagyban rontja a felhasználói élményt, amikor a vezérlőpultra lépünk. Nem beszélve arról, ha napokig, esetleg hetekig nem lépünk be a felületre, akkor addig nem történik meg az összesítés, így azok nagymértékben felgyűlnek, majd a következő belépésnél akár percekbe is telhet, amíg betölt minden panelt. Ezért már rövidtávon is erősen ajánlott megoldani az archiváló script cron-ból történő futtatását.
Log könyvtár létrehozása
Az archiváló script kimenetet is generál, amit naplózni tudunk. Így első körben szükségünk lesz egy log könyvtárra, ahol a Matomo számára gyűjtjük a naplófájlokat (később majd lesznek még PHP-FPM naplófájlok is).
Ehhez root-ként lépjünk be, majd hozzunk létre egy matomo könyvtárat a /var/log alatt:
mkdir /var/log/matomo
Majd adjuk át a könyvtárat a www-data felhasználónak, hogy ez is a Matomo webes felületét (is) futtató felhasználóé legyen, mert a legelején úgy állítottuk be az Apache-ot, hogy az a moduljával töltse be a PHP fájlokat. Ennek megfelelően állítsuk át a tulajdonosát a könyvtárnak:
chown www-data:www-data /var/log/matomo/
Cron feladat létrehozása
Most, hogy már megvan a helye a leendő naplófájlunknak, hozzunk létre egy cron feladatot. Ehhez root-ként nyissunk meg egy üres fájlt a cron.d könyvtárában:
nano /etc/cron.d/matomo-archive
Majd tegyük bele a következő tartalmat:
MAILTO='' SHELL='/bin/sh' */5 * * * * www-data /usr/bin/php /opt/matomo/console core:archive --url=http://www.wordpress.vm/matomo/ >> /var/log/matomo/matomo.log
Itt a következők a lényegesek:
- MAILTO: Éles környezetben itt állítsunk be egy működő email címet, ilyenkor a cron ide küldi a hiba kimenetet, ha gond van.
- */5 * * * *: 5 percenként fut le ez a feladat. Állíthatjuk ritkábbra is, de ez megfelelő.
- www-data: A feladat ennek a felhasználónak a nevében kerül végrehajtásra. A már korábban is említett mod_php miatt a www-data felhasználó kell, hogy futtassa ezt a scriptet.
- /usr/bin/php: A Parancssori (CLI) PHP futási helye.
- /opt/matomo/console...: A futtatandó parancs és paraméterei, kapcsolói. Jelen esetben a Matomo rendszer konzol scriptje, annak megadva a külső elérési URL címet.
Figyelem! Itt mindenki a saját Matomo példányára mutató URL címet adja meg! Ami lehet a szerver IP-címe alatti /matomo könyvtár, vagy a szerveren futó valamelyik weboldal alatti /matomo könyvtár, ami már be van állítva a megbízható hosztok közé. - És végül a kimenet átirányítása a megfelelő naplófájlba.
Ezután, ha kivártuk a következő 5 precre kerek időt, és benézünk a /var/log/matomo/ könyvtárba, akkor már láthatunk is egy 4-5 kbyte méretű fájlt. Ha megnyitjuk, akkor ilyesmi van benne:
cat /var/log/matomo/matomo.log
INFO [2019-08-26 15:00:01] 18921 --------------------------- INFO [2019-08-26 15:00:01] 18921 INIT INFO [2019-08-26 15:00:01] 18921 Running Matomo 3.11.0 as Super User INFO [2019-08-26 15:00:01] 18921 --------------------------- INFO [2019-08-26 15:00:01] 18921 NOTES INFO [2019-08-26 15:00:01] 18921 - If you execute this script at least once per hour (or more often) in a crontab, you may disable 'Browser trigger archiving' in Matomo UI > Settings > General Settings. INFO [2019-08-26 15:00:01] 18921 See the doc at: https://matomo.org/docs/setup-auto-archiving/ INFO [2019-08-26 15:00:01] 18921 - Reports for today will be processed at most every 900 seconds. You can change this value in Matomo UI > Settings > General Settings. INFO [2019-08-26 15:00:01] 18921 - Reports for the current week/month/year will be requested at most every 3600 seconds. INFO [2019-08-26 15:00:01] 18921 --------------------------- INFO [2019-08-26 15:00:01] 18921 START INFO [2019-08-26 15:00:01] 18921 Starting Matomo reports archiving... INFO [2019-08-26 15:00:01] 18921 - tracking data found for website id 3 since 2019-08-25 22:00:00 UTC (since midnight) INFO [2019-08-26 15:00:01] 18921 Will pre-process for website id = 3, period = day, date = last8 INFO [2019-08-26 15:00:01] 18921 - pre-processing all visits INFO [2019-08-26 15:00:02] 18921 Archived website id = 3, period = day, 0 segments, 6 visits in last 8 days, 1 visits today, Time elapsed: 0.973s INFO [2019-08-26 15:00:02] 18921 Will pre-process for website id = 3, period = week, date = last8 INFO [2019-08-26 15:00:02] 18921 - pre-processing all visits INFO [2019-08-26 15:00:03] 18921 Archived website id = 3, period = week, 0 segments, 6 visits in last 8 weeks, 1 visits this week, Time elapsed: 1.058s INFO [2019-08-26 15:00:04] 18921 Will pre-process for website id = 3, period = month, date = last8 INFO [2019-08-26 15:00:04] 18921 - pre-processing all visits INFO [2019-08-26 15:00:05] 18921 Archived website id = 3, period = month, 0 segments, 6 visits in last 8 months, 6 visits this month, Time elapsed: 1.340s INFO [2019-08-26 15:00:05] 18921 Will pre-process for website id = 3, period = year, date = last7 INFO [2019-08-26 15:00:05] 18921 - pre-processing all visits INFO [2019-08-26 15:00:06] 18921 Archived website id = 3, period = year, 0 segments, 6 visits in last 7 years, 6 visits this year, Time elapsed: 1.093s INFO [2019-08-26 15:00:06] 18921 Archived website id = 3, 4 API requests, Time elapsed: 4.478s [1/1 done] INFO [2019-08-26 15:00:06] 18921 Done archiving! INFO [2019-08-26 15:00:06] 18921 --------------------------- INFO [2019-08-26 15:00:06] 18921 SUMMARY INFO [2019-08-26 15:00:06] 18921 Total visits for today across archived websites: 1 INFO [2019-08-26 15:00:06] 18921 Archived today's reports for 1 websites INFO [2019-08-26 15:00:06] 18921 Archived week/month/year for 1 websites INFO [2019-08-26 15:00:06] 18921 Skipped 0 websites INFO [2019-08-26 15:00:06] 18921 - 0 skipped because no new visit since the last script execution INFO [2019-08-26 15:00:06] 18921 - 0 skipped because existing daily reports are less than 900 seconds old INFO [2019-08-26 15:00:06] 18921 - 0 skipped because existing week/month/year periods reports are less than 3600 seconds old INFO [2019-08-26 15:00:06] 18921 Total API requests: 4 INFO [2019-08-26 15:00:06] 18921 done: 1/1 100%, 1 vtoday, 1 wtoday, 1 wperiods, 4 req, 4615 ms, no error INFO [2019-08-26 15:00:06] 18921 Time elapsed: 4.615s INFO [2019-08-26 15:00:06] 18921 --------------------------- INFO [2019-08-26 15:00:06] 18921 SCHEDULED TASKS INFO [2019-08-26 15:00:06] 18921 Starting Scheduled tasks... INFO [2019-08-26 15:00:06] 18921 Scheduler: executing task Piwik\Plugins\ExamplePlugin\Tasks.myTask... INFO [2019-08-26 15:00:06] 18921 Scheduler: finished. Time elapsed: 0.000s INFO [2019-08-26 15:00:06] 18921 Scheduler: executing task Piwik\Plugins\CustomPiwikJs\Tasks.updateTracker... INFO [2019-08-26 15:00:06] 18921 Scheduler: finished. Time elapsed: 0.001s INFO [2019-08-26 15:00:06] 18921 Scheduler: executing task Piwik\Plugins\PrivacyManager\Tasks.deleteLogData... INFO [2019-08-26 15:00:06] 18921 Scheduler: finished. Time elapsed: 0.006s INFO [2019-08-26 15:00:06] 18921 Scheduler: executing task Piwik\Plugins\PrivacyManager\Tasks.anonymizePastData... INFO [2019-08-26 15:00:06] 18921 Scheduler: finished. Time elapsed: 0.001s INFO [2019-08-26 15:00:06] 18921 done INFO [2019-08-26 15:00:06] 18921 ---------------------------
Itt mindent leír az összesítési ciklussal kapcsolatban. Hány weboldal statisztikát összesített, hányat hagyott ki, miért hagyta ki, stb. Jelen esetben azt írja, hogy nem történt az oldalon aktivitás az utolsó script futás óta, így nem volt mit összesítenie. Ha ilyenkor elkezdenénk mászkálni az oldalon, utána már más lenne a kimenete ennek az összesítőnek.
Tehát a lényeg itt az, hogy az összesítés már lefut a háttérben a megfelelő időközönként, és a kimenete hozzáfűzésre kerül ehhez a fájlhoz.
Webes archiválás kikapcsolása
Ha idáig minden rendben ment, akkor lépjünk vissza a beállítások oldalra, majd ott bal oldalon válasszuk ki az "Alapbeállítások" menüpontot:
Itt a két felső narancssárga figyelmeztetéssel (ha van ilyen másnál is) most nem foglalkozunk, hanem az alatta lévő beállítást kapcsoljuk át a Nem opcióra. Ezzel letiltjuk a rendszert, hogy a webes felület megjelenítése során generálja le az összesítéseket és archiválásokat, így marad a háttérben futó cron feladat, ami 5 percenként elvégzi ugyanezt.
Mentsük le az űrlapot, majd lépjünk vissza a korábbi Rendszerellenőrzés oldalra, ahol a részleteket is láttuk:
És itt már láthatjuk, hogy az "Archive Cron" és a "Last Successful Archiving Completion" sorainál zöld pipa van. Valamint írja is az utolsó sikeres archiválás idejét.
Naplófájl forgatása a Logrotate programmal
Eddig minden tökéletes, illetve majdnem minden. A fent látott archiválási ciklus kimenete minden egyes alkalommal hozzáfűződik a meglévő naplófájlhoz, mivel a cron feladatban a kimenet átirányításánál nem a szimpla ">" jelet alkalmaztuk, hanem a dupla ">>" jelet. Így nem csak az utolsó ciklus kimenetét nézhetjük vissza, hanem az eddigi összeset. Ez viszont azzal jár, hogy egy idő után a naplófájlunk mérete nagyon nagy lesz, kezelése bonyolultabbá válik, valamint a nagy méretű fájlokat a rendszer is kicsit lassabban tudja írni, ami többlet erőforrást igényel. Ennek elkerülése érdekében naplófájl forgatást alkalmazunk. Erről korábban már készítettem egy külön leírást, ezért itt most nem részletezem, csak a kész konfigurációt mutatom be.
Lépjünk be a /etc/logrotate.d/ könyvtárba:
cd /etc/logrotate.d/
Majd hozzunk létre egy új fájlt a Matomo számára:
nano matomo
És tegyük bele az alábbi tartalmat, majd mentsük le:
/var/log/matomo/matomo.log { rotate 7 daily copytruncate compress delaycompress missingok notifempty }
(Az opciók jelentéseit a fentebb már linkelt leírás tartalmazza.)
Ezzel további teendő nincsen, innentől már a logrotate végzi a dolgát.
Adatbázis maximális csomagméret beállítása
Ha megnézzük újra a Matomo - beállítások - Rendszerellenőrzés oldalát, akkor a soron következő probléma az adatbázis maximális csomagméret: A "Max Packet Size" sorban egy ilyen figyelmeztető üzenet áll:
"It is recommended to configure a 'max_allowed_packet' size in your MySQL database of at least 64MB. Configured is currently 16MB. "
Természetesen így is működik a Matomo rendszerünk, azonban az optimális működés érdekében fel kell emelnünk a MySQL/MariaDB adatbázis kiszolgálónk beállításaiban a maximális csomagok méretét legalább 64 Mb-ra.
Nyissuk meg szerkesztésre (root-ként) az Adatbázis kiszolgálónk konfigurációs fájlját:
MySQL konfigurációs fájl
Régebbi (pl. Debian 8) rendszereken:
nano /etc/mysql/my.cnf
MariaDB konfigurációs fájl
Újabb (pl. Debian 9, Ubuntu 18.04 LTS, stb) rendszereken pedig:
nano /etc/mysql/mariadb.conf.d/50-server.cnf
Ha megvan a fájl, keressük meg benne a "max_allowed_packet" változót (nano-ban a CTRL+W a keresés), írjuk át az értékét 16M-ről 64M-re, és mentsük le.
Indítsuk újra az adatbázis kiszolgálót (itt mindegy melyiket használjuk, ugyanaz a parancs).
systemctl restart mysqld.service
Ezután ha visszanézünk a Matomo Rendszerellenőrzés oldalára és ráfrissítünk, akkor már a "Max Packet Size" sorában is zöld pipa van:
Kényszerített SSL kapcsolat
A Matomo készítői erősen javasolják, hogy a kezelőfelületet csak SSL kapcsolaton keresztül használjuk. Ezért ha nem áll rendelkezésre a HTTPS elérhetősége a tárhelynek, hibának veszi. A működést nem korlátozza, de itt hibaként jelenik meg.
Ebben a leírásban most nem térünk ki az SSL beállítására, ezért csak néhány linket osztok itt meg, amikkel érdemes elindulni ezzel a témával kapcsolatban:
LAMP rendszerekhez sajnos még nem készítettem ilyen leírásokat, de apránként pótolom ezeket is. Így ha ilyen szervert választottunk kiindulásnak és nem sikerült beállítani rajta az SSL-t, akkor ezt a részt ugorjuk át, a statisztikai rendszerünk enélkül is szépen fog működni.
Mivel a Debian 9 (stretch) V1.0-ás tökéletes szerveren készítem ezt a leírást, ezért a bemutató kedvéért most bekapcsoltam az ISPConfigban a WordPress tesztoldalhoz egy (self-signed) SSL-t, így most HTTPS-en keresztül tudom elérni az oldalt is, és rajta keresztül a Matomo felületét is. Persze, most a böngésző dobálja a figyelmeztetéseket a nem hiteles SSL miatt, de ezzel most nem foglalkozunk.
Ha tehát sikerült valamilyen formában (self signed, ingyenes Let's Encrypt, vásárolt tanúsítvány, stb) beállítanunk az SSL-t, akkor a Matomo konfigurációs fájljában kapcsoljuk be, hogy csak SSL kapcsolaton keresztül lehessen ezután elérni a felületét.
Az alábbi beállítást csak akkor végezzük el, ha beállítottunk valamilyen SSL-t, azaz HTTPS kapcsolaton is el tudjuk érni a Matomo felületét. Ellenkező esetben nem lesz elérhető a rendszer!
Nyissuk meg a konfigurációs fájlt:
nano /opt/matomo/config/config.ini.php
És a [General] szekcióhoz adjuk hozzá az alábbi beállítást:
force_ssl = 1
Ezután ha ismét ráfrissítünk a Matomo Rendszerellenőrzés oldalára, akkor a "Forced SSL Connection" sor is zöldre változott:
Geolokáció beállítása
Már csak a geolokáció beállítása maradt hátra, azonban ez az oldal már nagyon hosszú lett volna így, ezért átkerült a következő oldalra.
- Enciklopédia - Matomo (Piwik) webanalitika
- Hogyan frissítsük Matomo (korábban Piwik) webanalitikai rendszerünket a 4.x verzióra
- Mit tegyünk, ha a Matomo webanalitikai rendszerünk "AH01630: client denied by server configuration" típusú Apache hibákat generál, ami miatt a Fail2Ban letiltja az IP-címünket?
- Matomo.org
- Matomo.org - Troubleshooting
- Naplófájlok forgatása és tömörítése a Logrotate programmal
- Szerver monitorozása a Munin segítségével Debian 9 (Stretch) és Debian 10 (Buster) rendszereken
Lapozó
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
- 83 megtekintés