Magento 2 monitoring — wat je moet meten en waarom

Magento 2 monitoring — wat je moet meten en waarom

We spreken gemiddeld drie keer per maand met een bedrijf dat monitoring wil opzetten nadat er iets mis is gegaan. Een trage checkout die weken onopgemerkt bleef. Een cron die al drie dagen niet draait. Orders die niet naar het ERP gaan omdat een wachtrij vol staat.

Monitoring ná een incident opzetten is beter dan niets. Monitoring vóór een incident opzetten is wat je wilt. Dit artikel legt uit wat je meet, welke tools je gebruikt en hoe je alerts inricht zodat ze nuttig zijn in plaats van ruis.

Wat je leert in dit artikel

• Welke metrics er toe doen voor Magento 2
• New Relic vs Datadog vs open source alternatieven
• Hoe je cron monitoring inricht
• Alerts: wat je instelt en wat je negeert
• Logging en foutopsporing in productie

De drie lagen van Magento monitoring

Magento monitoring werkt op drie niveaus. Je hebt alle drie nodig.

De zakelijke laag is de meest waardevolle. Een conversieratio die met 20% daalt is een signaal dat iets mis is — ook als de infrastructuurmetrics normaal lijken. Maar zonder infrastructuur- en applicatiemonitoring weet je niet wat je moet repareren.

Infrastructuurmonitoring: de basis

CPU en geheugen

Magento is resource-intensief. Een PHP-FPM-worker die niet correct is geconfigureerd kan geheugen lekken. Een Elasticsearch-reindex kan de CPU pieken.

Stel alerts in op:

• CPU > 80% gedurende meer dan 5 minuten
• Geheugen > 85%
• Schijf > 80% (log files groeien onverwacht snel)

Database performance

De MySQL slow query log is je eerste diagnostisch hulpmiddel.

-- Controleer slow query log status
SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';

-- Stel in via MySQL config
slow_query_log = ON
long_query_time = 1
slow_query_log_file = /var/log/mysql/slow.log

Queries boven de 1 seconde zijn een signaal. Queries boven de 5 seconden zijn een probleem. Wij zien regelmatig dat een niet-geïndexeerde kolom in een custom module de gehele database vertraagt tijdens piekbelasting.

Redis en Varnish

Als Magento gebruikmaakt van Redis voor cache en sessies, monitor dan:

• Redis geheugengebruik (bij volloop gooit Redis willekeurige keys weg)
• Hit/miss ratio (lage hit ratio betekent cache werkt niet goed)
• Verbindingsaantal (te veel verbindingen blokkeren nieuwe verzoeken)

Voor Varnish: de cache hit ratio moet boven de 90% liggen voor gecachte pagina's.

Applicatiemonitoring: waar New Relic en Datadog APM voor zijn

New Relic

New Relic APM is de tool die wij het meest inzetten bij Magento-klanten. Het instrueert PHP automatisch en geeft inzicht in:

