Seite wählen

NETWAYS Blog

NETWAYS Chefs | Azubis grillen – Teil 1/2

This entry is part 16 of 17 in the series NETWAYS Chefs

Als vor einer Weile unsere Catharina das neue Konzept für NETWAYS Chefs verkündet hat, hab ich sofort das Team „Zentrale Ausbildung“ für August eingetragen. Da zu dem Zeitpunkt eh ein gemeinsames Projekt anstand, war die Zeit dafür vorhanden und für mich ist es eine super Teambuilding-Maßnahme. Die Auszubildenden waren aus unterschiedlichen Gründen begeistert. Für die einen war es eine Chance, sich in der Küche auszutoben, für die anderen eine gratis Mahlzeit! 😉

Die ersten Ideen wurden immer mal wieder besprochen und es zeichnete sich schnell passend zum Sommer „Grillen“ als Thema ab. Die Pläne wurden dann am Ende der gemeinsamen Icinga-Schulung konkretisiert, sodass wir eine Umfrage für alle Kollegen erstellen konnten. Aus dieser durfte jeder ein oder zwei Hauptgerichte wählen. Wem nichts von unseren Vorschlägen gefallen hat, wählte die Option „You bring it, we grill it“. Beilagen in Form von Brot und Salaten versprachen wir einfach anhand der Anzahl von Kollegen beizusteuern. Und was wäre ein Essen ohne Nachtisch? Also sollten alle mit einem extra Magen für Süßes auch noch in dieser Spalte ein Kreuzchen machen. Nachdem sich bis zur Deadline fast 30 Kollegen eingetragen hatten, stand am Mittwoch der große Einkauf an. Hierfür legten wir gemeinsam fest, was gemacht werden sollte und wer dafür verantwortlich ist. Derjenige schrieb seine Zutaten zusammen und daraus machten unsere Einkäufer eine Liste. Als diese zurück waren, begannen schon die ersten Vorbereitungen, da manches über Nacht gehen, einziehen oder abkühlen sollte. Bevor wir aber nun mit den Rezepten starten, sollen nun erst mal unsere Einkäufer zu Wort kommen.

 

Der Einkauf von Johannes Rauh

Meine Aufgabe war es, die ganzen Einkäufe zu planen und durchzuführen. Diese Aufgabe habe ich mir mit Apostolos geteilt. Da wir schon den Nachmittag vor dem Grilltag angefangen hatten, die ersten Sachen vorzubereiten, mussten wir auch schon einen Tag davor einkaufen gehen. Dazu haben mir alle Leute ihre Rezepte mit genauen Mengenangaben geschickt und ich habe eine große Einkaufsliste zusammengeschrieben. Daraus hat sich ergeben, dass wir in 5 Läden mussten: Metzger, Baumarkt, einen griechischen Laden, ALDI und REWE.
Da wir ja Grillen wollten, war klar, dass wir eine gewisse Menge an Fleisch benötigen. Unsere Umfrage hat ergeben, dass wir 20 fränkische Bratwürste, 18 Putenspieße, 10 Rinder-Roastbeef à 200g, 10 Lachsfilets sowie 20 Grillkäse benötigen.

Alles bis auf die Lachsfilets wollten wir bei einem Metzger vorbestellen und am Tag des Grillens abholen. Hierfür sind wir zum Partyservice Wahler gefahren.

EinkaufAnschließend waren wir beim Baumarkt und haben die Gasflasche für unseren Gasgrill auffüllen lassen. So war sichergestellt, dass uns nicht plötzlich während des Grillens das Gas ausgeht und die Leute hungrig bleiben müssen.

Apostolos – ein Grieche durch und durch – hat darauf bestanden, den Joghurt für sein Tsatsiki in seinem griechischen Fachgeschäft des Vertrauens zu besorgen und so haben wir dort auch gleich ein Kilo Feta für die Salate geholt.

Der Plan für den Rest war, möglichst viel bei ALDI zu bekommen, um ein wenig Geld zu sparen. Alles, was wir dort nicht bekommen haben, haben wir vom REWE direkt nebenan geholt.

 

Fischmarinade von Dirk Götz

Irgendwann war mir danach, statt Fisch natur oder mit ein paar Kräutern gewürzt zu grillen, mich im Marinieren zu versuchen. Dabei bin ich über die „Fisch – Marinade à la Ralli“ auf Chefkoch gestolpert, die meine aktuelle Standard-Marinade geworden ist, aber wie immer mit ein bisschen Abwandlung.

Du brauchst:
Marinierter Lachs
1 TL Pfeffer (am besten bunter, frisch gemahlen)
1 TL Salz
1 Peperoni
1 EL süßer Senf
3 EL dunkle Sojasauce
12 EL Olivenöl
3 EL Balsamico
4 große Zehen Knoblauch
1/2 Bund Dill

