why monitoring sucks

1. Why
monitoring
sux
en wat we er aan kunnen doen (in controll)
Jurgen van de Pol, maart 2013

3. Waarom zuigt monitoring?
● Monitoring tools verwachten dat iedereen een
monitoring expert is.
● Correlatie van metrics tussen alle infrastructuur
componenten is complex.
● Monitoring vreet tijd.
● Het herhaaldelijk verzamelen van metrics is saai en
ondankbaar werk.
● Er zijn veel te veel verschillende monitoring tools en
interfaces.
● Producten kunnen niet autonoom analyseren,
correleren en patronen herkennen.
● Focus ligt op infrastructuur ruis i.p.v. op business pijn.
● Proces identificatie, isolatie en oplossing is niet
geautomatiseerd.

4. zonder monitoring is het:
● lastig snel de belasting en gezondheid van
infrastructuur te zien.
● zeer bewerkelijk vragen over de
belangrijkste infrastructuur metrics en
performance te beantwoorden. Ambachtelijk
● moeilijk een uitzondering te isoleren als er
iets misgaat.
● niet mogelijk een compleet beeld van invloed
dagelijkse wijzigingen op de eindgebruiker te
hebben (dashboard)

5. Wat wil je weten ?
Monitoring verzamelt, analyseert en
presenteert relevante metrics.
Relevant voor de business.
Zodat verstoringen van die business
kunnen worden voorkomen en opgelost.
Je kunt gigabytes diagnostische gegevens verzamelen.
Zonder de juiste context, het juiste probleem,
en de juiste gebruiker:
zinloos als een theepot van chocolade.

6. Complexiteit!
Fools ignore it.
Pragmatists suffer it.
Geniuses remove it.

7. Wat verwachten we van monitoring?
● Notificatie/Alerting
● Complex Event Processing (time based
correlatie)
● Patroon herkenning (behavioral learning)
● Real time & historische performance &
trending
● gauges, counters, meters, histograms, timers
● Capacity prognose
● Logging & Auditing
● Painless to implement and frictionless to
maintain

8. Commitment
Serieuze monitoring vraagt:
● geld
● kwaliteit
● tijd
Het ligt niet aan de tooling:
Concord (€270.000)
Concord + Spectrum
Spectrum solo
SCOM (RC)
SCOM (RC) + Orion
SCOM + keten + Orion
SCOM + Orion + Matrix
CHOOSE
2
GOE
D
SNEL
GOE
D
KOO
P

9. Wat doen we met al die wensen?
methode van foutanalyse:
OODA : observe, orient, decide, act
1. probleem identificatie
wat is er aan de hand, is het een
probleem?
1. probleem isolatie
waar zit het probleem
1. probleem oplossing
hoe los ik het op

10. 1: probleem identificatie
Heb ik überhaupt een probleem?
een dynamische performance baseline voorkomt 'false positive' foutmeldingen
bv het hebben van een vast piek patroon in je belasting

11. 1: probleem identificatie
Heb ik überhaupt een probleem?
Wat is de business context van het probleem.
90% CPU op 1 ESX host
versus
klanten service wacht > 20 sec op responce
DEVOPS!

12. 2: probleem isolatie
Waar zit mijn probleem?
prob: silo's, no drill down, no devops, no
visualisation, no insight
plaatje: appdynamics

13. 2: probleem isolatie
Waar zit mijn probleem?
Huidige tools verzamelen wel data,
maar visualiseren en isoleren het probleem niet
autonoom.
Correlatie/patroon herkenning van hypervisor,
compute, OS, storage, netwerk, database,
applicatie met de hand is zeer arbeidsintensief.

14. 2: probleem isolatie
Waar zit mijn probleem?
Een KRIS transactie duurt > 20 sec.
Waar precies zijn die 20 sec besteed?
Bekijk je de performance data vanuit de silo's
ESX, OS, applicatie, database en network
perspectief dan krijgt je 5 verschillende views
zonder correlatie, te grof om die ene slechte
transactie te tonen.

15. 2: probleem isolatie
waar zit mijn probleem?
monitor de business keten & endpoints!
vraag niet elke silo: werkt jouw silo 'normaal'?

