Monitoring sucks
Download as PPTX, PDF•0 likes•640 views
why monitoring sucks
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