kne hat geschrieben:Allein die Mandantenfähigkeit in Icinga ist quasi das Todesurteil für jede noch so komplexe Nagios-Lösung. Aber wem Nagios schon ein Graus ist, für den ist Icinga ein Buch mit sieben Siegeln. Mich inbegriffen, ich "darf" es zum Glück nur bedienen.
Hattest du Support von Netways bei der Migration? Benutzt ihr LConf im backend?
Kommt ja immer drauf an, was man genau erreichen will. In unserem Fall fließen alle Daten in eine Icinga-Instanz und über ein Rechtemodell zeige ich den einzelnen Betriebsteams nur was sie sehen wollen. Die Datenbanker halt nur DB-Services und DB-Filesysteme; den Webserver-Kollegen komplette Server und den Solaris-Leuten alle Services unterhalb der Applications. Mag bei uns etwas speziell sein, weil jedes Team wieder andere Anforderungen äußern darf... Und genau deswegen haben wir das auch nicht mit LConf & Co. gelöst, sondern eben ein eigenes Web-Portal zur Konfiguration mit eigenem Rechtemodell gebaut. Einige Teams verwalten ihre Alarme und ihre Schwellwerte dort eigenverantwortlich, wieder andere äußern ihre abstrakte Vorstellung und wir tun dann. Jeder wie er mag und kann – hat sich aber unter'm Strich bewährt. Naja, zumindest teilweise. Das Datenbank-Backend (ido2db) ist eine mittelschwere Katastrophe und einer der Gründe, weshalb wir gerade an einem PoC für den Wechsel zu CheckMK (und Config dort mit WATO) arbeiten.
Die Migration damals war ohne Netways oder sonstige Externe. Nur ein paar Hilfestellungen via Forum, ein paar Entwicklunsgwünsche die wir eingekippt haben und regelmäßige Teilnahme bei der OSMC waren unsere "Ressource". War aber deutlich ruhiger damals – aktuell mache ich da nur noch Lebenderhaltung und um den CheckMK-Part kümmern sich die Kollegen. Ich verschwinde inzwischen überwiegend in der Windows-Server-Welt... Jaja. Hat aber auch seinen Reiz
