PDA

Bekijk Volledige Versie : Cross site checks (NOC vanaf andere locaties)



starfix
27/06/06, 01:15
Naar aanleiding van een idee in dit (http://www.webhostingtalk.nl/shared-colocated-dedicated-reseller-registratie-aanvragen/98949-gezocht-5mb-ruimte-cron-php-en-mysql.html) topic open ik dit onderwerp.

Wat is het plan:

- Hosters bieden gratis site-checks met een nader te ontwikkelen scriptje op basis van het open NOC (http://www.webhostingtalk.nl/scripting-techniek-beveiliging/97257-het-grote-noc-script-support-topic-12.html) script.
- Cron van 1x per 60 seconden dit scriptje laten uitvoeren


Hosters die zich beschikbaar stellen:
********mods, het zou handig zijn als deze post ook na een half uur nog is aan te passen*****
- ErikKosters
- DiedX
- Directhosten
- xYnta
- Ikzelf (StarFix)

Het script, todo list:
Het script moet in principe hetzelfde doen als het bekende NOC script, maar dan voor meerdere users.
- Klein "admin" gedeelte voor invoeren/bewerken users en servers / services
- Per server aangeven bij welke user deze hoort
- Per user een SMS nummer en email adres aangeven
- *oplossing bedenken* Hoe veilig houden van privacy logingegevens voor de SMS gateways?
- Sms / email aan en uitzetten per user
- Statuspagina per user


De grote moeilijkheid is het SMS gedeelte. Smsjes betalen voor iemand anders lijkt me geen goed plan, maar je kunt ook moeilijk iemands login gegevens van de SMSgateways opslaan in je database (gezien mogelijk misbruik). Een scriptje laten uitvoeren op de server die plat ligt werkt ook niet. Denk even mee aan een oplossing hiervoor.

Belangrijk lijkt me ook dat personen gedeeld worden, zodat niet iemand alle personen op zich neemt.


Mocht dit breed gebruikt worden door hosters, dragen we allemaal bij aan een beter internet!

xYnta
27/06/06, 01:22
Wij stellen ons ook beschikbaar voor het onderbrengen van een NOC.

Frangkje
27/06/06, 01:31
Ik wil wel iets ontwikkelen dat op basis van het ontvangers nummer een sms account geselecteerd wordt (iedereen betaald dan de smsjes voor zijn eigen GSM nummer(s)) of een gratis account aanbieden waarmee berichten reversed billed (a 25 eurocent per bericht) naar de gsm verzonden worden, dan betaald de ontvanger het zelf.

starfix
27/06/06, 01:35
Ik wil wel iets ontwikkelen dat op basis van het ontvangers nummer een sms account geselecteerd wordt (iedereen betaald dan de smsjes voor zijn eigen GSM nummer(s)) of een gratis account aanbieden waarmee berichten reversed billed (a 25 eurocent per bericht) naar de gsm verzonden worden, dan betaald de ontvanger het zelf.
Goed idee! Mocht een nummer dan niet voorkomen als account, dan zou je reversed billing kunnen doen inderdaad, maar dit moet wel absoluut veilig zijn (niet dat iemand hier misbruik van kan maken)

Frangkje
27/06/06, 01:43
We kunnen aan onze kant eenvoudig de aanvragen op IP adres filteren, dus zolang iemand ons laat weten welke IP adressen er berichten aan mogen leveren is dat geen probleem.

HostPerfect
27/06/06, 09:01
Ook ik heb interesse om hiermee mee te doen.
Ook het sms idee staat me erg aan.

londoneye
27/06/06, 09:12
Meer info would be nice :)
Wat wordt er van mij verwacht behalve webhosting-ruimte?

XBL
27/06/06, 09:31
Wij doen ook graag mee (Open Host). Via reversed billing betalen vind ik geen probleem, vermits de sms'jes maar niet 75 cent per stuk gaan kosten (de genoemde 25 cent vind ik wel de max; inkoop ligt voor op dit moment op de helft).

Wel vraag ik me de volgende zaken af:

- Wordt er gebruik gemaakt van een centrale database? Of wordt er op een bepaalde manier gebruik gemaakt van replication? 1 centrale database heeft als nadeel dat downtime van diezelfde database onacceptabel is.

- Om 'nut' te hebben van een dergelijk groot netwerk (hoe meer mensen zich laten controleren; hoe meer servers kunnen controleren), moeten er natuurlijk wel vanaf meerdere locaties een check plaats vinden in geval van vermeende downtime (zodat deze bevestigd kan worden door, bijvoorbeeld, 2 andere netwerken -> aansluitend: hoe selecteer je die andere netwerken; doe je het at random is geef je nog bepaalde voorwaarden mee). Komt dit er ook in? Dit lijkt mij, net als een goede oplossing voor de centrale database, extreem belangrijk.

Het zou trouwens ook prettig zijn als de stats in XML aangeboden wordt; dan kan men vervolgens zelf bepalen wat ze met de data doen.

Leuk project verder, ik hoor het wel als er hulp nodig is.

Jochem

WilloW
27/06/06, 10:01
Eliveld Networks wil ook wel wat doen.. voordeel is dat wij gebruik maken van Datacentrum in Doetinchem, En straks NDix hebben en nog een andere lijn dus mocht amsterdam volledig plat gaan zijn wij nog up

Als het goed is.

starfix
27/06/06, 10:28
- Wordt er gebruik gemaakt van een centrale database? Of wordt er op een bepaalde manier gebruik gemaakt van replication? 1 centrale database heeft als nadeel dat downtime van diezelfde database onacceptabel is.


Wat ik als eerste dacht was dat iedere hoster zijn eigen database heeft, met daarin alleen de gegevens: Service is up of down, als down nog een keer checken en dan smsen of e-mailen.
Dus eigenlijk hetzelfde als het NOC script.
Misschien is het ook een idee een netwerk te creeren van hosters, dat de een bij de ander checkt of een website inderdaad plat ligt. Zo ja: Smsen of mailen

Leuk project verder, ik hoor het wel als er hulp nodig is.

Jochem[/quote]

_arno_
27/06/06, 11:57
Ik zou op elke webserver scriptje draaien wat alles via xml displayed, ik zat zelf te denken aan zoiets ( had bij zoiets ook keer gedachte om wat mee te doen ):
http://www.van-rossum.com/additional/noc/noc/serverstatus.php

Alleen ik wist zelf nog niet helemaal hoe ik het beste kon syncen over meerdere servers, vandaar dat ik gestopt was ermee.
Hoe ga jij dit oplossen?

Overigens als je een testbak nodig heb zonder paneel en email server moet je het maar even zeggen.
Dan ben ik bereid om wel database open te zetten, vind dit soort projecten altijd wel leuk.

starfix
27/06/06, 12:07
Ik zou op elke webserver scriptje draaien wat alles via xml displayed, ik zat zelf te denken aan zoiets ( had bij zoiets ook keer gedachte om wat mee te doen ):
http://www.van-rossum.com/additional/noc/noc/serverstatus.php

Alleen ik wist zelf nog niet helemaal hoe ik het beste kon syncen over meerdere servers, vandaar dat ik gestopt was ermee.
Hoe ga jij dit oplossen?

Overigens als je een testbak nodig heb zonder paneel en email server moet je het maar even zeggen.
Dan ben ik bereid om wel database open te zetten, vind dit soort projecten altijd wel leuk.

Syncen lijkt me niet nodig, of misschien gewoon via een GET request.

Wat ik in gedachte had:

checkserver1:
- user1
- user2

Checkserver2:
- user3
- user4

Checkserver1 ziet dat user1 dood is, dan stuurt hij een GET request naar checkserver2 met de vraag of bij hem ook user1 offline is. Zo ja: smsen of mailen. Daarnaast kunnen checkserver1 en 2 elkaar in de gaten houden (en wel eventueel elkaars users overnemen voor het geval een checkserver plat gaat)

Als iedere hoster dezelfde users zou krijgen dan genereer je onnodig verkeer.

_arno_
27/06/06, 12:13
Ik had zelf ook een dergelijke constructie bedacht, helaas weet ik niet zeker of dit wel praktisch werkt.

Hoe doe je dit als je meerdere checkservers krijgt? user1 gaat plat, stuur je dan naar elke checkserver een vraag of user1 het doet?

Wat als user1 plat is en checkserver2 is plat? dan zou je dus meerdere checkservers moeten hebben.

Hoe hou je je checkserver lijst bij, centrale database, sync je die? ;)

