Een dag uit het leven van een APM agent

In de APM wereld zijn er grofweg twee manieren om data uit de IT infrastructuur te halen; agent-based vs agentless.

Agentless betekent dat de software remote inlogt (NetBios, SSH, SNMPT, etc.) en daar door het aanroepen van software /methodes data verzamelt. Na het verzamelen van de data logt de software weer uit en klaar. Ideaal zou je denken maar we moeten verder kijken want we hebben ook agent-based.

Agent_smithAgent-based betekent dat er op de infrastructuur een agent wordt geïnstalleerd die vanaf een centrale omgeving opdrachten krijgt en uitvoert. De resultaten van de opdrachten worden teruggestuurd naar de centrale omgeving. Lijkt vergelijkbaar maar dat is het niet. Een agent is veel beter in staat om zaken op het systeem uit te voeren omdat het toegang heeft tot het gehele systeem, afhankelijk van de rechten natuurlijk. Bij agentless ben je afhankelijk van de mogelijkheden die de toegangslaag biedt.

Waar ik op in wil zoomen is de start van elke agent binnen alle organisaties. Software wordt aangeschaft door afdeling A omdat zij behoefte hebben, in mijn geval, aan meer controle over de systemen en de applicaties die daar op draaien.

Afdeling A gaat praten met de afdeling die verantwoordelijk is voor de systemen (B) en ze vertellen dat ze een agent gaan installeren.

Wij willen graag een agent hebben op alle Linux systemen waar onze applicatie op draait. Kan dat? – Afdeling A

Ja natuurlijk maar we hebben al vier agents draaien op alle Linux systemen. Wat wil jij met deze agent nog gaan doen? Welke impact heeft de agent op de resources van het systeem? – Afdeling B

Wij willen allerlei metrieken gaan verzamelen over de systemen en de software. De agent gebruikt maar een klein beetje CPU en memory. Moet kunnen toch? – Afdeling A

Hmm dat zeggen ze allemaal. Laat ze dat maar eens bewijzen. – Afdeling B

Dat gaat toch langer duren dan verwacht maar ja je wilt het wel dus je gaat aan de slag. Na enkele weken proefdraaien lijkt alles in kannen en kruiken en we mogen naar de productiesystemen. Yeah!

Op een vrijdag in een vakantie worden de agents uitgerold en we zijn live! Fijn weekend.

Tijdens het weekend komen op de service desk de 1e calls binnen.

De applicatie is traag!

Ik kan niet inloggen.

Wat nu? Op maandagmorgen kom je op kantoor en zit je mailbox vol (als je al niet gebeld bent in het weekend).

De applicatie functioneert niet en de agent heeft het gedaan…hmm ok….

Nu moeten we gaan bewijzen dat de agent het probleem niet is geweest. De beste aanpak hiervoor is de agent isoleren om te kijken waar het probleem zich bevindt.

Als je een loadbalanced infrastructuur hebt kun je het beste de agent op 1 van de X machines installeren en daar een minimale load op zetten. Als het probleem ook nog op de andere machines voorkomt weet je gelijk dat de agent niet het probleem is.

Als het om een single server infrastructuur gaat dan wordt het lastiger. Hopelijk is er een testomgeving beschikbaar. Dan kun je de agent hier op installeren. Probeer zelf load te genereren en bewaak de effecten op de applicatie. Als ook  een testomgeving niet voorradig is moet je de agent activeren op momenten dat de bezoekersaantallen zeer laag zijn zodat de impact minimaal is.

Zorg in alle gevallen dat je de invloed van de agent op infrastructuur beperkt door de configuratie zo optimaal en minimaal mogelijk neer te zetten. Als je ziet dat dit goed werkt zet je stapje voor stapje steeds meer aan totdat je op het gewenste niveau zit.

Probeer ten allen tijde alternatieve monitoring op de applicatie te plaatsen anders kun je helemaal niet meer zien wat er gebeurd. Real User Monitoring en Agentless monitoringtools zijn hiervoor het meest geschikt. RUM meet alleen echte gebruikers op netwerkniveau en heeft 0 impact op de systemen. Agentless monitoringtools genereren gebruikersverkeer op de systemen en is dus optimaal onder controle.

In bovenstaande situatie zijn er aantal valstrikken:

  • Alle monitoring uitzetten. Zoals gezegd zie je dan niets meer en kan het van alles zijn geweest.
  • Gelijk in de logfiles duiken. De kans is hier dat je een ander probleem vind en dat je daar alle energie in stopt. Dit blijkt uiteindelijk niet de oorzaak en je bent weer terug bij af en veel tijd verloren.
  • Zonder gedegen plan overal in duiken. Je moet laagje voor laagje de infrastructuur af gaan pellen om steeds iets uit te sluiten. Steek daar liever eerst een aantal uren in dan dat je gelijk de machines gaat afspeuren.

Hebben jullie meer tips? Deel ze hier want ik ben vast niet de enige die hier ervaring mee heeft.

Over Coen Meerbeek

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

Laat wat van je horen

*