contains not working as expected

[tlkhorses]

I posted this in help but should have posted it here:
Running version 7.2.4. It looks like Alert>Discovery Actions using received value contains with service type SNMP isn't working as I thought it should. I'm trying to use it to link a template according to the type of device it is. So if I set Received value contains Mimosa it doesn't work and falls through the the generic catch all action of Network Generic Device by SNMP. If I use or in the action and list out each possible name it may find, the action then works. Same for other types of hardware such as RouterOS. I would have to list out each type of mikrotik using or. Using a snmp get on the ORI shows something like SNMPv2-MIB::sysDescr.0 = STRING: RouterOS RB4011iGS+. I would think that "contains" would catch RouterOS in that and apply the action.
What am I missing or is this a bug?

[cyber]

You are correct, contains should look for a substring in value...

contains - contains the substring. Parameter is given as a string.

https://www.zabbix.com/documentation/current/en/manual/config/notifications/action/conditions

I have no options to test this....

[tlkhorses]

Thought so, it doesn't. Tried it against several types of equipment where the value will vary according to model and the only way I can get a correct action is to "or" each possible value. So bug it is I think.

[markfree]

Note that the condition is "Received value", not "contain".
"Contain" is actually the operator for a string comparison of the agent's received value.

In some of the environments I work with, there are several discovery actions that use multiple "Received value" condition, and they all work fine.

So maybe your discovery action conditions are missing something.

Could you better describe your scenario so that we can investigate the issue? Some pictures and text formatting may help to understand the scenario.

[tlkhorses]

Using just the gui.
I define my Discovery Rules according to location. IE: Tower 1, Tower2 etc. I've attached a screen shot of one of those Discovery rules. Basically all the rules use the same items but different IP addresse ranges. Since I have a mixture of old and new equipment I am using SNMPv1. Ubiquiti uses v1. Since I couldn't get them to work with a mixture ov v1 and v2 I went with v1. The values are to display what name the host is and to apply the proper template.

In the Actions discovery I look for the value then assign the proper Template. Also a screen shot of that showing four different items.
Autodiscover Mimosa1 did not work and it would fall through to Autodiscover other. So I disabled that one.
Autodiscover Mimosa2 works using "or". I listed the complete values I see when a do a snmpget of the OID for different Mimosa equipment.
Auto discover Mikrotik does not work, it falls through to the Other action. When doing a snmpget on the OID for those, the return is something similar to what I showed in the initial post above depending on the model.

[tlkhorses]

I checked on one other item, the Ubiquiti action and it appears to be working. I am attaching a new screen shot of the actions which has it included. An snmpget of that OID is:
.1.3.6.1.2.1.1.9.1.3.5 = STRING: Ubiquiti Networks MIB module
So I am not sure why that on is working but the others are not.

[tlkhorses]

So does this get reported as a bug or do I do that somewhere else?

[markfree]

Based on the discovery rule configuration you shared, your host names are set as the system description (1.3.6.1.2.1.1.1.0). Is this what you are aiming for?
Shouldn't it be "sysName" (1.3.6.1.2.1.1.5.0)?

