Best Practices: Plugin-Verwaltung

Hi zusammen,
mal eine Frage zu Plugins. Wie handhabt ihr die Verwaltung von Plugins auf den Zielsystemen. Also deployments und updates von Plugins. Vor allem interessieren mich Lösungen, ohne die Bakery. Arbeitet ihr mit ansible und dann mit plugin-bezogenen Inventory files?
Und wie macht ihr das, wenn ihr zig verschiedene Python-s auf den Zielsystemen habt und dementsprechend ggf. plugins anpassen müsst, damit diese laufen. Habt ihr diese Sonderlocken dann auch in eurem Verfahren berücksichtigt?

Danke für Feedback zu dem Thema!
Christian

PS: es geht um mehrere tausend Zielsysteme…

Ich mache eine Mischung aus Bakery & Deployment mit Ansible. Über die Bakery deployen wir eine große Menge an Checks, die auf mehr als einer Maschine ausgeführt werden sollen. Wir versuchen hier, die Anzahl der unterschiedlichen zu backenden Agents möglichst klein zu halten, sodass wir lieber Plugins zu viel ausliefern. Hintergrund ist, dass wir mal in einer Situation waren, in der wir über zehn Minuten die Bakery laufen hatten, und das skaliert einfach nicht…

Für selbstgeschriebene Checks, die nur auf einzelnen Systemen laufen sollen, implementieren wir sie so, dass sie immer über Agents ausgerollt werden können, in der Standardkonfiguration aber schlicht nichts tun. Via Ansible kommt dann eine dazugehörige Konfigurationsdatei auf diejenigen Hosts, auf denen der Check benötigt wird. Auch das ist eine Maßnahme, um die Anzahl unterschiedlicher Agent-Konfigurationen im Zaum zu halten.

Bzgl. Programmiersprachen: wir nutzen wenig Python, viel Perl & Shell. Da wir auf 99% aller Hosts das initiale Deployment des Agents selbst via Ansible machen, installieren wir dann auch gleich noch die benötigten Programme, die die Checks benötigen (zsh, jq, diverse Perl-Module, den richtigen netcat-Flavor etc. etc.). Andere Perl-Module, die im Laufe der Zeit hinzu kommen, deployen wir oftmals über den Agent (das geht bei vielen kleineren Perl-Modulen ziemlich gut, weil deren Ordnerstruktur einfach mit nach z.B. /usr/lib/check_mk_agent/perl-modules deployt werden kann & die alle auch mit super alten Perl-Versionen sehr, sehr gut funktionieren — das Perl-Ökosystem ist da harmloser als das von Python).

Bei Ansible selber nutzen wir eher weniger verschiedene Inventorys, sondern steuern das Deployment über verschiedene Gruppen- & Host-Variablen. Aber hier ist Ansible so flexibel, dass man nahezu beliebige Konstrukte umsetzen kann.

Zur Einordnung: wir haben grob 1.350 Hosts in der Überwachung auf über 50 Sites. Neben verschiedenen Windowsen haben wir Debian, Ubuntu, Univention Corporate Server (basiert auf Debian), CentOS, Rocky etc. als Hosts in sehr unterschiedlichen Versionen, bis runter zu Ubuntu 14.04, was inzwischen zehn Jahre alt ist.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.