aartvg
27/06/06, 12:18
goed iedee,

maar ik denk dat het een helehoop denk werk is.
zoals hier al gebuurt.

zoveel dataverkeer zal het niet wezen denk ik.

er moet ijgelijk een ijgen app geschreven worden die niet afhanelijk is van bv. apache of anderen app's,
dat programma luuster gewoon 1 poortnummer af
al komt daar een aanvraag op binne gaat hij zelf (locaal) alle services af kijken of die nog berijkbaar zijn.
dan geeft het app. een xml terug wat de status is van de services
dit is dan makelijk te controliren door middel van php of zo.

ik wil ook wel mee doen tevens met ontwikkelen

edit:


Hoe hou je je checkserver lijst bij, centrale database, sync je die? ;)
dat moet tog geen probleem zijn dat kan doormiddel van 1 master db en op de anderen controleer services de zelfde db. al heb je dan 1 server die als master dient al is er dan 1 down gaat hij naar de 2 de server

groeten Aart

_arno_
27/06/06, 12:31
Eigenlijk is het idd het mooiste om een soort deamon te hebben draaien die alles terug geeft.

Technotop
27/06/06, 12:36
Gewoon één bestand op een server plaatsen, via script elke dag 1x laten binnen trekken waar alle hosts in staan bijvoorbeeld. Hoef je zelf niets meer te up daten en gaat het vol automatisch (het updaten).

DiedX
27/06/06, 13:32
Gewoon één bestand op een server plaatsen, via script elke dag 1x laten binnen trekken waar alle hosts in staan bijvoorbeeld. Hoef je zelf niets meer te up daten en gaat het vol automatisch (het updaten).
Kunnen we dit niet doen?

1 centraal inlogpunt (hub?) voor alle hosters, waarbij je eens per uur een XML plaatst, welke de checkers ophalen.

De checkers doen aan de hand van de nieuwe XML de hosts checken, en plaatsen die in een lokale XML, die kan weer opgehaald worden door de hub.

Voordelen:

1 punt van opslag
1 punt van inlog
weinig rompslomp (als je het dat al vind) voor de checkers

NADEEL (!)
SPOF (Single Point Of Failure) . (Al zou je dat kunnen voorkomen door bij geen update gewoon door te gaan op de huidige config)

Zit ik me alleen even af te vragen hoe dat met de SMS moet. Als de hub SMS'd kan je dat direct billen, maar dan zit je weer met je SPOF. Of mijn bak gaat naar die van starfix om te checken, en daarna SMS, maar dan zal je dat inderdaad qua SMS-configuratie moeten configureren.

Interesting :)

starfix
27/06/06, 14:09
Kunnen we dit niet doen?

1 centraal inlogpunt (hub?) voor alle hosters, waarbij je eens per uur een XML plaatst, welke de checkers ophalen.

De checkers doen aan de hand van de nieuwe XML de hosts checken, en plaatsen die in een lokale XML, die kan weer opgehaald worden door de hub.

Voordelen:

1 punt van opslag
1 punt van inlog
weinig rompslomp (als je het dat al vind) voor de checkers

NADEEL (!)
SPOF (Single Point Of Failure) . (Al zou je dat kunnen voorkomen door bij geen update gewoon door te gaan op de huidige config)

Zit ik me alleen even af te vragen hoe dat met de SMS moet. Als de hub SMS'd kan je dat direct billen, maar dan zit je weer met je SPOF. Of mijn bak gaat naar die van starfix om te checken, en daarna SMS, maar dan zal je dat inderdaad qua SMS-configuratie moeten configureren.

Interesting :)

