Seite wählen

NETWAYS Blog

OpenSearch: Dashboards Plugins einfach installieren

OpenSearch ist in seiner Vanilla Version schon sehr umfangreich. Doch erst mit den OpenSearch Plugins kannst du deine Experience personalisieren und das Maximum aus dem Elastic-Fork herausholen.
Eines vorab, bevor ich richtig ins Thema einsteige: die Geschwindigkeit, in der sich das Projekt aktuell weiterentwickelt ist extrem positiv. Deshalb kann man aktuell davon ausgehen, dass die Plugins beim Release des Blogposts noch mal besser geworden sind oder es noch mehr Regeln geben wird.

OpenSearch Plugins für Backend und Dashboards

Nun aber hinein ins Thema OpenSearch Plugins!
Hier muss direkt zwischen dem Backend „OpenSearch“ und den OpenSearch Dashboards unterschieden werden.

Das Backend kommt schon pre-Bundled mit einer Menge nützlicher Plugins. Diese vorinstallierten Plugins kannst du dir mit einem einfachen Befehl anzeigen lassen:

/usr/share/opensearch/bin/opensearch-plugin list

opensearch-alerting
opensearch-anomaly-detection
opensearch-asynchronous-search
opensearch-cross-cluster-replication
opensearch-geospatial
opensearch-index-management
opensearch-job-scheduler
opensearch-knn
opensearch-ml
opensearch-neural-search
opensearch-notifications
opensearch-notifications-core
opensearch-observability
opensearch-performance-analyzer
opensearch-reports-scheduler
opensearch-security
opensearch-security-analytics
opensearch-sql

Im Gegensatz dazu steht das Frontend OpenSearch Dashboards. Hier gibt es out-of-the-box keine Plugins und du kannst, darfst oder musst hier selbst Hand anlegen. Dadurch haben Anpassungen an deine individuellen Bedürfnisse jedoch nur die Grenze der Software.

Auch wenn du alle Plugins selbst installieren musst, ist dort so schnell viel in Bewegung gekommen, dass es leicht geworden ist, Plugins zu installieren. Und das Ganze ohne sich um Versionen / Git-Repositories kümmern zu müssen.

WICHTIGER HINWEIS: Es wird NICHT empfohlen, nachfolgende Skripte als Root auszuführen. Der Vollständigkeit halber habe ich die Flagge als Kommentar auskommentiert im Skript stehen lassen, solltest du das doch tun wollen.
Zum Installieren von Plugins habe ich mir folgendes „./deploy-plugins.sh„-Skript gebaut, das einfach mit dem Pfad der Binärdatei eine Installation über die Namen der Plugins macht:

#!/bin/bash

PLUGINS=(
alertingDashboards
anomalyDetectionDashboards
customImportMapDashboards
ganttChartDashboards
indexManagementDashboards
mlCommonsDashboards
notificationsDashboards
observabilityDashboards
queryWorkbenchDashboards
reportsDashboards
searchRelevanceDashboards
securityAnalyticsDashboards
securityDashboards
)

for PLUGIN in "${PLUGINS[@]}"
do
    /usr/share/opensearch-dashboards/bin/opensearch-dashboards-plugin install $PLUGIN # --allow-root
done

Mit diesem kleinen, von mir geschriebenen Skript ist es schnell und unkompliziert möglich, mehrere OpenSearch Dashboard Plugins gleichzeitig zu installieren.

Da man Plugins in den meisten Fällen nicht nur installieren, sondern auch einmal entfernen will, habe ich dazu ebenfalls ein kleines Skript geschrieben. Es hört auf den Namen „./remove-plugins.sh„:

#!/bin/bash

PLUGINS=(
alertingDashboards
anomalyDetectionDashboards
customImportMapDashboards
ganttChartDashboards
indexManagementDashboards
mlCommonsDashboards
notificationsDashboards
observabilityDashboards
queryWorkbenchDashboards
reportsDashboards
searchRelevanceDashboards
securityAnalyticsDashboards
securityDashboards
)

for PLUGIN in "${PLUGINS[@]}"
do
    /usr/share/opensearch-dashboards/bin/opensearch-dashboards-plugin remove $PLUGIN # --allow-root
