Seite wählen

NETWAYS Blog

Die Migration von IDO zu Icinga DB – so geht’s kinderleicht!

Letzte Woche hatten wir ein sehr erfolgreiches NETWAYS Webinar, in dem ich demonstriert habe, wie einfach die Installation der Icinga DB auf einem bestehenden System ist. In diesem Blogpost möchte ich auf einige Aspekte und Anleitungsschritte aus dem Webinar eingehen. Ich werde Dir zunächst die Vorteile der Icinga DB und ein paar Unterschiede zwischen IDO und Icinga DB erklären, bevor wir dann in Kürze die notwendigen Schritte auf dem Weg zu Deiner laufenden Icinga DB durchgehen.

Was ist die Icinga DB eigentlich?

Was ist die Icinga DB?“ Auf dieses Thema bin ich letztes Jahr im gleichnamigen Webinar eingegangen. Bei der Icinga DB handelt es sich um ein vollständig neues Backend für Icinga, um Informationen zu speichern und in Icinga Web verfügbar zu machen. IDO und Icinga DB unterscheiden sich maßgeblich in ihrer Architektur. Diesen Unterschied merkt man vor allem in sehr großen oder sehr Check-Intensiven Umgebungen.

Was ist der Unterschied zwischen IDO und Icinga DB?

Alles in die Datenbank

In der bisherigen IDO werden alle Statusinformationen direkt in der MySQL/MariaDB oder PostgreSQL Datenbank gespeichert. Das bedeutet, dass jeder einzelne Check, der von Icinga ausgeführt wird, als Ergebnis in die Datenbank geschrieben wird. Dabei reden wir aber noch nicht von historischen Daten oder Statusänderungen von einem Host/Service. Jeder einzelne Output, der von einem Plugin generiert wird, egal ob es eine Statusänderung gibt oder nicht, wird in die Datenbank geschrieben. Schließlich möchte man im Webinterface den aktuellen Plugin Output sehen.

Werden Checks nun in einem sehr häufigen Intervall ausgeführt oder es handelt sich um eine sehr große Umgebung, steigt die Last auf der Datenbank exponentiell. Das sorgt für Mehrkosten bei der Datenbank, aber auch für mehr Aufwand zum Fine-Tuning.

Aufteilung von volatilen und persistenten Daten

Hier kommt der Vorteil der neuen Icinga DB zum Einsatz. Anders als bei der IDO, werden die Informationen nach Ihrer „Lebensdauer“ sinnvoll verteilt. Bei volatilen Daten sprechen wir beispielsweise von den oben bereits erwähnten Check-Ergebnissen, die keine Auswirkungen auf Statusinformationen haben, sondern rein für den Output relevant sind. Mit der Icinga DB werden diese Daten in einen Redis geschrieben. Dieses Tool erlaubt das Ablegen von Informationen über eine entsprechende API direkt im Memory des Servers, ohne dass eine Schreibaktion auf die Festplatte oder in einer Datenbank notwendig sind. Über die vorhandene API werden die Informationen dann später wieder ausgelesen, aktualisiert oder gelöscht.

In der MySQL/MariaDB/PostgreSQL Datenbank, landen dann nur historische Daten, Statusinformationen oder andere wichtige persistente Daten. Damit reduziert sich die Schreib- und Lese-Last auf der Datenbank enorm. Icinga Web liest die notwendigen Inhalte der jeweiligen Objekte dann sowohl aus dem Redis, als auch aus der Datenbank und stellt diese im neuen Icinga DB Webfrontend dar.

Installation der Icinga DB

Die Installation der notwendigen Komponenten für die Icinga DB ist spielend einfach. Sehr praktisch ist, dass ein Parallelbetrieb zwischen IDO und Icinga DB möglich ist. Somit kannst Du die Icinga DB testen und beide Backends parallel verwenden.

Ja nach Linux Distribution sind die Befehle für die Installation ein wenig anders. Die notwendigen Pakete sind jedoch überall gleich. Du benötigst die Folgenden:

  • icingadb
  • icingadb-redis
  • icingadb-web

Im Webinar sind wir ab 7:58 dabei, die Pakete zu installieren und die Konfigurationen einzustellen. Wichtig ist dabei zu beachten, dass die Icinga DB eine eigene Konfigurationsdatei unter

/etc/icingadb/config.yml

besitzt, die im Vorfeld editiert werden muss. Bei einem klassischen Setup von lokalen Redis und externer Datenbank, sind nur die IP und die Authentifizierungs-Daten für die Datenbank wichtig.

Icinga DB Web

Sind alle Schritte wie in den Anleitungen und im Webinar aufgezeigt durchgeführt worden, hast Du einen sauberen Parallelbetrieb zwischen IDO und Icinga DB verfügbar. Die Unterschiede der Web UI sind bemerkenswert!

