Nagios für die Zukunft

Ich persönlich gehöre zwar der "Check_MK-Fraktion" an, würde dir in Sachen zukünftiger (kostenloser) Support aber Icinga2 empfehlen. Da wirst du nämlich in diesem Forum mehr als gut beraten. Ebenso hast du mit Icinga2 einen aktuellen Monitoring Core, der aktiv in Fortschritt und Entwicklung ist.
Die kostenfreie Version von Check_MK wird zwar auch stets weiterentwickelt, setzt aber immer noch auf die alten Monitoring Cores von Nagios, Icinga(1) oder Naemon (auch nur ein Nagios Fork) auf.
Auf ein reines Nagios-System bei einem Neuaufbau rate ich zudem absolut ab und stehe mit der Meinung sicherlich nicht allein da.
Was die Verwaltung von Icinga2 angeht, hab ich zwar wenig Schimmer von, denke aber, dass es keine große Hürde für jemanden ist, der schonmal ein Nagios zu administrieren hatte.

Community Support kostet viel Zeit, die es aber lohnt zu investieren. So findest du hier einige, die in ihrer Arbeits- und Freizeit unermüdlich Antworten geben, Bugs bearbeiten oder fixen und Software releasen. Das ist nicht nur bei Icinga 2 so, sondern geht in alle Richtungen, gerade bei Addons und Plugins tut sich ja auch noch so einiges.

Was man beobachten kann - jedes Tool, das eine kommerzielle Version hat (Enterprise, Subscriptions, whatever) spaltet sich irgendwann ein bisschen ab. Bei Nagios gibts im deutschsprachigen Raum fast keine Aktivität mehr, das läuft mehrheitlich über deren moderiertes Forum. Eine Roadmap wie es mit Nagios4 weitergeht, kennt niemand - ausser dass es Teil der kommerziellen Variante ist und dafür weitergepflegt wird. Den Eindruck habe ich bei Naemon auch, welches nun Teil von op5 ist.

Ich verfolge die "anderen" aber ehrlich gesagt nicht mehr wirklich aktiv. Ich weiss dass es von checkmk einen Closed-Source-Core namens "CMC" gibt, der irgendwas toll kann, und auch sonst ist es ein gutes Produkt mit vielen mitgelieferten Plugins oder SNMP-Inventory. Es entwickelt sich aber an meinem Open-Source-Gedanken mit Subscriptions und Paywalls soweit vorbei, dass ich es aktiv ausklammere. Ähnlich wenig begeistert bin ich über Puppet Enterprise oder Elastic X-Pack. Viele Ideen sind in Icinga 2 eingeflossen, oder liegen als Feature Requests da und warten auf Abnehmer. Und in manchen Belangen unterscheiden sich auch die Ansprüche. "Überwach alles mit auto-discovery" vs "integriere deine CMDB/dein Foreman und überwach nur das was du kennst" sind markante Unterschiede. Ohne da jetzt ins Detail zu gehen, aber davon kann man sich in Test-Stellungen und Prototypen ein entsprechendes Bild machen.

Entwickeln tut sich jedes Projekt und Produkt in seine eigene Richtung. Das ist auch bei Icinga so. Die Interessen die wir in unserer tagtäglichen Arbeit haben, fliessen genauso in die Priorisierung von Issues mit ein, wie auch die Analyse von Community-Problemen. Dass hier schwerwiegende Bugs oder Sponsoring von Kunden mehr Gewicht hat, als ein Feature das gut klingt aber keiner Zeit für hat, braucht man wohl nicht zu erwähnen. Manche Sachen landen auch drinnen, weil man wieder mal Spass an Feature-Implementierung hat und nicht ewig dumme Bugs fixen mag. So funktioniert Open Source nunmal