done
systemctl restart opensearch && systemctl restart opensearch-dashboards

Mit dem letzten Befehl startest du OpenSearch und OpenSearch Dashboards neu. Nur so können wir sichergehen, dass die Installation oder Deinstallation von Plugins auch angenommen wird.

OpenSearch Dashboards: Plugin Überblick

Wenn du mein Skript verwendet hast, um Plugins für das Dashboard zu installieren, solltest du jetzt eine größere Seiten-Leiste haben als zuvor. Denn irgendwie musst du ja auch auf die Plugins zugreifen.
Damit du weißt, welche OpenSearch Plugins ich in meinem Skript verwende, folgt hier nun für jedes Plugin eine kurze Beschreibung sowie ein Screenshot, um dir die visuelle Darstellung vorzustellen.

Query Workbench:
Mit diesem Plugin kannst du in SQL und PPL Abfragen machen. Interessant finde ich vor allem die Explain-Funktion, die die Darstellung im JSON-Format zurückgibt.

Reporting:
Mit Reporting lassen sich bequem alle relevanten Daten, zum Beispiel deine individuell angelegten Dashboards, aber auch viele weitere Daten exportieren. Der Export kann natürlich auch mit Schedulern automatisiert werden.
Ich kann mir vorstellen, das exportiere Reportings in den Formaten PDF und PNG in vielen Business-Umgebungen eine sinnvolle Erweiterung darstellen.

Alerting:
Hiermit kannst du für alle Parameter, die du überwachst, etwa Anomalien in deinen Datensätzen, Schwellwerte setzen und Aktionen auslösen lassen. Stark sind hier die vielen Möglichkeiten, die geboten werden. Du kannst dich zum Beispiel benachrichtigen lassen, wenn ein „whoami“ eingegeben wird oder ein Icinga2Host ausfällt! Die Grenzen sind sehr weit gefasst, dass sicher auch für deinen Use Case das passende Alerting einstellbar ist.

Stark sind vor allem mitgelieferten Notification Channels und das freundliche UI!

Anomaly Detection:
Hier wird der Nutzer mit mehr Neugier, Statistikwissen und tieferer Kenntnis seiner Daten (sowie, deren Felder) besseren Nutzen rausholen können.
In meinem Screenshot siehst du ein kleines Beispiel der Anomalien der Event Codes eines Active Directories der letzten 30 Tage. Solche Möglichkeiten sind natürlich genial für alle Admins, Data Scientists oder Analysten die projizieren und erkennen wollen:

Maps:
Richtig spannend wird es, wenn dir Geodaten zur Verfügung stehen. Im OpenSearch Dashboards Plugin Maps kannst du dann aus mehreren visuellen Layern auswählen. Damit kann man schnell beeindrucken und mit den unterschiedlichen Layern sogar seine präferierte Ansicht wählen.

Security Analytics:
Vielleicht hast du mittlerweile auch ähnliche Gedankengänge wie ich zum Zeitpunkt, als ich OpenSearch getestet habe. Einer der prominentesten Gedanken bei mir war „Okay cool. Und das ist wirklich alles umsonst?“. Die einfache Antwort: Yes!

Aber als ich dann bei Security Analytics mit einem Klick einen Detector anlegen wollte, war ich dann einfach nur (positiv) schockiert. Hier sind massig Sigma Regeln eingebunden und das komplett umsonst!
Allein die Auswahl an Providern ist der Wahnsinn.

Fast 1600 Sigma-Regeln für Windows?! Wow!

Die Auswahl an Linux-Regeln ist auch stark und auch wenn es nicht viele sind, scheint man sich mit der Auswahl sehr viel Gedanken gemacht zu haben, um eine breite Trickkiste abzufangen:

Also ist hier alles perfekt? Sehr gut, ja, aber nicht perfekt. Denn ein kleiner Haken im Vergleich zu Graylog und Elastic, die fertig eingerichtet kommen, ist, dass du die Detector-Regeln erst mal an die Felder der Indices anpassen musst. Dafür benötigst du schon einiges an Wissen und Zeit. Das heißt aber nicht, dass das so bleiben muss / wird!

Kaum am Laufen und minimale Anpassungen später hatte ich direkt einen simulierten Treffer in einem Honeypot-AD von mir:

Index Management & Snapshot Management:
Snapshots sind für viele Admins und Entwickler wichtig. Ebenso wichtig sind Rollups mit denen man abbilden kann, wie lange die Daten der einzelnen Indizes verwahrt werden sollen.
In meinem Anwendungsbeispiel lege ich mir einfach einen neuen Index an und schiebe den alten dort hinein. Das Feld ist zusätzlich noch zeitgesteuert, womit man sehr viel Customization erhält:

Search Relevance:
Mit diesem Plugins sich verschiedene Suchen vergleichen. Ziemlich hilfreich, um schnell Daten, etwas Felder aus verschiedenen Indizes miteinander zu vergleichen. Das setzt natürlich voraus, sich einmal mit der OpenSearch Query DSL auseinanderzusetzen.

Maschine Learning:
Um dieses Plugin einzusetzen, willst du genug Cluster haben, mit genug CPU & GPU Power. Dabei ist auch die Frage, wo du die Arbeit verrichten lassen willst, denn Logging braucht so schon genug Leistung und du brauchst auch extra Libraries.
Den Einsatz dieses OpenSearch Dashboard Plugins solltest du also etwas genauer planen. Auch Maschine Learning Modell-Deployments habe ich im Rahmen meiner OpenSearch Analyse genauer unter die Lupe genommen. Dieser Abschnitt würde jedoch den Rahmen dieses Blogbeitrags sprengen. Deshalb werde ich zum Thema OpenSearch Machine Learnung einen gesonderten Blogpost schreiben.

Ich hoffe, ich konnte dir mit diesem Blogpost ein paar Beispiele für die vielfältigen Plugins in OpenSearch zeigen und freue mich auf dein Feedback!

Icinga 2 Best Practice Teil 6: Service-Checks auf Agenten schedulen

In Teil 1 dieser Blogserien beschäftigten wir uns mit Zonen, Agenten und wie man zentral angetriggert Plugins auf diesen Agenten ausführt. Nun im aktuellen Teil soll es darum gehen, das einplanen und ausführen dem Agenten selbst zu überlassen, damit werden auch während eines Verbindungsausfalls weiter Daten gesammelt und später, wenn die Verbindung wieder besteht, nachträglich übertragen.
In dem hier folgenden verdeutlichen wir, wie dies zu konfigurieren ist, mit einem Beispiel von einer Zone master, einer globalen Zone global-templates und einer Zone zu einem Beispiel Agenten agent.example.org.
Die Zonen- und Endpoint-Definitionen des Agenten auf Seite des Masters müssen in einer Datei in der Master-Zone oder in zones.conf hinterlegt werden. Leider ist es hier nicht möglich die jeweiligen Host-, Zonen- und Endpoint-Objekte in einer Datei zusammen zufassen, da wir das Host-Objekt agent.example.org zum Agenten selbst synchronisieren müssen und diese Definition in der Agenten-Zone abgelegt sein muss, z.B. in der Datei zones.d/agent.example.org/agent.conf:

object Host "agent.example.org“ {
 import "generic-host"
 address = "10.0.10.42"
 zone = get_object(Zone, name).parent
 vars.os = "Linux“
}

Durch die Ablage an genau diesem Ort, wird das Objekt zum Agenten synchronisiert. Mit setzen des Attributes zone auf die eigene Parent-Zone sorgen wir jedoch wieder dafür, dass das Host-CheckCommand sowie alle an diesen Host gebundenen Services auf einem Endpoint der Parent-Zone ausgeführt werden, hier die Zone master.
Damit wird der hostalive vom Master ausgeführt, was gewünscht ist, da sonst der Host seine Erreichbarkeit von sich selbst aus testen würde. D.h. alle Services, die auf den Agenten über das Netzwerk zugreifen sollen, bleiben wie sie sind und wir müssen keine Anpassungen vornehmen. Ganz im Gegensatz zu Services, die ein Plugin lokal auf dem Agenten ausführen sollen.

apply Service "load“ {
 import "generic-service“
 check_command = "load“
 if ( get_object(Zone, host.name) ) {
   zone = host.name
 }
 assign where host.vars.os == "Linux"
}