In den YouTube Kommentaren kam die Frage auf, wieso wir auf das Paket icingadb-web nicht weiter eingegangen sind, obwohl es installiert wurde. Das liegt daran, dass in der Modulansicht in Icinga Web das Paket als icingadb und nicht als icingadb-web angezeigt wird. Alle Schritte und Konfigurationen innerhalb von Icinga Web, die sich auf das icingadb Modul beziehen, beziehen sich also auf das installierte Paket icingadb-web.

Migration von IDO zu Icinga DB

Zu guter Letzt fehlt nur noch die Migration von IDO auf Icinga DB, um alle historischen Informationen, Ereignisse, etc. im neuen Datenbackend verfügbar zu haben. Damit steht Deinem Parallelbetrieb mit allen Informationen nichts mehr im Wege, Du kannst Dich an das neue Interface gewöhnen, bevor Du die IDO und das alte Monitoring Modul abschaltest. Im Webinar sind wir auf diesen Punkt zwar eingegangen, durch eine Fehlkonfiguration lief es jedoch nicht wie gewünscht durch.

Wer eine vollständige Datenübernahme wünscht, kann dies wie folgt tun. Bitte beachte, dass je nachdem wie große eure Datenbank ist, der Task mehrere Stunden oder Tage in Anspruch nehmen kann. In diesem Fall empfehle ich Dir, das Migrationsskript mehrmals auszuführen und die Zeiträume unterschiedlich zu splitten. Das Skript erkennt, ob Daten bereits übernommen wurden und führt keine doppelten Aktionen aus, auch wenn sich Zeiträume von einem Durchlauf zum nächsten überschreiten.

Als erstes brauchst Du Deine Environment Id für die Icinga DB. Diese erhältst Du wie folgt:

# cat /var/lib/icinga2/icingadb.env

Anschließend generierest Du eine .yml Datei mit folgendem Inhalt – damit werden alle Daten aus der IDO in die Icinga DB migriert:

icinga2:
  # Content of /var/lib/icinga2/icingadb.env
  env: ....

# IDO database
ido:
  type: mysql # or "pgsql" for PostgreSQL
  host: 127.0.0.1
  #port: 3306
  database: ido_db
  user: dbuser
  password: dbpass
  # Input time range
  #from: 0
  #to: 2147483647

# Icinga DB database
icingadb:
  type: mysql # or "pgsql" for PostgreSQL
  host: 127.0.0.1
  #port: 3306
  database: icingadb
  user: icingadb_user
  password: icingadb_pass

 

Ist alles konfiguriert, kannst Du das Skript starten, welches direkt mit dem icingadb Paket installiert wird.

# icingadb-migrate -c icingadbmigrate.yml -t ~/icingadb-migration.cache

In diesem Fall befindest Du Dich direkt in dem Ordner, in welchem Du die .yml Datei abgelegt hast – bei mir heißt diese icingadbmigrate.yml. Das Skript schreibt nun zunächst alle Informationen aus der IDO in die icingadb-migration.cache Datei. Ist dies erledigt, werden die Daten aus dem Cache in die Icinga DB geschrieben. Bricht aus irgendeinem Grund der Vorgang ab oder das System muss neu gestartet werden, ist dies kein Problem. Solange die Konfiguration und die Cache-Datei unverändert bleiben, macht das Skript an der Stelle weiter, wo es aufgehört hat, nachdem Du es erneut aufrufst.

Professionelle Unterstützung

Wer diesen Vorgang nicht allein durchführen möchte, in Probleme läuft oder eine Beratung zur Architektur und dem genauen Vorgehen zur Umstellung wünscht, kann natürlich über uns direkt professionelle Unterstützung in Form von Consulting für euer zeitlich begrenztes Projekt oder Outsourcing für langfristige Unterstützung erhalten.

Beim Outsourcing bieten wir drei unterschiedliche Modelle für Dienstleistungen an und können schnell sowie zielgerichtet auf Themen eingehen. Die Zeitbuchung erfolgt immer im 15 Minuten Intervall und wird von einem vorhandenen Kontingent abgebucht oder über einen Vertrag monatlich abgerechnet. Das ist vor allem hilfreich, wenn kontinuierliche Unterstützung bei kleinen Themen gewünscht ist oder der tägliche Betrieb abgegeben werden soll.

Im Consulting können wir darüber hinaus zielgerichtet auf alle Details zur Architekturplanung, Umstellung oder dem Aufbau/Ausbau eingehen und bei der Konzeptionierung sowie der eigentlichen Umsetzung unterstützen. In Kombination mit dem Outsourcing, bietet das ein starkes und flexibles Paket.

