[VBS] server check script

[Koelkasten]

Werkzaam zijnde bij een ICT gerelateerd bedrijf hebben wij een aantal productie servers. Deze productie servers worden op werking gecontroleerd door eigen geschreven "scripts". Deze scripts zijn zo specifiek dat ze juist de productie processen op de servers volgen en controleren op werking en beschikbaarheid van diensten.

Werkt allemaal prima, deze scripts zijn gemaakt met Perl en sturen bij fouten of problemen waarschuwingen uit per email en of per sms berichten. Dit hele concept werkt nu al een hele tijd zonder problemen.

Nu heeft binnen ons bedrijf een andere afdeling onlangs ook zelf servers geplaatst voor een geheel ander product. Dit zijn dan ook geen linux based servers maar windows bakken. nu willen zij daar ook een soortgelijk server controlle productie proces controlle script voor maken. Echter als ontwikkel omgeving vallen ze al direct terug op VBS scripting.

Nu kreeg ik meteen een vieze smaak in mijn mond, en iets in mijn hoofd vertelde me nee voor zo iets als proces bewaking moet je geen VBS gebruiken. Echter toen ik argumenten ging bedenken waarom dit een verkeerde keus was liep ik zelf een beetje vast.

Kortom was zijn goede redenen en argumenten om een server controlle script niet in VBS te maken maar in een andere taal? Of zijn er helemaal geen argumenten en komt de vieze smaak in mijn mond van slechte koffie en heb gewoon een VBS script fobie.

[curry684]

Je hebt definitely betere koffie nodig. Er is geen enkele reden waarom een scripttaal off all things niet geschikt zou zijn voor vitale processen.

[RobIII]

Ik denk dat je een VBS fobie hebt en suiker in je koffie, al dan niet in combinatie met melk, helpt
Ik zie geen echt goede reden waarom het met VBS niet goed zou zijn (ik neem aan dat je dan WMI wil gaan gebruiken?)

perl of vbscript

[ Voor 13% gewijzigd door RobIII op 01-03-2005 10:21 ]

[Standeman]

De enige redenen om bijv. Perl te gebruiken i.p.v. VBS zijn:

- Je hebt de ballen verstand van VBS en juist wel van Perl
- Het zijn / of worden in de toekomst *nix servers

Verder kan ik echt helemaal geen reden bedenken om geen VBS te gebruiken..

[Luppie]

Wat is het probleem, Perl is al jarenlang gewoon beschikbaar voor Windows.

[P_de_B]

Cobra_Lup schreef op dinsdag 01 maart 2005 @ 10:39:
Wat is het probleem, Perl is al jarenlang gewoon beschikbaar voor Windows.

Dat je het nog los moet installeren?

Daarnaast vraagt TS om argumenten tegen het gebruik van VBS. Die zijn er eigenlijk niet

[RobIII]

Soms he, héél soms, zijn we toch eigenlijk allemaal best eensgezind * RobIII krijgt er een warm gevoel van

Sorry, moest effe

[ Voor 18% gewijzigd door RobIII op 01-03-2005 11:05 ]

[LuCarD]

Beetje afhankelijk wat voor een controle de scripts moeten doen. Als het bv heel simpel is op de bestaande perl scripts te porten naar windows toe. Dan is dat IMHO een geldige reden om geen VBS te gebruiken maar Perl. Onderhoud word dan makkelijker en installatie van de scripts ook.

Verder kan ik geen andere verzinnen om geen VBS te gebruiken.

[Koelkasten]

LuCarD schreef op dinsdag 01 maart 2005 @ 11:33:
Beetje afhankelijk wat voor een controle de scripts moeten doen. Als het bv heel simpel is op de bestaande perl scripts te porten naar windows toe. Dan is dat IMHO een geldige reden om geen VBS te gebruiken maar Perl. Onderhoud word dan makkelijker en installatie van de scripts ook.

Verder kan ik geen andere verzinnen om geen VBS te gebruiken.

Wel het was niet de bedoeling om het script van Perl naar VBS te porteren. dit omdat het Perl script echt heel specifiek is gemaakt op onze linux productie servers om onze processen in de gaten te houden. Die windows machines zijn van een andere afdeling en hebben een totaal ander product. het enige wat ze van mij over wilde nemen was het concept.

RobIII schreef op dinsdag 01 maart 2005 @ 11:05:
Soms he, héél soms, zijn we toch eigenlijk allemaal best eensgezind * RobIII krijgt er een warm gevoel van

Sorry, moest effe

Ha ik was dus niet de enige

curry684 schreef op dinsdag 01 maart 2005 @ 10:16:
Je hebt definitely betere koffie nodig. Er is geen enkele reden waarom een scripttaal off all things niet geschikt zou zijn voor vitale processen.

Ik ga echt iets aan mijn koffie doen dan maar. want ook ik heb nog geen zinnig argument bedacht om tegen een VBS script te zijn.


Conclusie lijkt me redelijk duidelijk. Er is eigenlijk helemaal geen reden te bedenken om geen VBS te gebruiken bij een server controlle script. Zeker omdat de dienst die ze aanbieden en dus bewaakt moet worden niet in de komende 10 jaar geporteerd gaat worden naar linux of een ander os en wel altijd op een windows platvorm zal blijven draaien.

Het was gewoon dat iemand tegen me begon over server bewaking en VBS scriptjes en dat ik meteen argwaan kreeg. onterecht dan blijkt bij deze.

[Luppie]

Voor het bewaken van een klein aantal servers zou je ook MOM workgroup edition kunnen gebruiken http://www.microsoft.com/mom/default.mspx hiermee kan je max. 10 servers (of andere dozen) monitoren. Het is upgradebaar naar een enterprise versie zou je serverpark gaan groeien.

Een virtual lab kan je hier vinden : http://www.microsoft.com/...ncert/virtuallab/mom.mspx om te kijken wat het is.

Dit product kost $ 499,- dit is een stuk voordeliger dan dat je iemand zou moeten inhuren om scripts te gaan bouwen en/of het beheer van de scripts.

_{Ook is het mogelijk om *nix machines er mee te monitoren, je kan het vergelijken met een soort van openview.}

[sko]

check ook eens Servers Alive ( www.woodstone.nu)
Voor 249 dollar heb je de enterprise versie, en de gratis versie kan tot 10 dingen monitoren. Stukken goedkoper dan MOM, en je kan alles wat je wilt monitoren en alerten.

werkt perfect hier

[Koelkasten]

Damn ik zie opeens mijn oude topic weer omhoog schieten dit terwijl de conclusie 3 posts geleden al lang was gegeven. Het topic ging er om of vbs nu wel of niet geschikt was en dit bleek gewoon geschikt te zijn. Het draait inmiddels ook al dus het is in de praktijk ook bewezen.

Die standaard server controlle software is in dit geval overigens niet goed genoeg. Het ging hier om software die inhouse ontwikkeld is en nogal uniek en specifiek is. hierdoor vind controlle plaats op het gehele proces (bijvoorbeeld hoeveel lijnen er per minuut worden geopend en gesloten) ik heb hier nog geen standaard pakketten voor kunnen vinden. en eigen check scripts zijn in dit geval ook een stukje goedkoper.