Dit komt al aardig in de buurt in ieder geval. Eén centrale DB zou het beste zijn inderdaad. Eén hoster zou dande centrale DB moeten checken en kunnen smsen naar de eigenaar van die server als hij down gaat. De rest gaat dan gewoon door met het checken van de opgeslagen lijst.

Ook een nummertje geven aande lijst zou handig zijn. Eerst vraag je aan de cenrale of er een update is, zo ja, updaten, zo nee, dan bespaar je weer een paar KB. Lijsten kunnen dan eens per uur(?) worden opgehaald.

Met SMS zou Frangk wat kunnen maken, je geeft een nummer op waarnaartoe het gestuurd moet worden, Frangk checkt of het nummer bestaat als account, zo ja, dan wordt hij via dat account verstuurd, anders betaal je 25 cent voor een ontvangen sms.
Wat óók nog zou kunnen is dat alleen de centrale SMSjes verstuurd, dan kan Frangk een IP adres instellen. User-login gegevens kunnen dan in de centrale worden opgeslagen als een hash (die worden dan niet getoond).

DiedX
27/06/06, 15:07
Ik heb trouwens heel het NOC-script gemist. Volgens mij moet dit een proof-of-concept worden? Anders zou Zabbix al een kant-en-klare oplossing zijn :)

starfix
27/06/06, 15:08
Ik heb trouwens heel het NOC-script gemist. Volgens mij moet dit een proof-of-concept worden? Anders zou Zabbix al een kant-en-klare oplossing zijn :)
In mn OP staat een link

DiedX
27/06/06, 15:10
In mn OP staat een link
Weet ik ;)

Ik doe gewoon mee. Ik vind het een leuk project, waarmee we (ik heb een prive-bak) als webhosters elkaar kunnen helpen, en dat vind ik leuk.

Je zou ook zo de updates van de software kunnen "pushen"

XBL
27/06/06, 15:28
Ik vind het idee van een centrale database niets. In ieder geval niet op de huidige manier. Het idee dat de centrale database eruit ligt is bij 10 deelnemers geen probleem, maar bedenk eens wat er gebeurt als er 200 hosters mee doen: een downtime van die hoster precies op het moment dat de centrale DB eruit ligt, is goed mogelijk. Vervolgens kunnen er geen sms'jes meer verzonden worden (of doet de checkserver dat zelf? Dat volg ik niet helemaal) en worden er geen stats gelogt.

Je zou dan al op een loadbalancing systeem moeten terugvallen. Dit is opzich wel te 'faken' door meerdere servers als 'master' in te stellen. Ze hebben allen elkaars informatie en in het geval dat er 1 down gaat, weten alle 'clients' dat ze naar een andere 'master' moeten gaat (vergelijkbaar met het MX record met verschillende prioriteiten). Je kan ook kiezen meerdere masters te nemen en clients at random te laten kiezen voor een master (vergelijkbaar met het MX record met dezelfde prioriteit); zo verdeel je de load ook enorm (wat behoorlijk kan toenemen afhankelijk van het aantal deelnemers).

@probleem van tweede check: Dit is op te lossen door de actuele status (helaas wel minimaal 1 minuut vertraging) van de tweede server op te halen (dit moet dus wel ergens centraal staan). Is deze up, dan kan er een tweede check gedaan worden, anders wordt er een andere server gekozen.

Hoe gaat trouwens status gelogt worden? Wordt er alleen up/down gelogt of ook uptime statistieken; en hoe ga je deze statistieken opslaan?

@verkeer: Ik denk dat het voor weinig hosters uit maakt als er 10gb per maand bij komt (dat is veel voor een client; een master zou dit wel kunnen krijgen).

Daarnaast is het misschien interessant te kijken naar een oplossing van Zabbix, zoals DiedX al zegt. Dit is een mooi pakket en hoogst waarschijnlijk een stuk efficiënter dan PHP.

Zoals je ziet, zie ik het wel graag behoorlijk professioneel. Het controleren van je servers is immers heel belangrijk en als dat halfbakken gaat waardoor je soms SMS'jes mist dan zal ik er al snel geen gebruik meer van maken.

Jochem

Danny Mekic
27/06/06, 16:00
SMS middels reversed billing..

Technotop
27/06/06, 16:02
Ik heb zelf net een test server staan in Rotterdam. Deze wil ik geheel inrichten als centrale database en noc server voor onze NOC. Deze kan als centrale noc server dienen voor jullie project.

Zelf ben ik ook wel benieuwd.

Gegevens voor onze noc krijgen wij nu uit:

Amsterdam, Euroaccess
Amsterdam, Reasonnet
Rotterdam, VerAert.

In Rotterdam lees ik alles uit zodat ik een totaalplaatje krijg.

Sander-
27/06/06, 16:20
Ik snap inet waarom iedereen dit aan de kant van de checkservers gaat zoeken in synchen ed... Ik heb zoiets van werk via een soort advertise principe, op de client staat een configfile met welke checkservers hij wil gebruiken, deze client biedt die file + andere configparameters, zoals de te checken poorten, aan aan de checkservers.

Nu kunnen de checkservers als tijdens controle de server eruit blijkt te liggen een simpele request sturen naar de andere servs. Allemaal IP/Portbased.

En tot slot kan de SMS en e-mail info gewoon ook in de configuratiefile meegezonden worden.

_arno_
27/06/06, 16:24
Nadeel is dat je dan misschien op elke client een programmatje/cronjob moet gaan draaien.
Je wilt toch periodiek de status weten.

Voor de rest vind ik het eigenlijk wel een interessante oplossing.

Sander-
27/06/06, 16:26
Nadeel is dat je dan misschien op elke client een programmatje/cronjob moet gaan draaien.
Je wilt toch periodiek de status weten.

Voor de rest vind ik het eigenlijk wel een interessante oplossing.

Lijkt me niet nodig, als er een otpie ingebouwd wordt om na configwijzigingen doormiddel van een simpel shellscriptje opnieuw de configuratie aan te bieden ana de checkservers (uiteraard met MD5 hash om integriteit van de file te checken)

