Optimale monitoring van WordPress met AppDynamics

Het is van groot belang om te zorgen voor een optimale gebruikerservaring van je website want performance en beschikbaarheid hebben grote invloed op het succes van je site. Of het nu gaat om het vinden van nieuwe klanten maar ook het behoudt van bestaande klanten.

Maar hoe zorg je dat deze ervaring optimaal is en blijft?

In deze post ga ik in op het bewaken van je WordPress site met AppDynamics. Ik geef een korte introductie van de twee producten, toegespitst op de samenwerking. Daarna beschrijf ik hoe je AppDynamics optimaal in kunt richten.

Monitoringtools zijn er in alle soorten en maten (en prijzen) en dus moet je goed nadenken over de juiste tool die bij je website past. AppDynamics is primair niet bedoelt voor het MKB maar voor enterprise-size organisaties. Wel heeft AppDynamics voor kleinere organisaties de Lite variant van hun monitoringplatform.

De technologie

Wat is WordPress?

Ja 90% van mijn bezoekers weten waarschijnlijk wel wat WordPress is maar toch wil ik het toelichten.

WordPressWordPress diensten is een op PHP gebaseerd blogplatform / CMS. Je kunt WordPress als een dienst afnemen via WordPress.com maar je kunt ook alles in eigen hand houden. Deze blogpost is van toepassing op de tweede variant.

Belangrijk om te weten is dat als jij je eigen WordPress site beheert en je monitoring in wilt zetten dat je voor AppDynamics ook je eigen infrastructuur moet beheren. Als je gebruik maakt van Shared Hosting is het interessant om naar synthetische monitoring te kijken.

Belangrijk om te weten voor degene die nog niet met WordPress hebben gewerkt is het volgende.

  • Je hebt de WordPress Core die door de open source community opgepakt wordt. Hierin zit de basis functionaliteit om inhoud te maken.
  • Je hebt een theme nodig om je site een bepaalde smoel te geven. Deze kun je downloaden vanaf wordpress.org maar er zijn ook veel andere sites waar je deze kunt vinden (StudioPress, ThemeForest, etc.)
  • Met plug-ins kun je extra functionaliteit toevoegen aan je site zoals een nieuwsbrief, de mogelijkheid om berichten te delen op sociale netwerken en meer.

In 80% van de gevallen zijn problemen met WordPress terug te voeren op het theme of één van de geinstalleerde plug-ins. Hierover later meer.

Een introductie van AppDynamics

In de wereld van APM, Application Performance Management, zijn er meerdere leveranciers actief. AppDynamics is er daar één van. Een Amerikaans bedrijf actief sinds 2010.

AppDynamics biedt een op agenten gebaseerde APM oplossing die zowel via een SaaS platform als On-Premise ingezet kan worden. Voor deze post maak ik gebruik van een SaaS omgeving maar dit verschilt niet van de On-Premise variant.

De agenten geven inzicht in de acties van de bezoekers van je website en op het moment dat daar problemen optreden kun je zien welke regels code impact hadden op dit probleem, welke database betrokken was en welke queries er uitgevoerd waren. De kracht van AppDynamics zit hem in het snel inzichtelijk maken van de betrokken componenten bij een probleem zodat de oorzaak snel te achterhalen en op te lossen is.

De setup

lampVoor deze post heb ik bij TransIP een Blade PureSSD X1 VPS opgezet met Ubuntu 14.04.2 LTS. Op deze machine heb ik een LAMP (Linux Apache MySQL PHP) stack geinstalleerd om WordPress te kunnen draaien.

Omdat het WordPress platform draait op PHP + MySQL maak ik gebruik van de PHP App Agent en DB Agent. Daarnaast zet ik End User Experience Monitoring in om de echte eindgebruiker te kunnen volgen. Om de VPS zelf te bewaken (CPU, memory, disk) draait er ook een Machine Agent.

De AppDynamics inrichting

Application Topology

De AppDynamics agents proberen automatisch een topologie van het WordPress landschap te schetsen.

In mijn geval zal dit een Web tier opleveren met daarin Apache/PHP nodes en 2 DB backends (MySQL). Zonder dat je hier iets voor hoef te configureren zal dit verschijnen in je Dashboard. Ook als er wijzigingen zijn zoals additionele nodes dan zal deze topologie automatisch bijgewerkt worden.

snapshot-topology

Maak je gebruik van Redis of Memcach als caching oplossing dan zal dit automatisch als backend gedefinieerd worden.

Business Transactions

Het belangrijkste element binnen AppDynamics is de Business Transaction (BT). Een BT is een actie van een eindgebruiker in de applicatie die voor de gehele organisatie herkenbaar is.

