Onderwerp: Cross site checks (NOC vanaf andere locaties)

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

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

Ik stel me wel beschikbaar om het project te leiden... Dan ga ik er wel vanuit dat ik meer steun krijg dan kritiek..

Een beetje zoals dit dus -> http://host-tracker.com/partnership/ ?

een beetje wel ja

Oorspronkelijk geplaatst door Domenico

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

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!

Mocht je nog een scripter nodig hebben, ben ik graag bereid om het e.e.a. mee te helpen. Wel gaarne in php dan .

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.

Oorspronkelijk geplaatst door groenleer

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

Oorspronkelijk geplaatst door XBL

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.

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!

Oorspronkelijk geplaatst door XBL

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!

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_...soft&words=noc
(misschien ook eens synoniemen of verwante woorden van noc proberen)

@_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