In der Summe gesehen steckt in Icinga 2 wohl viel Entwicklungszeit die sich nie wieder rentieren werden. Aber auch Dinge, die das Leben erleichtern (siehe: eine Service-Apply-Regel anlegen, zukünftige Hosts "erben" diesen Service automatisch). Oder auch der Zwang, Pakete zu installieren anstatt Sourcen zu kompilieren. Weil man sich gerade bei gegenseitiger Hilfe darauf fokussieren möchte, wie die Konfiguration und das Setup aussieht, und nicht wie ein Compiler-Fehler bei OpenSSL am Erbrechen ist. Klarerweise gibt es auch Dinge, die hätten besser laufen können, im Sinne von - wie designe ich etwas, wie setzt es der User um. Cluster und Clients gehören da dazu, aber die Zeit hat auch gezeigt, dass man ohne Community-Support und Feedback niemals zu Veränderungen gekommen wäre. In erster Instanz betrifft das "nur" die Doku, mittelfristig aber auch Features.

Kurzum - Nagios ist für mich schon lange tot, dass sich Icinga1 und andere Forks mit ähnlicher Code-Basis auch relativ wenig von der Stelle bewegen, realisiere ich sukzessive in den letzten Monaten. Wir messen uns hier an ganz anderen Kalibern ausserhalb des Nagios-Ökosystems, die ebenso Zuspruch finden (Zabbix, OpenNMS, Prometheus, etc.) aber genauso ihre Tücken und Probleme in anderen Bereichen haben. Die perfekte Monitoring-Lösung gibt es nicht. Aber eine eigene zurecht-gebaute kann man mit Open-Source sehr schön sich selbst erschaffen. Gerade wenn es an das Thema "Integrations" geht. Wir investieren hier auch viel Zeit, etwa Graphite, InfluxDB, Elastic Stack, usw. in Verbindung mit Automatisierung ans Laufen zu bekommen. Und wenns dann noch eine gute Community hat, die sich gegenseitig aushilft, machts noch mehr Spass.

Vielleicht sieht man sich ja auf der OSMC im November, oder am Icinga Camp Berlin nächstes Jahr

Ich würds mir an deiner Stelle mal ansehen. Am besten mit den Vagrant-Boxen: https://www.icinga.org/2015/12/02/vagrant-box-playtime/

Geschmäcker sind bekanntlich verschieden und bevor ich dir das jetzt aufdränge, solltest du es selbst entscheiden. Hier am Icinga Camp verwendens schon alle, bis auf einen der morgen von Nagios auf Icinga 2 migriert

Grüße aus San Diego
Michael

Classic UI ist noch ein Überbleibsel aus der alten Zeit, was damals zum Testen für Icinga 2 herhalten musste. Entwicklungstechnisch wurde Icinga Web 2 einige Monate nach Icinga 2 gestartet und war von dem her erst später verfügbar. Heutzutage ist es das Flaggschiff worin auch vom Web-Team vollständig die Ressourcen reinfliessen.
Classic UI empfehle ich niemandem mehr, da gehen viele Sachen von Icinga 2 damit auch ned.

Hi,

auch wenn ich jetzt noch nicht so den Erfahrungshorizont wie manch' anderer hier habe - in Sachen Monitoring, als Linux SysAdmin bin ich schon ganz fit, gebe ich mal meinen Senf dazu, vor allem zu Check_MK, das System von dem ich Ahnung habe.

Ich verwende seit ca. 2 Jahren Check_MK/Nagios und muss sagen, dass ich selten so eine geniale OS Software wie Check_MK gesehen habe. Nach dem arbeiten mit BigSister und plain Nagios war das ein Traum. Bisher hat alles, was ich umsetzen wollte damit problemlos funktioniert. Angefangen von einem genialen Webinterface zur Nutzung und Administration, weiter zu der Status-API(Livestatus), guter Erweiterbarkeit und vielleicht noch zu der Konfigurations-API(WATO-Web-API, noch nicht mit gearbeitet).

