Philosophy Sanity Check - Discovery, Triggers

[Linwood]

Can someone see if I'm understanding this correctly. Been diving in for several days and want to see if I'm thinking in the proper way.

Am trying to set up discovery so as to minimize the post-discovery work.

First observation is that you must do all of your own actions. I didn't see any out-of-the-box actions, and haven't found much floating around. Maybe because they are easy, but I'm finding them to be a bit hard, because...

Second observation is that discovery appears to have a rather vague, arcane but quite limited amount of logic available to select templates. As a simple example, I have devices whose community strings are "public" (and cannot be reset) and others that are only V1 (V2c won't work at all), and others that have been set to another community string.

I managed to get the string itself taken care of by doing a separate discovery for just that string, adding a template that had ONLY a macro in it, then attach the same SNMP templates on both the "public" and non-public ones. No problem. I could not manage to figure out how to tell V1 from V2c, since the V2c hosts respond to V1 as well.

I tried doing a =V1 check and <>V2c check but with no luck, I got inconsistent results. In fact anytime I tried to refer to two different checks (in the same rule) I got inconsistent results, maybe it's not doing all the checks before executing the rules?

Third observation and biggest concern is that the logic in the checks is tied to the subnets, and the actions are tied to the checks (which means they are tied to subnets). It would APPEAR that if you get a pretty complex but working setup for discovery, you then have to clone EVERYTHING to apply to other subnets. Or you have to go in and change the one you have. There's no real segregation between subnet, rules and actions.

So where I ended up is that I got a nicely working set of rules and actions for some common devices, not terribly complex but not simple either, and now if I want to expand to other subnets I copy-copy-copy. as I (inevitably) add complexity I must copy all that complexity into the rules and actions in each subnet.

It's as though I'm missing a level of abstraction?

Or am I?

Or am I over-analyzing it- do most people do a cursory discovery then hand-edit everything and so don't care about discovery accuracy?

[steveboyson]

You got the point, in a heterogeneous environment as you described this will definitely become a nightmare.

I'm not that familiar with autodiscovery but isn't it possible to have a "decision item" which exists only on v1 devices and a different which is existing only in v2 devices?
What I read so far indicates that SNMPv2 is downwards compatible to SNMPv1, so in theory it should not make a difference if you query a v2 device with v1. Differences are only the PDU format an "bulk requests" whic Zabbix does not perform AFAIK.

Perhaps your SNMPv1 devices have one thing in common which the v2 devices do not have. This (OID?) could be the difference mentionend before.

[Linwood]

What I read so far indicates that SNMPv2 is downwards compatible to SNMPv1, so in theory it should not make a difference if you query a v2 device with v1. Differences are only the PDU format an "bulk requests" whic Zabbix does not perform AFAIK.

Perhaps your SNMPv1 devices have one thing in common which the v2 devices do not have. This (OID?) could be the difference mentionend before.

Yeah, and that's more example than the core problem. However there are issues with using V1 (lack of 64 bit counter support in switches and routers) that will eventually be an issue, as well as bulk transfers if it can do them.

And perhaps more to the point, most of the ready-made templates are SNMP V2 only, and I don't see a way to parameterize that.

It's more how all this is tied together. I love templates, it's a very nice way to handle trigger and check production. But it seems that same kind of abstraction layer is completely missing in discovery. They built the framework for something like it (rules -> checks -> actions -> operations) but then intimately tied them together (e.g. the action tests are against a specific rule's checks, tied to a specific subnet, not something that could be generic).

I was rather hoping though you wouldn't agree with me, you'd point out that menu option I missed that let's these all be templated in some fashion and applied generically.

[steveboyson]

Well, items in LLD rules can't be "mass updated" but you can manually do a search'n'replace in the XML file.

On the other points I have to agree with you. As I said I'm not really experienced with autodiscovery and autocreation of hosts.

When we started with zabbix, we had an overall pretty complete picture of our whole network and defined different monitoring profiles (Linux, Windows, agentless, with or w/o Zabbix, and so on etc.)

Ater that we developed and assigned the needed templates and manually created one exemplaric host for each type. That one we cloned and gave the clones the correct names and IP addresses. Every now and then when a new host comes into monitoring we just clone an existing or assign templates manually.
So you see we are doing that part manually althoug we are working quite much with LLD rules (services, disks, processors, DRBD resources, disk performance, backups, virtual machines etc). But: manually.