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

Icinga – so wählst du Plattform und Betriebssystem

This entry is part 1 of 5 in the series Icinga. Einfach. Erklärt.

In unserer Blogserie „Icinga. Einfach. Erklärt.“ entführen wir Dich ins Icinga-Universum. Wir beleuchten verschiedene interessante und spannende Themen, die Dir bei Deiner Arbeit mit Icinga helfen können.
Unsere erfahrenen Consultants nehmen Dich mit in ihre Welt und teilen ihre Expertise und Sichtweise, wägen Vor- und Nachteile ab und berichten aus ihrer täglichen Arbeit mit dem Open-Source-Enterprise-Monitoring-Tool Icinga.

Den Anfang macht unser Principal Consultant Dirk Götz mit dem ersten Teil seiner Tipps für eine state-of-the-art Icinga-Installation. Darin geht er auf die Hardware- oder Containerlösung ein und welches Betriebssystem für Dich und Dein Team am besten geeignet sein könnte.

Aus zahlreichen Kundenprojekten, die ich im Laufe meiner Zeit bei NETWAYS durchgeführt habe, haben sich für mich einige Best Practices bei der Einrichtung und Konfiguration von Icinga ergeben. Um diese state-of-the-art Icinga-Installation zu beschreiben, dachte ich mir, ich gehe hier im Blog so vor wie ich es im Consulting auch würde. Das heißt, als Erstes gehe ich auf die richtige Plattform ein also primär das Betriebssystem, aber auch ob Hardware, virtuelle Maschine oder gar Container. Im zweiten Teil beantworte ich dann die Frage „Pet or Cattle“, gehe darauf ein, welche Icinga-Komponenten für mich einfach dazu gehören und beantworte nebenbei hoffentlich noch die Frage nach der Icinga-Repository-Subscription.

Hardware, virtuelle Maschine oder gar Container?

Starten wir also einmal ganz am Anfang und überlegen uns, welche Vor- und Nachteile wir von einer Hardware-Lösung hätten. Für mich gibt es hier immer noch einen großen Vorteil und zwar, dass man mit Hardware eine Icinga-Monitoring-Lösung aufbauen kann, die unabhängig von der zu überwachenden Umgebung ist. Leider ist dies in der Praxis in den meisten Fällen nicht so gegeben, wie man sich das als Consultant erhofft. Oder es ist mit viel Planung und weiteren Komponenten verbunden. Denn schon allein so etwas wie der Alarmierungsweg per Mail verkompliziert dies ungemein.
Daher überwiegen für mich in den meisten Fällen die Vorteile virtueller Maschinen und die damit verbundenen komfortablen Managementmöglichkeiten. Man muss sich nur bewusst machen, wovon dann das Monitoring abhängt, was davon vielleicht zu kompensieren ist und was einen Ausfall auslöst, der im schlimmsten Fall einen Blindflug bedeutet.
Wenn virtuelle Maschinen aus meiner Sicht die meisten Vorteile bieten, sind Container dann der nächste logische Schritt? Das Icinga-Projekt bietet auf jeden Fall eigene Container an, hat den Icinga-Prozess container-freundlich gebaut und einige Kunden laufen sehr erfolgreich mit diesem Konzept. Aber wenn ich mir die Plugin-Fähigkeit von Icinga und Modularität von Icinga Web so anschaue, so stehen diese Eigenschaften, die ich als Vorteile ansehe, dem Container-Ansatz doch etwas im Weg. Vor allem wenn dann ein Plugin durch ein Icinga-Web-Modul zur Verfügung gestellt wird, welches ohne Agent im Container nicht aufrufbar ist.

Wahl des Betriebssystems

Bei der Wahl des Betriebssystems bin ich ein großer Fan davon, besonders auf bestehendes Know-how zu setzen. Daher rate ich meinen Kunden Icinga auf der gewohnten Linux-Plattform zu installieren. Da aber jede Distribution ihre Eigenheiten sowie Vor- und Nachteile hat, müssen wir das Thema Betriebssystem etwas detaillierter betrachten. Und da sie direkt mit der Wahl der Distribution zusammenhängen, gibt es einen kleinen Exkurs in Richtung Monitoring-Plugins.

Debian-Familie