Voorbeelden zijn

  • Inloggen
  • Checkout
  • Book Flight

Deze BT’s zijn gebaseerd op URL’s die aangeroepen worden door de eindgebruikers als ze de website bezoeken.

WordPress bestaat uit pages (reguliere pagina’s) en posts (blogberichten). Uiteraard wordt niet voor elke pagina of blogbericht een nieuwe php pagina aangemaakt maar er wordt 1 php bestand aangeroepen met een parameter die de inhoud bepaald. Een voorbeeld is www.example.com/single.php?post_id=123.

Wat je in de praktijk ziet is dat deze URL’s niet duidelijk zijn voor de bezoeker en ook ze zijn ook niet zoekmachine vriendelijk. In dit geval wordt er middels een .htaccess bestand een vertaling gemaakt van vriendelijke naar niet zo vriendelijke URL’s. In zo’n geval kan het dus zijn dat je in je browser www.example.com/blog/monitoring-wordpress-appdynamics/ ziet maar dat dit onderwater vertaald wordt naar wat je hierboven hebt gezien.

Dit is belangrijk omdat de AppDynamics PHP agent deze vertaalslag niet ziet. De PHP agent haakt in op de Apache webserver nadat deze via het .htaccess bestand de vertaling heeft gemaakt. Je ziet daar dus alleen single.php voorbijkomen.

Let op! Dit betekent dus dat alle posts die gemaakt zijn op 1 hoop gegooit worden onder single.php. Dit is niet erg omdat je anders enorm veel metrieken genereerd die niet veel van elkaar zullen verschillen.

Gelukkig kun je binnen AppDynamics de automatische gedetecteerde BT’s wel hernoemen naar logische namen. En lees vooral ook verder naar het hoofdstuk over EUEM want daar zal de JavaScript agent het wel juist vertalen.

AppDynamics-BT-rename

Mijn advies is om, nadat je de PHP agent hebt geinstalleerd en je de eerste BT’s ziet binnenkomen, deze te hernoemen naar logische namen. Hieronder heb ik vast een aangezet gemaakt.

  • single.php > Single Post
  • page.php > Single Page
  • search.php > Search Page
  • category.php > Category Page
  • author.php > Author Page
  • index.php > Homepage
  • archive.php > Archive Page

Op de WordPress Developer site is meer informatie te vinden over de template hierachie.

Transaction Snapshots

Als de BT’s eenmaal goed ingericht zijn gaat AppDynamics baselining toepassen. Dit betekent dat hij gaat leren wat “normaal” gedrag is voor een BT. Dit berekent hij voor elke metriek die binnenkomt voor elke BT te weten Reponse Time, Call rate, Calls/min, Error rate, Errors/min.

Als er een afwijking op deze baseline waargenomen wordt zal AppDynamics deze classificeren in de categorien Slow, Very Slow, Stalled of Error. Indien een specifieke BT in deze categorien valt zal er een Transaction Snapshot genomen. Daarnaast wordt per BT elke 10 minuten een Periodic Snapshot genomen.

Een Snapshot is een foto moment van het applicatie landschap op het moment dat de BT uitgevoerd werd. Alleen de relevanten componenten en acties worden geregistreerd.

Als je vervolgens op Drill Down klikt krijg je alle details informatie te zien die nodig is om dit probleem te analyseren.

snapshot-callgraph

Je ziet nu de PHP bestanden en het regelnummer waar de tijd is gaan zitten.

Voor WordPress is het belangrijk om te weten dat je de focus moet leggen op de zaken die je op kunt lossen in het theme of de plug-in die je gebruikt. Dit is te herkennen aan de padnaam waar /wp-content/themes/<theme-naam>/ of /wp-content/plug-ins/<plugin-naam>/ gebruikt wordt. Aanpassingen aan andere bestanden gaan verloren na elke WordPress update omdat deze in de core zitten.

Web User Experience

Zoals in een eerdere paragraaf genoemd is het raadzaam om de End User Experience Monitoring ook in te zetten. Deze module werkt met een JavaScript agent die in de header van elke pagina meegegeven moet worden om zo te zorgen dat elke webpagina die aangeroepen wordt ook bewaakt wordt. De kracht van deze module is dat deze wel de URL weergeeft zoals de gebruiker dat ziet maar dat er ook een vertaling gemaakt wordt naar de BT die door de PHP Agent gegenererd wordt.

AppDynamics-EUEM

Om dit mogelijk te maken moet je in AppDynamics EUEM aanzetten via Configure -> Instrumentation -> End User Monitoring.

AppDynamcis-enable-EUEM

De JavaScript agent is een bestand genaamd adrum.js. Je hebt twee manieren om deze te gebruiken in je applicatie. Via een aparte module in Apache genaamd mod_proxy. Hoe je die gebruikt kun je lezen in de publieke AppDynamics documentatie.