Wer mehr dazu wissen möchte, kann sich über unser Kontaktformular mit uns in Verbindung setzen. Wir stehen beratend zur Seite und stimmen gemeinsam die beste Vorgehensweise ab!

Ich freue mich auf eure Anfragen!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

FAQs zur Icinga DB

Nachfolgend möchte ich auf einige Fragen zur Icinga DB eingehen, die uns derzeit bei unseren Kunden begegnen:

Was ist die Icinga DB?

Icinga DB ist eigentlich ein Sammelbegriff für verschiedene Komponenten der Monitoringlösung Icinga. Vorwiegend bezieht sich Icinga DB aber auf das Datenbankbackend als Nachfolger der IDO. Damit einher geht auch auch ein neues Modul für Icinga Web das mit diesem neuen Backend sprechen kann.

Was haben Icinga DB und IDO gemeinsam?

Beide Komponenten stellen einen persistenten Speicher für Icinga zur Verfügung, dieser basiert auf einer relationalen Datenbank. Es wird sowohl MySQL bzw. MariaDB als auch PostgreSQL unterstützt.

Was ist der Unterschied zwischen Icinga DB und IDO?

Während das Datenbankschema der IDO historisch gewachsen ist wurde das Datenbankschema der Icinga DB von Grund auf neu designed. Zusätzlich zum persistenten Speicher bringt die Icinga DB mit Redis auch einen In-Memory-Datenspeicher mit. Damit wird effizienter und insgesamt weniger in den persistenten Speicher geschrieben, was sich positiv auf die Gesamtperformance des Systems auswirkt.

Wie konfiguriere ich den Icinga Core für Icinga DB als Backend?

Aktuelle Icinga-Versionen bringen die Unterstützung für Icinga DB bereits mit. Die Komponenten der Icinga DB stehen als zusätzliche Pakete zur Verfügung. Sobald diese installiert sind, die persistente Datenbank erstellt ist und die beiden Dienste der Icinga DB für Redis und Datenbank ordnungsgemäß laufen, verbindet man den Icinga Core über ein integriertes Feature mit dem Redis Service der Icinga DB.

Wie konfiguriere ich das Webfrontend für Icinga DB?

Mit einem zusätzlichen Modul für Icinga Web ist dieses in der Lage die Daten der Icinga DB aus Redis und persistenten Speicher anzuzeigen, beide Teile werden konfiguriert und angesprochen. Auch der sog. Command Transport muss für Icinga DB entsprechend konfiguriert werden um z.B. Aktionen wie die Neuausführung von Checks via Icinga Web an den Icinga Core weiter zu geben.

Ist ein Parallelbetrieb der Backends von Icinga DB und IDO möglich?

Ja. Da beide vom Icinga Core als Features angesprochen werden, können diese auch parallel laufen. Natürlich führt das dann in beiden persistenten Speichern auch zu doppelter Datenhaltung. Daher empfehlen wir das nur temporär.

Ist ein Parallelbetrieb des Webfrontends für Icinga DB und IDO möglich?

Ja. Sobald Icinga Web das Monitoring Modul und auch das Icinga DB Modul aktiviert und konfiguriert hat, ist ein Zugriff auf beide Backends möglich. Mittels Berechtigungen lässt sich allerdings einschränken wer überhaupt das herkömmliche Monitoring bzw. Icinga DB sehen und benutzen darf. Sind die Berechtigungen für beide Module erteilt, gibt es beim sog. „Dualview“ in vielen Ansichten eine Auswahlmöglichkeit zwischen Daten aus der Icinga DB oder der IDO. Die Unterstützung der Backends variiert jedoch v.a. bei Community Modulen noch etwas.

Wie sieht eine Migration von IDO auf Icinga DB aus?

Das letzte Release der Icinga DB liefert auch ein Migrationsskript. Damit kann die gesamte Historie aus der IDO in den persistenten Speicher der Icinga DB übernommen werden. Alternativ kann aber auch der Zeitraum der zu migrierenden Daten eingeschränkt werden. Eigene Dashboards in Icinga Web müssen auf Icinga DB angepasst werden und auch bestehende Reports sind für Icinga DB mit dem neuen Backend abzuspeichern. Da sich die Ansichten des Webmoduls für Icinga DB von dem für IDO (Monitoring) teilweise unterscheiden, ist jedoch eine Übergangszeit mit einem Parallelbetrieb beider Backends ratsam um v.a. auch die Nutzer daran zu gewöhnen.

Sollten alle auf Icinga DB umsteigen?