Hier ist es relativ einfach, denn für Debian und Ubuntu stellt das Icinga-Projekt Pakete frei zur Verfügung. Diese gibt es für jede bekannte Version, auch für einen ARM-Build in Raspberry Pi OS ist gesorgt.
Einzige kleine Einschränkung: Support gibt es im Falle von Ubuntu nur für LTS-Releases.
Damit Icinga nicht nur schön aussieht, sondern auch die gewünschte Überwachung liefert, werden Plugins benötigt. Monitoring-Plugins ist in der Debian-Familie die Quelle für die gleichnamigen Pakete. Hier bekommen wir eine paketierte und gut supportete Standard-Plugin-Sammlung, die zudem noch einfach zu installieren und gut gepflegt ist.
Etwas verwirrend ist der Benutzer „nagios„, der im weiteren Verlauf von den Icinga-Paketen weiterverwendet wird, die Nagios-/Icinga-1-Konfiguration, die durch die Plugins abgelegt wird, und die grobe Aufteilung auf Pakete.
Dass hier statt mit setuid mit Filesystem-Capability gearbeitet wird, finde ich persönlich sehr gut. Heißt, wir haben bei den Plugins Vor- und Nachteile, die aber vor allem dann eine Rolle spielen, wenn wir verschiedene Distributionen im Einsatz haben.
Einzig meine persönlichen teils negativen Erfahrungen mit Ubuntu lassen mich eher ein Debian empfehlen, Stichwort „Sonderwege“.

Red-Hat-Familie

Bei der Red-Hat-Familie wird es aus meiner Sicht komplizierter. Fangen wir mit Red Hat Enterprise Linux (RHEL) an. Hier gibt es die Pakete vom Icinga-Projekt auf Basis einer Repository-Subscription. Nachdem hier explizit auf RHEL gebaut wird, Partnerverträge bestehen etc. finde ich das ein berechtigtes Vorgehen!
Nächste in der Familie wären eigentlich CentOS Linux bzw. CentOS Stream. Ich sage hier eigentlich, denn CentOS Stream wird zukünftig nicht mehr aktiv unterstützt. Was heißt das für aktuelle Nutzer von CentOS? Es wird (Stand heute) keine Pakete für CentOS Stream 8 und 9 geben. Da es sich bei diesen Distributionen um den Upstream zu RHEL handelt, könnten theoretisch die RHEL-Pakete genutzt werden.
Leider werden auch die RHEL-Derivate Rocky Linux, AlmaLinux und Oracle Linux nicht aktiv als Icinga-Systeme unterstützt. Hier findet sich auf der Icinga-Homepage jedoch der Hinweis, dass die RHEL-Pakete bei Systemen, die zu 100-Prozent binär-kompatibel sind, genutzt werden können. Das ist zumindest bei Rocky Linux und AlmaLinux der Fall. Ob es sich dabei um eine gute Lösung für den Einzelfall handelt, muss man selbst entscheiden.
Erfreulicher sieht es dahingehend bei Amazon Linux aus. Im Rahmen der Icinga-Subscription bekommt man Zugriff auf die entsprechenden Pakete.
Alternativ kann mit Fedora auf Community-Support gesetzt werden.

Kommen wir zu den Plugins für Red-Hat. Hier befinden sich die Nagios-Plugins in einem zusätzlichen Repository, den „Extra Packages for Enterprise Linux“ oder im Fall von Fedora in den normalen Repos des Fedora-Projekts. Es handelt sich also um eine andere Quelle als diejenige, die bei Debian-basierten Systemen zum Einsatz kommt. Wie bei Debian wird aus „historischen Gründen“ die Gruppe „nagios“ verwendet und mit setgid gearbeitet, um Plugins höhere Rechte zu geben.
Man merkt, dass die Situation bei Red-Hat-Derivaten deutlich komplexer ist als bei Debian. Und besonders CentOS-Nutzer müssen sich aktuell nach Alternativen umsehen, was innerhalb der Community zu der einen oder anderen kritischen Stimme geführt hat.

Um der Komplexität etwas entgegenzuwirken, bauen wir bei NETWAYS wieder selbst Pakete. Unsere Buildplattform orientiert sich am Icinga-Projekt, daher bauen wir auf CentOS Linux 7, RHEL 8 und 9. Unsere Buildziele orientieren sich an unseren Kunden. Wir bauen und testen also für CentOS und RHEL, gehen von Funktion auf Rocky Linux und AlmaLinux aus, aber betrachten nicht Fedora, Oracle Linux und Amazon Linux.

SUSE-Familie

