Dan bouwen we het toch zelf?

Door Sam de Poorter, back-end developer
23 januari 2014 - 2138 x bekeken - Categorieën: Innovatie

Soms wil je iets voor elkaar krijgen, maar vind je niet de juiste oplossing. Ook bij E-sites zijn we daar vaker tegenaan gelopen. En dan denken we al snel "Dan bouwen we het toch zelf?". Vanuit die gedachtegang en de nodige investeringen, hebben we de afgelopen jaren al best wat neergezet waar we trots op zijn. Maak kennis met onze eigen creaties: onze errorlogger, de Cronitor (monitoringtool voor cronjobs) en ons narrowcastingsysteem, de E-hub.

Errorlogger: een overzicht van alle errors

De errorlogger geeft een helder overzicht van alle errors van de afgelopen twee weken. Dit overzicht gebruiken we dagelijks, om te kijken wat er mis is en wat de oorzaak ervan is (zie figuur 1).

Figuur 1, het overzicht van onze errorlogger

Onze errorlogger leest elke vijf minuten de serverlogs uit, ook van acceptatieomgevingen. Op deze manier zijn we er zeker van dat we ook echt alle errors verzamelen. En dat is een uitkomst, want de meeste alternatieven zijn niet toereikend. Zoals de (native) functionaliteit van onze programmeertaal PHP. Want PHP heeft problemen om fatal-errors (die vervelende witte schermen) te loggen. Het script is op dat moment compleet vastgelopen, waardoor PHP geen kans ziet om iets weg te schrijven. Ook is het goed om na te denken over waar je de errors wegschrijft. Want kies je bijvoorbeeld voor de database, dan neem je een risico. Stel dat er juist problemen zijn met de database(connectie)? Fatal errors en databaseproblemen komen overal nog voor. Dit zijn zeker geen uitzonderingen die je over het hoofd wilt zien. 

Wij verzamelen onze errors uiteindelijk wel in een aparte database, maar in een veilige omgeving. Tegenover de ingelezen tekstbestanden, geeft een database ons de mogelijkheid om items:

Te groeperen
Dit zorgt ervoor dat dezelfde error niet opnieuw als los item wordt toegevoegd, maar informatie voor de error bijwerkt. Zo krijgen we per error informatie over wanneer hij voor het eerst en laast is voorgekomen en hoe vaak. Dankzij het groeperen kunnen we een error die vaak is voorgekomen in een keer markeren als opgelost. Dat scheelt weer een vacature ;)

Te filteren
FIlteren kan per server, per ontwikkelteam, per type errors of een combinatie daarvan. We zetten dit buiten het overzicht ook nog eens in om een aparte RSS-feed te generen. Zo kunnen wij eenvoudig op de hoogte blijven van errors die voor ons relevant zijn, zonder continu het overzicht te hoeven raadplegen.

Te sorteren
Standaard sorteren we de items al zo dat de nieuwste items bovenaan staan. In figuur 1 zie je aan de kolommen waar we nog meer op kunnen sorteren. Daarbuiten sorteren we ook vaak per project, waarvan de kolom net buiten beeld valt. Errors in een project hebben vaak met elkaar te maken. Het is ook fijner om errors per project op te lossen, zodat je niet tussentijds tussen projecten moet wisselen.

Te zoeken
Zoeken is hier eigenlijk niet anders dan op een website. Als je bijvoorbeeld wilt weten of er bij meer projecten problemen waren met GoogleMaps, de database of met bestanden, kan je daar makkelijk op zoeken via de zoekfunctie.

Nog een ander voordeel is dat we dankzij de opzet van de errorlogger voor alle projecten dezelfde werkwijze gebruiken voor foutafhandeling. Ongeacht  of het een sitemanager (ons eigen CMS), Magento, of een ander systeem is.

Cronitor: Monitoren van cronjobs