DiedX
27/06/06, 19:22
Ik vind het idee van een centrale database niets. In ieder geval niet op de huidige manier. Het idee dat de centrale database eruit ligt is bij 10 deelnemers geen probleem, maar bedenk eens wat er gebeurt als er 200 hosters mee doen: een downtime van die hoster precies op het moment dat de centrale DB eruit ligt, is goed mogelijk. Vervolgens kunnen er geen sms'jes meer verzonden worden (of doet de checkserver dat zelf? Dat volg ik niet helemaal) en worden er geen stats gelogt.

Dat is ook het probleem wat ik met een centrale database heb. Maar een alternatief zou half P2P zijn, waar ik me een voorstelling bij kan maken dat je dat OOK weer niet wilt.


Je zou dan al op een loadbalancing systeem moeten terugvallen. Dit is opzich wel te 'faken' door meerdere servers als 'master' in te stellen. Ze hebben allen elkaars informatie en in het geval dat er 1 down gaat, weten alle 'clients' dat ze naar een andere 'master' moeten gaat (vergelijkbaar met het MX record met verschillende prioriteiten). Je kan ook kiezen meerdere masters te nemen en clients at random te laten kiezen voor een master (vergelijkbaar met het MX record met dezelfde prioriteit); zo verdeel je de load ook enorm (wat behoorlijk kan toenemen afhankelijk van het aantal deelnemers).


True, maar dan zit je weer met het SMS verhaal. EN het wordt een redelijk hels karwei om zoiets te maken.



@probleem van tweede check: Dit is op te lossen door de actuele status (helaas wel minimaal 1 minuut vertraging) van de tweede server op te halen (dit moet dus wel ergens centraal staan). Is deze up, dan kan er een tweede check gedaan worden, anders wordt er een andere server gekozen.

Hoe gaat trouwens status gelogt worden? Wordt er alleen up/down gelogt of ook uptime statistieken; en hoe ga je deze statistieken opslaan?

Wees eens creatief ;) Met dit systeem kan je dit zelf bepalen. Dat is ook datgene wat ik een beetje TEGEN het script heb: bijna alles bestaat al (Nagios checkt, Zabbix checkt, BB checkt, dus waarom moet je weer het wiel opnieuw uitvinden. Maar goed, ik ga het niet programmeren ;))



@verkeer: Ik denk dat het voor weinig hosters uit maakt als er 10gb per maand bij komt (dat is veel voor een client; een master zou dit wel kunnen krijgen).

Ik denk dat dat wel meevalt.


Daarnaast is het misschien interessant te kijken naar een oplossing van Zabbix, zoals DiedX al zegt. Dit is een mooi pakket en hoogst waarschijnlijk een stuk efficiënter dan PHP.

Dat laatste weet ik niet. Ik doe zelf weer (gratis) checken voor een andere partij, en mijn eigen bakkies. Zelf laat ik Zabbix-server weer checken door Nagios op een ander netwerk, door een collega. (!10051 = alarm). Hierdoor watch je de watchdog, waardoor ik wel zeker weet dat het gecheckt wordt.

Ik heb mijn Zabbix gedeeltelijk openstaan op http://zabbix.diedx.nl/. Hier mag je gerust rondklikken. Vooral http://zabbix.diedx.nl/screens.php is erg leuk :)



Zoals je ziet, zie ik het wel graag behoorlijk professioneel. Het controleren van je servers is immers heel belangrijk en als dat halfbakken gaat waardoor je soms SMS'jes mist dan zal ik er al snel geen gebruik meer van maken.

Monitoring is een gedeelte van je professionaliteit. Zelf houdt ik er van om zelf er voor te zorgen dat de zaak niet plat gaat, wat ik zelf ook professioneel vind ;)

liber!
27/06/06, 19:28
Ik wil zeker ook hieraan meedoen (over een maandje). Monitoring vanuit LCL Antwerpen op EuroAccess en een VPS servertje in de VS.

InterNetjes
28/06/06, 02:36
Ik wil zeker ook hieraan meedoen (over een maandje). Monitoring vanuit LCL Antwerpen op EuroAccess en een VPS servertje in de VS.

Ik wil best een accountje regelen qua sms, voor fallback, dus iets van 50 ofzo?

Werkt via een simpele API.

londoneye
28/06/06, 02:44
Wie gaat 't hele scriptingwerk doen dan? Wordt dit een charity-actie dan? In het belang van alle medewerkende webhosters willen er wel iemand het voortouw nemen die alles programmeert?

Maico
28/06/06, 03:33
Ik zit net het hele topic door te lezen, en ik vind het echt een super idee :W:.
Wel zou ik graag nog 1dinge willen opmerken/toevoegen.

Er word nu gezegd dat je wilt sync met andere clients, of via een centrale database. Maar, stel je netwerk is down. Hoe willen mensen dan ooit je noc pagina gaan berijken (de de voorstelling dat je maar op 1 netwerk zit!). Of dat je NOC server down gaat.

Dan is het nog steeds wel handig dat de noc pagina werkt (en dan ook voor de simpele hoster). Hoe je dit zou kunnen oplossen weet ik zo ook niet. Maar het is misschien een gedachte :).

Als er hulp nodig is help ik graag (php oid :))

:lovewht:

NDIS
28/06/06, 18:51
Ik vind dit ook een zeer interesant project ik hou het in de gaten!

Maar wat dacht je van 3 of 4 Master servers in verschillende netwerken in verschillende landen wie met elkaar de data syncen

aartvg
28/06/06, 19:04
Dan is het nog steeds wel handig dat de noc pagina werkt (en dan ook voor de simpele hoster). Hoe je dit zou kunnen oplossen weet ik zo ook niet. Maar het is misschien een gedachte :).

Als er hulp nodig is help ik graag (php oid :))

:lovewht:


we gaan controliren op verschillende locaties je noc pagina blijft gewoon op je ijgen server draaien / meschien colega hoster maar niet dat iedereen iedereens servers kan zien