Bleibt noch SUSE Linux Enterprise Server (SLES). Diese Pakete sind ebenfalls nur für Subscription-Kunden zugänglich. Eine Alternative für alle SUSE-Fans wäre openSUSE, welches ich persönlich ebenso wie Fedora normalerweise nicht in einem Unternehmensumfeld sehe. Es soll jedoch ab 15 SP 3 zu 100-Prozent binär-kompatibel mit SLES sein, wodurch es vielleicht für den einen oder anderen in Frage kommt. Hier gibt es direkt Monitoring-Plugins über das Packagehub-Repository und da wir als NETWAYS bisher wenig Anfragen in dem Bereich hatten, bauen wir aktuell noch nicht standardmäßig für SLES.

Andere Systeme kommen nicht als Plattform für das zentrale System infrage, aber als Agent wird auch noch Windows supportet und bauen lässt sich die Software selbst auf weiteren Plattformen. Im Fall von FreeBSD und Alpine Linux werden sogar Pakete von der Community bereitgestellt.

Zusammenfassung

Welche Distribution kann ich nun empfehlen? Debian ist sinnvoll für all diejenigen, denen der Community-Support ausreicht. Wer eh schon auf Enterprise-Support beim Betriebssystem setzt, für den lohnen sich die RHEL-Pakete, auch wenn diese mit einer Icinga-Subscription verbunden sind. Alle anderen Optionen sind auch valide, aber fühlen sich einfach nicht optimal an.
Wer eine heterogene Umgebung zu überwachen hat, findet im Icinga-Umfeld neben der Verfügbarkeit, wie man oben raus lesen konnte, ein paar kleinere Baustellen, die mit Erfahrung aber leicht zu handhaben sind. Für diese kann aber das Icinga-Projekt recht wenig, denn auch wenn man versucht hat, in der Vergangenheit in Zusammenarbeit mit allen Distributionen einen gemeinsamen Kurs zu finden, ist dies leider nicht immer gelungen.

Damit sind wir am Ende des ersten Teils meiner Vorstellung einer state-of-the-art Icinga-Installation. Ich hoffe Dir damit weiterhelfen zu können!
Falls Du bereits jetzt Interesse an Icinga gefunden hast und es auch in Deinem Unternehmen vorschlagen oder sogar einführen willst, führen ich oder ein:e Kolleg:in gerne eine individuelle Betrachtung der vorhanden IT-Umgebung durch. Im Rahmen eines solchen Consultingtermins erstellen wir gerne zunächst ein Proof of Concept. Natürlich können wir auch gleich mit der Implementierung von Icinga beginnen.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Icinga nun auch mit IcingaDB einfach und leicht installieren – der Icinga-Installer

Icinga ist das Open Source Monitoring Tool, mit dem Du Deine gesamte Infrastruktur mit allen Hosts, Netzwerkkomponenten und Anwendungen überwachen kannst. Dass Du Icinga nutzen möchtest, weißt Du bereits, aber Dir ist die Installation einer kompletten Icinga-Umgebung zu kompliziert und zeitaufwendig? Und nun kommt auch noch die IcingaDB hinzu? Dann schau Dir den neuen Icinga-Installer an!

Schritt für Schritt zu Icinga

Der Icinga-Installer führt Dich Schritt für Schritt durch den gesamten Installationsprozess. Diese Möglichkeit, Icinga zu installieren, erfordert bei einem Standalone-System keine weiteren manuellen Anpassungen deinerseits. Somit kommst Du auf schnellem und einfachem Weg zu einer laufenden icinga Instanz – etwa mit diesem Aufruf in der Kommandozeile:

$ icinga-installer -S server-db-pgsql

Mit der nun erschienen Version 1.0.0 wird die IcingaDB vollumfänglich unterstützt. Auch der Parallelbetrieb mit der IDO ist mit den Szenarien server-ido-pgsql bzw. server-ido-mysql konfigurierbar. Eine auf den Server abgestimmte Installation von Satelliten und Agenten ist ebenfalls mit wenigen Angaben möglich.

Icinga ist Deine professionelle Open Source Monitoring-Lösung für alle Deine Systeme. Mit unserer jahrelangen Erfahrung im Consulting, Outsourcing und Support unterstützen wir Dich vollumfänglich auf allen Ebenen Deines Monitorings mit Icinga. Schau Dir unsere Leistungen genauer an und melde Dich bei allen Fragen und Anliegen rund um Icinga – unser Sales Team findet bestimmt das passende Angebot für Dich und freut sich darauf, von Dir zu hören!

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Migration auf die Icinga DB gewünscht?

In 2022 wurde die Icinga DB erfolgreich veröffentlicht und für die produktive Nutzung freigegeben. Wir haben hierzu bereits ein Webinar mit dem Titel „Was ist die Icinga DB?“ durchführt, in welchem wir die Architektur im Detail erläutert haben.