Der von Michi angesprochene Punkt ist natürlich wirklich so eine Sache: Wie wird es weiter gehen? Wird das OSS-Check_MK sterben zugunsten der Bezahlvariante? Da wird man mit Sicherheit genau beobachten müssen. Die Features, die bis jetzt der Enterprise-Variante vorbehalten waren(Performancedaten-Design-Editor(nenn ich jetzt mal so: Individuelle Graphen gestalten), CMC-Microcore(Performanterer Core der eine wesentlich höhere Effizienz hat, d. h. viel mehr Hosts/Services mit der gleichen Leistung bewältigen kann), Agent-Bakery(Agentenverteilung), Reporting), habe ich bisher noch nicht gebraucht. Reporting wäre wohl eines, was ich in Zukunft gebrauchen kann. Das müsste ich mir dann über die APIs halt selber basteln.

Wenn ich Check_MK so von aussen beobachte, sind die eigentlich eher noch in einer Aussenseiterposition, was die Verbreitung betrifft, verzeichnen aber stark steigende weltweite Nachfrage. Ich würde mal sagen, dass das so eine Phase ist, in der sich entscheidet, welchen Weg man dort in Zukunft gehen wird.

Was ich gerade wesentlich finde ist, das es in der Alltagsarbeit wichtig ist, sowohl für den versierten Monitoring-Guru als auch für den wenig erfahrenen Linuxpraktikanten, die für das jeweilige Aufgabenfeld notwendigen Arbeiten einfach erledigen zu können. Und das finde ich echt gelungen.

Ich kann mir auch durchaus vorstellen mit dem aktuellen Softwarestand von der OSS Check_MK und der gut abgehangenen Nagios-Version noch 10-15 Jahre zu leben. 15 Jahre in der IT sind natürlich schon Welten

-----

Ich habe mich immer mal etwas umgeschaut, was andere Mütter so für Töchter haben, bin aber vom ersten knutschen da nicht wirklich überzeugt gewesen, das mich es mich umgehauen hätte.

Ich entschuldige mich schon mal vorab dafür, dass ich aufgrund meiner geringen Erfahrung mit den folgenden Monitoringsystemen vielleicht Eindrücke schildere, die vielleicht so nicht korrekt sind.

Von Zabbix hat mich spontan das Webgui und die Bedienung eher abgetörnt, auch dass ich für die Konfiguration viele Begriffe(Die Namen der Checks) lernen muss und das händisch eingeben muss hat mir nicht gefallen. Gemerkt habe ich mir, dass Zabbix aufgrund der Architektur wohl sehr performant sein muss und laut Aussagen Anderer, die damit arbeiten, wohl auch recht flexibel.

Bei Icinga(1/2) habe ich mehrmals durch die Dokumentationen und Webdemos geklickt und gelesen und ich habe ehrlich gesagt nicht verstanden, was dieses System vom Fork-Vater Nagios unterscheidet, was es viel besser macht und was die Stärken sind. Auch hier hat mich das Interface nicht vom Hocker gehauen. Vielleicht ist das ein geeigneter Zeitpunkt um mal wieder etwas auf der Icinga-Seite zu schmökern oder für einen Icinga-begeisterten einem diesbezüglichen Noob mit der eigenen Faszination vorzuschwärmen. (EDIT: Sieht so aus als ob sich da seit meinem letzten Besuch tatsächlich so einiges getan hat. Icinga Web 2 kannte ich offensichtlich noch gar nicht).

Was ich mir noch gar nicht angeschaut habe, ist Bloonix(ist recht Web-Zwo-Nullig, sprich ansprechend gestaltet) und Centreon.

Icinga2 for the win!

Am Anfang ist es echt ne Qual und ich hab Schweiß und Tränen vergossen, bis ich alles Begriffen hatte, was ich begreifen musste, damit es bei mir so läuft wie es soll. Und auch jetzt habe ich noch 10000 Fragen die immer wieder hochkommen. ABER bisher habe ich hier, was Icinga2 angeht, immer eine gute Antwort bekommen und bin mittlerweile auch soweit, dass ich versuche, mein Wissen hier zu teilen.