Auch Objekte vom Typ Service besitzen das Attribut zone mit dem wir hier nun die umgekehrten Weg beschreiten, existiert zum Host eine Zone selben Namens, wird die Zone zur Ausführung des zugeordneten Plugins in die eigene Agenten-Zone verlegt.

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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 3: Plugins

Heute gehen wir der Frage nach wann und wie Plugins installiert werden sollten, was besonders wichtig bei Systemen mit icinga Benutzern zum Gegensatz nagios zu beachten ist. Auf z.B. RedHat-Systemen besteht das Problem, dass der Prozess Icinga 2 unter dem Benutzer icinga läuft, aber unteranderem das Plugin check_icmp oder auch check_dhcp nur vom Benutzer root oder einem Mitglied der Gruppe nagios mittels suid-Bit ausgeführt werden können.

# ls -l /usr/lib64/nagios/plugins/check_icmp
-rwsr-x---. 1 root nagios ... /usr/lib64/nagios/plugins/check_icmp

Das Ändern der Gruppenzugehörigkeit mit Puppet ist wenig hilfreich, da leider bei einem Update des Paketes nagios-plugins die alten Berechtigungen wieder hergestellt werden. Man könnte nun natürlich den Benutzer icinga und das Paket nagios-plugins explizit vor der Klasse icinga2 managen, verliert dann jedoch die Paketkontrolle über die uid und muss das Home-Directory, Shell und weitere Eigenschaften per Hand in Puppet entscheiden. Klarer ist die Methode genau diese Sachen dem Paket zu überlassen und erst danach icinga in die Gruppe nagios aufzunehmen.

yumrepo { 'icinga-stable-release':
  ...
}
->
package { [ 'icinga2', 'nagios-plugins' ]:
  ensure => installed,
}
->
user { 'icinga':
  groups => [ 'nagios' ],
}
->
class { '::icinga2':
  manage_package => false,
}

Um dieses Vorhaben umzusetzen ist es erforderlich die benötigten Repositories zuerst einzubinden, hier mit yumrepo angedeutet, dann die Pakete zu installieren, den Benutzer anzupassen und erst dann die Klasse icinga2 zu deklarieren.

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.

Monitoring Plugins in Go