16. 3: probleem oplossing
Van opinie naar inzicht is een
complex traject.
Analyse tooling kan hier
helpen.
Oplossingen gebaseerd op
100% menselijke inspanning
voor configuratie en analyse
blijven 100% falen.
Opinie:
Intuïtie, gebaseerd op wat je
ervaart
Data:
Gestructureerd maar in ruwe
vorm, lastig te duiden
Metrics:
Ratio, toont trends maar verliest
snel aandacht
Analyse:
Correlatie, toont relaties
Inzicht:
Waar zit het echte probleem
Actie:
Oplossing van het probleem
DataAnalyticsValueChain

17. Het alternatief
Hoe de klant een dienst beoordeeld wordt
ultiem bepaald door de ervaring met die dienst.
Als kun je de kwaliteit van de ervaring niet kunt meten, kun je
de kwaliteit van de dienst niet waarborgen.
End User Experience

18. End User Experience, 5 dingen
1. Volgt in real time, de uitvoering van de software
algoritmen die tezamen de toepassing vormen.
2. Meet en rapporteert de beperkte hardware en software
resources, toegewezen aan de applicatie.
3. Bepaalt of de toepassing goed wordt uitgevoerd in
overeenstemming met eisen van de applicatie eigenaar.
4. Registreert vertragingen in elk van de uit te voeren
stappen in een keten.
5. Bepaalt waarom de toepassing niet goed functioneert,
of waarom resource verbruik en latency levels afwijken
van de verwachting.

19. End User Experience
Be Paranoid Be Smart Be Lazy
meet elke
transactie!
vergelijk
voor & na
release
meet de SLA
alleen met
EUE

20. EUE paranoid
Pak het grondig aan:
● Bepaal de belangrijkste gebruikerservaring
metrics.
● Meet elke transactie van elke gebruiker.
● Meet de keten.

21. EUE smart
Maak End User Experience intelligent:
● Stel performance modellen op.
● Vergelijk goede en slechte transacties van
hetzelfde type.
● Vergelijk EUE voor en na changes.

22. EUE lazy
Kies de weg van de minste weerstand:
● Service Level Agreements (SLA's) puur op
eindgebruikerservaring.
● Automatiseer alerts wanneer responsetijden
drempels dreigen te overschrijden.
● Automatiseer acties om prestaties te
verbeteren (zou mooi zijn he?).

23. Magic Quadrant for Application
Performance Monitoring

24. Compuware ADM

25. OpNet APM

26. AppDynamic

27. DevOps
Samenwerking
ontwikkeling en operationeel
beheer -> meer inzicht.
Gezamenlijk eigenaarschap
nemen over hele product
keten gedurende hele
levenscyclus.
Ops guys schuiven aan in
functioneel en architectuur
overleg & ontwikkelaars gaan
alerts ontvangen.
release
management
ITIL
DevOp
s

28. wat is DevOps?
DevOps is een software development methode die communicatie,
samenwerking en integratie tussen software-ontwikkelaars en operationeel
beheer benadrukt. DevOps is het antwoord op de groeiende behoefte aan meer
samenhang tussen software ontwikkeling en IT operations. Met als doel de
organisatie te helpen sneller en beter software producten en diensten te

29. Dev & Ops nu, los van elkaar
Dev Ops
functionele requirements non-functionele requirements
security, backup, HA,
upgradability, monitoring,
scale
stuurt op business behoeften stuurt op beschikbaarheid,
schaalbaarheid, performance
implementeert code zonder
te kijken naar ops
beperkte applicatie kennis
kerntaak is wijzigingen wijziging = risico

30. Out with the old, In with the new
Out: focus op infra & resource monitoring
In: focus op eindgebruikers & applicaties

31. Out with the old, In with the new
Out: focus op beschikbaarheid
In: focus op performance en service levels

32. BI for OPSguys:
Operational Intelligence
Real-Time
Business Insights
Operational
Visibility
Proactive
Monitoring
Search &
Investigation
Dashboards, events and predictive models are used
by the business to prevent problems and seize
opportunities.
The business becomes engaged with machine data
analisys. Advanced models of behavior are created.
IT finds problems in advance and learns how to
present machine data to the business.
Machine data begins to be understood as a business
asset.
The Roadmap to Operational Intelligence
Reactive
Proactive

33. SPLUNK >
heeft een oplossing voor OI

34. FIN