we zouden een soort db moeten hebben waar alle gegevens in staan van alle server die mee doen, daar kan je dan per ip de gegevens ophalen van down / up

allemaal meschien een beetje ondudelijk.

en er moet 1 iemand de lijding nemen anders gaat het echt op niks uit lopen...

TiMMiEJ
28/06/06, 19:43
Ik heb even het topic in een vogelvlucht doorgenomen. Ik zie het volgende probleem steeds terugkomen:

Stel je pakt een centrale database waar je alle servers in hebt staan die gecheckt moeten worden. Stel dat de 'checkserver' plat gaat of het gehele netwerk ligt op zijn gat. Hoe los je dit op?

Ik denk dat je iedere user die iets wil laten checken moet laten registreren, waar hij in een controlepanel servers kan toevoegen en op welke poorten er gecontroleerd moet worden. Als hij een SMS account heeft (weet niet precies hoe dat SMS gedoe in elkaar zit) dat ie dat moet invullen in zijn panel. Stel er gaat iets down, dan krijgt ie een SMS en die betaald ie zelf. Stel iemand heeft account bij een SMS ding(?). Dan krijgt ie een SMS die automatisch betaald wordt, maar de prijs ligt een stuk hoger. (ben ff zijn nick vergeten, maar iemand in dit topic kon dit aanbieden).

Het enige probleem is dus de database, als die plat ligt moet ie ergens anders zijn data vanaf halen.

Ik lees net de reactie hier boven mij, waar ik me goed in kan vinden. Stel je hebt een stuk of 3 'masterservers'. Iedereen draait het NOC script op zijn eigen server, het script kijkt of ie de masterserver kan bereiken. Zoja, dan haalt ie daar zijn data vanaf. Is dat niet het geval gaat ie bij de 2e server kijken en zo verder.

Je zult wel gewoon op de 'hoofdsite' je servers moeten toevoegen/verwijderen enzovoort. Hoe je de data op alle 'masterservers' krijgt zal het grootste probleem niet zijn.

_arno_
28/06/06, 20:06
Naja ik neem aan dat de checkservers niet afhankelijk zijn van je centrale database.
Bv if database is down, hou oude config aan.

Overigens hoeft de database geen probleem te zijn, aangezien het maar een suggestie was van mij ;)

TiMMiEJ
28/06/06, 20:42
Naja ik neem aan dat de checkservers niet afhankelijk zijn van je centrale database.
Bv if database is down, hou oude config aan.

Overigens hoeft de database geen probleem te zijn, aangezien het maar een suggestie was van mij ;)

Maar mijn plan is toch nog een slecht idee :P. Want ik had in gedachten dat je als client zelf moet checken. Maar je moet natuurlijk een SMS krijgen wanneer de boel plat ligt. En dat kan dus niet als je het zelf moet checken!

Dan loop je meteen tegen het volgende probleem aan:
Stel je hebt 3 masterservers die natuurlijk allemaal dezelfde database hebben met dezelfde gegevens.

Hoe controleer je dan of er iets down is? Doe je dit vanaf de masterservers? Zoja, hoe weet je dan vanaf welke server je moet checken, want als het netwerk eruit ligt bij die server dan kan die niet ff zeggen tegen die andere doe jij het maar want hier ligt het netwerk plat.

_arno_
29/06/06, 00:29
Waarom zou dat niet kunnen ?

Je kan bv op de client mysql ftp etc checken, en als je geen verbinding krijgt met die server dan krijg je een sms.

Of iets down is doe je natuurlijk op je checkservers, heet niet voor niets checkservers :P

Op je checkservers doe je het volgende:
1 keer in de x tijd doe je een check,
die check houd in:
contact maken met 'master' server om checklist te updaten, is deze plat hou dan oude config aan.
Loop daarna de checklist door, zijn er servers plat vraag aan andere checkserver of hij daar ook plat is.
Verwerk gegevens in database, en klaar is kees ;)

Tenminste zo denk ik dat het ongeveer bedoelt word hierboven, alhoewel dit natuurlijk 1 systeem is, en zo mogelijk niet de weg naar rome.

XBL
29/06/06, 08:30
@_arno_: Ik weet niet zeker of jij dit ook had bedacht; maar de checkservers ('clients') kunnen niet alle servers checken (is ook niet nodig). Kortom: per checkserver moet het aantal te checken servers eerlijk verdeeld worden (wat inhoud dat je als checkserver maar 1 server hoeft te controleren plus soms nog een second opinion voor een andere server).

Ik weet niet wat de master servers hier van gaan vinden als dit elke minuut gebeurd (elke minuut dus het fetchen van een config bestand door alle servers en elke minuut een update van de status).

@TiMMiEJ: Problemen met het syncen van de masters zijn er niet; een master moet gewoon elke X tijd de laatste config ophalen (en de stats updaten). Lukt het een keer niet, is dat geen punt: de volgende keer wordt de config dan wel opgehaald. Dit betekend wel dat het soms voorkomt dat bepaalde nieuwe servers niet gecheckt worden.

Jochem

_arno_
29/06/06, 09:45
Naja ik had er nog niet over na gedacht of elke checkserver alle clients moet bekijken, inderdaad logischer om dit niet te doen.

Ik denk dat de master server helemaal niks moet doen, behalve checkserver list bijhouden.

Ik denk dat de masterserver niet de checkservers moet updaten, maar de checkservers de master server.

Dus checkserverA komt erachter dat er een status wijziging is bij clientA, ( als voorbeeld offline ), checkserverA weet dit niet zeker en vraagt aan checkserverB of dit inderdaad het geval is.
checkserverB geeft terug, clientA is inderdaad down.
checkserverA verwerkt gegevens en stuurt deze op naar masterserver.

Op deze manier hoeft de masterserver alleen de gegevens verwerken op het moment van clientA status change.
En laten we nou eerlijk zijn, jullie als 'fantastische' hosters zijn toch altijd up. ;)
Dus krijgt de masterserver geen update requests, en is er geen load. :D


Plus daar komt eens bij dat je bv de checkservers naar config update zou kunnen laten kijken 1 keer per dag bv, waardoor je de load zou kunnen verhuizen naar doeloze tijden.