Ja, v.a. mittel- bis langfristig! Denn Icinga DB gilt als Nachfolger bzw. Ersatz der IDO. Auch wenn der genaue Zeitpunkt derzeit noch nicht feststeht, wird der Support für IDO früher oder später eingestellt werden. Schon jetzt ist absehbar das neue Features v.a. bei Icinga Web Modulen nur noch für Icinga DB kommen und man profitiert ab sofort von der verbesserten Performance.

Natürlich beraten und unterstützen wir gerne bei der Neuinstallation von Icinga oder beim Umstieg auf Icinga DB. Kommt einfach ganz unverbindlich auf uns zu!

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

IDO-Snap: war vorher wirklich alles besser?

Kürzlich entstand im Rahmen eines Kundenprojektes ein nettes kleines Icinga-Modul, welches ich hier vorstellen möchte.

Ein Monitoring-System ist abgesehen vom Desasterfall immer dann gefragt, wenn man Änderungen an seiner IT-Umgebung vornimmt. Firmware- oder Betriebssystemupgrades, Ausrollen von Patches, Änderungen an Sicherheitsrichtlinien – es gibt ja immer was zu tun.

Von seinem Monitoring-System möchte man dann wissen, ob hinterher alles noch so schön grün ist wie vorher. Das klappt aber nur, wenn man eine überschaubare, liebevoll gehegte und gepflegte Umgebung hat.

Die Realität sieht meist ganz anders aus. Je größer die Umgebung, desto mehr Objekte sind ständig bunt. In das schöne Grün mischt sich das kritische Rot, das meist vernachlässigte Gelb der Warnings oder das nervige Lila der Objekte mit unbekanntem Zustand.

Dann hat man noch Teams, die das Monitoring zwar mit nutzen – Instrumente wie Acknowledgements und Downtimes aber nicht einsetzen. Schließlich wissen sie ja, was gerade rot sein darf. Dies erschwert dann leider die Arbeit anderer Teams, welche plattformübergreifend Änderungen an den Systemen ausrollen müssen. Woher sollen sie wissen, welche der unbestätigten Probleme nach dem Change denn vorher schon da waren? Klar, die Historie verrät es. Aber spätestens da wird die Arbeit mühsam.

In hoch automatisierten Umgebungen ist es zudem gang und gäbe, dass deprovisionierte Systeme auch automatisiert aus dem Monitoring fallen. Wie soll man dann aber noch überprüfen können, ob denn auch wirklich die richtigen verschwunden sind? Und nicht am Ende ein paar Server zu viel, für die es dann dank Automatisierung schlimmstenfalls keine Alarmierung mehr gibt?

Diese und ähnliche Fragen stellten sich auch besagtem Kunden. Als Lösung dafür konnte ein nützliches kleines Modul entwickelt werden: IDO Status Snapshots (idosnap)

Damit lässt sich jederzeit der Status sämtlicher Objekte, die von Icinga überwacht werden, sichern. Neben dem aktuellen Zustand wird auch vermerkt, ob sich das Objekt gerade in einer Downtime befand, und im Falle eines Problems, ob dieses bereits bestätigt worden ist (Acknowledgement).

Zusätzlich lässt sich das Modul so konfigurieren, dass vor jedem Deployment aus dem Director automatisch ein Snapshot erstellt wird. Und das unabhängig davon, ob dieses Deployment manuell oder automatisiert erfolgt. Denn oft bemerkt man erst im Nachhinein, dass ein vorheriger Snapshot praktisch gewesen wäre.

Weitere Details finden sich in der Dokumentation des Moduls, viel Spaß!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Icinga 2 Entwicklungsstand 2014 – Webinar Reminder

logo_icinga3Morgen früh um 10:30 Uhr beginnt das letzte Webinar vor der CeBIT. Diesmal wollen wir auf das neue Icinga 2 eingehen und alle bisher vorgenommenen Änderungen der Milestones ansprechen.
Im Webinar werden wir einige Grundkonfigurationen kennenlernen, bis hin zur Einrichtung eines Clusters von zwei Nodes. Natürlich wollen wir im selben Schritt auf einige Unterschiede zu Nagios / Icinga eingehen und die Roadmap für Version 0.0.8 präsentieren.
Wer noch daran teilnehmen möchte, kann sich über unsere Webinarseite registrieren.
Eine Aufzeichnung des Webinars und die gezeigte Präsentation wird anschließend in unserem Webinar-Archiv online gestellt.
Cebit BlogWer Icinga 2 näher betrachten möchte, kann sich entweder über unser Kontaktformular bei uns melden oder uns auf der CeBIT im Open Source Park, Halle 6, an Stand E16 (310) besuchen. Um uns schneller zu finden, gibt es natürlich auch eine Wegbeschreibung.
Bis morgen im Webinar!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".