• Gemiddelde en P95/P99 response time per transactie
• Tijdverdeling per laag (PHP, database, externe API's, cache)
• Error rate per endpoint
• Apdex score (een gecombineerde snelheids-/tevredenheidsscore)

De Magento 2-integratie werkt out-of-the-box. Na installatie van de PHP-agent zie je binnen 15 minuten transactiedata.

# New Relic PHP agent installeren (Ubuntu/Debian)
echo 'deb http://apt.newrelic.com/debian/ newrelic non-free' \
  | sudo tee /etc/apt/sources.list.d/newrelic.list
wget -O- https://download.newrelic.com/548C16BF.gpg | sudo apt-key add -
sudo apt-get update && sudo apt-get install newrelic-php5
sudo newrelic-install install

De meest waardevolle feature van New Relic voor Magento: transaction traces. Als een pagina langzaam is, zie je precies welke database query of welk externe API-verzoek de vertraging veroorzaakt.

Datadog

Datadog combineert infrastructuur-, applicatie- en logmonitoring in één platform. Dat maakt correlatie eenvoudiger: je ziet in één dashboard dat een CPU-piek samenvalt met trage checkout-transacties.

Datadog is duurder dan New Relic bij schaal, maar de breedte van het platform maakt het aantrekkelijk als je ook infrastructuurmonitoring en logging wilt centraliseren.

• New Relic: ~€250-500/maand voor een gemiddelde webshop
• Datadog: ~€400-800/maand voor vergelijkbare coverage

Open source alternatief: Prometheus + Grafana

Voor teams die kosten willen beperken en technische capaciteit hebben: Prometheus verzamelt metrics, Grafana visualiseert ze. Beide zijn open source.

Je mist wel de automatische PHP-instrumentatie van New Relic en Datadog. Je moet metrics handmatig exporteren via een PHP-library.

// Prometheus PHP client - custom metric registreren
use Prometheus\CollectorRegistry;
use Prometheus\RenderTextFormat;
use Prometheus\Storage\Redis;

$registry = new CollectorRegistry(new Redis(['host' => 'localhost']));
$counter = $registry->getOrRegisterCounter(
    'magento',
    'orders_placed_total',
    'Totaal aantal geplaatste orders',
    ['store_code']
);
$counter->incBy(1, ['nl']);

Cron monitoring — de meest onderschatte prioriteit

Magento draait op cron. Indexers, orderverwerking, e-mailwachtrijen, cache-invalidatie — het werkt via cronjobs. Als cron stopt, merkt de klant dat niet direct. Jij merkt het pas als er klachten zijn over ontbrekende ordermails of verouderde zoekresultaten.

Wat je monitort

# Controleer Magento cron status
php bin/magento cron:status

# Bekijk cron_schedule tabel op hangende of mislukte jobs
SELECT job_code, status, created_at, scheduled_at, executed_at, finished_at
FROM cron_schedule
WHERE status IN ('error', 'missed')
ORDER BY scheduled_at DESC
LIMIT 50;

Een simpele maar effectieve aanpak: laat een cronjon elke 5 minuten een HTTP-ping sturen naar een external service (Healthchecks.io, Dead Man's Snitch, of Datadog synthetics). Als de ping uitblijft, krijg je een alert.

# In crontab: elke 5 minuten een healthcheck ping
*/5 * * * * php /var/www/magento/bin/magento cron:run && \
  curl -fsS --retry 3 https://hc-ping.com/jouw-uuid > /dev/null

Specifieke jobs om te monitoren

Zakelijke monitoring: conversie en ordervolume

Dit is de monitoring die het meest directe bedrijfseffect heeft.

Stel een alert in als het ordervolume per uur meer dan 30% afwijkt van het gemiddelde voor dat uur op die dag van de week. Een conversieratio die daalt van 2,1% naar 1,3% is een signaal van een probleem — ook als alle servers groen staan.

Wij bouwen dit doorgaans op twee manieren:

-- Uurlijks ordervolume per winkel (voor dashboard)
SELECT
    DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00') AS uur,
    store_id,
    COUNT(*) AS orders,
    SUM(grand_total) AS omzet
FROM sales_order
WHERE created_at >= NOW() - INTERVAL 7 DAY
  AND status NOT IN ('canceled')
GROUP BY uur, store_id
ORDER BY uur DESC;

Alerts instellen die niet irritant zijn

Alert fatigue is een reëel probleem. Als elke kleine afwijking een notificatie stuurt, schakel je je telefoon stil en mis je het echte probleem.

1. Elke alert moet actie vereisen. Als je een alert krijgt en de eerste gedachte is "dit negeer ik wel even", is het geen goede alert.
2. Gebruik drempelwaarden, geen vaste getallen. Een CPU van 80% is een probleem op een server die normaal op 20% loopt, maar niet op een server die tijdens reindexing altijd naar 75% gaat.
3. Groepeer gerelateerde alerts. Als MySQL, PHP-FPM en Varnish tegelijk alarmen geven, is het waarschijnlijk één onderliggend probleem.
4. Onderscheid urgentie. PagerDuty/OpsGenie voor alerts die iemand 's nachts moeten wekken. E-mail voor alerts die de volgende ochtend aandacht vragen.

Conclusie

Monitoring is geen eenmalige installatie. Het is een systeem dat je onderhoudt. Drempelwaarden die vorig jaar klopten kloppen niet na een servermigratie of een piekseizoensperiode.

Begin met de basis: infrastructuurmetrics, New Relic APM, cron healthchecks en een eenvoudig ordervolume-dashboard. Dat geeft je 80% van de waarde voor 20% van de inspanning.

Meer complexiteit — distributed tracing, custom business metrics, log correlation — voeg je toe als je de basismonitoring stabiel hebt lopen.

Hulp nodig bij het opzetten van monitoring voor jouw Magento-installatie? Bekijk onze Magento hosting- en beheeropties of neem direct contact op. Onze Magento 2 diensten omvatten ook monitoring en beheer.

Veelgestelde vragen

Voor een enkele applicatieserver met APM: €200-400 per maand afhankelijk van datavolume. Grotere installaties met meerdere servers zijn duurder.

Ja. Prometheus + Grafana + Alertmanager is volledig open source. Je betaalt alleen voor hosting. Nadeel: je moet het zelf onderhouden en mist de automatische PHP-instrumentatie.

Combineer cron:status in de CLI met een externe healthcheck service. Alleen de CLI controleren is niet voldoende — als de server overbelast is, kan de cron-check zelf ook falen.

Boven de 0.85 voor de productieconfiguratie. Onder de 0.70 is zichtbaar voor gebruikers en leidt tot hogere bouncerates.