* !!! 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.