You could try removing the "Service type equals SNMPv1 agent" condition (I've never had luck with it). Change it for the "Discovery object equals Device" (but not really necessary).

Then, check your action "Type of calculation" and try customizing it. I think you might be mixing up the "Received value" condition with "Or".

From what I could understand so far, the condition calculation should be something like:

• Mimosa2 - A and B and C and D (ditch the "contains AIRSPAN-B5c")
• Mikrotik - A and B and C
• Mimosa1 - A and B and C
• Other - A and B and C and D and E
• Ubiquiti - A and B and C

Make sure these actions are restricted to the appropriate environment and are not overlapping.
Also, try to add the "Discovery check equals [DISCOVERY NAME]" condition. This should make your discovery action more precise.

[CLTX2025]

My downtime alarm always has a delay of four seconds from trigger to action. Zabbix7.0 has already improved by a few hundred milliseconds, but I didn't feel it after upgrading. Is there a problem with the configuration? Can someone help me

Yes	localhost:10051
7.0.0	New update available
7.0.0	New update available
2025-05-08
7.0.12	Release notes
7590	6499 / 1091
179
440748	392554 / 48188 / 6
319132	271917 / 47215 [40 / 271877]

[cyber]

My downtime alarm always has a delay of four seconds from trigger to action. Zabbix7.0 has already improved by a few hundred milliseconds, but I didn't feel it after upgrading. Is there a problem with the configuration? Can someone help me

Yes	localhost:10051
7.0.0	New update available
7.0.0	New update available
2025-05-08
7.0.12	Release notes
7590	6499 / 1091
179
440748	392554 / 48188 / 6
319132	271917 / 47215 [40 / 271877]

How all this relates to the topic?

[tlkhorses]

Markfree, your question about the hostname, for now that is what I intended so I can see easily what values were returned. DNS is not in play here so doesn't matter.
So did some more testing and basically getting the same results. Attached screen shot has the current Action> discovery. Everything in each of the Discovery Actions is "and" except the Mimosa action which is or between the to "contains'. I've disabled the "Autodiscover other" action for now to keep from having a bunch of warnings between test changes.
For clarification, each of the Discovery Rules covers the IP subnets on a particular tower. Each tower has a mixture of hardware so Autodiscover actions are trying to apply the correct template to that particular hardware manufacturer if you will.
As it stands now;
The Autodiscover Ubiquiti applies only the Generic network which is not correct.
The Autodiscover Mimosa applies both the Generic network and the Mimosa templates. It should only apply Mimosa.
The Autodiscover Mikrotik applies only the Generic network template which is not correct. It should apply the Mikrotik template only.
Cambium equipment has the Generic network template applied which is what I would expect.
Various switches have the Generic Network Template applied which is what I would expect.

[tomecki10000]

i also have a problem with microtik. i started discovery with ubiquity and everything works. then i started adding microtiks and nothing. it doesn't add to group and it doesn't add templates
(snmp v1 .1.3.6.1.2.1.1.2.0 = mikrotikExperimentalModule)

[markfree]

Your discovery is mainly based on "sysDescr" and "sysORDescr", right?
If you query these OIDs with something like "snmpget", what kind of values do you get?

[tlkhorses]

Here are the three OIDs I have listed in the Discovery for each of the types. I use -v1 because some of the Ubiquiti hardware is old, using only v1.

FOR UBIQUITI

snmpget -v1 -ctheword 10.10.10.10 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux 2.6.32.68 #1 Fri Jan 3 10:25:52 Europe 2025 mips

snmpget -v1 -ctheword 10.10.10.10 1.3.6.1.2.1.1.5.0
SNMPv2-MIB::sysName.0 = STRING: honeyS

snmpget -v1 -ctheword 10.10.10.10 1.3.6.1.2.1.1.9.1.3.5
SNMPv2-MIB::sysORDescr.5 = STRING: Ubiquiti Networks MIB module

FOR MIMOSA

snmpget -v1 -ctheword 10.10.10.20 1.3.6.1.2.1.1.9.1.3.5
SNMPv2-MIB::sysORDescr.5 = STRING: The MIB module for logging SNMP Notifications.

snmpget -v1 -ctheword 10.10.10.20 1.3.6.1.2.1.1.5.0
SNMPv2-MIB::sysName.0 = STRING: SplawnNewClark

snmpget -v1 -ctheword 10.10.10.20 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: AIRSPAN-B5c

FOR MICROTIK

snmpget -v1 -ctheword 10.10.10.30 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: RouterOS RB750Gr3

snmpget -v1 -ctheword 10.10.10.30 1.3.6.1.2.1.1.5.0
SNMPv2-MIB::sysName.0 = STRING: honeybkrtr

snmpget -v1 -ctheword 10.10.10.30 1.3.6.1.2.1.1.9.1.3.5
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-MIB::sysORDescr.5 zz0.w57mofxujmrzz

[tlkhorses]

And for whatever reason, the Ubiquiti equipment is now working correctly. Correct template only. The others are as described as above.