Valt een WordPress site op vrijdagmiddag uit, dan spelen er meteen twee problemen: de site moet weer werken, en iedereen moet het eens worden over wie het veroorzaakt heeft.
Dat tweede probleem duurt bijna altijd langer. De ontwikkelaar wijst naar de campagne die net live is gegaan. De marketeer wijst naar de server. Het bureau krijgt van beide kanten telefoontjes en heeft zelf geen data om op te varen. Tegen de tijd dat iedereen het eens is over waar je moet zoeken, heeft de storing al een hoop geld gekost. En de discussie erover ook.
De oorzaak is niet dat teams het oneens zijn. De oorzaak is dat ieder team maar een stukje van de data ziet. De ontwikkelaar ziet de code. De marketeer ziet het verkeer. Het bureau ziet de wachtrij met supporttickets. Niemand kijkt op hetzelfde moment naar hetzelfde, dus niemand kan iets uitsluiten.
Kinsta pakt dat anders aan en zet elk team op hetzelfde diagnostische niveau. De data waarmee de supporttechnici van Kinsta een probleem onderzoeken, zoals responscodes, PHP-prestaties, cacheratio’s en verzoeklogs, is precies de data die elke MyKinsta-gebruiker met toegang tot Analytics voor zich heeft. Kijkt iedereen naar dezelfde signalen, dan wordt een kapotte site iets wat je samen diagnosticeert in plaats van iets waar je ruzie over maakt.
Dat verandert ook hoe teams met support omgaan. In deze gids lees je welke diagnostische tools er in MyKinsta zitten, wat ze laten zien, wanneer je ze gebruikt en hoe je er samen mee werkt in plaats van in je eentje te zitten debuggen.
Waarom prestatieproblemen schuldvragen worden
Bij een moderne WordPress site ligt de verantwoordelijkheid zelden bij één persoon. Ontwikkelaars beheren de codebase. Marketeers voeren campagnes uit. Bureaus of freelancers regelen de hosting. Iedereen doet zijn werk, alleen overlapt hun zicht op de site nergens.
En zodra een site uitvalt, verandert dat gat in zichtbaarheid een technisch probleem ongemerkt in een persoonlijk probleem:
- Ontwikkelaars kijken naar de code, niet naar de server. Hun blik stopt bij de applicatielaag, dus een oorzaak aan de serverkant zien ze simpelweg niet.
- Marketeers zien het verkeer, niet de database. Een piek door een campagne lijkt dan de voor de hand liggende oorzaak, want dat is de enige variabele die zij kunnen meten.
- Bureaus krijgen de klacht binnen, maar hebben de data niet. Zo worden ze een doorgeefluik tussen partijen in plaats van de plek waar de antwoorden vandaan komen.
Zonder gemeenschappelijk referentiepunt gaat elke partij ervan uit dat de oorzaak ergens anders ligt. Veel hostingplatforms houden dat patroon in stand door diagnostische data binnen het supportteam te houden. Je opent een ticket en wacht, terwijl iemand anders de logs leest waar jij niet bij kunt.
Kinsta doet het precies andersom. Hieronder zie je welke tools je als eerste inzet, en hoe je ze gebruikt als gezamenlijke workflow in plaats van solo.
Wat het Analytics-dashboard van MyKinsta laat zien als er iets misgaat
Werkt een site niet goed, dan bepaal je eerst met wat voor probleem je te maken hebt. Trage, kapotte en overbelaste sites vragen namelijk elk om een andere aanpak. Stel je die diagnose verkeerd, bijvoorbeeld door een cachingprobleem aan te zien voor een serverprobleem of een piek in fouten voor een verkeersprobleem, dan verspil je ieders tijd.
In het Analytics-gedeelte van MyKinsta begint die diagnose.
Onder de sectie Analytics van MyKinsta vind je data op bedrijfsniveau. Voor één site ga je naar Sites > sitenaam > Analytics. In beide gevallen geldt: dezelfde rapporten zijn beschikbaar voor iedereen met toegang tot Analytics.
Controleer of de site echt fouten geeft
Stel om te beginnen vast of de site echt uitvalt of alleen traag is. Dat zijn twee dingen met verschillende oorzaken en verschillende oplossingen, en juist als je ze door elkaar haalt, beginnen de schuldvragen.
Het tabblad Response geeft daar antwoord op. De centrale grafiek, de uitsplitsing van responscodes, laat zien hoe de HTTP-statuscodes die je site in de gekozen periode teruggaf zijn verdeeld.
Een cluster 5xx-codes wijst richting de server of de applicatie, terwijl 4xx-codes duiden op problemen met toegang tot resources. Twee andere grafieken laten je verder inzoomen:
- De uitsplitsing van 500-fouten haalt een algemene 500-fout uit elkaar van een 502 bad gateway of een 503 service unavailable, die elk op een andere oorzaak wijzen.
- De uitsplitsing van 400-fouten splitst de codes aan de clientkant uit, zodat je een stortvloed aan 404’s kunt onderscheiden van responses die duiden op problemen met authenticatie, rechten of rate limiting.
Omdat iedereen met toegang tot Analytics dezelfde uitsplitsing ziet, kun je direct aan de slag met het concrete probleem in plaats van er eerst nog over te moeten overleggen.
Maak onderscheid tussen een trage site en een site die uitvalt
Een site die er zes seconden over doet om te laden en een site die 500-fouten geeft, voelen voor een gefrustreerde bezoeker ongeveer hetzelfde. De oorzaken verschillen alleen volledig. Op het tabblad Prestatie haal je ze uit elkaar.
Een paar rapporten zijn hier bij elk onderzoek naar een trage site de moeite waard:
- Gemiddelde PHP + MySQL responstijd laat zien hoe lang de applicatie erover doet om elk niet-gecachet verzoek op te bouwen en op te vragen. Een plotselinge piek is meestal het eerste teken van teruglopende prestaties, en niet van een infrastructuurprobleem.
- PHP-doorvoer laat zien hoeveel verzoeken er in die periode zijn uitgevoerd. Valt een vertraging samen met een piek in de doorvoer en niet met een codewijziging, dan zit de oorzaak waarschijnlijk in de belasting en niet in een bug.
- AJAX-verbruik brengt pieken in de activiteit van admin-ajax.php aan het licht: een veelvoorkomende en makkelijk over het hoofd geziene belasting van backend resources, veroorzaakt door plugins en ingelogde gebruikers die achtergrondtaken draaien.
- Onder Top maximale upstreamtijd staan de traagste afzonderlijke paden. Zo zie je meteen welke pagina of welk endpoint het gemiddelde van de site omhoog trekt, zonder te hoeven gissen.
Bij elkaar vertellen ze je of je de applicatie moet optimaliseren of een storing moet escaleren.
Kijk hoeveel van de site uit de cache wordt geleverd
Een site kan ook traag aanvoelen om redenen die niets met code of infrastructuur te maken hebben: er komt te weinig uit de cache. Zakt de cacheratio, dan verwerkt de server verzoeken die hij helemaal niet zou hoeven verwerken, en lopen de responstijden op. Dit is een van de meest voorkomende aanleidingen voor de vraag ‘Ligt het aan de host?’. En bijna nooit is de host de boosdoener.
In het gedeelte Cache zie je hoe verzoeken worden afgehandeld in de verschillende cachinglagen van Kinsta.
Elk verzoek komt in een van deze drie statussen terecht:
HITbetekent dat Kinsta het verzoek vanuit de cache afhandelt. Dat is wat je voor het meeste verkeer wilt.BYPASSbetekent dat een regel of een conflict het verzoek buiten de cache houdt.MISSbetekent dat de content nog niet in de cache staat, maar er na het eerste verzoek wel in komt.
De cachegrafiek van een gezonde site bestaat grotendeels uit HIT’s. Loopt het percentage BYPASS op, dan noemt het rapport Meest voorkomende server cache-bypasses precies de paden die de cache overslaan.
Sommige bypasses zijn geen enkel probleem, zoals de WordPress inlogpagina die nooit in de cache komt. Maar staat er een pagina in die lijst die wél gecachet zou moeten worden, dan wijst dat op een pluginconflict of op je cacheregels. Lees je deze rapporten terwijl je naar een trage pagina kijkt, dan zie je of die pagina gecachet is in plaats van aan te nemen dat de host het probleem is.
Zoek uit wat je resources opslokt
Geeft een site geen fouten, maar verbruikt hij meer bandbreedte of capaciteit dan zou moeten, dan vind je de oorzaak in het rapport Top verzoeken. Problemen met resources zijn het lastigst te achterhalen: een overschrijding van de bandbreedte of vertraging onder hoge belasting komt meestal zonder foutcode voorbij.
Drie rapporten maken van dat giswerk een concreet antwoord:
- Belangrijkste aanvragen per serverbandbreedte laat zien welke URL’s de meeste data rechtstreeks van je originserver halen.
- Top verzoeken op totale bandbreedte telt de data mee die via het CDN en de edge cache binnenkomt, zodat je het volledige gewicht van elk verzoek ziet.
- Belangrijkste aanvragen per view toont de meest opgevraagde resources, ongeacht hun grootte. Zo herken je een endpoint dat constant onder belasting staat in plaats van één zwaar bestand.
Samen laten ze zien waar een piek in het resourceverbruik vandaan komt: een te groot mediabestand, een uit de hand gelopen endpoint of een crawler die hetzelfde pad duizenden keren opvraagt. De oplossing is vanaf daar meestal het bestand optimaliseren, het via een CDN leiden of het endpoint aanpakken.
Zit crawler- of botverkeer achter die piek, dan kun je met Botbescherming van Kinsta niet-menselijk verkeer direct vanuit MyKinsta identificeren, classificeren en blokkeren. Zonder plugin, zonder supportticket.
Hoe APM een prestatieprobleem tot aan de bron traceert
De Analytics-rapporten laten zien wat er op een site gebeurt. De APM-tool van Kinsta vertelt je waarom. Waar Analytics laat zien dát de PHP-responstijd om 14.00 uur piekte, laat APM zien welke pluginfunctie, databasequery of externe API-aanroep die piek veroorzaakte.
APM zit bij elk Kinsta-pakket inbegrepen en draait binnen MyKinsta.
Gebruik APM als sessie, niet continu
Het Analytics-dashboard registreert continu op de achtergrond, maar de APM-agent werkt anders: die belast de CPU en het geheugen van je server zolang hij data verzamelt. Kinsta raadt daarom aan om APM alleen te draaien terwijl je actief een probleem onderzoekt.
Ga voor een sessie naar Sites > sitenaam > APM, klik op APM inschakelen en kies een monitoringperiode: 2, 4, 12 of 24 uur. Aan het einde van die periode schakelt APM zichzelf automatisch uit.
Dat geeft je een eenvoudige werkwijze:
- Start APM als je een probleem vermoedt of kunt reproduceren, zodat je site er tijdens normaal gebruik geen last van heeft.
- Kies een periode waarin het probleem zich voordoet en reproduceer het daarna, of wacht tot het vanzelf terugkomt, zodat de tool het met live data vastlegt.
- Bekijk de resultaten zodra er data binnen is en schakel APM daarna weer uit.
De APM-resultaten lezen
APM verdeelt de verzamelde data over vier tabbladen: Transacties, WordPress, Database en Extern.
Begin bij Transacties om de traagste verzoeken te vinden. Klik je een transactie open, dan krijg je een tijdlijn van alle processen die bij dat verzoek horen, met de zwaarste spans gemarkeerd. Daarmee weet je of je moet optimaliseren op een trage databasequery, een specifieke pluginfunctie of een API van een derde partij.
Het tabblad Extern is vooral handig om de host uit te sluiten. Komt de vertraging van een transactie door een externe API-aanroep, dan laat de APM-data dat zwart op wit zien. Dat is het verschil tussen een supportticket met de melding ‘de site is traag’ en een ticket waarin staat ‘de vertraging zit in de API van onze e-mailprovider, niet in de server’.
Hoe de logviewer en het activiteitenlogboek een tijdlijn reconstrueren
Een incident oplossen valt of staat meestal met de vraag wat er is gebeurd, en in welke volgorde. Twee registraties in MyKinsta helpen je die tijdlijn te reconstrueren: de logviewer legt vast wat de site doet, het activiteitenlogboek legt vast wat mensen doen.
De logviewer laat zien wat de site rapporteert, niet hoe hij presteert. Op het scherm Logs vind je voor elke site in MyKinsta drie bestanden:
error.loglegt PHP-fouten en waarschuwingen vast. Dit is de eerste plek om te kijken bij een kapotte pagina.kinsta-cache-perf.loglegt de cacheprestaties vast en laat zien of pagina’s uit de cache komen of die omzeilen.access.logregistreert elk HTTP-verzoek dat de site bereikt. Hier spoor je verkeerspatronen en terugkerende 404-fouten op.
De ingebouwde viewer laadt tot 20.000 regels en heeft een zoekveld waarmee je op elke tekststring filtert. Wil je de logs in een externe tool bekijken, dan download je ze via de Bestandsbeheerder in MyKinsta.
Het activiteitenlogboek: wat mensen hebben gedaan
Het activiteitenlogboek registreert elke actie die gebruikers in MyKinsta op een site uitvoeren, netjes op volgorde van tijd.
Je vindt de activiteitenlogboeken onder Sites > sitenaam > Gebruikersactiviteit. Elk item beschrijft de actie in gewone taal, met daarbij de gebruiker, een tijdstempel en een statuspictogram. Een groen vinkje betekent gelukt, een rood uitroepteken mislukt.
In combinatie met de andere logbestanden brengt dat je snel bij de oorzaak. Heb je bijvoorbeeld een gevuld error.log-bestand, dan open je het activiteitenlogboek, filter je op hetzelfde tijdvenster en zie je welke acties daarbij horen.
Hoe uptime monitoring zorgt voor gedeeld inzicht
De tools hierboven zijn reactief. Uptime monitoring maakt detectie proactief: je hoort niet via een klacht van een klant dat er iets mis is, maar komt er tegelijk met Kinsta achter.
Kinsta controleert elke site op het platform zo’n 480 keer per dag. Zet je de meldingen voor monitoring aan onder Gebruikersinstellingen > Meldingen, dan krijg je een e-mail zodra er iets kritieks speelt:
- Sitefouten duiden op een probleem dat op de site zelf is gedetecteerd.
- SSL-fouten wijzen op iets in het certificaat of de configuratie, nog voordat bezoekers worden weggestuurd.
- Domeinvervaldatum waarschuwt je voor een domein dat bijna verloopt, ruim voordat het daadwerkelijk verloopt.
Die e-mails gaan pas uit na drie mislukte controles op rij, dus niet al na de eerste. Zo filter je de korte storingen eruit die je anders zouden bedelven onder valse alarmen.
SIX15 Solutions beheert meer dan 30 klantsites met deze monitoring. De waarde zit daarbij niet zozeer in de controle zelf, maar in hoe vaak een probleem al is opgelost voordat een klant er iets van merkt.
Ik host op dit moment meer dan 30 klantwebsites op mijn Agency-pakket, van kleine marketingsites tot volwaardige membershipsites met duizenden gebruikers, zonder problemen of downtime.
Niet elke waarschuwing betekent overigens dat er iets mis is. Waarschuwingen over pakketlimieten laten je weten dat je tegen de grenzen van je pakket aanloopt, en dat werkt als vroege waarschuwing. Via je analytics zie je vervolgens waar het vandaan komt: een campagne die meer verkeer oplevert dan verwacht, bijvoorbeeld, of activiteit van crawlers of bots.
Gedeelde data maakt een einde aan de schuldvraag
Bij een kapotte site gaat de meeste tijd zitten in uitzoeken wie verantwoordelijk is, niet in de oplossing zelf. Analytics in MyKinsta laat zien of een site traag, kapot of overbelast is. En met de APM-tool, de logviewer, het activiteitenlogboek, uptime monitoring en meer weet iedereen tegelijk waar het probleem zit en kan iedereen meteen aan de slag, zonder eerst in een ticketwachtrij te belanden.
Het idee is dat je deze overzichten behandelt als een gezamenlijke workflow. Heeft elk teamlid de juiste toegang tot Analytics, dan spreek je af op basis van welke rapporten je werkt vóórdat iemand een ticket opent. Zo blijft het gesprek een diagnose in plaats van een ruzie.
Beheer je sites waar meerdere teams samen verantwoordelijk zijn, dan geeft de managed WordPress hosting van Kinsta elk van die teams een plek aan de diagnostische tafel. Beheer je klantsites op schaal, dan is het Agency Partner Programma de moeite waard vanwege de tools voor gedeelde toegang en gezamenlijk beheer.