Und nach all den "Qualen", die ich am Anfang hatte, liebe ich Icinga2 umso mehr. Und es gibt so viel, was man ausprobieren, erweitern, testen kann. Ich könnte den lieben langen Tag nur Icinga2 und Icingaweb2 widmen.
Und das schönste ist, es ist schlank und performant. Die Entwicklung geht stetig vorran. Es ist jetzt schon gut und wird noch besser.

Wir benutzen derzeit Nagios. Ist nicht ganz meine entscheidung - würde ein wechsel zu Icinga schon bevorzugen.
Muss allerdings auch noch anmerken. Nagios tut in der Regel was es soll. (Ich denke da wird kaum ein unterschied zu Icinga und Nagios sein)
Allerdings ist die Aktivität im Nagios-Bereich recht gering (ohne jetzt das Board schmälern zu wollen.)
Ist aber auch nicht schlimm - die meisten Probleme wurden hier schon ein bis x mal behandelt

Auf den Support Gedanken bezogen ist der Gedanke wohl eher bei Icinga aufgrund der Aktivität.

Mal davon ab - wenn man mal so in den Icinga-Ecken lungert gibt es ja das ein oder andere neue interessante.

Ist zwar nicht viel neues - im Vergleich zu dem was zuvor geschrieben wurde und leider auch etwas spät. (Geister hier halt umher wenn ich eine Lösung suche)
Aber es ist die Sicht von jemanden der aktuell noch Nagios nutzt und noch nicht bereits gewechselt ist. (Vielleicht hilft das ja dem einen oder anderen)
[Im grossen und ganzen solltest dich aber für die Lösung entscheiden mit der am besten klarkommst - denke ich.]

Hi,

sorry für das ausgraben des alten Threads. Aber für mich ist das nach wie vor aktuell.

Ich schätze und benutze Check_MK sehr gerne und für kleine bis mittlere Instanzen finde ich das ganze absolute klasse(siehe oben).

Doch wenn es gross wird, dann wird es da schwieriger. In der Open Source Variante ist der Nagios-Kern drunter unter der ist nun mal um einiges langsamer als Icinga2 ( Das ist jetzt meine Vermutung von einigem an Recherche zum Thema. ) Man kann die Hardware noch bis zum Anschlag hochdrehen und muss auch bei den implementierten Checks auf die Performance achten(sollte man sowieso immer).

Mein Hauptmonitoringsystem umfasst derzeit ca. 200 Server mit ca. 8000 Checks. Unten drunter ist ein etwas älterer Core i7 als virtuelles(8 Vcores) System der auf Dauer-CPU-Last von 50% liegt mit einer Dauer-Load zwischen 7-11. Und 200 Server ist jetzt mal gar nicht mal so viel.

Man kann zwar auch noch auf die Enterprise Edition gehen. Doch da wird's dann halt teuer.

Was sagen die Icinga2- und Check_MK-Kenner dazu?

Mich würde an der Stelle interessieren, welche Server das sind, und ob du ungefähr einen Überblick geben kannst, welche Services und Plugins das sind. Nur damit man ungefähr ein Gefühl dafür bekommt, wo du letztendlich hinwillst, solltest du eine Migration in Betracht ziehen.

Dass ich dir Icinga 2 ans Herz lege, ist dir ohnehin klar. Ich würde mir aber auch sonst noch "vorher" Gedanken machen, ob du nicht schon deine Systeme mit Puppet, Ansible, etc ausrollst, ob man da nicht ansetzen kann (etwa: puppet-icinga2 oder ähnliches). Auch wäre es interessant, ob ein hochverfügbarer Master (also zwei im HA-Verbund) in deinem Setup eine sinnvolle Ergänzung sind. Oder auch Config-Deployments mit Imports aus CMDBs wie es etwa der Director bietet.