Dabei sind wir auf

  • das neue Datenbank-Backend
  • den Redis als Cache
  • und die Kommunikation zwischen Core und Web

eingegangen.

Der Vorteil der Icinga DB

Die Icinga DB bietet neben einer vollständig neuen Architektur ein neues Webfrontend, welches völlig neu gestaltet ist. Damit sind einzelne Elemente nun deutlich besser ersichtlich und erlauben einen noch schnelleren Überblick, wie beispielsweise der Status der aktuellen Check-Ausführung ist, in welchem Intervall geprüft und wann dieser ausgeführt wird.

Installation und Konfiguration

Eine ausführliche Anleitung für die Installation findet man in der offiziellen Dokumentation auf icinga.com. Wir möchten hierfür jedoch einen Schritt weitergehen und werden unsere aktuelle Demo-Umgebung, welche wir in einer Icinga Webinar-Reihe aufgebaut haben, in einem Webinar Live auf die Icinga DB umstellen.

Das Webinar findet am

15. März 2023 um 10:30 Uhr

statt. Hierfür könnt Ihr einfach unseren YouTube-Kanal abonnieren und einen Reminder für das Icinga DB Webinar setzen.

Wir freuen uns auf eure Teilnahme! Wenn Ihr im Vorfeld Unterstützung bei der Migration auf die Icinga DB benötigt, nehmt doch gerne Kontakt mit uns auf. Wir bieten euch gerne Dienstleistungen und Beratungen dazu an.

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

Die Icinga Repository Subscription

Icinga stellt für Red Hat Enterprise Linux (RHEL), Amazon Linux2 und SUSE Linux Enterprise Server (SLES) betriebssystemspezifische Pakete zur Verfügung, die wie das Icinga Director Branches Modul in der Subscription enthalten sind.

Bei der Beratung zu Icinga Repository Subscriptions stoße ich des Öfteren auf so einige Kundenfragen, die ich hier gerne etwas genauer erläutern möchte.

 

Ab wann beginnt die Laufzeit und wie sieht es mit der Verlängerung aus?

Der Zugang zum Repository läuft ab der Bestellung ein Jahr. Man hat aber auch die Möglichkeit, einen Startzeitpunkt festzulegen ab wann die Subscription beginnen soll.

Nach einem Jahr verlängert sie sich dann um 12 Monate, wenn nicht 3 Monate vor Ablauf gekündigt wird. Oder man gibt von vornherein eine fixe Laufzeit an – ohne automatische Verlängerung.

 

Ist die Benutzung limitiert und braucht man für jeden Server eine Repository Subscription?

Die Pakete der Subscription können konzernweit so oft heruntergeladen und installiert werden, wie man möchte. Sie ist global für alle Umgebungen ausreichend und die Anzahl der Icinga Systeme und überwachten Hosts mit Agenten spielt dabei keine Rolle.

 

Wie erhalte ich das Repo und gibt es eine Anleitung wie es einzurichten ist?

Zu dem Repository erhält man einfach die Zugangsdaten.

Unter diesem Link https://icinga.com/docs/icinga-2/latest/doc/02-installation/ findet man als Unterpunkte die einzelnen Distributionen als Installationsanleitung.

 

Muss bei der Icinga Repository Subscription noch etwas implementiert werden?

Nein, bei der Repository Subscription muss nichts mehr implementiert werden. Hier ist alles beinhaltet, was es von Seiten Icinga kostenpflichtig für die jeweiligen Distributionen gibt.

 

Wie lange ist ein Angebot von der Icinga Repository Subscription gültig?

Ein Angebot von der Icinga Repository Subscription hat in der Regel keine Gültigkeit und kann auch noch Wochen nach Angebotserstellung abgerufen werden.

 

Sind Supportleistungen in der Icinga Repository Subscription inkludiert?

Nein, in der Subscription sind keine Supportleistungen inkludiert – jedoch beinhaltet die Icinga Support Subscription auch die Repository Subscription.

 

In welcher Währung bieten wir die Icinga Repository Subscription an?

Die Subscription wird in Euro angeboten.

 

Kann ich Unterstützung bei der Einbindung erhalten?

Im Rahmen unserer Outsourcing-Dienstleistungen können wir gerne bei der Einrichtung des Icinga Repositories unterstützen und bei Bedarf weitere Leistungen übernehmen.

 

An wen kann ich mich bei Fragen wenden?

Bei weiteren Fragen könnt Ihr euch gerne über das Kontaktformular an uns wenden☺