Veel van onze projecten hebben ingeplande taken, ook bekend als cronjobs. Soms zijn dit kleine taken zoals het ophalen en verwerken van de betaalstatus van openstaande orders. Maar zeker bij grotere projecten zijn deze vaak veel complexer. Daarbij heb je vaak import-, order- en voorraadkoppelingen. Om cronjobs te monitoren, hebben we de Cronitor in het leven geroepen.

Binnen de Cronitor worden de resultaten opgeslagen van elke individuele keer (run) dat een cronjob is gestart. Dus niet alleen van de laatste keer. Dankzij deze historie kunnen we makkelijk achterhalen of een cronjob is gestart en wat de resultaten zijn. We bewaren het vervolgens voor ongeveer twee weken, daarna is deze data niet meer relevant. Buiten het standaard loggen van errors, kiezen onze developers zelf welke extra meldingen ze willen opnemen in de Cronitor: een standaard melding of een errormelding.

Figuur 2, een detailpagina van een run van een cronjob

Bij een import wil je in ieder geval melden welke categorieën zijn behandeld en hoeveel producten er zijn verwerkt. Maar als er een importbestand mist, wil je dit als error opnemen. Zodra de Cronitor ziet dat er een error is, wordt de cronjob gemarkeerd in het overzicht. Afhankelijk van de instellingen van de cronob (zie figuur 3) worden er extra acties ondernomen.

Figuur 3, instellingen per cronjob

Complexe cronjobs lopen vaak in de nacht om het systeem van de klant en die van ons te ontlasten. Voordat we de werkdag echt beginnen, lopen we het overzicht dan ook even na om te zien hoe het er voor staat. In het begin was het idee om dit alleen op kritieke processen toe te passen. Maar omdat er eigenlijk geen nadelen te vinden zijn, passen we het nu overal toe. Nieuwe cronjobs worden dan ook vrijwel altijd opgenomen in onze Cronitor. Het nalopen van dit overzicht is nu een onderdeel van ons ochtendritueel.

E-hub: ons narrowcasting systeem

Verspreid in ons gebouw hangen er verschillende beeldschermen, waarop de E-hub draait. Dit is ons narrowcastingsysteem, bedoelt om belangrijke informatie voor onze medewerkers te tonen. De errorlogger en de cronitor komen hier soms ook in naar voren, maar dat proberen we natuurlijk altijd te voorkomen ;). Op deze manier worden we wel extra geattendeerd op deze meldingen die om (snelle) acties vragen. 

Figuur 4, E-hub die de waarschuwingen van de cronjob en errorlogger toont.

De E-hub toont ons ook:

  • de statistieken van onze servers, de uptime en de reactietijd van een paar van onze sites (zie figuur 5).
  • de twitterfeed van @esites.
  • interesante nieuwsberichten van tweakers.net en nu.nl.
  • weersvooruitzichten.
  • NS-vertrektijden (in de ochtend en namiddag).
  • statistieken van ons ticketsysteem zendesk (aantal openstaande uren qua tickets, tevredenheid van de klanten en andere statistieken).
Aan de opzet en invulling van de slides wordt nog volop gewerkt. En eigenlijk zijn we hier ook nooit in uitontwikkeld. 
 
Conclusie
We gebruiken zelf het liefst bestaande en bekende tools, waaronder Phing, Jenkins, xdebug, Subversion (SVN) en Codesniffer. Maar als er geen geschikte tool is, bouwen we die zelf! Buiten de E-hub, Errorlogger en Cronitor, hebben we ook een eigen planning- en urenregistratietool, een eigen publicatieomgeving naast Phing en veel maatwerk op al bestaande tools ontwikkeld. Het is niet dat we het wiel opnieuw uitvinden, maar we zorgen voor iets bruikbaars dat precies in onze processen past, zonder last te hebben van afhankelijkheden. En hierdoor blijven we flexibel, nu en in de toekomst!

 
 

iOS: Continuous integration

Door Bas van Kuijck

Continuous integration (CI) is een term die vaak wordt gebruikt voor software ontwikkeling. CI is eigenlijk niets meer, of minder, dan een aanpak die… - Lees meer

Lees verder