Performancedaten von Services in dashing-icinga2 anzeigen

This forum was archived to /woltlab and is now in read-only mode.
  • Hallo zusammen!


    Vorab schonmal ein großes Danke an dieses Forum, auch bevor ich mich hier registriert habe habe ich schon einiges an Tipps und Hinweisen aus den Postings hier gezogen. Heute möchte ich mich mit einem Problem an euch wenden, zu dem ich leider noch nichts finden konnte.


    Mein Ziel:

    Einige der Performancedaten unserer VM-Hosts sollen in list-Widgets auf dem dashing-icinga2 Dashboard angezeigt werden. Angedacht sind hier Auslastung von RAM, CPU und Disk I/O.


    Die derzeitige Situation:

    In unserer von Windows Server 2012 R2 dominierten Serverlandschaft steht seit ein paar Wochen ein CentOS 7 Server mit meiner Icinga2 Installation. Diese besteht aus:

    • Icinga2 in der Version 2.6.0 aus den EHEL Repos, installiert nach dem Leitfaden der Dokumentation
    • Icinga Web 2 in der Version 2.4.1, ebenfalls aus den Repos
    • dem Director Modul in Version 1.2, installiert wie hier beschrieben
    • dem Plugin "check_wmi_plus", mit dem die Windows-Hosts auch ohne Client einfach via WMI geprüft werden können
    • dashing-icinga2, in der Version, die am 18.01.17 im Github-Repo lag, und nach der dortigen Anleitung installiert.

    Da ich mich ohne Vorerfahrung in Sachen Icinga und Dashing in dieses Projekt gestürzt habe, habe ich das bisschen das ich weiß unterwegs erlernt. Das dabei entstandene Konstrukt ist daher wohl weit entfernt von "best practices", aber es funktioniert und hat durchaus Freude bereitet.


    Das Problem:

    Das bestehende Dashboard soll wie gesagt erweitert werden. Mein Ruby ist allerdings etwas eingerostet, daher habe ich arge Probleme mit der Erstellung der neuen Jobs. Aus dem, was ich in den bestehenden Dateien jobs/icinga2.rb und test/icinga2.rb lesen konnte, habe ich versucht einen eigenen Job zu erstellen, der erstmal testweise die Services abfragen sollte, bevor ich an die Performancedaten gehe. Aber sobald meine Ruby Datei in jobs/ liegt, kommt Dashing beim Neustart nicht wieder hoch.


    Mein Script (was fast ausschließlich eine Kopie des Test-Scripts ist):


    Der Fehler:


    Hat jemand einen Ansatzpunkt für mich? Mit etwas Glück reicht mir schon ein Hinweis auf eine Dokumentaion/Anleitung für die lib/icinga2.rb Bibliothek oder eine Erklärung, wie die bisherigen Jobs funktionieren. Falls einer von euch aber schon einen fertigen Job für Performancedaten herumliegen hat, den ich für meine Bedürfnisse anpassen darf, sage ich natürlich auch nicht nein.

    Have a nice day,

    Christian

  • from here:

    Try installing node:

    $ sudo apt-get install node

    Your filter breaks your code. My workaround:


    Code
    1. 11c11
    2. < serviceFilter = "service.name == check_wmi_driveio"
    3. ---
    4. > serviceFilter = "match(\"check_wmi_driveio*\",service.name)"

    Results in the below screenshot (hope that this is expected...)

  • Hallo,


    vielleicht habe ich mich nicht ganz klar ausgedrückt, der Start von Dashing hat ohne mein eigenes Rubyscript funktioniert, $ sudo apt-get install node hilft mir also nicht weiter (zumal CentOS auch nicht apt sondern yum verwendet). Der Hinweis auf den Filter hat aber geholfen. Wie zu erwarten werden nun bei allen Servern Nullen für "OK" angezeigt:



    Der Vollständigkeit halber daher auch nochmal der aktualisierte Code:


    Das Checkergebnis "OK" ist an der Stelle zwar richtig, aber war nicht mein Ziel. Am Ende sollen wie gesagt Performancedaten angezeigt werden. Ich habe daraufhin ein wenig in der Doku geblättert und diese so interpretiert, dass diese über die normale API gar nicht abgefragt werden können. Allerdings bin ich auf das Feature perfdata gestoßen und habe es aktiviert:

    # icinga2 feature enable perfdata

    $ systemctl restart icinga2

    Nun habe ich unter /var/spool/icinga2/perfdata/ meine Performancedaten in Textfiles. Als nächstes werde ich also einen Job für Dashing schreiben, der diese Dateien auswertet und in einem Tabellen-Widget anzeigt.

    Have a nice day,

    Christian

  • Guck dir mal die Ausgabe des Service im IcingaWeb2 an. da ist schon verdammt viel schönes dabei.

    Und das läuft alles über die API.


    Möglicherweiuse kommst du doch um perfdata herum.

  • Im Dictionary attrs gibt es das Array Performance Data, da musst du wohl drann:

  • Davon abgesehen ist der Test-Runner nur hilfreich, wenn du ihn lokal ausführst. Vielleicht schmeiss ich ihn auch wieder weg, und verwende RSpec-Tests.


    Die Performance-Daten kriegst du bereits gratis in den Host- und Service-Objekten, die etwa die Methode getServiceObjects() liefert. Du kannst das aber auch umbauen und dir etwas eigenes stricken. Ist bloss Ruby-Code der die API abfrägt.


    Jedes Host/Service-Objekt besitzt das Attribut "last_check_result" wie sru schon richtig erklärt hat. Dort darunter verstecken sich die Performance-Daten, die du programmatisch via Key rausziehen kannst (vorausgesetzt diese sind nicht nil).


    Code
    1. host_stats = []
    2. hostObjs.each do |host|
    3. host_stats.push({ "label" => host["attrs"]["__name"], "value" => host["attrs"]["last_check_result"] })
    4. end


    Allerdings finde ich die Strings aus den Performance-Werten nicht gerade schön darstellbar in einer Listing-Kachel. Deswegen habe ich darauf in den Dashboards auch verzichtet. Da finde ich eine Kachel mit Grafana-Dashboards deutlich reizvoller, da du bei Metriken eigentlich immer einen zeitlichen Verlauf sehen willst.


    Dein initialer Fehler mit "thin not found" liegt an deiner Installationsweise. Vermutlich hast du kein "bundle install" gemacht, und der thin-Server liegt nun woanders als sich Dashing das erwartet. Da würde mich generell interessieren, wie du Dashing als Gem installiert hast, inklusive der anderen Paket-Abhängigkeiten.

  • Dein initialer Fehler mit "thin not found"

    Michael, das haben wir doch schon in Posts #2, #3 geklärt.

    Dein Beispiel läuft, also kein Installationsproblem.

    Sein Script lief nicht, da eine Filter-Bedingung nicht in Ordnung war - Läuft jetzt aber.

    So von mir 1 zu eins auf neu aufgesetzter Maschine reproduzierbar.


    Kannst Du mir noch einmal erklären worauf sich folgendes bezieht ? edit: hm könnte sich auf die ruby ci tests beziehen...


    Davon abgesehen ist der Test-Runner nur hilfreich, wenn du ihn lokal ausführst. Vielleicht schmeiss ich ihn auch wieder weg, und verwende RSpec-Tests.

    The post was edited 1 time, last by sru ().

  • Ich hab da ehrlich gesagt nicht rauslesen können, dass das geklärt wurde. Grade wo dann Icinga Web 2 vorkam ... aber egal.


    test/icinga2.rb ist Spaghetti-Code von mir, den da einfach mal hingelegt habe, damit $user sich daran orientieren können. Sauber ist das nicht, aber besser als nix. Was ich gerne hätte - Testfälle die die Klasse abrufen und diese dann auch testen. Problem dabei ist, dass du ein laufendes Icinga 2 im Hintergrund brauchst.

  • Danke euch beiden! Tut mir leid, dass ich mich so lange nicht zurückgemeldet habe, andere Aufgaben haben mich von diesem Projekt abgehalten...
    Mit dem last_check_result Attribut komme ich auf jeden Fall weiter, vielen Dank für den Tipp! Sobald ich mein Ziel damit erreicht habe werde ich nochmal Bericht erstatten und dann vermutlich auch diesen Thread als gelöst markieren können.

    Have a nice day,

    Christian