Error displaying SLA graph with fortinet IP SLA plugin (only error for 1 interface)

[CaseBlue (Dieter Lievens)]

CMK version:
2.1.0p22

OS version:
Ubuntu latest 22.04 server

Error message:

When trying to view the graph of the IP sla history, they refuse to work for the “wan2” interface. All other IP SLA graphs work fine.

When the IP sla history graph is trying to be shown, I get the following error message:

Service graphs Cannot calculate graph recipes

Syntax error in expression ‘(‘rrd’, ‘dossche’, ‘DOSROTFW01’, ‘SLAv2_wan2’, ‘LinkLatency’, ‘max’, 1.0), (‘rrd’, ‘dossche’, ‘DOSROTFW01’, ‘SLAv2_wan2’, ‘LinkLatency’, ‘max’, 1.0), (‘rrd’, ‘dossche’, ‘DOSROTFW01’, ‘SLAv2_wan2’, ‘LinkLatency’, ‘max’, 1.0), (‘rrd’, ‘dossche’, ‘DOSROTFW01’, ‘SLAv2_wan2’, ‘LinkLatency’, ‘max’, 1.0), (‘rrd’, ‘dossche’, ‘DOSROTFW01’, ‘SLAv2_wan2’, ‘LinkLatency’, ‘max’, 1.0), (‘rrd’, ‘dossche’, ‘DOSROTFW01’, ‘SLAv2_wan2’, ‘LinkLatency’, ‘max’, 1.0), (‘operator’, ‘MERGE’)’: too many operands left
Service Metrics LinkLatency: 9.6 [](javascript:void(0)

---

LinkPacketLoss: 0 [](javascript:void(0)
Linkstate: 0 [](javascript:void(0)
Currently in downtime no
Current check attempt 1/1
The age of the current service state 17 h
The time since the last check of the service 10.5 s
Cached agent data
The time of the next scheduled service check -
The last time the service was OK 10.5 s
Service check latency 0.00 s
Service check duration 54.0 ns
Service notification period 24X7
In notification period yes
Service notification number 1
The time of the last service notification -
The time of the next service notification -
Notification postponement reason
Service normal/retry check interval 60 s / 60 s
Service contact groups all
Service contacts
Service groups the service is member of
Service service level
Service check command check_mk-sla_fortinet
Service performance data (source code) LinkState=0;;;; LinkLatency=9.596;150;200;; LinkPacketLoss=0;0;5;; LinkState=0;;;; LinkLatency=12.156;150;200;; LinkPacketLoss=0;0;5;; LinkState=0;;;; LinkLatency=26.209;150;200;; LinkPacketLoss=0;0;5;; LinkState=0;;;; LinkLatency=8.376;150;200;; LinkPacketLoss=0;0;5;; LinkState=0;;;; LinkLatency=11.08;150;200;; LinkPacketLoss=0;0;5;; LinkState=0;;;; LinkLatency=19.436;150;200;; LinkPacketLoss=0;0;5;;
Service custom attributes
Check manual (for Checkmk based checks) Man page sla_fortinet not found.
Custom services notes

Output of “cmk --debug -vvn hostname”: (If it is a problem with checks or plugins)

OMD[dossche]:~$ cmk --debug -vvn DOSROTFW01Checkmk version 2.1.0p22Try lic -...

Too long for the post here

[andreas-doehler (Andreas)]

There are two points what i see.
To fix this problem it would be best to contact the author of this plugin as there is no “sla_fortinet” inside the CheckMK distribution.
For the error itself it looks like the check uses the wrong data to build the unique ID (check item). You have multiple “wan2” entries and this causes your problem.

From your SNMPwalk

sla_fortinet: Fetching data (SNMP walk cache is enabled: Use any locally cached information)
Executing BULKWALK of ".1.3.6.1.4.1.12356.101.4.9.2.1.14" on DOSROTFW01
.1.3.6.1.4.1.12356.101.4.9.2.1.14.1 => [b'wan1'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.2 => [b'MPLS_TNL_2_DC'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.3 => [b'INT_TNL_2_DC'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.4 => [b'wan2'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.5 => [b'wan2'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.6 => [b'P1_IPSEC_2_DEI'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.7 => [b'wan2'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.8 => [b'P1_IPSEC_2_KER'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.9 => [b'wan2'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.10 => [b'P1_IPSEC_2_MER'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.11 => [b'wan2'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.12 => [b'P1_IPSEC_2_MOE'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.13 => [b'wan2'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.14 => [b'P1_IPSEC_2_AVE'] 'OCTETSTR'
.1.3.6.1.4.1.12356.101.4.9.2.1.14.15 => [b'P1_IPSEC_2_RAL'] 'OCTETSTR'

The check uses this name as the check item. This will only work if every name is unique. It would be better if the check also fetches the OID “.1.3.6.1.4.1.12356.101.4.9.2.1.1.x” (it’s the link ID) and build a unique item with booth.

There is no quick solution for your problem, as the check needs to be fixed.

[CaseBlue (Dieter Lievens)]

Interesting.

While it may not address the core-issue, could the solution not simply be to rename the interface to something else?

I will try tomorrow