Auf Twitter hat Jan Schaumann vor Kurzem begonnen eine Liste aufzustellen mit Dingen, die jeder Sysadmin in seinem Leben schon mindestens ein mal getan hat. Darunter zählen Sachen wie einen Parser für den ifconfig Befehl zu schreiben oder unvollständige Regexes für IP Adressen zu basteln. Beim Durchgehen dieser Liste habe ich mich immer wieder selbst ertappt. Es ist erschreckend, wie viele von diesen Dingen auf einen selbst zutreffen. Dennoch ist es sehr amüsant zu lesen.
Bei Netways arbeiten wir sehr viel im Bereich Monitoring. So ist es kein Wunder, das ich bei den Dingen die jeder Sysadmin schon mal getan hat, sofort auch an dieses Thema denken musste. Lange muss man da auch nicht überlegen: Jeder Sysadmin hat mindestens schon ein mal in seiner Karriere ein monitoring Plugin geschrieben. Das gehört einfach dazu und selbst DevOps wird uns vermutlich nicht davor bewahren.
Das Schreiben von monitoring Plugins ist auf den ersten Blick ein ziemlich einfaches Thema. So ein Plugin muss einen Rückgabewert von 0, 1 oder 2 liefert und im besten Fall einen Text ausgeben, der den Zustand beschreibt. Damit wären schon mal alle Grundvoraussetzungen gegeben. Weil es eben so einfach ist, gibt es auch so viele von diesen Plugins. Sie werden in nahezu jeder Programmiersprache geschrieben. Manche Plugins sind umfangreich mit vielen Optionen und noch mehr Performance Daten in der Ausgabe. Andere wiederum bestehen nur aus wenigen Zeilen und erfüllen einen einzigen speziellen oder simplen Zweck.
Was mich bei monitoring Plugins schon immer gestört hat, ist das Deployment von jenen. Je nachdem in welcher Sprache das Plugin entwickelt ist, müssen mit cpan, gem, pip, npm, pear, composer oder andern Package Managern Abhängigkeiten nachinstalliert werden. So richtig lästig wird das bei ein paar Hundert Plugins für ein paar Tausend Server mit unterschiedlichen Distributionen. Sind Windows Systeme dabei, … ach davon fang ich garnicht erst an.
Welche Lösung gibt es also dafür? Noch keine fertige, zumindest meiner Meinung nach. Selbst Configuration Management löst das Problem nicht ganz. Um das vernünftig zu machen, müsste man ja seine 3-Zeiler Plugins packetieren und vernünftige Module oder Cookbooks schreiben, die das dann auf die Systeme ausrollen. Bestenfalls natürlich auf jedes System nur die Plugins die dort auch wirklich hin gehören. Seitdem ich mich bezüglich eines Projekts aber mit der Programmiersprache Go auseinander setze, beschäftigt mich ein anderer Ansatz um das Problem zu lösen: was wäre, wenn so ein Plugin gar keine Abhängigkeiten hat?
Go ist eine Programmiersprache, deren Wurzeln bei C liegen. Sie ist dementsprechend auch keine Scriptsprache wie Ruby oder Python, fühlt sich manchmal aber trotzdem so an. Das führt dazu das Leute wie ich, die aus der Scripting Welt kommen, sich sehr schnell wohl fühlen mit Go. Ob Go eine objektorientierte Sprache ist, da scheiden sich die Geister. Objekte im klassischen Sinne gibt es nicht, zumindest werden sie nicht so genannt. Betrachtet man es im Detail, kann man aber nachvollziehen warum es Stimmen gibt, die Go als objektorientiert bezeichnen.
Wie bei anderen Sprachen auch gibt es bei Go viele Libraries die verwendet werden können, sie werden aber Packages genannt. Der in Go geschriebene Code muss kompiliert werden. Ein großer Vorteil dabei ist, dass die entstandenen Binaries standardmäßig statisch gelinkt sind. Das heißt im Umkehrschluss es muss nichts nachinstalliert werden mit gem, pip, cpan usw. Alles steckt schon in dieser einen Binary. Sicherlich lässt sich dasselbe auch mit C, C++ oder anderen Sprachen erreichen. Keine ist aber so einfach und einsteigerfreundlich wie Go. Das zählt für mich als sehr großer Vorteil, schließlich werden diese Plugins oft von Sysadmins entwickelt, deren Hauptbeschäftigung nicht das Programmieren ist.
Statisch gelinkte Binaries könnten also das Problem der Abhängigkeiten lösen. Spinnt man die Idee weiter, könnte man mit einem „monitoring plugin“ Package für Go ein Framework schaffen mit dem einheitliche Plugins entwickelt werden. Eine tolle Idee, wenn ihr mich fragt. Das Problem des packetierens lässt sich übrigens wunderbar mit fpm lösen, dazu aber vielleicht ein anderes Mal mehr.
Mein Aufruf an dieser Stelle also: Schreibt eure monitoring Plugins in Go, denn ich möchte mich nicht stundenlang damit Beschäftigen sie zum Laufen zu kriegen!

Blerim Sheqa
Blerim Sheqa
COO

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Inzwischen ist Blerim als COO für Icinga tätig und kümmert sich dort um die organisatorische Leitung.

Monitoring Plugins 2.0 Release

nagios-plugins-upgradeWas lange reift, wird endlich gut – wer im Jänner mitbekommen hat, dass die ursprünglichen Nagios Plugin Entwickler vom Trademark-Besitzer rausgekickt worden sind, und ihre Software nunmehr unter dem Namen „Monitoring Plugins“ an Mann/Frau ausliefern, hat lange auf dieses Release warten müssen. Nun ist es aber endlich da – Monitoring Plugins 2.0. Aktualisierte Pakete gibts hoffentlich bald, und jedem sei ans Herz gelegt, die vorherigen Nagios Plugins aus dieser vertrauenswürdigen Quelle zu aktualisieren.
Icinga 2 ist mit den Monitoring Plugins vollständig kompatibel, und liefert mit den Plugin Check Commands sogar erste Templates out-of-the-box die einfach weiterverwendet werden können. Wie man das macht, gibts unter anderem auch in unserer Icinga 2 Schulung zu bestaunen.
 
(Bild (c) memegenerator.net)