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:
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.
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?
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.
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
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.
Sorry i forgot to answer
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.
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.
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.
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.