• No results found

Product selectie “Volledige open source oplossing”

In document Monitoring SOA Architectuur (pagina 37-39)

4 Onderbouwing keuzes en werkzaamheden

4.2.5 Product selectie “Volledige open source oplossing”

De oplossingsrichting waarbij gebruikt gemaakt zou worden van een enkele open source monitor product om alle HP Sitescope functionaliteit te vervangen heb ik als laatste onderzocht. Ik ben gestart met een overzicht te maken van alle op dit moment bekende en goed ondersteunde open source monitor pakketten. De eerste voorselectie heb ik uitgevoerd op basis van de beschikbaarheid van commerciële support. Ondanks dat de software gratis is wil je graag dat in ieder geval voor de implementatie op de productie omgeving een

marktpartij met diepgaande kennis support kan leveren volgens een vooraf overeen gekomen SLA. Is dit niet geborgd dan ben jij als engineer de laatste schakel in de keten en

rust

de volledige verantwoordelijkheid van het oplossen van storingen op jouw schouders. Ook wanneer de verstoring niet veroorzaakt wordt door een fout in de configuratie maar wanneer er een patch geschreven moet worden om een probleem in de software te verhelpen. Deze vraag kun je natuurlijk ook bij de community neerleggen maar daarbij ben je volledig afhankelijk van welwillendheid en beschikbare tijd van de leden van de community. Het zijn immers mensen die op vrijwillige base in hun vrije tijd aan deze producten

ontwikkelen. Richting onze klanten is het echter niet mogelijk om dergelijke afhankelijkheden in de SLA’s te verwerken mits we gaan werken op basis van “best effort”. Het is echter zeer onwaarschijnlijk dat onze klanten daarmee akkoord zullen gaan.

Na deze voorselectie bleven de volgende kandidaten over: Zabbix

Nagios Icinga Opsview

Van deze 5 heb ik er 2 (Zabbix en Opsview) geselecteerd die wat betreft geleverde functionaliteit het meeste overeen kwamen met de benodigde functionaliteit. Wel werd gedurende deze fase al snel duidelijk dat geen van de geselecteerde producten de volledige Sitescope functionaliteit out-of-the-box konden leveren. Hier was enig maatwerk voor nodig. Op zich was dit een optie geweest zij het niet dat de combinatie van maatwerk en open source niet binnen de scope van deze oplossingsrichting viel. De functionaliteit die deze oplossingen wel bezaten zat hoofdzakelijk op het gebied van Operations. Wanneer het doel was geweest HP Operations vervangen met een open source product met beperkt maatwerk van zouden beide producten goede kandidaten geweest kunnen zijn.

Daarnaast waren er eigenlijk geen mogelijkheden om de verzamelde metrics per monitor aan HP Operations aan te leveren middels een van de in het vorige hoofdstuk omschreven interfaces. Wel bestonden er voor beide producten mogelijkheden om de

eindresultaten van afgeronde monitor acties (good, error, warning) door te zetten op basis van SNMP. Maar daarnaast zou ook de repository van de tools waar in de metrics opgeslagen worden gesynchroniseerd moeten worden met de HP Operations repository. Omdat de datamodellen in de database van de 3 tools niet met elkaar overeen kwamen zou er voor zowel de koppeling tussen HP Opertions en Opsview als HP Operations en Zabbix een data conversie script geschreven moeten worden om interfacing mogelijk te maken. Weer extra maatwerk dus. Omdat de kracht van beide tools vooral lag op het leveren van “HPOperations” functionaliteit en omdat er in mindere mate invulling werd gegeven aan HP Sitescope

functionaliteit werd het inzetten van deze tools minder interessant. De hoeveelheid maatwerk die nodig was om de oplossingen te laten werken in combinatie met het feit dat deze beide oplossingen niet vallen binnen de scope van deze oplossingsrichting hebben ervoor gezorgd dat we het onderzoek in deze oplossingsrichting gestaakt hebben. De resultaten van het uitwerken van deze oplossingsrichting zijn terug te lezen in het document “ Product vergelijking en selectie V1.8”

Competenties:

De competenties die ik met dit punt aangetoond heb zijn “1.4 het uitvoeren van analyse door definitie van requirements (complex / zelfstandig)” en “4.2 beheren van applicaties

(complex/zelfstandig)”, “1.3 het selecteren van standaard software (lastig / zelfstandig)” Door in de voorgaande fase en het begin van deze fase een duidelijke set requirements te definiëren en helder de scope van deze oplossingsrichting te formuleren ben ik instaat geweest een heldere analyse te maken van de mogelijkheden om een open source monitor tool in te zetten om daarmee invulling te geven aan de HP Sitescope functionaliteit. Hiermee heb ik

aangetoond in voldoende mate de competentie “1.4 het uitvoeren van analyse door definitie van requirements (complex / zelfstandig)” te beheersen. Door op basis van de nieuwe requirements een alternatieve oplossingsrichting te kunnen bedenken en ook te kunnen vaststellen dat de gekozen oplossingsrichting onvoldoende voldoet aan de vooraf opgestelde requirements heb ik aangetoond de competentie “4.2 beheren van applicaties

(complex/zelfstandig)” te beheersen. De competentie “1.3 het selecteren van standaard software (lastig / zelfstandig)” heb ik aangetoond door te kunnen onderbouwen dat de inzet van de bekeken standaardsoftware niet mogelijk is op basis van de geboden functionaliteit.

Daarnaast heb ik in kunnen schatten dat de hoeveelheid maatwerk die noodzakelijk is niet opweegt tegen de standaard functionaliteit van deze producten en dat het verder gaan met deze oplossingsrichting geen zin heeft om dat het eindproduct buiten de scope van deze oplossingsrichting (1 product met standaard functionaliteit) valt.

De conclusie die getrokken is uit de bovenstaande paragrafen is om de PoC fase in te gaan met de geselecteerde producten uit de oplossingsrichting “maatwerk en open source” en de overige oplossingsrichting gezien de resultaten buiten beschouwing te laten.

4.3 Fase 3, Uitwerken oplossingsrichting en testen haalbaarheid (PoC)

In document Monitoring SOA Architectuur (pagina 37-39)