Nicht zuletzt ist sicher auch das Integrationsthema nach wie vor ein spannendes - hast du Graylog/Elastic am laufen, möchtest du deine Perfdaten/Metriken in eine moderne TSDB schreiben und Grafana-Dashboards generieren. Wie visualisierst du aktuell deine Hosts, hast du beispielsweise Maps mit NagVis im Einsatz, oder ein fancy Dashboard bei dir im Office wo die Problem-Counter aktualisiert werden.

Und dann vielleicht auch noch die Schnittstellen - bist du der einzige Admin, oder teilt sich das in ein Team auf, sodass etwa jeder Bereich selbst notifiziert wird. Gibt es spezielle Notifizierungschannels (Slack, Telegram, etc.) die hier auch bedient werden könnten.

Einige Dinge hiervon habe ich in der Agenda für die heurige OSMC gesehen (Marianne Spiller etwa, oder auch Markus Thiel). Vielleicht schaust du mal vorbei

Quote

Nur damit man ungefähr ein Gefühl dafür bekommt, wo du letztendlich hinwillst, solltest du eine Migration in Betracht ziehen.

Also migrieren möchte ich meine Umgebung erst einmal gar nicht. Hier gibt's noch ausreichend Luft durch mehr Hardwarepower. Mir geht's eher um ein Kundenprojekt, das derzeit mit plain Nagios aufgesetzt ist und ca. 25000 Geräte umfasst und im Laufe der nächsten Jahre angegangen werden soll. Es braucht ca. 1 Stunde für einen Restart und wird mit diversen Scripten krude irgendwie generiert. Die Performance kann mit Check_MK auch nicht besser werden, ist ja schliesslich auch nur Nagios als Kern drunter.

Quote

Mich würde an der Stelle interessieren, welche Server das sind, und ob du ungefähr einen Überblick geben kannst, welche Services und Plugins das sind.

Mein eigenes Check_MK ist eher hystischerisch gewachsen - aber bei weitem nicht so schlimm, wie die Phrase meinen könnte. Am Anfang hatte ich da noch nicht so den ganz den Blick auf die Performance als später, deswegen sind da auch perl, python, lua und bash checks mit drin, und wahrscheinlich alle nicht so hochoptimiert, wie Sie sein könnten. Auch werden eine steigende Anzahl an - hauptsächlich clientbasierten - Einzelchecks durchgeführt. Refaktoring lässt grüssen. Ansonsten bin mit ich damit, was die Flexibilität, den Nutzungskomfort, das effiziente Interface und die Stabilität betrifft hochzufrieden. Was das andere Projekt betrifft, da bin ich selbst auch noch nicht umfassend informiert.

Quote

Dass ich dir Icinga 2 ans Herz lege, ist dir ohnehin klar.

monitoring-portal: hosted by netways

---

Bei der Grössenordnung darf man sich vorher einiges an Gedanken machen. CMDB ist wohl vorhanden/im Aufbau. Deployment ist im Einsatz(Chef). Und gerade mit moderner Log-Verarbeitung(Graylog/ELK/....) sehe ich einen grossen Gewinn. Es gibt auch eine ganze Reihe von Personen, die das Monitoring nutzen werden: Zentrale Admins, Anwendungsbetreuer der verschiedenen Kunden.

fx998 wrote:

Es braucht ca. 1 Stunde für einen Restart und wird mit diversen Scripten krude irgendwie generiert. Die Performance kann mit Check_MK auch nicht besser werden, ist ja schliesslich auch nur Nagios als Kern drunter.

Die Konfigurationssyntax der Objekte hat sich bei Naemon im Gegensatz zu Nagios 3 nicht verändert. Es dürfte daher relativ einfach sein, ein Testsystem aufzusetzen, mit dem du ein Gefühl für mögliche Verbesserungen bekommst (z.B. Startzeit, Load, ...).

Für welches aktuelle Monitoring-Tool du dich schlußendlich entscheidest, bleibt dir überlassen ;-).

fx998 wrote:

Also migrieren möchte ich meine Umgebung erst einmal gar nicht. Hier gibt's noch ausreichend Luft durch mehr Hardwarepower. Mir geht's eher um ein Kundenprojekt, das derzeit mit plain Nagios aufgesetzt ist und ca. 25000 Geräte umfasst und im Laufe der nächsten Jahre angegangen werden soll. Es braucht ca. 1 Stunde für einen Restart und wird mit diversen Scripten krude irgendwie generiert. Die Performance kann mit Check_MK auch nicht besser werden, ist ja schliesslich auch nur Nagios als Kern drunter.

Mein eigenes Check_MK ist eher hystischerisch gewachsen - aber bei weitem nicht so schlimm, wie die Phrase meinen könnte. Am Anfang hatte ich da noch nicht so den ganz den Blick auf die Performance als später, deswegen sind da auch perl, python, lua und bash checks mit drin, und wahrscheinlich alle nicht so hochoptimiert, wie Sie sein könnten. Auch werden eine steigende Anzahl an - hauptsächlich clientbasierten - Einzelchecks durchgeführt. Refaktoring lässt grüssen. Ansonsten bin mit ich damit, was die Flexibilität, den Nutzungskomfort, das effiziente Interface und die Stabilität betrifft hochzufrieden. Was das andere Projekt betrifft, da bin ich selbst auch noch nicht umfassend informiert.

25k ist schon eine ordentliche Hausnummer. Ich geb dir hier den Tipp, das vorab zu evaluieren mit den Tools die du ins Auge gefasst hast. Das wird der Kunde vermutlich nicht bezahlen wollen, aber mMn ist das gut und notwendig, um sich über Skalierung und auch Erweiterung nachhaltig Gedanken machen zu können. Man baut Systeme ja auch ned für den Ist-Stand, sondern möchte etwa wachsen, oder die Umgebung entsprechend erweitern. Mal kommen auch neue Rechenzentren und Standorte dazu, usw.

Hinsichtlich der Checks die du ausführst, bleibt noch offen, ob das eher Linux/Unix-Kisten sind oder Windows. Was sicherlich auch noch dazu beträgt - ein lokaler Client der Check-Anfragen beantwortet, oder etwa was per remote eine Service API befrägt.

Sinnvoll ist in dieser Grössenordnung sicherlich ein Setup, wo die Master selbst nix checken, und man das auf 2 Satelliten, oder auch mehrere Zonen aufteilt. Der Master ist dann nur für die Konfiguration, Deployment und Web Interface da, während die Checker-Satelliten die eigentliche Last übernehmen.

Da du Chef erwähnt hast, sollte man auch das nicht ausser Acht lassen. Zum einen kannst du damit elegant Plugins ausrollen, zum anderen etwa $agent (icinga2, etc.) und dessen Konfiguration. Quasi am Ende ein vollautomatisiertes Monitoring-Setup. Im besten landet ein neu provisionierter Server dank Chef auch gleich im Monitoring, nicht als Extra-Task "nachher".

fx998 wrote:

monitoring-portal: hosted by netways

Irgendjemand muss das Betreiben dieser Plattform auch bezahlen. Da bin ich sehr dankbar, dass ich keine eigene Kiste am Laufen haben muss, und mein Arbeitgeber dafür aufkommt. Bedingung für diesen noblen Gefallen ist das erwähnte Logo unten auf der Seite. Die Domains liegen allerdings alle bei mir, und kosten mich im Jahr auch XY Euronen. Gleiches gilt für sensitive Daten wie User-Information, das ist mein Versprechen an die vormaligen Admins.

Langer Rede, kurzer Sinn - ich schreibe hier privat, und darf als Teil meiner Arbeitszeit auch Community-Support machen. Manch einer legt mir das gerne falsch aus, und glaubt ich sei immer als Mitarbeiter einer Firma unterwegs. Dem ist allerdings nicht so. Wenn ich dir was verkaufen wollen würde, dann mach ich das nicht hier. Das gehört - finde ich - zum guten Ton. Wenn man jemanden mal ein Buch, Training, Consulting empfiehlt, dann bloss weil es mit den eigenen Mitteln (Freizeit, Knowhow) oder mangels Verständnis nicht mehr ausreicht. Im Grunde genommen soll jeder der eine Antwort sucht, auch eine zufriedenstellende bekommen

