![[RSS]](https://tweakers.net/g/if/v2/icons/rss_small.png){kind=icon}
Let op: Tweakers stopt per 2023 met Tweakblogs. In
dit artikel
leggen we uit waarom we hiervoor hebben gekozen.
Het belang van monitoring
De meeste van ons herkennen het nog wel uit het begin van het digitale tijdperk. Een medewerker belt op naar de computerafdeling om verhaal te halen want men kan niet inloggen in het mainframe. De medewerker van de computerafdeling gaat controleren wat er aan de hand is en komt tot de ontdekking dat er een onderdeel van het mainframe niet meer functioneert. Jammer dat hij er pas achter is gekomen nadat een medewerker dit tegen hem heeft moeten vertellen.
Nu “enkele” jaren later belt diezelfde medewerker op naar afdeling IT om te vertellen dat men niet kan inloggen op de computer. De IT-medewerker kan al vertellen dat er momenteel een storing gaande is waar men al druk mee bezig is om dit te verhelpen.
Zoals men kan zien zijn dit 2 vrijwel identieke situaties, maar met 1 wezenlijk verschil: Monitoring.
Een onwetend bedrijf kan een gedachte hebben van: “Monitoring? Wat heb ik daar aan?”
Het antwoord hierop is simpel. Uw systemen zijn bereikbaar op de momenten dat u ze nodig heeft.
Ok. Dat was het makkelijke deel. Nu het moeilijkere deel.
Monitoring kan op basis van meerdere methodes en nog veel meer verschillende tools die je hierbij kunnen assisteren. Zowel de verschillende methodes als de verschillende tools hebben allemaal hun voor- en nadelen. Ze vergelijke is echter een ander verhaal, omdat de tools niet zomaar 1-op-1 met elkaar te vergelijken zijn doordat ze niet allemaal dezelfde features hebben. Ik spreek hier zelf uit een stuk ervaring want doordat ik gelieerd ben aan een bepaalde organisatie, doordat ik in mijn privétijd ook iets met computers doe en natuurlijk door mijn werk, ben ik door de jaren heen met allerlei verschillende tools in aanraking gekomen. Hierdoor kan ik echt zeggen dat ze allemaal hun voor en nadelen hebben.
In de ene tool laat je een scan lopen op je netwerk en letterlijk ALLES dat hij detecteert wordt vanaf dat moment gemonitord, een andere tool scant wel, maar hierna kun je specificeren wat er gemonitord moet worden en bij de volgende tool moet je werkelijk alles met de hand invullen.
Tot zover lijkt me alles duidelijk voor iedereen.
Nu hebben we nog 2 verschillende monitoring opties. Te weten:
Als je teveel monitort, dan kan het gebeuren dat je door de bomen het bos niet meer ziet, omdat je van zoveel bronnen zoveel verschillende informatie krijgt, waarbij het kan gebeuren dat je vanaf meerdere plekken andere informatie terug krijgt waardoor het uitzoeken va het werkelijke probleem onoverzichtelijk wordt.
Te Weinig
Als je te weinig monitort dan kun je niet achter de werkelijke oorzaak van het probleem komen. Hierdoor is het moeilijk om het probleem op te gaan lossen omdat je geen oorzaak hebt.
Precies genoeg
Het is de kunst om precies genoeg te monitoren zodat je makkelijk een oorzaak kunt vinden dat speelt bij de klant. Deze balans is altijd een moeilijk vraagstuk en kan dus ook geheel per klant verschillen.
In een volgende aflevering gaan we kijken naar de eerste van 2 tools die ik nu veel gebruiken en waarom we overgaan van de ene naar de andere tool.
Nu “enkele” jaren later belt diezelfde medewerker op naar afdeling IT om te vertellen dat men niet kan inloggen op de computer. De IT-medewerker kan al vertellen dat er momenteel een storing gaande is waar men al druk mee bezig is om dit te verhelpen.
Zoals men kan zien zijn dit 2 vrijwel identieke situaties, maar met 1 wezenlijk verschil: Monitoring.
Een onwetend bedrijf kan een gedachte hebben van: “Monitoring? Wat heb ik daar aan?”
Het antwoord hierop is simpel. Uw systemen zijn bereikbaar op de momenten dat u ze nodig heeft.
Ok. Dat was het makkelijke deel. Nu het moeilijkere deel.
Monitoring kan op basis van meerdere methodes en nog veel meer verschillende tools die je hierbij kunnen assisteren. Zowel de verschillende methodes als de verschillende tools hebben allemaal hun voor- en nadelen. Ze vergelijke is echter een ander verhaal, omdat de tools niet zomaar 1-op-1 met elkaar te vergelijken zijn doordat ze niet allemaal dezelfde features hebben. Ik spreek hier zelf uit een stuk ervaring want doordat ik gelieerd ben aan een bepaalde organisatie, doordat ik in mijn privétijd ook iets met computers doe en natuurlijk door mijn werk, ben ik door de jaren heen met allerlei verschillende tools in aanraking gekomen. Hierdoor kan ik echt zeggen dat ze allemaal hun voor en nadelen hebben.
In de ene tool laat je een scan lopen op je netwerk en letterlijk ALLES dat hij detecteert wordt vanaf dat moment gemonitord, een andere tool scant wel, maar hierna kun je specificeren wat er gemonitord moet worden en bij de volgende tool moet je werkelijk alles met de hand invullen.
Tot zover lijkt me alles duidelijk voor iedereen.
Nu hebben we nog 2 verschillende monitoring opties. Te weten:
- Te Veel
- Te Weinig
Als je teveel monitort, dan kan het gebeuren dat je door de bomen het bos niet meer ziet, omdat je van zoveel bronnen zoveel verschillende informatie krijgt, waarbij het kan gebeuren dat je vanaf meerdere plekken andere informatie terug krijgt waardoor het uitzoeken va het werkelijke probleem onoverzichtelijk wordt.
Te Weinig
Als je te weinig monitort dan kun je niet achter de werkelijke oorzaak van het probleem komen. Hierdoor is het moeilijk om het probleem op te gaan lossen omdat je geen oorzaak hebt.
Precies genoeg
Het is de kunst om precies genoeg te monitoren zodat je makkelijk een oorzaak kunt vinden dat speelt bij de klant. Deze balans is altijd een moeilijk vraagstuk en kan dus ook geheel per klant verschillen.
In een volgende aflevering gaan we kijken naar de eerste van 2 tools die ik nu veel gebruiken en waarom we overgaan van de ene naar de andere tool.
09-'15 Windows 10 ≠ Privacy by default…
Reacties
Door
CodeCaster,
dinsdag 18 juli 2017 15:18
Er is natuurlijk ook nog een verschil tussen monitoring en alerting.
Niet iedere 404 in de logs van een webserver is een alert waard (crawlers, bots), maar een reeks 404s na een deployment weer wel.
Ga je Nagios en/of Check_MK behandelen?
Maar goed, aan "Ik ga bloggen!"-blogs geen gebrek, ik wacht rustig af.
Niet iedere 404 in de logs van een webserver is een alert waard (crawlers, bots), maar een reeks 404s na een deployment weer wel.
Ga je Nagios en/of Check_MK behandelen?
Maar goed, aan "Ik ga bloggen!"-blogs geen gebrek, ik wacht rustig af.
[Reactie gewijzigd op dinsdag 18 juli 2017 15:22]
Door
masauri,
dinsdag 18 juli 2017 15:20
Klinkt boeiend, ben benieuwd naar de volgende blog.
Door
Harm_H,
woensdag 19 juli 2017 00:12
Monitor = logging? Of onderdeel daarvan?
Alerts zijn ook beter dan monitoring. Je kan daarnaast nooit genoeg loggen lijkt me vanuit beheer perspectief. Te veel monitoring lijkt me vreemd, liever een paar logs teveel dan 1 te weinig toch?
Alerts zijn ook beter dan monitoring. Je kan daarnaast nooit genoeg loggen lijkt me vanuit beheer perspectief. Te veel monitoring lijkt me vreemd, liever een paar logs teveel dan 1 te weinig toch?
Door
Gomez12,
woensdag 19 juli 2017 00:31
Imho is er niet iets als teveel monitoring,
Je moet alleen zoals CodeCaster zegt je alerting goed zetten als dat je primaire doel is.
Alleen je kan monitoring voor zoveel meer gebruiken als enkel alerting.
Zo gebruiken wij het ook voor trenddetections, maar ook voor nakijken of we onze interne goals wel bereiken (bijv 2017 moet minder error 500's geven dan 2016, of minder 404's.
Zo hebben we voor alerting een maximale tijd wat het produceren van een gemiddelde pagina mag kosten maar dat is een berekend product uit de monitoring die op elke tijd van elke request, zodat we voor bijv een performance sprint er uit kunnen trekken wat de traagste request is (simplistisch gezegd degene met de meeste kans op verbetering).
Zo hebben we ook nog een groot gedeelte van de monitoring puur staan voor maandelijkse rapportages die day-to-day niet nodig zijn, maar die wel zeggen dat als we doorgaan met gebruikersgroei en geheugengebruik dat we binnen 2 maanden nieuwe servers nodig hebben of we krijgen over 3 maanden alerts.
Monitoren om te constateren dat er nu een probleem is dat is wmb al primitief, wij proberen te monitoren om te zien of we over 3 maanden problemen krijgen
Je moet alleen zoals CodeCaster zegt je alerting goed zetten als dat je primaire doel is.
Alleen je kan monitoring voor zoveel meer gebruiken als enkel alerting.
Zo gebruiken wij het ook voor trenddetections, maar ook voor nakijken of we onze interne goals wel bereiken (bijv 2017 moet minder error 500's geven dan 2016, of minder 404's.
Zo hebben we voor alerting een maximale tijd wat het produceren van een gemiddelde pagina mag kosten maar dat is een berekend product uit de monitoring die op elke tijd van elke request, zodat we voor bijv een performance sprint er uit kunnen trekken wat de traagste request is (simplistisch gezegd degene met de meeste kans op verbetering).
Zo hebben we ook nog een groot gedeelte van de monitoring puur staan voor maandelijkse rapportages die day-to-day niet nodig zijn, maar die wel zeggen dat als we doorgaan met gebruikersgroei en geheugengebruik dat we binnen 2 maanden nieuwe servers nodig hebben of we krijgen over 3 maanden alerts.
Monitoren om te constateren dat er nu een probleem is dat is wmb al primitief, wij proberen te monitoren om te zien of we over 3 maanden problemen krijgen
Door
eagle00789,
woensdag 19 juli 2017 08:02
Monitoring en alerting en logging zijn natuurlijk niet synoniem aan elkaar maar wel belangrijke onderdelen met afhankelijkheden bij elkaarCodeCaster schreef op dinsdag 18 juli 2017 @ 15:18:
Er is natuurlijk ook nog een verschil tussen monitoring en alerting.
dat blijft nog even een geheimpje, maar het blijft niet bij 2 pakketten.CodeCaster schreef op dinsdag 18 juli 2017 @ 15:18:
Ga je Nagios en/of Check_MK behandelen?
Ook hier geldt, alerts =/= monitoring, maar slechts een onderdeel ervan.Harm_H schreef op woensdag 19 juli 2017 @ 00:12:
Alerts zijn ook beter dan monitoring. Je kan daarnaast nooit genoeg loggen lijkt me vanuit beheer perspectief. Te veel monitoring lijkt me vreemd, liever een paar logs teveel dan 1 te weinig toch?
Te veel monitoring kan ook kwaad waarvan ik ook een zeer duidelijk voorbeeld aanhaal in het volgende artikel.
Wij gebruiken de monitoring dan net zoals jullie ook 2-ledig. enerzijds voor de items die NU omvallen door wat voor oorzaak dan ook (ongeacht of we dit hadden kunnen zien aankomen of niet) maar inderdaad ook door dagelijks rapporten uit de logging van de monitoring te halen om trend-detection te kunnen doen waarop we weer de nodige acties kunnen uitvoeren zodat we eventuele problemen in de toekomst voor kunnen zijn.Gomez12 schreef op woensdag 19 juli 2017 @ 00:31:
Imho is er niet iets als teveel monitoring,
Je moet alleen zoals CodeCaster zegt je alerting goed zetten als dat je primaire doel is.
Alleen je kan monitoring voor zoveel meer gebruiken als enkel alerting.
Zo gebruiken wij het ook voor trenddetections, maar ook voor nakijken of we onze interne goals wel bereiken (bijv 2017 moet minder error 500's geven dan 2016, of minder 404's.
Zo hebben we voor alerting een maximale tijd wat het produceren van een gemiddelde pagina mag kosten maar dat is een berekend product uit de monitoring die op elke tijd van elke request, zodat we voor bijv een performance sprint er uit kunnen trekken wat de traagste request is (simplistisch gezegd degene met de meeste kans op verbetering).
Zo hebben we ook nog een groot gedeelte van de monitoring puur staan voor maandelijkse rapportages die day-to-day niet nodig zijn, maar die wel zeggen dat als we doorgaan met gebruikersgroei en geheugengebruik dat we binnen 2 maanden nieuwe servers nodig hebben of we krijgen over 3 maanden alerts.
Monitoren om te constateren dat er nu een probleem is dat is wmb al primitief, wij proberen te monitoren om te zien of we over 3 maanden problemen krijgen
[Reactie gewijzigd op woensdag 19 juli 2017 08:02]
Door
Rowdy.nl,
woensdag 19 juli 2017 08:59
Te veel monitoring (mits het de performance niet (negatief) beïnvloed) bestaat niet. Opslag kost niets en je weet (nog) niet wat je aan informatie uit die data kunt halen.
Kom ik bij mijn volgende punt; monitoring en alerting zijn leuk en zorgen ervoor dat je op het moment dat er een probleem is direct gewaarschuwd wordt. Maar nu komt de volgende stap waar iedereen imho al mee bezig zou moeten zijn. Predictive maintenance.
Met al die (historische) data die je hebt kun je straks van tevoren problemen identificeren. Stel; een (kritiek) systeem is vastgelopen omdat die oververhit raakte. Blijken de fans kapot gegaan te zijn. Als je dan in je data kunt zien dat er in verloop van tijd die fan langzamer is gaan draaien; de temperatuur is gaan oplopen, of die fan meer vermogen nodig had; allemaal tekenen van een kapotte fan. Als je je systeem leert dat zo'n trend op een kapotte fan kan duiden kun je die fan op voorhand controleren en op een geschikte tijd (buiten de werkuren van je klant) vervangen. Hetzelfde geld voor storage (write/read failures die oplopen) en noem nog maar genoeg situaties op.
Als je al die monitoringdata die je opgeslagen hebt gaat vergelijken met alle servicecalls en issues zul je heel interessante (en te voorspellen) trends gaan vinden..
Kom ik bij mijn volgende punt; monitoring en alerting zijn leuk en zorgen ervoor dat je op het moment dat er een probleem is direct gewaarschuwd wordt. Maar nu komt de volgende stap waar iedereen imho al mee bezig zou moeten zijn. Predictive maintenance.
Met al die (historische) data die je hebt kun je straks van tevoren problemen identificeren. Stel; een (kritiek) systeem is vastgelopen omdat die oververhit raakte. Blijken de fans kapot gegaan te zijn. Als je dan in je data kunt zien dat er in verloop van tijd die fan langzamer is gaan draaien; de temperatuur is gaan oplopen, of die fan meer vermogen nodig had; allemaal tekenen van een kapotte fan. Als je je systeem leert dat zo'n trend op een kapotte fan kan duiden kun je die fan op voorhand controleren en op een geschikte tijd (buiten de werkuren van je klant) vervangen. Hetzelfde geld voor storage (write/read failures die oplopen) en noem nog maar genoeg situaties op.
Als je al die monitoringdata die je opgeslagen hebt gaat vergelijken met alle servicecalls en issues zul je heel interessante (en te voorspellen) trends gaan vinden..
Door
walteij,
woensdag 19 juli 2017 11:45
Ik heb enkele jaren geleden monitoring & alerting mogen inrichten bij een MBK ICT dienstverlener.
We hadden een standard monitoring set, die de volgende dingen in de gaten hield:
- Diskspace
- CPU gebruik
- MEM gebruik
- Disk queue length
- Services met status "automatic" moeten draaien (uitzonderingen zijn uiteraard mogelijk).
- Daarnaast werden een aantal events-error berichten genegeerd (event id 1111 met source Microsoft-Windows-TerminalServices-Printers bijvoorbeeld)
Ook zorgden we voor een mooie trend rapportage van de gebruikte resources (1 maand, 6 maanden en 3 jaar), zodat we ook redelijk konden voorspellen wanneer disks vol zouden raken en we een passende offerte voor nieuwe hardware konden leveren als er nieuwe servers besteld moisten worden.
Daarnaast liet ik via de monitoring tool die we gebruikte alle warnings en errors die in het eventlog naar voren kwamen (per server) wegschrijven naar een aparte tabel in de database.
Als we een nieuwe klant kregen, koppelden we de standard monitoring set ook altijd aan de servers van die klant.
Na een maand dook ik dan voor een dag of 2 een apart hok in (zodat ik niet gestoord werd) en ging ik de tabel doorspitten naar alles wat binnen was gekomen.
Met behulp van de gegenereerde tickets van de klant, de logs, de eigen kennis over de events en het nodige zoekwerk op internet over deze event meldingen, konden we vervolgens een keurige set van eventlog monitoring en alerting aanbieden voor de klant.
Voor een aantal generieke events heb ik ook wat scripts geschreven die ervoor zorgden dat het issue verholpen werd (een service die stopt, werd herstart, een Exchange DAG waarbij 1 node inconsistent was opnieuw consistent maken) etc.
Voor deze taken werd dan geen alert gegenereerd, maar een low prio ticket gegenereerd, met als melder monitoring klant en gesloten na een controle later op de dag.
We hadden een standard monitoring set, die de volgende dingen in de gaten hield:
- Diskspace
- CPU gebruik
- MEM gebruik
- Disk queue length
- Services met status "automatic" moeten draaien (uitzonderingen zijn uiteraard mogelijk).
- Daarnaast werden een aantal events-error berichten genegeerd (event id 1111 met source Microsoft-Windows-TerminalServices-Printers bijvoorbeeld)
Ook zorgden we voor een mooie trend rapportage van de gebruikte resources (1 maand, 6 maanden en 3 jaar), zodat we ook redelijk konden voorspellen wanneer disks vol zouden raken en we een passende offerte voor nieuwe hardware konden leveren als er nieuwe servers besteld moisten worden.
Daarnaast liet ik via de monitoring tool die we gebruikte alle warnings en errors die in het eventlog naar voren kwamen (per server) wegschrijven naar een aparte tabel in de database.
Als we een nieuwe klant kregen, koppelden we de standard monitoring set ook altijd aan de servers van die klant.
Na een maand dook ik dan voor een dag of 2 een apart hok in (zodat ik niet gestoord werd) en ging ik de tabel doorspitten naar alles wat binnen was gekomen.
Met behulp van de gegenereerde tickets van de klant, de logs, de eigen kennis over de events en het nodige zoekwerk op internet over deze event meldingen, konden we vervolgens een keurige set van eventlog monitoring en alerting aanbieden voor de klant.
Voor een aantal generieke events heb ik ook wat scripts geschreven die ervoor zorgden dat het issue verholpen werd (een service die stopt, werd herstart, een Exchange DAG waarbij 1 node inconsistent was opnieuw consistent maken) etc.
Voor deze taken werd dan geen alert gegenereerd, maar een low prio ticket gegenereerd, met als melder monitoring klant en gesloten na een controle later op de dag.
[Reactie gewijzigd op woensdag 19 juli 2017 11:48]
Door
SKiLLa,
woensdag 19 juli 2017 14:24
"Een onwetend bedrijf kan een gedachte hebben van: “Monitoring? Wat heb ik daar aan?”
Het antwoord hierop is simpel. Uw systemen zijn bereikbaar op de momenten dat u ze nodig heeft."
Nee, monitoring vertelt je alleen of een systeem wel of niet beschikbaar is, het lost niet automagisch je problemen voor je op
En zoals anderen al zeggen, monitoren zonder alerting heeft weinig toegevoegde waarde op trend-analyse na. Maar minstens net zo belangrijk als performance en beschikbaarheids-monitoring: Security Event Monitoring; geen enterprise kan zonder
Het antwoord hierop is simpel. Uw systemen zijn bereikbaar op de momenten dat u ze nodig heeft."
Nee, monitoring vertelt je alleen of een systeem wel of niet beschikbaar is, het lost niet automagisch je problemen voor je op
En zoals anderen al zeggen, monitoren zonder alerting heeft weinig toegevoegde waarde op trend-analyse na. Maar minstens net zo belangrijk als performance en beschikbaarheids-monitoring: Security Event Monitoring; geen enterprise kan zonder
Door
IceTeaGX,
woensdag 19 juli 2017 15:17
Laat een n-able probe eens alles uit een netwerk scannen en monitoren. Dat komt wel neer op teveel monitoren. Daar zit ik nu mee, de mensen die het opgezet hebben zijn ondertussen al lang weg, en ik heb geen tijd om mij er in te verdiepen. Moest de remote control er niet bij zitten, had ik de boel al weggegooid.
Door
eagle00789,
woensdag 19 juli 2017 15:18
Daar zijn wij dus naar toe aan het migreren wegens bedrijfpolicy en voorkomen van verspreiding en centralisering...IceTeaGX schreef op woensdag 19 juli 2017 @ 15:17:
Laat een n-able probe eens alles uit een netwerk scannen en monitoren. Dat komt wel neer op teveel monitoren. Daar zit ik nu mee, de mensen die het opgezet hebben zijn ondertussen al lang weg, en ik heb geen tijd om mij er in te verdiepen. Moest de remote control er niet bij zitten, had ik de boel al weggegooid.
Door
Deagle,
woensdag 19 juli 2017 18:52
Grappig, ik gebruik n-able ook dagelijks. Ik ga dit even volgen.eagle00789 schreef op woensdag 19 juli 2017 @ 15:18:
[...]
Daar zijn wij dus naar toe aan het migreren wegens bedrijfpolicy en voorkomen van verspreiding en centralisering...
Door
Waarnemer,
donderdag 20 juli 2017 13:17
Daar zit iets fout. Zodra je monitor de storing meldt dient de IT-er de medewerkers in te lichte dan er een storing is..Nu “enkele” jaren later belt diezelfde medewerker op naar afdeling IT om te vertellen dat men niet kan inloggen op de computer. De IT-medewerker kan al vertellen dat er momenteel een storing gaande is waar men al druk mee bezig is om dit te verhelpen.
Dat ze ermee bezig zijn is iets dat hij vroger ook kon.. er is dus in dit praktijkvoorbeeld nog niet wezenlijks iets verandert.
Monitoring én Alerting zorgen ervoor dat je pro-actief kan werken. Net als predictive maintenance kun je ook de collega's inlichten dat ze koffie kunnen gaa drinken...
Door
IceTeaGX,
donderdag 20 juli 2017 14:40
Dan ben ik wel eens benieuwd naar de tevredenheid.Deagle schreef op woensdag 19 juli 2017 @ 18:52:
[...]
Grappig, ik gebruik n-able ook dagelijks. Ik ga dit even volgen.
Ik weet dat de setup die ik gebruik niet optimaal is, maar ik was meer tevreden van een zabbix monitoring.
Door
yochi,
donderdag 20 juli 2017 16:31
Ik gebruikt PRTG en moet zeggen dat ik hier zeer tevreden van ben. Zeker omdat het agentless monitoring is en je betaalt per sensor i.p.v. per functie.IceTeaGX schreef op donderdag 20 juli 2017 @ 14:40:
[...]
Dan ben ik wel eens benieuwd naar de tevredenheid.
Ik weet dat de setup die ik gebruik niet optimaal is, maar ik was meer tevreden van een zabbix monitoring.
Door
Teaclo,
donderdag 20 juli 2017 19:54
Ikzelf zit ook aan de PRTG, awesome tool maar mist toch wel wat features in grotere omgevingen. Het grootste om te huilen was dat migratie van sensordata er gewoon niet inzit.yochi schreef op donderdag 20 juli 2017 @ 16:31:
[...]
Ik gebruikt PRTG en moet zeggen dat ik hier zeer tevreden van ben. Zeker omdat het agentless monitoring is en je betaalt per sensor i.p.v. per functie.
Het 2de wat me echt stoorde is dat ze een eigen db gebruiken, dus zeg maar dag tegen custom data reports.
Ik vindt dat Solarwinds superieur is tegenover PRTG. (maar de prijs is ook superieur)
Ik ga deze blog zeker volgen!
Door
computer1_up,
vrijdag 21 juli 2017 18:57
Behalve dan de winst uit de tijd tussen het opmerken van de storing door de medewerker en het begin van het oplossen van het probleem. Als een IT afdeling al lang met de storing aan de slag kan als de storing op komt, i.p.v. meerdere uren later als die desbetreffende medewerker pas inlogt, dan scheelt dat uiteindelijk down-time.Waarnemer schreef op donderdag 20 juli 2017 @ 13:17:
[...]
Daar zit iets fout. Zodra je monitor de storing meldt dient de IT-er de medewerkers in te lichte dan er een storing is..
Dat ze ermee bezig zijn is iets dat hij vroger ook kon.. er is dus in dit praktijkvoorbeeld nog niet wezenlijks iets verandert.
Dat is toch waar monitoring uiteindelijk om draait? Zo snel mogelijk achter de problemen komen om downtime te verminderen, en beter uit laten komen qua tijdstip?
[Reactie gewijzigd op vrijdag 21 juli 2017 19:05]
Door
hmmmmmmmmmpffff,
vrijdag 21 juli 2017 19:41
Werkt bij ons perfect. We hebben ook een boel self-healing policies en automation policies toegevoegd. Ook deployen wij bijv. Bitdefender direct via N-able, inclusief licensing. Al met al een boel instelwerk, maar dan heb je wel echt een heerlijk product om mee te werken.IceTeaGX schreef op donderdag 20 juli 2017 @ 14:40:
[...]
Dan ben ik wel eens benieuwd naar de tevredenheid.
Ik weet dat de setup die ik gebruik niet optimaal is, maar ik was meer tevreden van een zabbix monitoring.
Hun geintegreerde online- backupoplossing werkt trouwens ook erg goed. Je gaat dan natuurlijk wel meteen wat verder dan alleen monitoring/alerting.
Door
Pingelmonster,
maandag 24 juli 2017 11:31
Bij mijn oud-werkgever (ICT-dienstverlening) heb ik drie jaar lang geroepen om alsjeblieft monitoring op te gaan zetten.
Wat we daar deden aan het oplossen van storingen was altijd puur reactief. Als er een klant belde dat het internet eruit lag gingen we pas zoeken, bij wijze van spreken.
Nu sinds 1,5 maand heb ik een eigen bedrijf in de ICT-dienstverlening. Natuurlijk heb ik monitoring ingesteld en ik heb er nu al de voordelen van mogen ervaren.
Monitoring gaat pas werken als:
1. balans tussen teveel/te weinig goed is
2. adequate opvolging plaatsvindt
Interessant artikel. Ik volg deze ook even ;-)
Wat we daar deden aan het oplossen van storingen was altijd puur reactief. Als er een klant belde dat het internet eruit lag gingen we pas zoeken, bij wijze van spreken.
Nu sinds 1,5 maand heb ik een eigen bedrijf in de ICT-dienstverlening. Natuurlijk heb ik monitoring ingesteld en ik heb er nu al de voordelen van mogen ervaren.
Monitoring gaat pas werken als:
1. balans tussen teveel/te weinig goed is
2. adequate opvolging plaatsvindt
Interessant artikel. Ik volg deze ook even ;-)
Door
Gomez12,
maandag 24 juli 2017 21:56
Er is geen teveel monitoring, als je dat anders ervaart ga je verkeerd met monitoring om.Pingelmonster schreef op maandag 24 juli 2017 @ 11:31:
Monitoring gaat pas werken als:
1. balans tussen teveel/te weinig goed is
Op zich vind ik het best jammer hoeveel mensen hier nog niet eens schijnen te begrijpen wat monitoring is. Monitoring = monitoring en voor de rest niets.
Wil je een dashboard hebben die al je monitoring toont dan heb je het concept dashboard niet begrepen.
Wordt je gek van je alerts die links en rechts opspringen dan heb je het concept alerting niet goed begrepen.
Maar monitoring kan nooit teveel zijn (of je moet tegen cpu/ram/hdd problemen aanlopen).
De truc van goede monitoring is dat je het eenmaal opzet en dat je er daarna zo goed als niets meer mee doet. Elke alert / trend weet ik veel wat je er daarna uit wil halen moet er al inzitten zodat je per direct toegang hebt tot historische monitoring data en je direct kan zeggen of je alert/trend goed staat ingesteld.
De meest gemaakte fout die ik in de praktijk bij alerting zie is dat men een probleem heeft gehad, men wil het voorkomen dus men wil er een alert opzetten, dan blijkt dat er nog geen monitoring voor is, dus wordt dan die specifieke monitoring toegevoegd, direct daarna wordt de alert ingevoerd et voilà, men heeft een alert die 3x per week afgevuurd wordt en waar tijd ingestoken wordt om te kijken wat er mee is etc.
Terwijl als je gewoon historische data hebt dan is het simpelweg bij het instellen van de alert kijken hoeveel die het afgelopen jaar getriggerd zou zijn en of dat echt serieus noodzakelijk is of dat je de trigger toch iets anders moet instellen om geen overbodige alerts te krijgen, want overbodige alerts zijn killing voor een alert-systeem.
Door
Pingelmonster,
dinsdag 25 juli 2017 09:16
Je kunt het zo uitgebreid maken als je zelf wil. Zaken monitoren waar je vervolgens toch nooit naar omkijkt kun je beter niet doen is mijn mening. Je maakt het er onnodig ingewikkeld mee.Gomez12 schreef op maandag 24 juli 2017 @ 21:56:
[...]
Er is geen teveel monitoring, als je dat anders ervaart ga je verkeerd met monitoring om.
De kunst is om te zorgen dat je precies dátgeen monitort wat nodig is en op basis daarvan ook je alerting inregelt. Enkel datgeen 'alerten' wat echt noodzakelijk is, het moet wel nuttig en 'opvolgbaar' blijven.
Reageren is niet meer mogelijk