doch doch, hat er. hat nur eben grade gemerkt das .com unterschiedlich zu .de ist ;-)
bez. monitoring
nagios/icinga ist eine art baukasten, dh du kannst jedwede plugins fuer checks verwenden (bereits vorhandene oder eigene), sofern diese die spezifikationen der plugin api erfuellen - naeheres dazu hier
http://docs.icinga.org/latest/de/pluginapi.htmldh man benoetigt eigentlich nur den core, der anhand bestimmter metriken die checks dann ausfuehrt und die resultate entsprechend verarbeitet (eventhandler, notifications, etc). weiters ist es moeglich, mit bordmitteln oder modulen (mod_gearman, dnx) auch distributed monitoring methodiken zu implementieren.
neben dem core gibt es die klassische ui, die auch bei Nagios mitgeliefert wird. Ist deswegen als "klassisch" zu bezeichnen, weils ein html frameset mit cgis ist.
bei icinga gibts seither stetig neuerungen dazu, weil wir ganz einfach unzufrieden waren mit bspweise "ich kann nur einen servicecheck reschedulen, und nicht mehrere".
grundsaetzlich ist die klassische ui in unserem entwicklungszweig als durchaus brauchbarer und wird nach community wuenschen auch so gestaltet, damit man von einem standard nagios setup relativ unkompliziert auf icinga wechseln kann.
eine demo gibts hier: (aktuelle 1.0.3)
http://classic.demo.icinga.org/icinga/es gibt im icinga tree auch eine vollstaendige neuentwicklung eines neuen webs, auf agavi und extjs basierend. dieses setzt auf der neu geschriebenen icinga php api auf, die einen abstrahierten layer fuer daten (idoutils mysql, postgresql, oracle) und commands (core external commands) bietet.
damit ist es mitunter moeglich, alles ein wenig einfacher zu betrachten und die oberflaeche auch anschaulicher zu gestalten. vor allem, wenn man mehrere monitoring instanzen betreibt, die alle ihre daten in eine gemeinsame datenbank schreiben - web+api koennen auch mit multiplen instanzen umgehen und diese gemeinsam im icinga-web anzeigen.
eine demo zum neuen icinga-web gibts hier (pre 1.2 development version)
http://web.demo.icinga.org/icinga-web/damit das ganze mit den angesprochenen rdbms als backend funktioniert, wurden die NDOUtils ebenfalls geforkt, und groesstenteils umgeschrieben, um nicht nur MySQL zu supporten, sondern auch Postgresql und Oracle. Letzteres vermag nicht viele zu begeistern, ist aber fuer ein enterprise monitoring system unerlaesslich - meine primaere aufgabe wie ich zu Icinga gestossen bin im Mai 2009. performance technisch laeufts in tests etwa 35% schneller als ndoutils und blockt den core nicht durch housekeeping.
Icinga an sich ist mittlerweile ein sehr grosses team geworden; es gibt fuer jedes subprojekt (core+cgi+idoutils, api, web, docs, testing, packaging) mehrere leute und auch eine release roadmap. naeheres dazu wirds auch auf der osmc in nuernberg naechste woche geben - wo auch 1.2 stable released wird.
http://www.icinga.org/team/http://www.netways.de/en/osmc/y2010/packages fuer debian speziell - experimentiell beinhaltet die aktuelle 1.0.3
http://packages.debian.org/experimental/icingawebsite / info blog
http://www.icinga.orgfeature requests, bug reports
http://feedback.icinga.orghttps://dev.icinga.orgdocs
http://docs.icinga.orgplugins
http://www.monitoringexchange.orgcommunity (mailinglists, forum, irc, facebook, twitter)
http://www.icinga.org/community/===
noch kurz zu den gestellten fragen:
die groesste uns derzeit bekannte icinga installation hat 11000 services, und das skaliert auch auf entsprechender hardware.
bez. trends - es gibt die moeglichkeit, performance daten (perfdata) mit pnp4nagios in rrds zu wandeln und das als bspweise als cacti alternative zu verwenden. laeuft wunderbar in unseren setups.
alternativ bauen wird gerade ein reporting modul basierend auf jasper, das die idoutils datenbank als backend verwendet (und damit wiederum mysql oder postgresql oder oracle als rdbms einsetzen kann). das soll auch direkt als "cronk" im neuen icinga-web verfuegbar werden.
sofern noch andere fragen auftreten, gerne hier oder kurzfristig in #icinga respektive /query dnsmichi
lg
Michi
