Active checks & vanished services

At a certain point, I applied plugins to a host to create services that were not created automatically.
The problem arises when when doing device full scan. Those services created previously with cmk -vII --checks = plugin name HOST, appear as vanished but they are not. Why do they appear like this? Periodically a cmk -II is executed to discover new services and delete the vanished ones, and this causes the manually created services to be lost. Any ideas?

The full scan result in the status detail is Received no data but the graphs are showing data.

And the output of cmk --debug -vII checkpoint :
1 hr_cpu
3 hr_fs
27 if64
1 snmp_info
1 snmp_uptime
1 ucd_cpu_load
1 ucd_mem
SUCCESS - Found 35 services, no host labels

What has happened to the rest of the services that there were and now they are not appearing?. I tried this on another Site and created the same new host there, ran same command and the result was different:

1 checkpoint_connections
4 checkpoint_fan
1 checkpoint_firewall
6 checkpoint_ha_problems
1 checkpoint_ha_status
1 checkpoint_memory
1 checkpoint_packets
2 checkpoint_powersupply
1 checkpoint_svn_status
4 checkpoint_temp
12 checkpoint_voltage
1 hr_cpu
3 hr_fs
27 if64adm
1 snmp_info
1 snmp_uptime
1 ucd_cpu_load
SUCCESS - Found 68 services, no host labels

The full scan output:

Thanks

Ana

I think i know what the problem is.
Your Checkpoint is not recognized by the check in the correct way.
With your manual discovery with “cmk --checks=plugin_name -vII HOST” you said - try to discover these checks also if the discovery function don’t match.
The “cmk -II HOST” without a plugin name does a discovery only for services who match the discovery function.

For your device you can have a look at the SNMP output of OID .1.3.6.1.2.1.1.1.0 and .1.3.6.1.4.1.2620.1.1.21.0
In the first OID the checks expect something like IPSO or Linux and cpx in the string.
The second OID must start with “firewall”

If you can post the content of the two OIDs it would be possible to modify the check in a way that it also discovers your device.

Hi Andreas,

Thanks for answering!. It was what you commented…

The content of the two OIDS are:

1. .1.3.6.1.2.1.1.1.0

SNMPv2-MIB::sysDescr.0 = STRING: Linux VSX-23900-APP2.redsara.es 2.6.18-92cpx86_64 #1 SMP Thu Jun 20 10:40:25 IDT 2019 x86_64

2. .1.3.6.1.4.1.2620.1.1.21.0
SNMPv2-SMI::enterprises.2620.1.1.21.0 = STRING: “Firewall”

That is strange as booth strings match the discovery function.
It should find the services.

Can you please make the following test. With you your inventory with debug you get a line after the scanning where it shows you in yellow color all checks what he found and all checks that are no tried to discover. The difference between booth are the ignored checks.

Was there some output at your debug inventory with some errors or anything else?

EDIT:
These two lines from the discovery i mean

   SNMP scan found                    hr_mem if64 mgmt_snmp_info mgmt_snmp_uptime snmp_info snmp_uptime
   SNMP filtered check plugin names   hr_mem if64 snmp_info snmp_uptime

The upper one shows all found check types and the lower one then only what will be discovered. The difference between these two can be a rule or some other settings. In the example case the “mgmt_” checks are not discovered as this is no management interface per definition inside WATO.

Hi Andreas,

After launching the command cmk --debug -vvvnI Checkpoint-app1
the output is:

EXECUTING DISCOVERY PLUGINS (10)
Trying discovery with: hr_cpu, ucd_mem, snmp_uptime, ucd_cpu_load, if64_tplink, hr_ps, if64adm, if64, hr_fs, snmp_info

I can’t find the line you say SNMP scan found, it doesn’t appear or I’m not able to find it. Maybe I should launch a cmk with other parameters to make it appear in my output.
I have done the same test on another site with the checkpoint and the output is different:

Loading autochecks from /omd/sites/integracion/var/check_mk/autochecks/checkpoint-app1.mk

  • EXECUTING DISCOVERY PLUGINS (27)
    Trying discovery with: checkpoint_tunnels, checkpoint_memory, dell_om_processors, checkpoint_powersupply, checkpoint_fan, dell_om_power.unit, checkpoint_temp, checkpoint_firewall, checkpoint_voltage, dell_om_mem, hr_ps, dell_om_fans, if64adm, hr_cpu, snmp_uptime, checkpoint_ha_problems, dell_om_power, checkpoint_svn_status, hr_fs, dell_om_esmlog, dell_om_sensors, dell_om_disks, snmp_info, checkpoint_connections, checkpoint_ha_status, ucd_cpu_load, checkpoint_packets

I am also having this problem with other models such as the Nexus and Cisco3750.

Thanks

Ana

Hi Andreas,

I don’t know if you have been able to see the result of what you asked me. Any idea would help me to know what is happening with the discovery of the services and the correct application of the plugins.

Regards

Ana

Sorry i forgot to answer :frowning:
The problem is that it shows only some SNMP checks in the line “Trying discovery with:”
This looks like generic SNMP device but nothing special like something from Checkpoint.
I will try to have a look a on of my installations with Checkpoint.
All the other output looks good only this line is strange.

Hi Andreas,

I found the SNMP scan section:

  • FETCHING DATA
    [snmp] No persisted sections loaded
    [snmp] Not using cache (Don’t try it)
    [snmp] Execute data source
    SNMP scan:
    Skipping system description OID (Set .1.3.6.1.2.1.1.1.0 and .1.3.6.1.2.1.1.2.0 to “”)
    Using cached OID .1.3.6.1.2.1.1.2.0:
    Using cached OID .1.3.6.1.2.1.1.2.0:
    Using cached OID .1.3.6.1.2.1.1.1.0:

The same discovery in another Site where the discovery works:

  • FETCHING DATA
    [snmp] No persisted sections loaded
    [snmp] Not using cache (Don’t try it)
    [snmp] Execute data source
    SNMP scan:
    Getting OID .1.3.6.1.2.1.1.1.0: Executing SNMP GET of .1.3.6.1.2.1.1.1.0 on checkpoint-app1
    => [‘Linux VSX-23900 2.6.18-92cpx86_64 #1 SMP Thu Jun 20 10:40:25 IDT 2019 x8 6_64’] OCTETSTR
    Linux VSX-23900- 2.6.18-92cpx86_64 #1 SMP Thu Jun 20 10:40:25 IDT 2019 x86_64
    Getting OID .1.3.6.1.2.1.1.2.0: Executing SNMP GET of .1.3.6.1.2.1.1.2.0 on checkpoint -app1
    => [’.1.3.6.1.4.1.2620.1.6.123.1.78’] OBJECTID
    .1.3.6.1.4.1.2620.1.6.123.1.78
    Using cached OID .1.3.6.1.2.1.1.2.0: .1.3.6.1.4.1.2620.1.6.123.1.78
    Using cached OID .1.3.6.1.2.1.1.2.0: .1.3.6.1.4.1.2620.1.6.123.1.78
    Using cached OID .1.3.6.1.2.1.1.1.0: Linux VSX-23900 2.6.18-92cpx86_64 #1 SMP Thu Jun 20 10:40:25 IDT 2019 x86_64
    Using cached OID .1.3.6.1.2.1.1.1.0: Linux VSX-23900 2.6.18-92cpx86_64 #1 SMP Thu Jun 20 10:40:25 IDT 2019 x86_64
    Using cached OID .1.3.6.1.2.1.1.1.0: Linux VSX-23900 2.6.18-92cpx86_64 #1 SMP Thu Jun 20 10:40:25 IDT 2019 x86_64
    Getting OID .1.3.6.1.4.1.2620.1.1.21.0: Executing SNMP GET of .1.3.6.1.4.1.2620.1.1.21 .0 on checkpoint-app1
    => [‘Firewall’] OCTETSTR

It seems like it skipped the OID description and didn’t discover it correctly.

Regards

Ana

Andreas

I found what the problem was … a rule like you said “Hosts without system description OID”.

A rule that I had created for devices without the description and applied to the main directory … and in three different sites, just where the discovery was not being done correctly.

Thanks for your time.

Regards

Ana

Nice to hear that it is working. With your last post i would also recommend to search for rules like the one you found. Most times it is such a small thing like a rule without conditions that is then matched to all hosts.