Felder eines Arrays in einem CustomCommand ansprechen

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


    Ich stehe grad vor einem Problem was sich um das ansprechen eines Arrays dreht.


    Also in meinem Object Host befindet sich eine custom vars :

    Code
    1. vars.check_snmp_cisco_ports_bandwidth    =    ["1G","4G","M","nagios"]


    Okay nun sieht mein CheckCommand so aus :

    So spreche ich das Array ja nicht mit irgendeinem Index an.

    Was Icinga nun tut sieht wie folgt aus :

    Code
    1. notice/Process: PID 3854 ('/usr/lib/nagios/plugins/check_snmp_cisco_ports_bandwidth' '-c' '1G' '-c' '4G' '-c' 'M' '-c' 'nagios' '-h' '10.0.100.16' '-p' '1G' '-p' '4G' '-p' 'M' '-p' 'nagios' '-s' '1G' '-s' '4G' '-s' 'M' '-s' 'nagios' '-w' '1G' '-w' '4G' '-w' 'M' '-w' 'nagios') terminated with exit code 3

    So soll das ja nicht sein (lustiger weise funktioniert es so bei einem anderen Check den ein Kollege geschrieben hat).


    Also mich würde es brennend interessieren wie ich denn die Felder des Arrays richtig anspreche..

    Also ausprobiert habe ich bisher ohne Erfolg:

    - "-w" = "$host.vars.check_snmp_cisco_ports_bandwidth[0]$",

    - "-w" = "$host.vars.check_snmp_cisco_ports_bandwidth_1$",


    Wäre super wenn mir jemand helfen würde :)


    Liebe Grüße

  • Moin,


    Array#get das zu sein was du suchst: https://www.icinga.com/docs/ic…brary-reference/#arrayget


    Habe das eben in der Icinga Console getestet


    Code
    1. Icinga 2 (version: v2.7.1-183-gadb4226dd)
    2. <1> => var check_snmp_cisco_ports_bandwidth = ["1G","4G","M","nagios"]
    3. null
    4. <2> => check_snmp_cisco_ports_bandwidth.get(3)
    5. "nagios"
    6. <3> => check_snmp_cisco_ports_bandwidth.get(2)
    7. "M"


    Ich würde das aber nicht mit fest zugeordneten Array Indexes machen. Ich würde für jeden Parameter den du an das Plugin übergibst eine eigene Variable erstellen.

  • Hey,


    Vielen Dank für deine Antwort, das ist genau das was ich gesucht habe.

    Aber wie genau implementiere ich das jetzt richtig in meinem CheckCommand?

    Mir ist die Synatx von Icinga immer noch ein Rätzel ab und an.

  • Ich würde da kein Array verwenden, das ist zu fehleranfällig, wenn du in deiner Host-Konfiguration mal einen Fehler machst.


    Dadurch dass das eh nur vier Einzelwerte sind, definiere am Host (oder im Template) einfach vier Custom-Attribute mit spezifischen Namen. So kannst du auch ohne ins CheckCommand zu schauen, am Host-Objekt nachvollziehen, was du da eigentlich konfigurierst.


    Gibt es bei deinen Hosts ein bestimmtes Muster mit diesen Attributen, oder auch - wird mit Apply-Regeln nicht nur ein Service, sondern mehrere generiert? Der Kontext wäre hilfreich, um eine Lösung mit Arrays/Dictionaries zu überdenken.

  • Ich würde da kein Array verwenden, das ist zu fehleranfällig, wenn du in deiner Host-Konfiguration mal einen Fehler machst.

    Wir haben eine seperate DB in der alle Host drin stehen in der man auswählen kann welcher check wo läuft, ob eine sms verschickt werden soll für den host/service, welche teams Benachrichtigungen bekommen.. etc..

    Die verschiedenen Host.confs generiere ich mit einem Skript, Von daher ist es relativ fehlerfrei solang das Skript richtig läuft.

    Das war zwar initial ein größerer Aufwand, aber jetzt ist das sehr angenehm.


    Das mit dem Array hab ich mir nicht wirklich selbst ausgesucht.
    Mein Vorgesetzter wollte alle Parameter in einem Feld haben. Klar hätte man das dann nachm Query escapen können und jeweils immer ein einzelnes Attribut draus machen können, aber das war nicht gewünscht, weil die Configs dann so unübersichtlich werden.


    Quote

    Dadurch dass das eh nur vier Einzelwerte sind, definiere am Host (oder im Template) einfach vier Custom-Attribute mit spezifischen Namen. So kannst du auch ohne ins CheckCommand zu schauen, am Host-Objekt nachvollziehen, was du da eigentlich konfigurierst.

    Sollte es also einen Weg geben das einfach über das Array im Command zu implementieren wäre das, auch wenn ich die Indizes statisch eintrage nicht so tragisch, da jeder Eintrag in der Spalt fast identisch ist, also die Reihenfolge der Argumente bleibt demnach immer die Gleiche. Nur die Werte sind anders


    Hoffe man versteht das einigermaßen :D


    Grüße und danke für die wie immer sehr schnellen Antworten :)

  • Die Reihenfolge der Argumente war so ein Punkt der mich bei Nagios immer massiv angekotzt hat, wenn es mal anders war als erwartet. Dein Vorgesetzter mag das vielleicht so gewohnt sein, aber angenehm zu lesen und zu warten ist das meines Erachtens nach nicht. Je weniger ich denken muss beim setzen von Attributen, desto besser ;-)


    Da du sagst, dass du das per Skript aus einer CMDB o.ä. generierst, ist es doch eigentlich wurscht, wie diese Werte dann aussehen, oder ned?


    Der Bonus beim Setzen von einzelnen Custom-Attributen - du siehst diese Werte auch einzeln in Icinga Web 2 im Detail View und kannst damit nachvollziehen, was da genau konfiguriert ist. Sensitive Information wie etwa community-Credentials kannst du in Icinga Web 2 spezifisch ausblenden lassen.


    Ich könnte dir auch andere Lösungen vorschlagen, aber bevor ich dir die Materie mit Dictionaries, Functions und vielem mehr erkläre, möchte ich wissen, ob es sich überhaupt auszahlt. Aktuell hab ich so das Gefühl, dass obige Lösung 5 Minuten Programmierarbeit sind, und es geht einfach.

  • Die Reihenfolge der Argumente war so ein Punkt der mich bei Nagios immer massiv angekotzt hat, wenn es mal anders war als erwartet. Dein Vorgesetzter mag das vielleicht so gewohnt sein, aber angenehm zu lesen und zu warten ist das meines Erachtens nach nicht. Je weniger ich denken muss beim setzen von Attributen, desto besser

    Stimme ich dir voll und ganz zu. Man muss dazu sagen, dass mein Vorgesetzter Nagios/Icinga1 Fan ist und dort vieles besser findet..


    Da du sagst, dass du das per Skript aus einer CMDB o.ä. generierst, ist es doch eigentlich wurscht, wie diese Werte dann aussehen, oder ned?

    Ja tendenziell ist das vollkommen egal, zudem guckt ja wenn alles läuft eig auch keiner in die Confs rein. Wäre demnach egal wie viel da stehen würde.


    Der Bonus beim Setzen von einzelnen Custom-Attributen - du siehst diese Werte auch einzeln in Icinga Web 2 im Detail View und kannst damit nachvollziehen, was da genau konfiguriert ist. Sensitive Information wie etwa community-Credentials kannst du in Icinga Web 2 spezifisch ausblenden lassen.

    Okay ja, die wären mit einzelnen Attributen noch deutlich erkennbarer. Ich sehe die halt unter einem Namen bei Angepasste Variablen.


    Also ich stehe mit einem Bein bei dir, auf der anderen Seite entscheide ich nicht wie das ganze laufen soll.
    Finde es schade, denn man hätte es halt deutlich schöner und einfacher machen können.

    Ich habs jetzt wie folgt gelöst :

  • Du hast mir auf die Frage, ob es ein Muster bei der Konfiguration gibt, oder etwaige Service-Apply-Regeln, leider keine Infos geliefert.


    Deine jetzige Lösung mag funktionieren, schön isses aber nicht. Ich hätte versucht, Funktionen innerhalb des CheckCommands zu vermeiden, da das deutlich teurer bei jedem Check-Ausführen ist, als wenn die Werte statisch vorkompiliert sind.

  • Gibt es bei deinen Hosts ein bestimmtes Muster mit diesen Attributen, oder auch - wird mit Apply-Regeln nicht nur ein Service, sondern mehrere generiert? Der Kontext wäre hilfreich, um eine Lösung mit Arrays/Dictionaries zu überdenken.

    Sry hab ich überlesen.

    Also die Apply-Regeln die wir bisher nutzen weisen eigentlich immer nur genau einen Service an die jeweiligen Hosts zu.


    Und ja es gibt ein Muster. In diesem Beispiel hier betrifft das alle Switche bei uns.

    Die Attribute für diesen Check werden immer gleich aussehen nur halt mit anderen Werten.

    Ich muss die Werte also pro Host(Switch) auslesen und speichern. Bisher nun mal in einem Array.


    Deine jetzige Lösung mag funktionieren, schön isses aber nicht. Ich hätte versucht, Funktionen innerhalb des CheckCommands zu vermeiden, da das deutlich teurer bei jedem Check-Ausführen ist, als wenn die Werte statisch vorkompiliert sind.

    Stimme ich dir zu. Wusste es jetzt aber erstmal nicht besser und ich bin froh das es jetzt grad überhaupt läuft.

    Für Vorschläge oder Ansätze, um das schöner und effizienter zu machen bin ich offen :)


    Grüße

  • Ich hätte noch einen pragmatischen Ansatz - alle Einzelvariablen im generischen Host-Template verstecken und nur bei Bedarf überschreiben. Die Snmp-Community ist wohl eh immer gleich für den Monitoring-User (meiner Erfahrung nach), das lohnt ned, das bei jedem Host nochmals extra rauszuschreiben. Was "M" sein soll, konnte ich anhand der Beschreibung nicht rauslesen. Scheint aber auch immer redundant gleich zu sein.


    Ist aber eh wurscht, weil es ja nun für dich funktioniert. Weil du meintest, dein Vorgesetzter sei ein Fan von dem alten Zeug - wenn du mal mit dem Basis-Monitoring fertig bist, installier dir Business Process, Cube, Grafana, Map, usw. Module, bastle schöne Metrik-Dashboards in Grafana, korrelier deine Events mit Log-Messages in Elastic Stack/Graylog und visualisiere alles im Office mit Dashing. Könntest deinen Chef auch auf die OSMC dieses Jahr schicken und dich gleich mit. Da reden wir über derartige Dinge in Talks und Kaffeepausen ;-)