fx998 wrote:

Bei der Grössenordnung darf man sich vorher einiges an Gedanken machen. CMDB ist wohl vorhanden/im Aufbau. Deployment ist im Einsatz(Chef). Und gerade mit moderner Log-Verarbeitung(Graylog/ELK/....) sehe ich einen grossen Gewinn. Es gibt auch eine ganze Reihe von Personen, die das Monitoring nutzen werden: Zentrale Admins, Anwendungsbetreuer der verschiedenen Kunden.

Ich glaube, in der Grössenordnung macht ein Konzept bzw auch mal eine Test-Installation Sinn. Ich weiss aber nicht, ob du hier im Forum dazu dann alle Fragen beantwortet bekommst. Einen Versuch ists sicher Wert, aber grade grössere Setups brauchen auch gute Meinungen. Deswegen auch der Wink mit dem Zaunpfahl Richtung Community-Events. Icinga Camp kann ich adhoc keines mehr dieses Jahr "anbieten", Berlin nächstes Jahr wird aber wieder stattfinden. Im November gibts eben die OSMC, die du mit Sicherheit auch kennst.

Zwischenzeitlich kannst du dir auch mal die Icinga Vagrant Boxen anschaun. Insbesondere die Integrationen mit Elastic Stack und Grafana. Sei gewarnt, an der Graylog-Box basteln wir noch rum für das 2.3 Release, gibts einen PR.

https://github.com/icinga/icinga-vagrant

In den Boxen findest du auch den Icinga Director und alle möglichen Module vorinstalliert. Bei anderen Cores und Projekten kann ichs nicht sagen, aber soweit ich beobachte, ist fast jeder auf den Paket-Zug mit aufgesprungen, was die initiale Installation deutlich verkürzt. Damit kann man sich aufs wesentliche fokussieren.

dnsmichi wrote:

zu "hosted by netways :)"

Das ist für mich absolut problemlos und heisst für mich "Ich habe deine Signatur gelesen, dass Du dort arbeitest als icinga-Entwickler, bei der Firma die Icinga entwickelt und wundere mich deswegen nicht, dass Du von icinga begeistert bist."

Ah ok, dann habe ich dich wohl missverstanden, sorry

Ich hoffe, meine Aussagen helfen dir auch ein bisschen weiter, wenngleich ich die MK-Seite nicht wirklich mehr beurteilen kann. Was mir von Icinga unabhängig wichtig ist, ist die Vision, alles zu integrieren, was man heutzutage so im Stack hat. Vieles davon bietet Schnittstellen an, die sich kombinieren lassen, und mittel- bis langfristig eine Erleichterung oder Ersparnis bedeuten können. Da ist der deutsche Markt noch nicht so "hip" wie etwa der amerikanische wo sie mit Containern um sich werfen, aber grad so Sache wie Logs, Metrics und Lifecycle Management kommen immer mehr. Der Markt wandelt sich da auch sehr stark, und es ist schwierig den Überblick zu behalten.

Ich versuche letzteres, weswegen du mich viel mit Integrationen spielen siehst. Ich hab mir mit diversen Trainings, Kollegen und Selbststudium Graylog, Elastic Stack, Graphite, InfluxDB und Puppet beigebracht. Von Dashing und Icinga Web 2 Modulen spreche ich noch gar nicht

Habe auch den Mikesch für einen OSMC Talk gewinnen können, weil mir das Thema am Herzen liegt

Ich kann die aus meiner Erfahrung mit vielen Grossen, richtig Grossen (>6k hosts, >200k Services) , kleinen oder mittleren Projekten sagen: Nimm Icinga2 und du hast bei Wachstum keine Schmerzen