SNMP plugin for Fortigate Virtual Domains - the same perfdata displayed

Hi

I followed this old guide to create a plugin/agent for monitoring Fortigate Virtual Domains (VDOMs):

def inventory_fortigate_vdom_cpu(info):
    for VDOMname, cpuusage in info:
        yield VDOMname, cpuusage

fortigate_vdom_cpu_default_levels = (80.0, 90.0)

def check_fortigate_vdom_cpu(item, params, info):
#    warn, crit = params
    warn = fortigate_vdom_cpu_default_levels[0]
    crit = fortigate_vdom_cpu_default_levels[1]
    for VDOMname, cpuusage in info:
        if  VDOMname == item:
            cpuusage = float(cpuusage)
            perfdata = [ ( "CPUusage", cpuusage, warn, crit ) ]
            if  cpuusage > crit:
                return 2, "CRIT - excessive CPU usage (%s>%s): %s" % (cpuusage,crit,cpuusage), perfdata
            elif cpuusage > warn:
                return 1, "WARN - CPU usage is worrying (%s>%s): %s" % (cpuusage,warn,cpuusage), perfdata
            else:
                return 0, "OK - CPU usage is normal: %s" % (cpuusage,), perfdata

check_info["fortigate_vdom.cpu"] = {
    "check_function"        : check_fortigate_vdom_cpu,
    "inventory_function"    : inventory_fortigate_vdom_cpu,
    "service_description"   : "VDOM %s CPU usage",
    "has_perfdata"          : True,
    "snmp_info"             : ( ".1.3.6.1.4.1.12356.101.3.2.1.1", [ "2", "5" ] ),
    "snmp_scan_function"    : lambda oid: oid(".1.3.6.1.4.1.12356.101.3.2.1.1.5.*") != None,
}

.1.3.6.1.4.1.12356.101.3.2.1.1.2.* is a table holding the VDOM names.
.1.3.6.1.4.1.12356.101.3.2.1.1.5.* is a table holding the VDOM CPU usage.

It appeared to run fine… so I created another plugin for Memory Usage:

check_info["fortigate_vdom.memory"] = {
    "check_function"        : check_fortigate_vdom_mem,
    "inventory_function"    : inventory_fortigate_vdom_mem,
    "service_description"   : "VDOM %s memory usage",
    "has_perfdata"          : True,
    "snmp_info"             : ( ".1.3.6.1.4.1.12356.101.3.2.1.1", [ "2", "6" ] ),
    "snmp_scan_function"    : lambda oid: oid(".1.3.6.1.4.1.12356.101.3.2.1.1.6.*") != None,
}

But eventually I realized that the graphics displayed the same values for CPU and Memory and they were wrong – I run a script which launches check_snmp comands and displayed other values.

Where is my mistake?

Best regards.

P.D: Here you can find a snapshot of the graphics of the three services of the same VDOM called root. They look the same graphic, even though their values are very different:

The current values got by check_snmp Nagios plugin are:

SNMP OK - CPUusage 13 | CPUusage=13;80;90
SNMP OK - Memoryusage 13 | Memoryusage=13
SNMP OK - Sessionrate 1963 | Sessionrate=1963

At the first glance I can’t see any issues in your script.
what is the output of the commands?

cmk --debug -nvv --checks fortigate_vdom_mem your_fortigate_name_in_cmk
and
cmk --debug -nvv --checks fortigate_vdom_cpu your_fortigate_name_in_cmk

Why do you use the sub check format “vdom.cpu” inside the definition.
It is better to use also here the right name - “fortigate_vdom_cpu” as name for your check.
The name of your check file should then be “fortigate_vdom_cpu” and so on.

Please check this and test your check again.

Hi @andreas-doehler

Thanks for your help. But I never had imagined this naming issue would be the key… because I followed this old guide where you can read the S.M.A.R.T. temperature example:

check_info["smart.temp"] = {
    'check_function':            check_smart_temp,
    'inventory_function':        inventory_smart_temp,
    'service_description':       'SMART drive %s',
    'has_perfdata':              True,
}

I just followed that example.

Thank you again.

It’s ok to ask if you have a problem.
All the sub checks are normally inside one file.
In your example this file hast the name “smart” and includes two sub checks. But this is an agent based check. If you plan to do such a check with SNMP i would recommend the “cmciii” check as example.
This is also a very complex check :slight_smile:
It has a check without sub check - “cmciii” and then many “cmciii…”