[offtopic]Over de duizend posts :eek: :lovewht:
Moge ze steeds nuttiger worden!

XBL
29/06/06, 10:46
Het updaten van de status hoeft inderdaad niet voor veel load te zorgen (er hoeft enkel een update naar de master indien de status is veranderd ten tijde van de check. Van 'up' naar 'down' of 'down' naar 'up).

Wel moet er telkens opgehaald worden welke server er gecheckt moet worden. Om het netwerk ten volle te benutten, is het wel zo prettig als de clients telkens een andere server voor hun rekening nemen. Misschien moet de config uit een lijst bestaan van een X aantal servers (bijvoorbeeld 60 servers indien er elke minuut gecheckt wordt), wel is het dan van belang dat er op het juiste tijdstip de juiste server gecheckt wordt.

Als een server namelijk overgeslagen wordt (doordat de cronjob een minuut oversloeg om wat voor reden dan ook (reboot etc)), gaat de hele boel in de war (servers worden niet gecheckt en servers worden dubbel gecheckt).

Ook moet het checken van de betreffende client overgenomen worden, indien deze down lijkt te zijn. Welke client gaat dit overnemen (random kiezen?). Uiteraard moet de nieuwe client (die het werk overneemt) dan de config binnenhalen van de client die down is gegaan en het werk oppakken op de juiste server.

Pfoe, gaat nog een hoop denk en script werk in zitten ;).

Jochem

_arno_
29/06/06, 11:10
Het ophalen welke servers gecheckt moeten worden doe je natuurlijk niet elke minuut, maar bv 1 keer per dag/meer.

Welke server je second opinion zou moeten worden is idd een interessante vraag, lijkt me dat je dit denk ik random het beste zou kunnen doen.
Heeft weinig kracht nodig aangezien de 2decheckserver maar 1 user extra hoeft te doen (denk ik zo).

Daarnaast moet je opletten dat je als checkserver netwerkje zelf niet plat gaat anders zou je load behoorlijk kunnen oplopen aangezien je dan om second opinions blijft vragen, infinite loop etc etc. :P


Anyways, nu zijn wij wel lekker aan het filosoferen alleen hoor ik niemand die nou daadwerkelijk iets gaat maken lol.

Overigens ben ik bereid wat space open te zetten in we-dare, en mogelijk mee te helpen aan een scriptje.

Dieter@be
29/06/06, 11:25
dat het hele gemeenschappelijk-noc-systeem eerst nog geplanned,uitgewerkt en gefijntuned moet worden lijkt me duidelijk, ik vind de aanmaak van deze topic dan ook erg vroegtijdig :) (ik zou dan ook terug gaan naar "de grote noc script topic" maarja wie ben ik)

en om even op die http GET request ideeen terug te komen, als je dat iets verder uitwerkt kom je uit bij soap http://www.w3.org/TR/soap12-mtom/, welke heel eenvoudig te implementeren is in php (php4 : een of andere lib uit bv SF.net; php5: native)

maar de vraag blijft maar weer: wie gaat dat allemaal programmeren? dit is niet "effe een scriptje schrijven" meer :)

DiedX
29/06/06, 12:36
maar de vraag blijft maar weer: wie gaat dat allemaal programmeren? dit is niet "effe een scriptje schrijven" meer :)
Ik KAN helaas niet programmeren (niet zo goed als de gemiddelde persoon hier anyway), maar weet daarentegen weer genoeg over hosting. Ik denk dat we WEL iemand nodig hebben om het project op te pakken. Helaas heb ik niet de tijd om nog een prive-project er naast op te pakken (heb nog 2 dedicateds uit te rollen, en wil ook wel weer eens RUST :))

_arno_
29/06/06, 13:01
Uit topics is dus gebleken dat er voldoende interesse is aan verschillende kanten, het enige waar het aan ligt zijn dus programmeurs en een project leider. ;)

Wie staat op :)

Postbode.Org
29/06/06, 13:23
Het is natuurlijk een leuk initatief, maar er moet idd wel een serieuze projectleider komen. Anders is dit project doodgebloed voordat we de final halen.

Ik wil wel ruimte beschikbaar stellen voor het e.e.a de (serieuze) projectleider komt zich maar melden als hij/zij er belang bij heeft.
Server staat niet in Amsterdam, maar in Friesland

Groet,

Arend

XBL
29/06/06, 13:30
Helaas heb ik geen tijd om een project te leiden. Wel ben ik bereid delen van de code te schrijven; enkel PHP echter.

Maar voordat er überhaupt aan schrijven van code gedacht kan worden, moet eerst het hele project gestart worden en moet er gedocumenteerd worden wat er allemaal moet gebeuren.

Jochem

Jochem

Keizer
29/06/06, 14:36
Ik stel me wel beschikbaar om het project te leiden... Dan ga ik er wel vanuit dat ik meer steun krijg dan kritiek..

Domenico
29/06/06, 14:37
Een beetje zoals dit dus -> http://host-tracker.com/partnership/ ?

Keizer
29/06/06, 14:41
een beetje wel ja ;)

XBL
29/06/06, 15:26
Een beetje zoals dit dus -> http://host-tracker.com/partnership/ ?
Beetje inderdaad, hoewel ik host-tracker.com niet betrouwbaar verder vind (foute stats).

@hoJan: Meestal is kritiek negatief, aangezien de complimentjes pas komen als alles af is. Als je niet om kan gaan met negatieve kritiek, kan je beter niet een project gaan leiden. En kritiek is ook meestal 'steun'... dan weet je immers wat er anders/beter moet etc.

Jochem

Keizer
29/06/06, 15:30
Afzeikende kritiek omdat de ander niets doet kan ik niet hebben.

Opbouwende kritiek (aka steun) van meehelpende mensen vind ik leuk en stel ik ook erg op prijs!

Maico
29/06/06, 19:46
Mocht je nog een scripter nodig hebben, ben ik graag bereid om het e.e.a. mee te helpen. Wel gaarne in php dan ;).


