Fortigate sessions service

[anajesus]

Hello everyone

I have monitored a fortigate in two sites with both version 1.6.0p20. The problem is in one of the sites where the sessions service does not seem to respond to a rule that modifies the session threshold.

In Site A (problem):

The check is not configurable via WATO.

it uses check_mk_fortigate_sesions.

Suddenly the service state gets critical and the levels turns to default 100000/150000 (don´t know why and always the flapping icon)

And then it gets OK with the rule levels (not the default)

In site B:

It uses check_mk-fortigate_sessions_base instead of check_mk_fortigate_sesions.
I can edit the fortigate Active Sessions in host& service parameters…(not being able to do it in the other site A)

Another diference between both Sites is that in Site A it´s configured the SNMP management Board and the host snmp.

Any idea would be appreciated so much.

Thanks in advanced!

Ana

[anajesus]

In Site A

cmk --debug -vvvnI myhost

• EXECUTING DISCOVERY PLUGINS (23)
  Trying discovery with: fortigate_memory, fortigate_ha_status, fortigate_wlan_info, fortigate_sslvpn, fortigate_ipsecvpn, mgmt_ snmp_uptime, fortigate_node, fortigate_memory_base, fortigate_ipsec, fortigate_sync_status, fortigate_node.cpu, fortigate_sessions, snmp_uptime, fortigate_node.sessions, fortigate_cpu, fortigate_node.memory, fortigate_sessions_base, if_fortigate, hr_mem, mgmt_snmp_info, fortigate_cpu_base, fortigate_signatures, snmp_info
  The discovery function “inventory_fortigate_ha_status” of the check “fortigate_ha_status” is expected to take a single argument (info or parsed), but it’s taking the following arguments: [‘checkname’, ‘info’]. You will have to change the arguments of the discovery function to make it compatible with this Checkmk version.

Site B:

• EXECUTING DISCOVERY PLUGINS (22)
  Trying discovery with: fortigate_vdom_memory, fortigate_vdom_cpu, fortigate_sslvpn, fortigate_vdom_sessionrate, fortigate_ipsecvpn, mgmt_snmp_uptime, fortigate_node, fortigate_memory_base, if64adm, fortigate_sync_status, fortigate_node.cpu, snmp_uptime, fortigate_node.sessions, fortigate_node.memory, fortigate_sessions_base, fortigate_vdom_sessioncount, if_fortigate, hr_mem, mgmt_snmp_info, fortigate_cpu_base, fortigate_signatures, snmp_info

[andreas-doehler (Andreas)]

@anajesus

The discovery function “inventory_fortigate_ha_status” of the check “fortigate_ha_status” is expected to take a single argument (info or parsed), but it’s taking the following arguments: [‘checkname’, ‘info’]

This sounds like an old check. Is this fortigate check from an installed mkp package?

[anajesus]

Don´t know, how can i see it?

[andreas-doehler (Andreas)]

You can look at the instance inside the folder “~/local/share/check_mk/checks”.
If there are some files starting with “fortigate_…” then it is an installed (manually or with mkp) check.
It sounds like you have two different versions there.

[anajesus]

The files are:
fortigate_cpu fortigate_ha_status fortigate_ipsec fortigate_memory fortigate_sessions fortigate_wlan_info

[anajesus]

Andreas found this:

[anajesus]

Hi Andreas, just releases the package. Trying to discover the fortinet but too many missing services (VDOM). The pluggins seem not to be applied. Any idea?

[andreas-doehler (Andreas)]

I think there are two things you can try. remove the installed fortinet package completely. Check what services are done from the included fortinet checks. And think if you need the missing checks.
The plugin is not maintained since 1.4 and needs a rework also now after 2.0 is release for sure

As i have no fortinet in my systems i don’t know how much works needs to be done.

[anajesus]

Hi Andreas, I´ve removed the package that for some reason was installed in the past (don´t need that package missing services). I have launched a discovery but the fortinet services are not being discovered correctly, exactly they do not appear. It´s as if the plugins were not installed.
the output of cmk --debug -vvvnI myhost in Site A:

• EXECUTING DISCOVERY PLUGINS (17)
  Trying discovery with: if_fortigate, fortigate_memory_base, hr_mem, mgmt_snmp_info, snmp_uptime, mgmt_snmp_uptime, fortigate_node, fortigate_node.memory, fortigate_sslvpn, fortigate_ipsecvpn, fortigate_node.sessions, fortigate_sync_status, fortigate_cpu_base, fortigate_node.cpu, fortigate_signatures, fortigate_sessions_base, snmp_info

So diferent from Site B:

• EXECUTING DISCOVERY PLUGINS (22)
  Trying discovery with: fortigate_vdom_memory, fortigate_vdom_cpu, fortigate_sslvpn, fortigate_vdom_sessionrate, fortigate_ipsecvpn, mgmt_snmp_uptime, fortigate_node, fortigate_memory_base, if64adm, fortigate_sync_status, fortigate_node.cpu, snmp_uptime, fortigate_node.sessions, fortigate_node.memory, fortigate_sessions_base, fortigate_vdom_sessioncount, if_fortigate, hr_mem, mgmt_snmp_info, fortigate_cpu_base, fortigate_signatures, snmp_info

I just want to rediscover the firewall and that right plugins are applied!

[anajesus]

The fortigate_vdom´s services are missing.

Thanks!

Ana

[anajesus]

Finally I´ve been able to find an answer … in case the same problem occurs to someone … there was a custom pluging created in Site B and I thought it was part of the improvement of the checkmk in relation to the fortigate vdom’s. That was the reason why one site had more services than the other.

Thank you Andreas for your time.

Ana

[andreas-doehler (Andreas)]

Sorry for no answer today, it was a little bit too much to do.
It’s good that you could solve the problem. Normally i had recommended to compare the “~/local/share/check_mk/checks/” folders on booth instances to find the problem files.