Posts by Isma399

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

    Hello,
    1. It updates daily? How would you know if a port were to go down or not
    during a day? Does this mean that it's not being monitored in
    "real-time"?


    If a port goes down, we'll be alerted.
    If we put a port up, il will be monitored the next day.


    2. I noticed that in the thread you linked, it generates a Grafana
    dashboard. Could you post what that looks like? I'm curious because I'm
    thinking of using Grafana.
    The dashboard looks like that :
    Then, a clic on the switch open more infos :

    Hello,


    I'm using my own couple of scripts to dynamically update daily the list of interfaces and switches(~20)
    https://github.com/Isma399/dyn…ches_dyn_update_icinga.py


    First, in the main block of switches_dyn_update_icinga.py, I declare my switches, for instance:


    Code
    1. switches = {'c3650': {"load":"1.3.6.1.4.1.9.2.1.58.0"}, \
    2. 'c2960g': {}, 'c2960s': {},\
    3. "c4500x" :{"load":"1.3.6.1.4.1.9.2.1.58.0"} \
    4. }


    The script generates a file containing declaration of switch like that (after removing unrouted VLAN, Stack, Null0 interfaces, interfaces down (ifOperStatus!=1), interfaces where ifSpeed not defined):

    Code
    1. object Host "c3750x" {
    2. import "generic-switch"
    3. groups = [ "switches" ]
    4. address = "x.x.x.x"
    5. vars.load = "1.3.6.1.4.1.9.9.109.1.1.1.1.5.1"
    6. vars.interfaces ="10623 10105 10104 10106 10101 10103 10102 10602 1 10603 10601 10606 10605 10621 10624 10701 10622 10612 "
    7. }


    Then, the check command uses the second script :
    https://github.com/Isma399/dyn…master/check_iftraffic.py


    More info: dynamically updates interfaces switches list and generate a grafana dashboard



    Hope that would be useful for you.

    Hello,


    I've just tried JasperServer and I'm in the same case, so I'm using your thread.
    For me, I've got a problem with the SQL function icinga_availibility which mainly (94%) return NULL
    I'm using icinga-report provided by github.


    SQL
    1. SELECT icinga_availability( icinga_objects.object_id , '2016-11-07 00:00:00.0', '2016-11-13 23:59:59.0') FROM icinga_objects ;
    2. ...
    3. ...
    4. 7731 rows in set (10.62 sec)



    SQL
    1. select name2, icinga_availability( icinga_objects.object_id , '2016-11-07 00:00:00.0', '2016-11-13 23:59:59.0') FROM icinga_objects WHERE icinga_availability( icinga_objects.object_id , '2016-11-07 00:00:00.0', '2016-11-13 23:59:59.0') IS NOT NULL;
    2. ...
    3. ...
    4. 447 rows in set (11.85 sec)

    The ido-mysql.conf looks like this :

    Hello,


    At work, we want a "clone" of MRTG.
    this couple of scripts updates from a given dictionnary of switches the Icinga configuration and then makes a Grafana DashBoard
    It uses fastsnmpy to use snmpblukwalk which is faster than snmpwalk.
    I got no snmp timeout during the tests.


    The grafana dashboard generated uses the description of Interface if given or the Interface Name.


    Scripts could be found here : https://github.com/Isma399/dyn-switch-update


    Hoping that will be useful.

    I thank you for your answer.
    nsca-ng is running with log_level=5 in its conf. Here's the output :

    Code
    1. Sep 2 09:34:09 icinga2 nsca-ng[10637]: [INFO] checker@19.3.7.8 C: MOIN 1 982IEs7e
    2. Sep 2 09:34:09 icinga2 nsca-ng[10637]: [INFO] checker@19.3.7.8 (ID: 982IEs7e) S: MOIN 1
    3. Sep 2 09:34:09 icinga2 nsca-ng[10637]: [INFO] checker@19.3.7.8 (ID: 982IEs7e) C: PUSH 6496
    4. Sep 2 09:34:09 icinga2 nsca-ng[10637]: [INFO] checker@19.3.7.8 (ID: 982IEs7e) S: OKAY
    5. Sep 2 09:34:09 icinga2 nsca-ng[10637]: [INFO] checker@19.3.7.8 (ID: 982IEs7e) C: [1472801649] PROCESS_SERVICE_CHECK_RESULT;tina2;tina_backups;1;'\nservelec(dare-linux_all)[...]
    6. Sep 2 09:34:09 icinga2 nsca-ng[10637]: [NOTICE] Queuing data from checker@19.3.7.8 (ID: 982IEs7e): [1472801649] PROCESS_SERVICE_CHECK_RESULT;tina2;tina_backups;1;'\nservelec(dare-linux_all)[...]
    7. Sep 2 09:34:09 icinga2 nsca-ng[10637]: [INFO] checker@19.3.7.8 (ID: 982IEs7e) S: OKAY
    8. Sep 2 09:34:09 icinga2 nsca-ng[10637]: [INFO] checker@19.3.7.8 (ID: 982IEs7e) C: QUIT
    9. Sep 2 09:34:09 icinga2 nsca-ng[10637]: [INFO] checker@19.3.7.8 (ID: 982IEs7e) S: OKAY







    The report from the backup server is queued. It seems to be passed to icinga2 :

    Code: /var/log/icinga2/icinga2.log
    1. [2016-09-02 09:34:09 +0200] information/ExternalCommandListener: Executing external command: [1472801649] PROCESS_FILE;/tmp/nsca.xztiNp;1
    2. [2016-09-02 09:34:09 +0200] information/IdoMysqlConnection: Query queue items: 0, query rate: 27.0167/s (1621/min 8626/5min 26014/15min);

    Enabling debug doesn't give much more information :


    #icinga2 feature enable debuglog
    #systemctl restart icinga2.service
    #tail -f /var/log/icinga2/debug.log

    Code
    1. [2016-09-02 09:53:58 +0200] information/ExternalCommandListener: Executing external command: [1472802838] PROCESS_FILE;/tmp/nsca.x1kADy;1
    2. [2016-09-02 09:54:05 +0200] information/IdoMysqlConnection: Query queue items: 0, query rate: 24.8167/s (1489/min 6524/5min 6524/15min);


    icinga2 troubleshoot


    cat /var/log/icinga2/crash/report.1456753036.1008

    Code
    1. Failed to launch GDB: No such file or directory


    icinga2 --version


    mysql -u root -p icinga -e "select * from icinga_dbversion;"

    Code
    1. Enter password:
    2. +--------------+----------+---------+---------------------+---------------------+
    3. | dbversion_id | name | version | create_time | modify_time |
    4. +--------------+----------+---------+---------------------+---------------------+
    5. | 1 | idoutils | 1.14.1 | 2015-11-23 09:43:13 | 2016-08-31 12:12:32 |
    6. +--------------+----------+---------+---------------------+---------------------+

    Hello,


    I've got a passive check on Icinga which work for 6 months and doesn't work anymore..
    A script watch every day the backup and send the result's file with nsca to icinga2.
    Before the file was proceeded and this appear in Icinga2 log and now the file is staying in tmp folder and nothing appear in Icinga.


    Running a test from the backup server is OK (I receive a notification)

    Code
    1. echo -e "tina2\ttina_backups\t1\t'Test'\n" | /usr/local/sbin/send_nsca

    The result's file (replacing the word "file" in the previous line) is quite long (around 6000).
    But that works before.


    Maybe it's a problem with nsca or the external pipe, I don't where to look.
    Could you help me?
    Thanks

    Hello,


    I'm making a script to update dynmically a custom_variable named vmware_value.
    The script is here : https://github.com/Isma399/ici…/master/list_vm_on_esx.py
    This variable is the list of vm active on an esx or a Vcenter. It used for instance with this service :

    Code
    1. apply Service "soap-vm-cpu" for (vmname in host.vars.vmware_vmname){
    2. name = vmname + ".cpu"
    3. check_command = "vmware-esx-soap-vm-cpu"
    4. vars.vwmare_vmname = vmname
    5. assign where host.vars.vmware_vmname
    6. vars.vmware_sessionfile = host.name
    7. }


    When the script have runned, the list of vm is updated :

    But in the web interface, I can't see any new services checked. The custom_variables is seen updated.


    If I hardcode the custom variable "vmware_vmname" in icinga2/conf.d/host.conf, it's ok.
    What I have missed?

    Have you this file :
    /usr/share/icinga2/include/plugins-contrib.d/virtualization.conf


    All check_vmare_esx commands are in this file and syntax help here : http://docs.icinga.org/icinga2…ds#plugins-contrib-vmware





    So, no need to declare a command. Only apply service like that for instance :

    Code
    1. apply Service "dc-volumes" {
    2. import "esx-service"
    3. check_command = "vmware-esx-dc-volumes"
    4. assign where "esx" in host.groups
    5. }


    vmware_datacenter is required, you could put it the declaration host:

    Code
    1. object Host "vcenter1" {
    2. vars.vmware_datacenter = "--"
    3. groups = [ "esx" ]
    4. }

    Check the logs.



    Finally, maybe it's more a problem with the plugin or ESX, check here : https://github.com/BaldMansMojo/check_vmware_esx/issues