82 lines
4.2 KiB
Text
82 lines
4.2 KiB
Text
* !!! der daemon braucht ne art parameter wie "-f" um im vordergrund zu bleiben
|
|
und nicht zu einem daemon zu werden. ausgabe dann an die console. ist wichtig zum
|
|
debuggin in ner IDE. oder ein "-d" um zu daemonisieren und sonst std out foo.
|
|
|
|
* Die services sollten nativ in form von python code entwickelt werden. Wir haben
|
|
sonst viel zu viele prozesse auf dem linspector host wenn der alle Abfragen mittels
|
|
exec() macht! SSH lib fuer python ist verfuegbar! : https://github.com/paramiko/paramiko
|
|
|
|
* Alerts dürfen natürlich nicht nur aufgrund Ihres Schwellwerts ausgelöst werden
|
|
sondern erst weil Nfach der Schwellwert überschritten worden ist. Sonst kann
|
|
der Admin nicht schlafen... ;)
|
|
|
|
* HRARARRARRA: vielleicht eine /usr/bin/linspector die auf jedem host liegt
|
|
und vordefinierferte formate ausgibt als addon. so als möglichkeit sich das
|
|
parsen auf dem daemon host zu erleichtern. Dennoch aber alles über SSH und kein
|
|
selbstausgedachtes protokoll zeugs... ;) mal drüber nachdenken aber später...
|
|
[update]: hehe, sowas könntem man aus nem fork bzw. patch für busybox machen
|
|
und dann gleich json formatiert auswerfen... :DDD
|
|
|
|
* Task scheduling may should be done with Celery in the future but for now it is
|
|
too complex. (http://www.celeryproject.org/)
|
|
|
|
* Es muss die möglichkeit geben, dass wenn ein alert immer wieder und wieder
|
|
aufgerufen wird und sich nix bessert, dass dann ein sozusagen parent member
|
|
informiert wird! (als parent für die member schon in der config!!!) --
|
|
vielleicht sogar multiple parents.
|
|
|
|
* SNMP abfragen müssen natürlich über die services auch möglich sein!
|
|
GELÖST: snmpget kommndo verwenden! Ist wahrscheinlich sogar einfacher als
|
|
eigene services
|
|
|
|
* Alle Sektionen in der config müssen einen comment parameter haben!!!!
|
|
X! In config drin aber code nicht geprüft!!!!
|
|
|
|
* conf.d foo hinzufügen und alle files zusammenparsen - mehr übersicht.
|
|
|
|
* Als default die config nach /etc/linspector/linspector.json und
|
|
/etc/linspector/conf.d. Allerdings nur fürs release! So wie es ist, ist es
|
|
nämlich ultra flexibel - aber eben nicht standard install FHS.
|
|
|
|
* Können wir den Fehler vom parsen der json config abfangen und selber
|
|
auswerten? dann nämlich nen eigenes handling einbauen!
|
|
|
|
* Pipelining von services wäre natürlich cool um nur einen SSH client zu starten
|
|
um mehrere service abfragen gleichzeitig auszuführen.
|
|
|
|
* Nagios plugin support für remote plugins wie check_smtp aber nicht local
|
|
plugins wie check_load!
|
|
|
|
* Event Handlers wie in Nagios sind eine gute idee. Z.B. um einen crtitical
|
|
service neu zu starten, zu stoppen etc.
|
|
|
|
* Für jeden zu überwachenden service auf den einzelnden hosts muss die period
|
|
festgelegt werden können. Eine allgemeine period pro hostgroup macht keinen
|
|
sinn wenn sensible vital informationen öfter abgefragt werden müssen, aber
|
|
deshalb nicht gleich alle services auf einmal.
|
|
|
|
* @+message in den filters wird ein JSON objekt. Damit können wir dann auch so
|
|
sachen wie den mongowriter als filter laufen lassen. Dieser benötigt
|
|
wesentlich mehr informationen als nur einen String.
|
|
|
|
* Es müssen in der Umgebung zu jedem Job nach Ausführung imemr ein paar
|
|
informationen für die nächste Ausführung bereit gestellt werden. Die Daten,
|
|
die an den mongowriter übergeben werden, müssen die Anzahl der Versuche, die
|
|
letzte Ausführung etc. enthalten. Daher auch der vorherige Punkt.
|
|
|
|
* Jedes Objekt in der config muss eine "disabled" feld haben. Dieser Wert hat
|
|
eine höhere priorität als das was "von oben" definiert worden ist. Wenn z.B.
|
|
der service discusage disabled ist, wird dieser nirgendwo verwendet. Das ist
|
|
ein extremes Beispiel. Im grunde kann man ja in der höheren config ebene
|
|
etwas rauskonfiguerieren was den selben zweck erfüllt. Umgekehrt empfinde ich
|
|
auch als sehr praktisch.
|
|
|
|
* threshold muss in die einzelnden services. raus aus der hostgroup.
|
|
|
|
* We need an escalation threshold! After this amount of fails the problem will
|
|
be escaleted.
|
|
|
|
* Jeder service braucht einen parser um die daten auszuwerten. das heisst, dass
|
|
wenn ein service angelegt wird auch ein parser für diesen verfügbar sein muss.
|
|
generische parser sind bestimmt in vielen fällen möglich aber der alltag wird
|
|
anders aussehen.
|