:lovewht:

groenleer
30/06/06, 11:45
Ik wil iedereen die aan dit project mee gaat werken (coders, leaders, testers) er op wijzen dat je project valt of staat met een goede documentatie.

Ik weet niet of er mensen hier goed bekend zijn met software ontwikkeling-planning en het maken van documenten met Eisen, Functioneel ontwerp en Technisch ontwerp.

Dit zijn mijn inziens toch de documenten die je moet hebben voordat je gaat code. Dit om er voor te zorgen dat je ook dat maakt, dat men wil hebben. Of dit nu een project is voor je eigen, je conculega's of je klanten.

Verder is het goed om na te denken in welke vorm je het uit eindelijk gegoten wilt hebben.
Het lijkt mij niet moeilijk om alle statistieken op "een" gezamelijke server te plaatsen, welke de informatie dan ook weer geeft (afhankelijk van de domeinnaam waar het request naar toe gaat) (Meerdere Vhosts op 1 codebase).

Ik zou iedereen, om eens te kijken welke wensen iedereen heeft voor een monitoring systeem, willen verzoeken om voor zichzelf de eisen op te schrijven. Dan er een nachtje over te slapen, en ze vervolgens hier te plaatsen. Dan kunnen we zien welke wensen gemeenschappelijk zijn.

Ook kan dan met een MoSCoW methode gekeken worden wat er gebouwd gaat worden.
MoSCoW:
Must have
Should have
Could Have
Won't Have
Als ik het me goed herriner van school....

Voor zover mijn gedachtengang over dit onderwerp.

XBL
30/06/06, 13:34
Dit zijn mijn inziens toch de documenten die je moet hebben voordat je gaat code. Dit om er voor te zorgen dat je ook dat maakt, dat men wil hebben. Of dit nu een project is voor je eigen, je conculega's of je klanten.Lijkt me vrij logisch (ik neem aan dat hoJan dat ook weet).

Mijn eisen:

Master: enkele servers in het netwerk welke allen dezelfde informatie hebben en informatie leveren aan- en ontvangen van de clients.
Client: alle andere servers in het netwerk welke controleren. Deze halen de informatie op van de masters.
Server: zelfde als een client, maar dan in de hoedanigheid van een te controleren server.

- Redundante uitvoering van de masters, ala MX systeem in DNS (zelfde prioriteiten, zodat de load verdeeld wordt... in een simpele manier (het is niet meer dan random een master kiezen)). Masters syncen elk uur (als een master down is, krijgt deze geen nieuwe informatie, pas het volgende uur wordt het weer aangeboden).

- Clients downloaden elk uur (elke dag kan ook; doet er niet veel toe) een lijst met servers die zij moeten checken. Die is per client uniek. De servers die gecheckt moeten worden krijgen een tijd mee (enkel dag + uur + minuut); zo worden servers niet per ongeluk dubbel gecheckt. Zodra een client down gaat, neemt een andere client het checken over (haalt dus de lijst van de client die down is op van één van de masters). Een client checkt in principe nooit meer dan 2 servers te gelijk (tenzij meer dan de helft van het client-netwerk eruit vliegt).

- Indien een server down gaat, wordt dit gemeld aan de master. De master houd dus de statistieken bij. Indien een server weer up komt, krijgt de master dit ook te horen (voor het gemak kan je ervoor kiezen dezelfde master die informatie te geven; maar dit maakt niet zo heel veel uit aangezien alles uiteindelijk bij elkaar gezet wordt en zo de stats weer kloppen).

- Statistieken komen in een vhost beschikbaar op de masters. Zo kan je als hoster een subdomein (die blijft werken bij downtime dankzij je redundante dns) koppelen aan de master. Klanten kunnen dan altijd bij je statistieken (en dus weten of je down bent!), zelfs als het netwerk eruit is (moet je sec.dns wel buiten het netwerk staan).

- Opslaan van de downtime lijkt me het makkelijkste door een timestamp op te slaan van down gaan en up komen. Hiermee kan je dan de statistieken berekenen van je uptime op elke manier die je maar zou willen (per uur, per dag, per week, per maand, per jaar, per [insert random getal] dagen)

edit: - In geval van down gaan wordt er een smsje+mail verstuurd; zoals ik het begrepen hebt kan je het volgende doen:
* Als het nummer bekent is: credits van de persoon die dat nummer heeft verlagen.
* Als het nummer niet bekent is: reversed billing toepassen.
De master zal het SMS'je moeten versturen, om zo misbruik te voorkomen (enkel de mensen die een master beheren kunnen het SMS'en misbruiken. Enige misbruik wat ik me overigens kan voorstellen is dat mensen SMS'jes naar andere gaan versturen zodat ze opdraaien voor de kosten). Uiteraard ontvang je bij downtime maar 1 SMS'je, en misschien nog een herhalings SMS'je na een uur.

Er zitten misschien nog wat gaten in mijn idee, maar dat ontdekken we wel bij verdere discussie erover.

Jochem

groenleer
30/06/06, 14:18
Lijkt me vrij logisch (ik neem aan dat hoJan dat ook weet).



Ik dacht dat iedere zichzelf software engineer noemend persoons dit wist.
Helaas heeft de praktijk mij geleerd dat de personen die iets er 'even' bij willen doen vaak de cruciale stappen vergeten.

Ook mensen die dus serieus alleen maar met dit soort zaken bezig zijn, vergaten dit in het begin nog wel eens. Ik ga er ook wel vanuit dat iemand die zich opwerpt als projectleider hier aan heeft gedacht.

Ik wil hoJan dan ook heel veel succes wensen bij dit project.

Keizer
30/06/06, 14:25
Helaas moet ik melden dat het feest niet doorgaat. Ik heb een aantal opdrachten gekregen waardoor ik niet de tijd heb die hiervoor nodig is. Als ik over een aantal weken weer tijd heb en er is nog niets gebeurd, dan ga ik er zeker weer mee bezig, maar op dit moment gaat dit niet lukken!