Voor deze demo heb ik ervoor gekozen om deze JavaScript file zelf te implementeren. Dit kun je in WordPress doen door:

  1. De JavaScript file via FTP te uploaden naar een locatie waar elke gebruiker van de website bij kan. Meestal de root van de website.
  2. De regel die in bovenstaand screenshot bij stap 2 weergegeven wordt in de header.php van je theme te plaatsen.

WordPress-AppDynamics-adrum

Als je gebruik maakt van een WordPress theme framework zoals Genesis, dan heb je in de backend van WordPress vaak een optie om daar extra code in de header te plaatsen. Uiteraard heeft dit dan de voorkeur.

Om te verifieren dat het werkt kun je de broncode van een pagina bekijken in een browser en dan moet daar code staan zoals je die hierboven hebt geplaatst.

Het eindresultaat in AppDynamics is dan:

AppDynamics-EUEM-dashboard

Database Monitoring

Op moment van schrijven zijn er voor AppDynamics 2 manier beschikbaar om je database te bewaken; AppD4DB en een geintegreerde oplossing. AppD4DB is een aparte component en niet bruikbaar in een SaaS omgeving als de SaaS omgeving geen verbinding naar de AppD4DB installatie kan leggen en dit is vaak niet het geval. Ook omdat AppD4DB op termijn uitgefaseerd zal worden heb ik hier voor de geintegreerde oplossing gekozen.

De geintegreerde oplossing vereist ook een aparte agent die geinstalleerd moet worden op een component die rechtstreeks met de database moet kunnen praten. Dit wil zeggen dat er er geen firewall mag zitten tussen de DB agent en de database zelf op de poort die nodig is om met deze DB te communiceren. Voor MySQL is dit standaard poort 3306.

Als de DB agent met de SaaS omgeving kan communiceren dan kan er een collector op de database gemaakt worden.

AppDynamics-DB-Collector

Als deze succesvol verbonden is komen er langzaam allerlei statistieken binnen over het gebruik van de database. Als laatste moet er een koppeling tussen AppDynamics APM en de Database Monitoring geled worden. Dit kan vanuit de Topology Map, lees hier hoe.

AppDynamics-DB-dashboard

Gebruik deze module om inzicht te krijgen in de details van specifieke queries die in de Transaction Snapshots zichtbaar gemaakt worden.

Extensions

Extensions zijn uitbreidingen in AppDynamics die je in staat stellen om extra data uit andere systemen te halen om die als metric op te slaan. Dit maakt het mogelijk om correlaties te maken dus data die AppDynamics zelf genereerd en data uit andere bronnen. Het doel hiervan is dat er sneller oorzaken van problemen gevonden worden.

Een aantal interessant extensies die gebruikt kunnen worden voor WordPress zijn hieronder te vinden.

  • Memcached – Informatie over de status van je memcached implementatie zoals het aantal items die gecached worden. Uiteraard alleen bruikbaar als je memcached ook gebruikt. Hetzelfde geldt voor andere caching oplossingen zoals Varnish of Redis.
  • Apache – Alle informatie die via mod_status zichtbaar gemaakt wordt maakt deze extension bruikbaar in AppDynamics. Voor NGINX is er een vergelijkbare extensie.
  • Apica – Een goede aanvulling op Real User Monitoring is synthetische monitoring. Als je daar Apica voor gebruikt is er een extension om de response tijden van deze transacties over de BT’s van AppDynamics te plotten om ze te vergelijken. Het kan interessant zijn om deze met elkaar te vergelijken om problemen in het netwerk tussen de eindgebruiker en de IT infrastructuur inzichtelijk te maken.

Een overzicht van alle extensions is te vinden op de AppDynamics Community.

Conclusie

De basis van de monitoring van WordPress met AppDynamics is nu gelegd. Als AppDynamics je bewakingsoplossing wordt kun je de basis functionaliteit van AppDynamics gebruiken om alarmeringen in te richten. Dit is functionaliteit niet specifiek toegepast op WordPress en daarom zal ik deze hier ook niet verder toelichten. Meer informatie vind je in de docs.

Heb je hulp nodig bij de inrichting of wil je advies over de inrichting van monitoring op je WordPress omgeving? Aarzel niet om contact op te nemen. Vragen stellen mag natuurlijk ook in de comments.

Over Coen Meerbeek

Splunk consultant @ Blue Factory, eigenaar en oprichter @ BuzzardLabs, basketbalspeler en Xbox-gamer. Lees meer van Coen op Launchers.nl en Twitter.

Loading Facebook Comments ...

Laat wat van je horen

*