Posts by Napsty

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

    OK - I like that approach. Poor DBA :)


    I update here just for "finishing" this thread. And for self-documentary reasons ;)


    Typisch - this weekend there are no gaps to report. However I adapted my cron script a little bit so it sorts out all found perfdata with the timestamp.

    Before:


    Code
    1. # find all rotated files (ending with a timestamp) and output into a single file
    2. for file in $(find $perfdatadir/ -type f -regex ".*[0-9]" -exec ls -tr {} +); do
    3. #echo $file
    4. cat $file >> /tmp/nagiosgraph-perfdata
    5. rm $file
    6. done


    Since Friday:


    Code
    1. # find all rotated files (ending with a timestamp) and output into a single file
    2. for file in $(find $perfdatadir/ -type f -regex ".*[0-9]" -exec ls -tr {} +); do
    3. #echo $file
    4. cat $file >> /tmp/nagiosgraph-perfdata2
    5. rm $file
    6. done
    7. # Sorting timestamp
    8. cat /tmp/nagiosgraph-perfdata2 | sort -n > /tmp/nagiosgraph-perfdata
    9. rm /tmp/nagiosgraph-perfdata2


    Maybe the first approach was not enough, even though I sorted the found perfdata files according to their cdate. As of now I can only assume the reason for the gaps to be a wrong sorting of the perfdata files before creating the file nagiosgraph will read (/tmp/nagiosgraph).

    That's a good point. And in the meantime I've cross-checked several gaps with the pnp4nagios graphs. I haven't seen any gaps in there, so the problem must be within the nagiosgraph script or the data it gets. Icinga2 is almost certainly not to blame.

    My current thought is that some data (timestamps in the perfdata) might be mixed up or sorted in the wrong order when nagiosgraph wants to handle it.

    For documentation purposes I described the integration of nagiosgraph here: https://www.claudiokuenzler.co…rate-nagiosgraph-icinga-2


    I probably should delete the thread because I'm positive that the problem can be pointed to nagiosgraph and/or my cron script. dnsmichi your call if you want to keep the thread just for historical reasons.

    Yes, I figured that only out while I already wrote 90% of the post . Will adapt the subject.

    I'm running now an ls on the folder where Icinga 2 writes its perfdata files for nagiosgraph everytime before the nagiosgraph insert.pl is launched. I hope to see what's going on during the gaps.

    When I was analyzing a certain service, I came across something weird in the graphs.




    Notice the gaps?

    It looks like the service isn't checked on weekends anymore since February 13th. And this is exactly the day I upgraded Icinga 2 from 2.4.10 to 2.6.1:


    Code
    1. Start-Date: 2017-02-13 08:26:00
    2. Commandline: apt-get upgrade
    3. Upgrade: icinga2-bin:amd64 (2.4.10-1~ppa1~trusty1, 2.6.1-1~ppa1~trusty2), icinga2:amd64 (2.4.10-1~ppa1~trusty1, 2.6.1-1~ppa1~trusty2), libicinga2:amd64 (2.4.10-1~ppa1~trusty1, 2.6.1-1~ppa1~trusty2), icinga2-classicui:amd64 (2.4.10-1~ppa1~trusty1, 2.6.1-1~ppa1~trusty2), icinga2-doc:amd64 (2.4.10-1~ppa1~trusty1, 2.6.1-1~ppa1~trusty2), icinga2-common:amd64 (2.4.10-1~ppa1~trusty1, 2.6.1-1~ppa1~trusty2)
    4. End-Date: 2017-02-13 08:27:03


    I verified the Icinga object and it does have a check_period of 24x7:



    The check itself seems to be running 24x7 because in pnp4Nagios I see the updated graphs without gaps. Only in Nagiosgraph I see the gaps (see cpu-graph-gaps.png).




    With Nagiosgraph I use a second PerfdataWriter object. Was there a significant change in 2.6 in the PerfdataWriter object?

    Quote

    Die sysUptime und sysDescr lässt sich nur OHNE Context auslesen, die Interfaces nur MIT Context.


    Und genau da liegt das Problem. Anscheinend benutzt check_nwc_health diese Info's zwingend.


    Wenn ich einen snmpwalk auf die vorhin erwähnte Firewall mache, erhalte ich diese Infos:


    Code
    1. # snmpwalk -v 3 -a MD5 -A XXX -l authNoPriv -u nagios firewallvsx -n vsid2 |more
    2. iso.3.6.1.2.1.1.1.0 = STRING: "Linux firewallvsx 2.6.18-92cpx86_64 #1 SMP Thu May 26 12:17:44 IDT 2016 x86_64"
    3. iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.8072.3.2.10
    4. iso.3.6.1.2.1.1.3.0 = Timeticks: (304683992) 35 days, 6:20:39.92
    5. iso.3.6.1.2.1.1.4.0 = STRING: "contact_2"
    6. iso.3.6.1.2.1.1.5.0 = STRING: "firewallvsx"
    7. iso.3.6.1.2.1.1.6.0 = STRING: "location_2"
    8. iso.3.6.1.2.1.1.8.0 = Timeticks: (7) 0:00:00.07
    9. [...]


    Das Plugin liest diese Werte zwingend aus, auch wenn ich z.B. beim Plugin --servertype checkpoint angebe.


    Vielleicht hat lausser noch eine Idee.

    Am Besten lässt du mal einen snmpwalk auf diesem Context laufen und schaust, ob überhaupt intelligente Daten zurückkommen.

    Hier zum Vergleich der Aufruf bei mir auf eine Firewall mit virtuellen Instanzen (Checkpoint VSX):


    Wie man daran sieht, wird ganz am Anfang die sysUptime und sysDescr ausgelesen:

    Wenn es sich um ein Cisco Device handelt, hast du es schon mal mit --servertype cisco versucht?

    Aber wie gesagt, mach erstmal einen snmpwalk auf dem Context.

    https://www.claudiokuenzler.co…ywbem-version-0.10.0-test


    Scheinbar behebt es sich mit dem Update, schon probiert?


    gerhard, Du erwähnst hier pywbem - das ist für das Plugin check_esxi_hardware relevant. Nicht aber für check_esx3.pl (oder deren Forks), um was es dem OP geht.


    Thomas, welches Plugin verwendest Du für die ESX Checks? Es gibt ja mehrere Varianten da draussen. Hast Du alle schon mal durchgetestet und sind Dir (Performance-) Unterschiede aufgefallen?


    Bei meinem Setup benutze ich check_vmware_esx (https://github.com/BaldMansMojo/check_vmware_esx) weil es schon als ITL Plugin verfügbar war. Damit werden konstant derzeit 36 ESXi Server überwacht. Die CPU, Status und IO Checks werden im 5-Minuten-Takt durchgeführt. Memory und Uptime alle 15min.

    Icinga2 läuft bei mir auf Ubuntu 14.04.

    Vendor ist DellCheck läuft so:
    check_esxi_hardware.py -H my-shiny-new-vmware-server -U root -P fakepassword -V dell -I de

    Versuch es mal mit -V hp, auch wenn es eine DELL Maschine ist.
    Falls auch das nicht klappt, stelle sicher, dass du auch das CIM Offline Bundle aktuell hältst: http://www.dell.com/support/ho…ersDetails?driverId=FN2KW


    Edit: Zufälligerweise gab es heute bei uns gerade ein ESXi Update von 6.0.0 3620759 auf 6.0.0 4600944 - also dieselbe Version wie bei Dir. check_esxi_hardware funktioniert auch nach dem Update noch. Hardware hier ist aber anders; sind Cisco UCS Blades (B200-M4).

    OK, danke für diesen Hinweis! Bisher hatte ich mich fast voll auf den Output im UI verlassen.


    Das Problem scheint zu sein, dass ich in den hinterlegten Usern die Stati "Down" und "Up" bzw. die Host Stati nicht hinterlegt hatte:



    Jetzt klappts, vielen Dank!

    Hallo zamn,


    Habe ein eigenartiges Problem festgestellt, dass keine Notifications für Hosts generiert werden.
    Bei Services funktioniert es, nur bei Hosts selbst werden die Notification Settings nicht übernommen.
    Bei der Suche hier im Forum bin ich auf Notifications stopped working after upgrading to 2.2.2 gestossen, was etwa "ähnlich" wie mein Problem klingt.


    Host Object Definition:


    Code
    1. object Host "ftp01" {
    2. import "host-linux-prod"
    3. address = "192.168.168.45"
    4. vars.team = ["WIS"]
    5. }


    Somit wird im Hintergrund für den Host das Template "host-linux-prod" geladen, welches folgendermassen aussieht:


    Code
    1. template Host "host-linux-prod" {
    2. import "host-linux"
    3. check_interval = 10s
    4. retry_interval = 10s
    5. max_check_attempts = 2
    6. vars.notification.type = "sms"
    7. vars.notification.interval = 15m
    8. vars.notification.period = "24x7"
    9. vars.environment = "PROD"
    10. }


    Hier sieht man, dass bereits im Template bestimmte Variablen gesetzt werden, welche später in einer globalen Apply Rule benutzt werden.
    Im Hintergrund wird erneut ein "host-linux" Template geladen, welches der Vollständigkeit halber folgendermassen aussieht:


    Code
    1. template Host "host-linux" {
    2. import "generic-host"
    3. icon_image = "vendors/linux.png"
    4. icon_image_alt = "Linux"
    5. }


    Und generic-host wiederum ist das "Grundtemplate" mit den Basis-Werten:


    Code
    1. template Host "generic-host" {
    2. max_check_attempts = 3
    3. check_interval = 1m
    4. retry_interval = 30s
    5. check_period = "24x7"
    6. check_command = "hostalive"
    7. vars.notification.type = "email"
    8. vars.notification.interval = 0
    9. vars.notification.period = "businesshours"
    10. }


    Soweit so gut. Wir haben ein paar Host-Templates, welche im Hintergrund in der Host Object Definition geladen werden und diverse Variablen setzen.


    Nun kommen wir zur Apply Rule für die Notifications der Hosts:



    Hier sagen wir also, dass zuerst einmal ein Notification Template "notification-base-host" geladen werden soll und danach, falls Variablen gesetzt sind, gewisse Notification Settings überschrieben werden sollen.
    Das notification-base-host Notification Template sieht folgendermassen aus:


    Code
    1. # Host Basic Template
    2. template Notification "notification-base-host" {
    3. command = "notify-host-by-email"
    4. interval = 0
    5. period = "businesshours"
    6. user_groups = [ "icingaadmins" ]
    7. states = [ Up, Down ]
    8. types = [ Problem, Recovery, Acknowledgement ]
    9. }


    Das heisst, bereits im Basis Template für Notifications wird zum Beispiel die period gesetzt, sowie ein interval von 0, die Stati usw. Überschrieben werden diese Basis Werte dann in der Apply Rule, falls die Variablen (host.vars.XXX) gesetzt sind.


    Und jetzt zum Eigenartigen.


    Das Setzen von gewissen Werten funktioniert (überprüft im UI in der Host Configuration, config.cgi?type=hosts&item_name=ftp01):
    - Notification Interval wird auf 15min gesetzt (vom Host Template genommen)
    - die user_groups (Default Contacts/Groups) wurden korrekt mit dem Wert vom host.vars.team gesetzt (vom Host Object genommen)


    Wiederum andere sind auf Werte gesetzt, bei denen ich nicht weiss, woher die kommen. Zum Beispiel:


    - Notification Options: Recovery ?(
    - Notification Period: leer ?(



    Als der Host down war, wurden somit auch keine Alerts verschickt. Wie gesagt, bei den Services funktioniert das Setzen von den Notification Settings. Und dort benutze ich dieselbe Struktur von Templates und Variablen.


    Gemäss "icinga2 object list" wird die Apply Rule auch auf dem Host durchgeführt und die korrekten Werte gesetzt:



    Und bei notification_interval und user_groups funktioniert es ja.


    Bin ich hier in einen bisher unbekannten Bug reingeschlittert? Bin über jede Idee, Fehlerhinweis oder auch Bestätigung eines potentiellen Bugs froh, da ich durch dieses Phänomen im Moment grad etwas "stuck" in der Migration zu Icinga 2 bin.


    Icinga Version:


    Hello again,


    Everything is working as I intended to do it, once the correct states were defined in the base host and base service notification templates.


    Here's my config if someone wants to go the same way one day.


    First a "base" notification template is defined for Host and Service.



    Then an Apply rule is defined which applies the base templates on all hosts. With the if clauses special variables are checked for their existance and if they exist, they're used to overwrite some of the notification settings:



    This way each Host and Service has the possiblity to have their own notification settings. Example on a Host:


    Code
    1. object Host "host1" {
    2. import "host-linux-prod"
    3. display_name = "host1"
    4. address = "192.168.1.50"
    5. vars.os = "Linux"
    6. vars.notification_type = "sms"
    7. }


    The Apply rules are great and allow a broad granularity without becoming too complex. So thanks a lot for having coded that! :thumbsup:
    Thanks for your help, dnsmichi!

    Hello again,


    really appreciate your quick answers, thanks!

    If you prefer doing it the hard way, feel free to go there. I don't think that the argument of non-linux admins editing configuration can be solved with the icinga2 configuration language, and I also don't think that we designed it for that. Given the nature of monitoring changing in dynamic environments (cloud, containers spinning up, etc) as well as users demanding simplified configuration methods - be it dynamic rules or a config api, I think Icinga 2 was designed the right way.


    Even the config parser tells you exactly what is wrong, where to look into (file, lineno, character) and marked the entire line. Compare that to the faulty parser in 1.x.
    It still tells you that your host notification filters are wrong (OK instead Up, etc.). You'll certainly learn that by reading the documentation. Like everything else - how to use apply rules, conditionals, functions, etc and how to troubleshoot (e.g. Icinga2 object list which the non-linux admin will love).


    If you don't like the way Icinga 2 works, you may still use icinga 1.x. But I bet there's too many other cool features you'll miss then. Your non-linux admins probably need a config gui. There's two colleagues at Netways working fulltime on that having Icinga Web 2 nearly RC ready.

    There are many ways to Rome. :) That's what currently seems best after having evaluated different ways of writing config files. And thats the beauty of it: There's no right or wrong. Everything depends how the monitoring admins want to use the monitoring configs. But that's off topic anyway, what I intended to ask in this thread is the technical possibility of what I'm trying to do.


    Thanks for pointing me into the right direction with the filters. I actually read http://docs.icinga.org/icinga2…s#objecttype-notification which gives the following information:


    Code
    1. Available notification state filters:
    2. OK
    3. Warning
    4. Critical
    5. Unknown
    6. Up
    7. Down


    After your hint I also checked out http://docs.icinga.org/icinga2…toring-basics#host-states and here the HOST and SERVICE states are clearly separated. I think it would be a good idea to make the same kind of separation also in the "Notification Object Type Definition".


    Thanks by the way also for the apply rule example you have posted above. Based on that I will most likely create a base rule which is able to check for the "notification overwrite variables" I have planned.


    Will test tomorrow and report back if it works.