_arno_
30/06/06, 14:36
Statistieken komen in een vhost beschikbaar op de masters. Zo kan je als hoster een subdomein (die blijft werken bij downtime dankzij je redundante dns) koppelen aan de master. Klanten kunnen dan altijd bij je statistieken (en dus weten of je down bent!), zelfs als het netwerk eruit is (moet je sec.dns wel buiten het netwerk staan).

Statistieken moeten aangeboden worden in XML, dan kun je zelf er mee doen wat je wilt!

Dieter@be
30/06/06, 15:51
ow en btw, vaak (veel te vaak naar mijn goesting) worden er nieuwe opensource projecten gelanceerd terwijl er al gelijkaardige (met dezelfde doelstellingen en ideeen zelfs soms) projecten in de maak zijn. Vaak is het beter om daarop in te pikken en soms zijn alle/de meeste benodigdheden gewoon al prima werkend.

vandaar dat het misschien interessant kan zijn om eens de projecten te bekijken op bvb SF.net
http://sourceforge.net/search/?type_of_search=soft&words=noc
(misschien ook eens synoniemen of verwante woorden van noc proberen)

XBL
30/06/06, 15:55
@_arno_: Inderdaad, dat ben ik vergeten erbij te zetten. In XML krijg je alles aangeboden, zodat je zelf kan uitzoeken wat je wilt (en dus de uptime weer geven op elke manier die je maar wilt). Maar ik vind ook dat er, zoals in mijn uitleg, een standaard pagina moet komen. Klanten willen namelijk graag weten wat er aan de hand is bij een downtime, en dit kan niet als je eigen site op de server staat die down is of als het netwerk eruit ligt.

Jochem

DiedX
02/07/06, 17:10
Ik denk dat we veels te ver ingaan op de materie zelf. HOE we het maken zien we later weer, maar laten we eerst eens kijken WAT we willen hebben.

Zelf heb ik geen behoefte aan monitoring: ik draai mijn eigen Zabbix, en die Zabbix wordt gecheckt door Nagios van een collega.

Ik denk dat het product/project een aantal significante voordelen moet hebben boven het hebben van een eigen Nagios/Zabbix/BB/whatever. Het enige voordeel wat ik kan noemen zijn:

- Monitoring van buitenaf (soms wordt monitoring geimplementeerd vanuit het netwerk, maar wat als het netwerk plat is?)
- Monitoring vanaf meerdere punten (zie punt 1)
- "Eerlijke" statistieken (maar ja: wat zijn de spelregels dan?)

Ik zal ook meteen mijn grote angst uitspreken: de kans dat dit project "Commercieel" gaat. Ik denk dat dit een uitgelezen kans is om bij WHT te laten zien dat WH'ers in Nederland ook gezamelijk iets kunnen laten zien. Ik zou het erg zuur vinden als dit project vervolgens als een product wordt verkocht.

"Voor webhosters, door webhosters" zou ik het willen noemen.

Als ik een webhoster zou zijn (want ik ben er geen):

Als webhoster:

- Makkelijker te configureren dan Zabbix / Nagios (VOORAL nagios ;)) / whatever
- Elke minuut een check, escalatie binnen 5 minuten. In die 5 minuten, checks vanuit meerdere punten.
- Stats! Pics! (En eventueel ook voor klanten, welke je kan importeren in je eigen mooie webinterface?)
- (DuH!) Meerdere servers.
- Importfunctie
- Functie op per server meer dan 1 contactpersoon op te nemen (resellerschap vanuit de webhoster! Stel je voor dat je jou klant op wil laten nemen in de monitoring)

Als checker:

- De mogelijkheid om de te checken host op te nemen in een firewall. Hiervoor is een XML / Plaintext bestand nodig, welke ik in kan lezen, en direct uit kan laten voeren;
- ENIG vorm van credits.

my816797
10/07/06, 11:49
Zo'n script is relatief makkelijk te ontwikkelen, en precies hetzelfde project staat al op mijn to-do list voor ontwikkeling binnen nu en een paar weken.

Hoe ik het betalen van SMS'jes ga aanpakken:

- Eigenaar (van systeem, hoster) koopt xx aantal SMS'jes in bij een gateway.
- Users kopen xx aantal SMS'jes in bij 'Eigenaar'.
- Mailtje wordt sowieso verstuurd, SMS'je alleen als 'User' SMS-credits heeft.
- Waarschuwings SMS en Mail wordt verzonden als SMS-Credits laag niveau bereiken.

DiedX
10/07/06, 12:55
Mooi voor jou, maar wat draagt dit bij aan het script waar wij nu mee bezig zijn?

NDIS
16/07/06, 16:37
is dit project ook dood gegaan?

DiedX
16/07/06, 17:11
Het is inderdaad erg stil

Jurian
16/07/06, 21:32
Het project is (IMHO) dan ook zodanig complex dat het onwaarschijnlijk is dat dit zo even in elkaar gedraaid wordt :p

Daarnaast snap ik nog steeds niet echt wat nou de reden is om dit op deze onnodig complexe manier te willen doen. Installeer gewoon nagios of zabbix of $WHATEVER op je 2e/3e NS, die toch al binnen een ander netwerk hangt dan de rest van je servers. Laat die alles checken op je hoofdnetwerk, en laat een of twee machines op je hoofdnetwerk die machine checken. Weet je altijd wat er aan de hand is, tenzij tegelijk je hoofdnetwerk *EN* het externe netwerk waar je checkserver op draait, down zijn, een situatie die niet vaak zal voorkomen. Ben je hier toch bang voor, spreek dan met een collega hoster af dat je elkaars check-server opneemt in de controles. Dan heb je al 3 netwerken die elkaar checken, terwijl het allemaal nog heel simpel is.

Het systeem zoals het in deze thread wordt voorgesteld, is zodanig complex dat het zeker weten meer problemen zal opleveren, dan een simpel systeem. Het KISS princiepe ( http://en.wikipedia.org/wiki/KISS_principle ) gaat ook in dit geval op. Simpel is beter.

IT-worX
12/07/07, 19:25
Hoort er hier iemand nog iets van?