added notes and todo

NOTES.hanez

@@ -0,0 +1,79 @@
+* !!! 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.
+
+* 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.

TODO

@@ -0,0 +1,11 @@
+
+# TODO
+
+ * Dokumentation des Konzeptes
+ * Workflow Diagramme
+ * Dokumentation der Code Struktur - Klassenhierarchie
+ * Code Fertigstellen
+   * Task Scheduling
+   * Implement clean Logging to files or stdout. Verbose mode too!
+   
+Weiteres siehe NOTES.hanez