So geht`s:

Die Peperoni einfach fein in Ringe schneiden, wobei ich persönlich Habanero oder ähnlich scharfe nehme, für die Kollegen sollte es aber eine einfache rote Peperoni tun. Den Dill fein hacken, alternativ geht auch getrockneter, aber frischer ist natürlich geschmacklich intensiver. Anschließend die Zutaten einfach vermengen.

Ich lasse den Fisch gerne über Nacht in der Marinade im Kühlschrank ziehen. Dafür einfach eine Schicht Fisch ins Gefäß legen, mit ein paar Löffeln Marinade übergießen, dann mit der nächsten Schicht wiederholen und zum Schluss den Rest einfach ins Gefäß gießen. Die Menge reicht für viel mehr als man denkt. Die 12 Lachsfilets waren also vollkommen ausreichend. Hat man weniger Zeit, kann man die Marinade auch während des Grillens immer wieder auftragen.

 

Mediterraner Kircherbsensalat von Dirk Götz

Bei diesem Salat handelt es um einen meiner Lieblingssalate zum Grillen. Dabei kann er aber auch ganz gut mit etwas Brot als vollwertige Mahlzeit dienen. Für die Kollegen hab ich die doppelte Portion gemacht, sodass auch genug für alle da war. Gefunden hab ich das Rezept auch wieder auf Chefkoch, da ich kein so großer Fan von Petersilie bin, lasse ich diese aber meist weg.

Du brauchst (für eine Schüssel):
Mediterraner Kichererbsensalat
1 Dose (800g) Kichererbsen
1 rote Zwiebel
1 Zucchini
1 (rote) Paprika
1 Peperoni
250g Feta (kann auch etwas mehr sein)
3 EL Balsamico-Essig
6 EL Olivenöl (und etwas zum Braten)
Zucker
Zitronensaft
Salz

So geht’s:

Die Kichererbsen abtropfen lassen. Währenddessen Essig, Öl, Zucker, Zitronensaft und Salz zu einem Dressing verrühren, wobei ich letztere nach Gefühl und durch Abschmecken dosiere. Die abgetropften Kichererbsen mit dem Dressing vermischen.
Die Zwiebel in schmale Halbkreise und die Peperoni in dünne Scheiben schneiden und hinzufügen. Auch hier darf es gerne eine schärfere Sorte sein, wenn man dies mag. Allerdings waren auch bei einer normalen Peperoni schon einige überrascht.

Zucchini in Scheiben und Paprika in feine Streifen oder größere Rechtecke schneiden und im Olivenöl anbraten. Das ganze darf schon etwas Farbe bekommen, die Zucchini gebräunt, die Paprika glasig.

Während des Anbratens den Schafskäse würfeln und unterheben. Nach dem Braten ebenso das Gemüse unterheben. Dabei lass ich auch gerne das Olivenöl vom Braten komplett mit reinlaufen. Gerne dann nochmal etwas abschmecken, je nach Geschmack braucht es noch etwas Zitronensaft oder Salz.

 

Mediterraner Nudelsalat mit getrockneten Tomaten und Pinienkernen von Leander Müller-Osten

Diesen Salat mach ich eigentlich bei jeder Grill-Feier. Zum einen ist er sehr schnell gemacht und auch sehr gut in großen Mengen zu machen. Vor allem heute, wo wir für ca. 25 Personen gekocht haben, genau der richtige Salat.

Du brauchst (für 10-12 Personen):
Nudelsalat (Work in Progress)
1kg Nudeln
1 Glas getrocknete Tomaten
400g Feta-Käse
2 Packungen Pinienkerne
4 EL Balsamicoessig
2 Becher Sauerrahm
3 Gläser rotes Pesto (grobes Pesto)

So geht’s:

  1. Bring einen Topf mit gesalzenem Wasser zum Kochen. Füge die Nudeln hinzu und koche sie gemäß den Anweisungen auf der Verpackung, bis sie al Dente sind.
  2. Rühre das Pesto nach Deinem Geschmack in die warmen Nudeln ein. Füge dann den Sauerrahm hinzu und vermische alles gut, bis die Nudeln gleichmäßig von der Pesto-Sauerrahm-Mischung umhüllt sind.
  3. Die getrockneten Tomaten abtropfen und in feine Streifen schneiden. Gib die geschnittenen Tomaten zu den Nudeln und rühre sie vorsichtig unter, damit sie sich gleichmäßig im Salat verteilen.
  4. Erhitze eine beschichtete Pfanne auf mittlerer Hitze. Gib die Pinienkerne in die Pfanne und röste sie leicht an, bis sie goldbraun und duftend sind. Achte darauf, sie regelmäßig zu wenden, damit sie sich gleichmäßig bräunen. Sobald die Pinienkerne fertig geröstet sind, nimm sie aus der Pfanne und gib sie zu den Nudeln.
  5. Zerbrösele den Fetakäse mit Deinen Händen über den Nudelsalat.
  6. Gib etwa 4 EL Balsamicoessig über den Salat. Nach Geschmack kannst Du auch etwas Olivenöl hinzufügen. Vermische alles gut und schmecke den Salat mit Salz und Pfeffer ab.
  7. Decke die Schüssel mit dem Nudelsalat ab und stelle sie für etwa 3-4 Stunden in den Kühlschrank.

 

Coleslaw von Leander Müller-Osten

Der Klassiker unter den Krautsalaten, der jedes Fleischgericht perfekt begleitet:

Du brauchst (für 10-12 Personen):
Coleslaw (Work in Progress)
1 Kopf Weißkohl
1/2 Kopf Rotkohl
3 Karotten
3 Äpfel
Mayonnaise
Honig
Apfelessig
Senf (mittel scharf oder Dijon)
Selleriesamen

So geht’s:

  1. Kohl vorbereiten: Weißkohl und Rotkohl vierteln und den Strunk entfernen. Schneide den Kohl dann in möglichst dünne Streifen und gib ihn in eine große Schüssel.
  2. Entwässern des Kohls (optional, aber empfohlen): Um sicherzustellen, dass der Coleslaw knackig bleibt und nicht zu viel Wasser abgibt, füge 1-2 Teelöffel Salz zum Kohl hinzu und vermische alles gründlich. Etwa 1 Teelöffel Salz pro Kohlkopf sollte ausreichen. Lasse den Kohl mindestens eine halbe Stunde stehen. Du kannst auch etwas Schweres auf den Kohl legen, um das Wasser herauszudrücken. Drücke den Kohl nach dem Ruhen kräftig aus, um so viel Wasser wie möglich zu entfernen.
  3. Apfel und Karotte raspeln: Raspel die Äpfel und Karotten, um feine Raspeln zu erhalten. Die Apfel- und Karottenraspeln fügen dem Coleslaw eine angenehme Süße und zusätzliche Textur hinzu.
  4. Dressing anrühren: Bereite das Dressing vor, indem Du Mayonnaise, Honig, Apfelessig, Senf und Selleriesamen in einer separaten Schüssel vermengst. Die genauen Mengen hängen von Deinem persönlichen Geschmack ab, aber als Richtlinie könntest Du etwa 1/2 Tasse Mayonnaise, 1-2 Esslöffel Honig, 2-3 Esslöffel Apfelessig, 1 Teelöffel Senf und eine Prise Selleriesamen verwenden. Rühre alles gut um, bis das Dressing gleichmäßig vermischt ist.
  5. Alles zusammen mischen: Gib die geraspelten Äpfel und Karotten zum entwässerten Kohl in die Schüssel. Gieße das vorbereitete Dressing über die Zutaten und vermische alles gründlich, bis der Kohl, die Äpfel und die Karotten gut mit dem Dressing bedeckt sind.
  6. Kühlen: Decke die Schüssel mit dem Coleslaw ab und stelle sie in den Kühlschrank. Lasse den Coleslaw für mindestens 1 Stunde oder länger kühl stehen, damit sich die Aromen verbinden und der Coleslaw gut durchziehen kann.

 

Kartoffelsalat von Jan Schuppik

Kartoffelsalat ist ein zeitloser Favorit, der zu den unterschiedlichsten Anlässen passt. Egal, ob bei Grillfesten, als leichtes Sommeressen oder auf Buffets – dieser Klassiker erfreut sich stets großer Beliebtheit. Dieses Rezept verleiht dem traditionellen Kartoffelsalat eine erfrischende Note und stammt von Chefkoch. Er begeistert durch ein einzigartiges Geschmackserlebnis und eine aufmerksam durchdachte Zubereitung.

Du brauchst (für 10 Portionen)::
Kartoffelsalat
2,5 kg vorwiegend festkochende Kartoffeln
2,5 Zwiebeln, fein geschnitten
2,5 Tassen heiße Gemüsebrühe (ca. 125 ml pro Tasse)
5 EL Essig
7,5 EL Rapskernöl
2,5 TL Salz
Prise Pfeffer
1,25 Salatgurken
Senf und/oder Salatkräuter

So geht’s:

Beginne damit, die frisch gekochten Kartoffeln zu schälen und in handwarme, hauchdünne Scheiben zu schneiden. Lege die Scheiben in eine großzügige Schüssel.

Erhitze die Gemüsebrühe und gib den Essig hinzu. Diese Mischung wird dem Kartoffelsalat die perfekte, harmonische Note verleihen. Nach Belieben kann auch etwas Senf hinzufügt werden, dieser wird dann in der Brühe-Essig-Mischung aufgelöst.

Jetzt kommt der interessante Teil: Beginne mit einer Prise Salz über den Kartoffelscheiben, gefolgt von den fein geschnittenen Zwiebeln. Je nach Geschmack kannst Du eine Prise gemahlenen Pfeffer oder feine Salatkräuter hinzufügen. Gieße dann die heiße Brühe-Essig-Mischung über die Zutaten.

Als Nächstes füge das Rapskernöl hinzu, dieses ermöglicht eine gleichmäßige Verteilung der Aromen. Verwende zwei Esslöffel, um die Zutaten vorsichtig zu vermengen, bis alles gut durchmischt ist. Lasse den Salat für mindestens eine Stunde in der Wärme ruhen, damit die Aromen sich entfalten können.

In der Zwischenzeit kannst Du die Salatgurken gründlich abwaschen und samt der Schale mithilfe eines Gemüsehobels in feine Scheiben schneiden. Diese knackige Ergänzung verleiht dem Salat eine erfrischende Textur und einen leichten Biss.

Sobald die Ruhezeit vorüber ist, füge die geschnittenen Gurkenscheiben hinzu und vermische alles behutsam miteinander.

Tipp:
Die heiße Gemüsebrühe in Kombination mit Essig mildert die Schärfe der Zwiebeln und lässt das Salz sowie den Pfeffer besser zur Geltung kommen. Das Öl wird immer zum Schluss hinzugefügt, um den Kartoffeln die Möglichkeit zu geben, Feuchtigkeit aufzunehmen und die Aromen gleichmäßig zu verteilen.

 

 

Nachtisch ist die beste OptonIn diesem ersten Teil ging es um das Grillgut und die Salate als Beilage. Im zweiten Teil kommen dann noch weitere Rezepte zu Broten, Dips und der Nachtisch dazu, denn wir wollten es uns natürlich richtig gut gehen lassen. Was auch schon das Abstimmungsergebnis gezeigt hat. 😉

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.

Foreman Birthday Event 2023 – Recap

Two years ago I started my recap of the event with „Last week on Thursday we had the Foreman Birthday event and I can proudly say it was a big success.“ and I can do the same for this one.

At the beginning of the year planning for the event started in the background as we discussed in which form we want it to happen. While I was excited for having an in-person event, I quickly realized that travel restrictions and budget would still be a problem for many people, so we agreed on keeping it online for another round would be the best. So keep the fingers crossed for the next time.
When we finalized the date and it was time to find some speaker, a wild hunt started as many changes of the last year had come together. Some of my usual suspects had changed position or company, environments moved from the classic IT environment managed by Foreman to a cloud native approach managed by Kubernetes and similar effects made me fear I can not provide a good program. So I was even thinking about jumping in myself and give a talk as I still do not own a kettle prod to motivate colleagues. 😉 But in the end I was happy with the four talks we got as it was a good mix.

Thanks to our events team who did so many things in the background which I would have forgotten, the managed services team who provided the servers and Christian who did the streaming setup, we had the same setup like last time. And when I started to adjust the configuration of all the buttons on the stream deck I started to finally remember everything including the mixed feeling of excitement and nervousness. Nervousness reached its top when I started the introduction and was signaled people could not hear me, just to realize one button was still showing me muted while the one I looked showed unmuted. But after this everything went smooth.

Screencapture of the Youtube Stream with Countdown at 0:00

Our first speaker was Christian Stankowic who gave a nice look into his work at many customer projects in his talk „Lessons Learned – Automated installations and hints“. The first part of his talk was about Foreman and alternatives and why people decide for or against Foreman. I like it if a talk is not free of critique and Christian had some good points here even if you do not agree with all. His tips and tricks focus on automated installation and documentation, but there are also some on infrastructure design. And with all the tips given he was so kind to provide an example repository on github, too! Thanks again Christian, I was really happy I convinced you to give this talk.

The second one was Bastian Schmidt with „Provisioning Ubuntu hosts in Foreman“ who was also was very involved with implementing the topic. It was a rocky road to get this up and running after Ubuntu moved from Preseed to Autoinstall with 20.04.3/22.04.1. Bastian talk showed how rocky it was and also how good the community was in tackling it. And his talked ended with a demo showing the next improvement currently in the making. Thanks again Bastian for the talk and even more for the hard work on this feature!

Screencapture of the Youtube Stream during the Live Q&A with Bastian Schmidt

Ewoud Kohl van Wijngaarden did his talk live as he just finished it last minute, but this also worked great. In “foreman-documentation: rethinking our documentation” we heard about past, present and future of the Foreman’s documentation. If you have not heard about before the new documentation started as the documentation for Red Hat Network Satellite which was given to the Foreman Project to make this a true open source project with upstream and downstream. From this it was a huge community effort to adapt this for Foreman and Katello while creating a good base not only for the Satellite but also Orcharhino. And now the next step is to get rid of the manual and make it the one documentation. Thanks to Ewoud and all those involved in creating and improving the documentation.

And last but not least we had Samir Jha who demoed the updates from the Katello content team. As an addition Ian Ballou had added a demo focusing on the Alternate Content Source feature and Chris Roberts did send me a demo to showcase Simple Content Access. So we finished with a great look inside the latest improvements to Katello and in the live Q&A Samir also talked about future improvements. Thanks to all of you!

In parallel and afterwards we had again the social event in workadventure which I could only join after the stream ended, but this was still enough to meet some community members. All of them were happy and gave great feedback about the event. In the end I had a quite long and productive discussion with Ewoud and Maximillian about many different topics. So I am really looking forward for the next event where I can meet this great community again!

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 Director – grafische Konfiguration für alle?

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

Um dir einen reflektierten und ehrlichen Einblick in meine Entscheidungsgrundlage zu geben, gehe ich so vor, als würde ich im Consulting einen Kunden beraten und mit ihm zu einem für ihn passenden Lösungsansatz kommen. Bevor ich die jeweiligen Vor- und Nachteile von Konfigurationsdateien und der grafischen Oberfläche, dem Icinga Director, beleuchte, möchte ich als Einstieg allerdings erst über die Icinga DSL reden. Dies soll dazu dienen, dass Du meine Argumente besser verstehst und nachvollziehen kannst. Nach dem Pro und Kontra werde ich dann mein persönliches Fazit ziehen und Dir verraten, wie ich mich entscheiden würde. Das muss aber nicht der Schluss sein, zu dem Du kommst. Hier darf gerne jede:r mit seiner eigenen Gewichtung zu einem persönlichen Ergebnis kommen. Und eigentlich handelt es sich hierbei nur um ein Zwischenfazit. Denn im Anschluss möchte ich noch auf die Möglichkeiten für eine Automatisierung der Konfiguration eingehen. Und falls Du Automatisierung in Betracht ziehst, wird auch das Deine endgültige Entscheidung maßgeblich beeinflussen. Also, schauen wir uns die Möglichkeiten einmal genauer an!

Icinga DSL

Nun hab ich die Abkürzung DSL bereits zweimal verwendet ohne sie auszuschreiben! Was ich meinen Auszubildenden angekreidet hätte, will ich aber bewusst als Stilmittel verwenden. Denn tatsächlich verwendet Icinga 2 zur Konfiguration nicht eine einfache Konfigurationssprache sondern eine Domain-Specific-Language (DSL). Das Gegenstück wäre eine General-Purpose-Language (GPL) wie beispielsweise YAML. Mit einer solchen ließen sich bestimmt auch alle Monitoring-Objekte abbilden, aber die Icinga DSL erlaubt noch mehr. Dank DSL lassen sich Verzweigungen und Funktionen umsetzen und damit die Konfiguration vereinfachen, was auch die Wartung vereinfacht.

Ein Beispiel für eine Host-Definition:

object Host "localhost" {
  imports "Default Host"
  address = "127.0.0.1"
  vars.os = "Linux"
}

Was aber für mich viel wichtiger ist, ist der Ansatz dahinter. War mit Icinga 1 die Konfiguration noch sehr objekt-basierend, so dass mehr oder weniger jedes Objekt einzeln angelegt und gepflegt werden musste, ist nun die DSL für eine regel-basierte Konfiguration gedacht. Das ermöglicht es, sich Regeln für Überwachung und Benachrichtigung zu überlegen und dann die Host-Objekte mit den passenden Eigenschaften auszustatten, damit die Regeln greifen.

Ein Beispiel für eine solche Regel zur Service-Definition:

apply Service "SSH" {
  import "Default Service"
  check_command = "ssh"

  assign where host.vars.os == "Linux"
}

Auch wenn Du Dich bisher nicht eingehender mit der Icinga DSL befasst hast, kannst Du vermutlich dieses einfache Beispiel nachvollziehen und erkennen, dass für jedes System inklusive unserem „localhost“ mit dem Betriebssystem Linux nun ein Service zur Überwachung des SSH-Diensts erzeugt wird. Natürlich kann es auch durchaus komplexer werden, aber auch das wollen wir vielleicht konfigurieren. Auch für einen komplexeren Befehl möchte ich Dir ein Beispiel geben.

Zeitabhängige Schwellwerte für die Überwachung der Auslastung als Beispiel für komplexere Konfiguration:

apply Service "Load" {
  import "Agent Service"
  check_command = "load"

  vars.load_wload1 = {{
    if (get_time_period("backup").is_inside) {
      return 20
    } else {
      return 5
    }
  }}
  vars.load_cload1 = {{
    if (get_time_period("backup").is_inside) {
      return 40
    } else {
      return 10
    }
  }}

  assign where host.vars.os == "Linux"
}

In diesem Beispiel werden die Schwellwerte für die Auslastung des Systems während der für das Backup definierten Timeperiod hoch gesetzt. Dadurch werden fehlerhaft-positive Alarme vermieden, ohne die Überwachung oder Alarmierung komplett abzuschalten.

Ich hoffe diese kleine Einleitung macht deutlich, was und wie wir aufgrund der Eigenschaften der Icinga DSL konfigurieren müssen. Egal ob in Konfigurationsdateien oder mit Hilfe der grafischen Oberfläche, dem Icinga Director.

Konfigurationsdateien

Der Vorteil von Konfigurationsdateien ist oftmals der „Haben wir schon immer so gemacht“-Faktor. Zwar muss man für den Einstieg die Icinga DSL lernen, aber man kann mit gewohnten Werkzeugen, Strukturen und Arbeitsweisen an die Konfiguration von Icinga herangehen. Auch eine Versionskontrolle mittels Git oder eine Automatisierung mit Ansible oder Puppet ist einfach möglich.

Eine Zusammenarbeit an den Dateien wird schon etwas komplizierter, denn alle müssen das gleiche Verständnis der Struktur mitbringen. Sollen dabei auch noch verschiedene Rollen eingenommen werden, müssen entsprechend feine Dateirechte her oder es braucht zumindest wirklich eine Versionskontrolle und damit verbundene Reviews.

Syntax-Highlighting ist für die wichtigsten Editoren vorhanden, aber trotzdem dürfte das Hauptproblem die Fehleranfälligkeit des Menschen sein. Sowohl syntaktische als auch logische Fehler fallen erst bei der Validierung durch Icinga auf und sind gerade wenn mehrere Personen parallel Änderungen vorgenommen haben auch nicht immer leicht zu finden.

Der größte Vorteil steht dem direkt entgegen, denn ohne eine weitere Abstraktion habe ich direkten und vollen Zugriff auf alle Möglichkeiten der Icinga DSL. Somit sind zahlreiche Anpassungen möglich wie die oben gezeigten zeitabhängigen Schwellwerte, aber noch vieles mehr wie das Erzeugen von Objekten per Schleife auch über komplexe Datenstrukturen oder das Auswerten und Zusammenfassen von bestehenden Checks zu einem Gesamtergebnis. Aber auch ohne die komplexen Beispiele kann eine einfache Ergänzung, wie etwa eine Fallunterscheidung, schon Arbeitserleichterung bringen und doppelte Pflege vermeiden!

Icinga Director

Übersicht des Icinga DirectorsDer Icinga Director als grafisches Frontend zur Konfiguration stellt eine Abstraktion der Icinga DSL dar, denn es müssen natürlich für alle Objekte mit allen Attributen Eingabemasken existieren. Um das noch etwas klarer zu machen, gebe ich Dir einen kurzen Einblick in die Funktionsweise des Icinga Directors. Der Director importiert von einer Icinga-Instanz grundlegende Objekte wie Check-Kommandos, Endpunkte und Zonen. Nach diesem Kickstart musst Du für die allermeisten Objekte zunächst Templates anlegen, wobei direkt Felder für zusätzliche Eigenschaften zu erstellen und anzuhängen sind. Sobald Du auch konkrete Objekte angelegt hast, kannst Du die Konfiguration für Icinga rendern und über den entsprechenden API-Endpunkt produktiv nehmen.

Das heißt auch beim Director können Fehler erst durch die Validierung durch Icinga sichtbar werden. Aber die Eingabemasken reduzieren das Fehlerpotential stark, da Syntax-Fehler weitestgehend ausgeschlossen werden. Bei der Erstellung von Templates, Feldern und Regelwerk kannst Du durch sprechende Namen, Beschreibungen, Filter die nur passende Kombinationen erlauben sowie weitere ähnliche Maßnahmen das Risiko für logische Fehler weiter senken.

Hostansicht im Icinga DirectorsAuf der Trennung von Templates und Objekten baut auch das Rechtesystem des Directors auf, denn der Zwang zur Erstellung von Templates bereitet auch eine entsprechende Rollentrennung vor. So soll gewährleistet werden, dass ein Monitoring-Administrator ganz leicht Vorgaben machen kann und beispielsweise der Linux-Administrator anschließend einfach seine Hosts einpflegen braucht. Wer darauf geachtet hat, dem ist hier mein zögerliches Zugestehen aufgefallen. Denn ein Nachteil, den ich nicht verschweigen möchte, ist leider die Dokumentation des Directors. Alles Grundsätzliche ist in der Dokumentation durchaus enthalten. Manche Details jedoch werden erst durch Ausprobieren klar und Best Practices kristallisieren sich erst mit einiger Erfahrung heraus.

Was erklärt Dir die Dokumentation gut? Komfortfunktionen wie die, dass Du über ein Attribut den Host zu einem Icinga Agenten erklären kannst, finden sich relativ einfach. Die Erklärung, dass es uns Arbeit abnimmt, nochmal separat Endpoint- und Zonen-Objekte für jeden Host zu definieren, findet sich auch. Ebenso ein Hinweis auf die Installations- und Konfigurationshilfe, die sich hinter einem neuen Tab verbirgt. Anderes ist meines Erachtens weniger optimal dokumentiert. Wie ich Checks auf einem anderen Agenten ausführe und was es für das Feature bedeutet, ist dann außer für den erfahrenen Benutzer schwer ersichtlich. Ähnlich geht es mir auch mit anderen Features wie Choices oder Datenfeldkategorien. Diese sind sicher alle optional, dienen jedoch die Benutzerführung zu verbessern und wie bereits angemerkt Fehleranfälligkeiten zu reduzieren.

Auch wenn es nicht ganz offensichtlich ist und die Möglichkeit erst einmal einschränkend wirkt, können mit dem Icinga Director sogar bei Argumenten von Check-Kommandos komplexere Konstrukte mit der Icinga DSL eingebaut werden. Das bedeutet, dass auch das Beispiel mit zeitgesteuerten Schwellwerten möglich ist. Nur muss es halt etwas anders gelöst werden.

Erwähnt werden wollen noch die integrierte CLI und API. Solche Schnittstellen sehe ich immer als Plus. Sie ermöglichen hilfreiche zusätzliche Arbeitsweisen. Die ein oder andere schnelle Schleife über die CLI hat mir schon einiges an Klick-Arbeit gespart.

Zwischenfazit

Für meine eigene kleine Instanz wären wohl Konfigurationsdateien meine erste Wahl, denn ich bin ziemlich schnell im VIM unterwegs, kenne die Icinga DSL doch ganz gut und vor allem bin dann auch nur ich auf dem System unterwegs.

Ansonsten möchte ich Dir aber den Icinga Director ans Herz legen! Mit entsprechender Vorbereitung durch einen erfahrenen Admin oder wenn Du selbst Dir die Zeit nehmen kannst, Dich einzuarbeiten, kannst Du aus dem Director einiges rausholen. Ein großer Vorteil: Du kannst im Director die Arbeit leicht auf mehrere Personen verteilen, ohne dass alle ganz tief in die Materie einsteigen müssen. Das erlaubt es euch, leicht im Team zusammenzuarbeiten und die Abhängigkeit von einzelnen Personen zu reduzieren. Auch die Qualität des Monitorings wird in der Regel besser, wenn Administratoren das Monitoring eigenverantwortlich für ihre Systeme und Dienste pflegen können. Dazu tragen auch die erwähnten Komfortfunktionen und Möglichkeiten zum Aufhübschen bei, denn zumindest ein Umdenken erfordert der Director: Weg von der einfachen Konfiguration, die das primäre Ziel verfolgt,möglichst schnell etwas zu konfigurieren, hin zu einer möglichst übersichtlichen Konfiguration, die leicht zu verstehen und damit auch zu pflegen ist!

Nun fragt sich der eine oder die andere vielleicht, ob er oder sie mit einer Mischung aus beidem nicht die Vorteile beider Welten bekommen kann. Davon möchte ich jedoch abraten! Es ist zwar theoretisch und auch praktisch möglich, erfordert aber definitiv ein sehr tiefes Verständnis. Spätestens bei der Fehlersuche kann dies zum Verhängnis werden. Zudem schränkt es die Möglichkeiten des Directors ein, Objekte aus den Konfigurationsdateien zu verwalten. Du hast beispielsweise nicht mehr die Möglichkeit, wenn Du einen Check-Command importierst, alle Eigenschaften zu pflegen. Gerne behalte die Option im Hinterkopf und denke daran, wenn Du zum Beispiel Check-Kommandos als Konfigurationsdatei beim Plugin mitgeliefert bekommst. Aber bitte plane nicht damit! Daher auch hier meine übliche Empfehlung, dass Du Dich direkt zu Beginn für einen der beiden Wege entscheidest. So ersparst Du Dir später eine Migration und damit einhergehendes Umdenken.

Möglichkeiten der Automatisierung

Automatisierung mit Jobs im Icinga DirectorsFür mich ist schlussendlich meistens nicht entscheidend, wie einzelne Objekte konfiguriert werden können, da ich im Idealfall das Monitoring gar nicht manuell pflegen möchte. Und hier kommt eine der größten Stärken des Directors zum tragen: Der Director bietet die Möglichkeit, Daten aus einer Datenquelle zu importieren und aus diesen Daten dann Monitoring-Objekte zu erzeugen. Dabei können sogar noch Modifikatoren genutzt werden, um die Daten für den Verwendungszweck anzupassen.

Als erstes einfaches Beispiel möchte ich skizzieren, wie ein Import von Benutzern aussehen könnte. Die gleiche LDAP-Ressource, die für die Authentifizierung hergenommen wird, kann im Director als Importquelle verwendet werden. Ich gehe üblicherweise her und erstelle eine erste Import-Regel, die Gruppen importiert, und da hier meist keine Anpassungen nötig sind, kann ich sie direkt zu Usergroups für Icinga synchronisieren.Als zweites erstelle ich eine Import-Regel, die Benutzer importiert, dabei die Gruppenmitgliedschaften filtert und in ein passendes Format bringt, bevor über die Synchronisation daraus User-Objekte werden. Und schon muss ich für Benachrichtigungen nur noch benötigte Templates und die eigentlichen Benachrichtigungen pflegen. Das Management der hierfür benötigten Benutzer und ihrer Gruppen übernimmt das Active Directory, egal ob neue Kolleg:innen, Namensänderungen, Team-Wechsel oder was auch immer anstehen.

Das zweite Beispiel ist in der Praxis oftmals komplizierter. Denn um das Management der Hosts zu automatisieren, braucht es eine geeignete Quelle. Gibt es eine gut gepflegte CMDB (Configuration Management Database) oder Asset Management (oder wie auch immer es im jeweiligen Unternehmen genannt wird)? Perfekt! Eventuell stellst Du fest, dass die Datenqualität nicht so hoch ist, wie Du dies gerne hättest. Und auch hier kommen Modifikatoren zum Einsatz und schaffen Abhilfe. So können etwa alle Hostnamen zum FQDN ergänzt, die Schreibweise beispielsweise des Betriebssystems vereinheitlicht, die fehlende IP-Adresse durch DNS-Abfragen herausgefunden werden oder was sonst noch nötig ist.

Falls Daten fehlen, kannst Du sie aus einer anderen Quelle beziehen, denn viele weitere Module liefern Import-Quellen für den Director. Du kannst Dir etwa Systeminformationen aus dem Konfigurationsmanagement mit Hilfe der PuppetDB oder aus der zugrunde liegenden Plattform wie VMware vSphere oder AWS holen. Und der Vorteil ist: die Daten sind garantiert richtig! Sollten immer noch Daten fehlen, kannst Du diese mit einer eigenen Quelle anreichern. Vielleicht ist die Information schon in einem Excel-Dokument gepflegt oder Du kannst Dir schnell eine CSV-Datei bauen, denn beide Möglichkeiten bringt der Fileshipper. Letzteres nutze ich so regelmäßig, um Standortinformationen anzureichern, dass diese Option sogar als Beispiel in die Schulung Icinga 2 Advanced eingeflossen ist.

Je nachdem wie sehr man dem Automatismus dann vertraut, lässt der Director sich noch weiter automatisieren, so dass Import, Synchronisation und sogar das anschließende Deployment vollautomatisch passiert. Wer im Fehlerfall nicht nachts raus geklingelt werden möchte, kann auch gerne einstellen, dass dies nur während der Arbeitszeit passiert! 😉

Fazit

Mein Zwischenfazit hat ja bereits gezeigt, dass ich zum Director tendiere, selbst wenn es nur um manuelle Konfiguration geht. Aber auch wenn Importe natürlich individuell sind und man sich Konfigurationsdateien anders auch automatisch erstellen kann: hier trumpft der Director wirklich auf! Nicht nur der Workflow ist gut gedacht und vorbereitet, sondern durch die Möglichkeit mit weiteren spezialisierten Modulen, die Zahl der Importquellen und Modifikatoren zu erweitern. Das ist bei Bedarf sogar selbst in wenigen Zeilen zu erreichen. Damit wird der Icinga Director zum ganz klaren Sieger!

Falls Du Dir nun Hilfe bei der Einrichtung des Directors wünscht oder Unterstützung bei der Automatisierung suchst, aber auch wenn Du trotz meiner Ausführungen noch nicht entscheiden kannst, was für Dich der richtige Ansatz ist, melde Dich gerne! Ich oder ein:e Kolleg:in führen gerne eine individuelle Betrachtung zu Deiner IT-Umgebung und ihren Anforderungen durch. Im Rahmen eines solchen Consultingtermins erstellen wir Dir zunächst ein Konzept und können gerne auch direkt mit der Umsetzung 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.

Foreman Birthday Event 2023 – Save the date

I can happily announce we will have a Birthday event on 27.07. this year again. I will be our host again, supported by my colleagues from NETWAYS, ATIX and the Foreman Project. When I talked to people at Cfgmgmtcamp, I was told by many that they really liked the format from 2021 and many companies still have travel or budget restrictions, so we decided to keep the event online. Hopefully returning to a face to face event in the future, but we will see what time brings.

What is planned so far?

We want to have 5-6 30 minute talks and I will moderate the event as live stream on youtube starting 15:00. But as the event also always was not only about the talks and knowledge, but also a social get-together we do want to provide some option to chat during the talks and breaks and have some accompanying social event.

If you like to give a talk please get in touch with me as I am in charge for planing this year (here in the community or via email). We aim for a wide variety of talks, be it a new plugin or some new tricks for an old one, a case study showing your environment, about Foreman itself, Katello/Satellite/Orcharhino, Pulp, Candlepin or even Puppet and Ansible or the Community. Everything related to Foreman will be considered. We plan to have all talks pre-recorded and will provide guidance for doing so. After the talk we want to give everyone the chance to ask questions, so the speaker can answer them live.

For the chat and the social event we will very likely use the same tools again which made the last event such a success, but perhaps our event team will come up with some improvements. If you want to reminisce about the last event or if you missed it and want to know what I am talking about, you can find my recap here at our blog.

How to stay up to date?

So save the date and spread the word! I will collect news in the Foreman-Community and at the latest will write another blog post when the program is finalized.

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 Installationsmethoden (und Wissenswertes zu Komponenten und Subscription)

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

Im ersten Teil bin ich auf die passende Plattform und die Wahl des passenden Betriebssystems eingegangen. Wenn du den ersten Teil noch nicht gelesen hast, dann solltest du das jetzt nachholen und anschließend hier weiterlesen!

In diesem Post beantworte ich nun die Frage, ob du das System eher als „Pet or Cattle“ ansehen solltest, was sich natürlich auf Installationsmethode, Management und einige weitere Aspekte auswirkt. Auch welche Icinga-Komponenten für mich ein Muss, eine nette Ergänzung oder doch eher ein Spezialfall sind, ist Teil meines Blogposts. Nebenbei beantworte ich dir hoffentlich auch die Frage, ob du dafür mittlerweile eine Icinga-Repository-Subscription brauchst oder nicht.

Wie installieren wir nun?

Bevor ich auf die Installation von Icinga eingehe, muss ich einen kleinen Exkurs einschieben und zwar zum Thema Agent. In meinen Augen gibt es kein agentenloses Monitoring, denn selbst wenn man SSH dafür her nimmt, nutzt man den eigentlichen Anmeldedienst als Monitoringagent und muss dafür etwas konfigurieren. Daher habe ich lieber einen dedizierten Agenten installiert und hier bietet die Nutzung von Icinga als Agent in meinen Augen die meisten Vorteile. Wir erhalten eine hohe Kommunikationssicherheit, Verfügbarkeit auf vielen Plattformen, einheitliche Konfiguration und keinen „Medienbruch“ durch externe Komponenten.

Daher möchte ich mit der Annahme starten, dass wir drei Arten von Installation haben. Zum einen das zentrale System, zum anderen die Agents und je nach Größe und Aufbau dazwischen noch Satelliten. Bei allen drei Varianten beantworte ich zudem die Frage, ob es sich aus meiner Sicht dabei um „Pet or Cattle“ handelt.

Auf dem Agent brauchen wir Icinga und eine gewisse Zahl Plugins für die lokalen Checks installiert. Zudem muss die Kommunikation mit dem übergeordneten System konfiguriert sein. In einer großen Umgebung wird die Zahl der Icinga-Agenten sehr schnell sehr groß und wir reden hier sicher von „Cattle“. Deshalb setzen wir hier auf ein gut konzipiertes Konfigurationsmanagement. Ich empfehle die Nutzung der offiziellen Puppet-Module oder Ansible-Collection anstatt etwas selber zu entwickeln. Wer diese Werkzeuge nicht für seine Windowssysteme nutzt, bekommt mit Icinga for Windows ein sehr gutes Hilfsmittel an die Hand.

Der Satellit dient üblicherweise nur dazu, die Last zu verteilen oder Netzwerkstrukturen abzubilden und kommt ohne Webinterface aus. Daher braucht es auch nicht viel mehr als bei einem Agent, wahrscheinlich nur kleine Anpassungen an der Konfiguration und mehr Plugins. Trotz der vermutlich überschaubaren Anzahl an Satelliten würde ich diese als „Cattle“ einordnen und wie Agents managen.

Beim zentralen System wird es dann doch etwas komplizierter. Neben den bisherigen Komponenten Icinga und den gewünschten Plugins braucht es die Datenbank als Schnittstelle und das Webfrontend für eine grafische Darstellung.
Als Freund des „Keep it simple (and) stupid“ würde ich sagen Hochverfügbarkeit nimmt uns die Virtualisierungsplattform ab, Lastverteilung bekommen durch Satelliten und Agents und die Kommunikation zwischen den verschiedenen Komponenten ist auf einem System am einfachsten und sichersten. So ein System kann aber entsprechend viel Ressourcenbedarf entwickeln und aus vielen Komponenten bestehen. Wer das vermeiden will, verteilt diese auf verschiedene Systeme und gewinnt damit die Möglichkeit, alles separat zu skalieren. Dann sind wir aber schnell weit weg von simpel! Egal wie die Umsetzung am Ende aussieht, hier haben wir ein System oder einen Verbund aus Systemen, das ich als „Pet“ betrachten würde.
Um diese Komponenten zu installieren, gibt es für mich drei valide Installationswege: manuell, semi-manuell mit dem Icinga-Installer oder auch automatisiert.

Der manuelle Weg ist für viele wohl der transparenteste und da man ja eine neue Software kennenlernt und noch nicht alle Stellschrauben kennt, auch der naheliegendste. Aber wer diesen Weg einmal beschritten hat, merkt hier schnell, dass der große Vorteil von Icinga, die Flexibilität und Integration bestehender Lösungen sich bei der Installation in einen Nachteil verwandelt. Schließlich muss ja genau jede dieser Komponenten installiert und das dafür notwendige Stellschräubchen gedreht werden.

Vollständig automatisieren ist zum Einstieg aber auch schwierig, daher stellt der Icinga-Installer von NETWAYS einen sehr guten Mittelweg dar. Vor allem verbaut man sich nicht die spätere Automatisierung. Auch gut geeignet ist der Weg als mögliche Restore-Möglichkeit oder zum einfacheren Bereitstellen von Testumgebungen. Als Puppet-Nutzer hat man sogar noch den Vorteil, dass der Installer auf genau diesen Modulen aufbaut und das Wissen bereits vorhanden ist oder ausgebaut werden kann.
Ein weiterer Vorteil des Icinga-Installers sowie der Puppet-Module, Ansible-Collection und Icinga for Windows ist, dass nach einem Update eventuell notwendige Änderung direkt vorgenommen werden. Somit wird das einfache Update über Pakete noch mal vereinfacht.

Welche Komponenten sollte mein Icinga haben?

Datenbank

Was installiere ich nun am besten auf dem zentralen System? Die erste Komponente ist natürlich die Datenbank. Hier stehe ich vor zwei wichtigen Entscheidungen. Zum einen, welches Datenbankschema ich nutzen will, den bisher verwendeten IDO oder die neue IcingaDB. Zum anderen, ob ich MySQL oder PostgreSQL als Backend einsetze. Bei einer neuen Installation würde ich ganz klar auf die IcingaDB setzen! Einzige Ausnahme wäre eine andere Komponente spielt noch nicht sauber mit. Aber auch hier wäre mein Ansatz eher über Issues diese Komponente dazu bewegen, IcingaDB zu unterstützen, also noch mit IDO zu starten. Als Backend würde ich MySQL empfehlen, was vor allem an der Verbreitung im Icinga-Umfeld liegt. Es ist einfach das häufiger genutzte und damit auch deutlich mehr getestete Backend. Wenn in Deinem Unternehmen jedoch PostgreSQL genutzt wird, gibt es aus meiner Sicht keinen Grund, hier nicht auf das gewohnte Backend zu gehen.

Frontend

Die zweite Komponente ist das Frontend, besser bekannt als Icinga Web. Hier brauchen wir neben den entsprechenden Abhängigkeiten auf alle Fälle noch das zusätzliche Modul Icinga DB Web, da wir uns für IcingaDB als Backend entschieden haben.

Alle Icinga-Komponenten die ich nachfolgend aufzähle, sind optionale Module. Dennoch will ich dir manche davon noch empfehlen.

Optionale Module

Als erste Entscheidung bei den „nicht-grundlegenden“ Modulen werfe ich die Frage nach dem Icinga Director in den Raum. Ich muss sagen, für mich ist das grafische Konfigurationstool fast schon gesetzt. Zum Warum, wieso, weshalb kommt in Kürze ein weiterer Blogpost von mir. Darum gibt es von mir hier nur den Hinweis, dass Du diese Entscheidung möglichst früh treffen solltest. Und zwar weil eine nachträgliche Migration einiges an Arbeit, aber auch Umdenken erfordert, die man sich so sparen kann.

Die erste Erweiterung, die ich persönlich als notwendig erachte, ist die Ergänzung um eine Graphing-Lösung. Ohne diese zeigt einem Icinga zwar sehr schön den aktuellen Status an, mit einem Graphing-Modul erhält der Status aber noch mal deutlich mehr Kontext. Mein Beispiel dafür ist immer die volllaufende Festplatte, bei der ich dank der Graphen leicht sehe, ob akuter Handlungsbedarf besteht oder der nächste Wartungstermin reichen wird. Ich bin zwar persönlich immer noch großer Fan der Einfachheit von Graphite, aber InfluxDB ist hier einfach die modernere Lösung und braucht auch deutlich weniger Pflege. Baut man also einen neuen Datenpool auf, empfehle ich InfluxDB und würde es sogar mit auf dem zentralen System installieren. Gibt es in Deinem Unternehmen schon eine bestehende Graphing-Lösung würde ich Icinga an diese anbinden, sodass man vielleicht später Daten korrelieren kann. Als Frontend zu den Daten ist aus meiner Sicht Grafana die erste Wahl. Das dazugehörige Modul kann problemlos in Icinga Web integriert werden.

Für weitere empfehlenswerte Erweiterungen hat man zu Beginn noch nicht genug Daten, daher empfehle ich Reporting, die Modellierung von Geschäftsprozessen oder das Cube-Modul für eine spätere Runde aufzusparen.

Heißt ich würde eher schauen, mit welcher Integration kann man vielleicht punkten oder mit welchem Eye candy Benutzer überzeugen. Hier können die Entscheidungen sehr unterschiedlich ausfallen!
Das Map-Modul hat mir schon oft freudige Anwender beschert, da plötzlich eine ganz andere Sicht auf die Umgebung gegeben ist. Auch über die vSphere-Integration hab ich schon gehört, dass diese übersichtlicher sei als die eigentlich vSphere-Oberfläche. Schau dich da also mal bei den Modulen um, meistens finden meine Kunden etwas, das sie direkt oder zumindest in einer späteren Ausbaustufe haben wollen.

Bevor wir zum letzten Themenbereich kommen, will ich auf ein Modul noch gesondert eingehen: Director-Branches, weil es nur mit der Icinga-Repository-Subscription verfügbar ist. Da es den Director erweitert, kommt es eh nur infrage, wenn Du dich für die grafische Konfiguration entschieden hast.
Bei der Erweiterung stellt sich die Frage, wie viele Editoren hat Deine Konfiguration bzw. wie viele soll sie haben. Wenn Du hier einen Nutzerkreis größer den eigentlichen Monitoringadministratoren anstrebst, ist das Modul auf alle Fälle einen Blick wert. Es erweitert den Icinga Director um Git-ähnliche Branching-Workflows und Review-Prozesse. Das erhöht zwar in gewissem Maß die Komplexität und ist somit nicht für jeden das Richtige, verhindert aber Situationen nach dem Motto „Viele Köche verderben den Brei“.

Die Frage nach der Subscription

Zum Abschluss nun noch meine Antwort auf die Frage „Brauche ich die Icinga-Repository-Subscription?“. Das ist eine sehr berechtigte Frage, zu deren Beantwortung ich hier ein paar Überlegungen mit Dir teilen will.
Wenn Dir der Community-Support reicht, suchst Du Dir die dazu passende Distribution aus, also vermutlich Debian.
Director-Branches kann jedoch für einen bestimmten Benutzerkreis hilfreich und den Preis einer Subscription wert sein. Ob Du und Dein Team dazu zählen kannst im vorangehenden Abschnitt noch mal prüfen.
Hast Du eine Umgebung, in der Du aber Red Hat Enterprise Linux oder SUSE Linux Enterprise Server überwachen möchtest und den Agenten nutzen, aber nicht selber paketieren willst, kannst Du eine Repository Subscription von Icinga erwerben.

Eine andere, aus meiner Sicht lohnendere Möglichkeit ist die Nutzung einer NETWAYS Support-Subscription, die Du auch über NETWAYS als erfahrenen Icinga-Partner bekommst.
Die Variante „Basic“ beinhaltet zum Repository-Zugriff bereits eine unlimitierte Anzahl von Support-Anfragen, allerdings mit Reaktionszeiten von 8 Stunden. Wer sich nicht solange gedulden kann oder will schaut besser auf die Variante „Premium“ mit kürzeren Reaktionszeiten und zusätzlich einem Tag Remote-Consulting für die jährliche Review der Umgebung. Für Umgebungen in denen das Monitoring eine wirklich kritische Komponente ist, gibt es noch die Variante „Enterprise“ mit Support rund um die Uhr und zwei Tagen Remote-Consulting. Wer es individueller braucht, wendet sich direkt an meine Kollegen vom Vertrieb.
Der Vorteil jeder Variante, Du hast nicht nur Zugriff auf die Software sondern immer direkt eine Ansprechperson.

Schlusswort

Im Rahmen meiner beiden Beiträge habe ich versucht, den passenden Detailgrad zu finden, sie nicht unnötig in die Länge zu ziehen, meine Empfehlungen aber nachvollziehbar darzulegen. Ob mir das gelungen ist, überlasse ich meinen Leser:innen zu beurteilen ;-). Zumindest hoffe ich meine Entscheidungen und welche Beweggründe zu diesen führen, sind für Dich nachvollziehbar und hilfreich.
Falls Du nun 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.