Seite wählen

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

von | Mrz 20, 2023 | Monitoring & Observability, Icinga

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".

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema Monitoring & Observability | Icinga