Zabbix SNMP autodiscovery (Like cacti)

[a1ex]

Hi All,

I don't suppose the "Auto-Discovery" talked about for 1.4 is similar to the SNMP auto-discovery within Cacti?

That's something I really miss and would love to see implemented.

Makes monitoring various ports on routers much easier!

[kanour]

this is true. OpenNMS has got something similar.

[Alexei]

Please can you elaborate more on SNMP auto-discovery functionality provided by Cacti/OpenNMS?

[PeterN]

Hi,
If you are going to implement autodiscovery in Zabbix,
taking a look at netdisco and this document may be usefull.

http://archiv.tu-chemnitz.de/pub/2005/0045/data/diploma_thesis_alexander_barthel.pdf

Regards
Peter

[Alexei]

Thanks for the document.

[a1ex]

When you first add a host to Cacti, it basically walks parts of the SNMP tree and presents the results so you can select what you want to monitor.

This can include the interface table, so you can pick an interface to monitor for things like bandwidth/errors, and things like memory/CPU usage.

Cacti lets you define auto-discovery templates so that you can import a template (i.e. for a cisco router) and when you next add a Cisco router, Cacti auto-discovers the bits in the template (things like temperature/voltage OID's) and presents them as easy "tick here to graph" options.

Much easier than having to remember SNMP strings and manually having to define hundreds of interfaces.

[mucknet]

This is what I was trying to describe here:

http://www.zabbix.com/forum/showthread.php?t=5726

[kanour]

Hi Alex.

In OpenNMS snmp works in very good way. I am not going to repeat others but I would like to point out the whole idea and how it should work. To make it simple I will state just points here and anyone can add what they think.

1/
Discover predefined group of devices on particular range of IPs with particular community string and assign template with OIDs to this group.

1. User should be able to define group of devices with same community string ( same community string means usually same devices in our company) and range of IPs for scanning.
2. Autodiscovery should then offer to get OIDs from device and create new template for this particular community string. This template should be as current templates which can be edited or cloned for purpose of disabling some OIDs which don't need to be monitored or adding OIDs if needed.

2/
Discovery process outlined above can work for not only SNMP but also for zabbix client or anything else. I am not sure how others but my brain tells me that the autodiscovery process should in general look like:

• create group
• set community string for group (rule)
• set network range for group (rule)
• scan network
• get OIDs
• create template
• put OIDs to template
• edit OIDs in template (disable/enable/edit)

(This is almost same principal as zabbix has now, but rules are created for group not for host.)

3/
Once the discovery service found all hosts user should be able to anable them or disable from monitoring. Also link with another template in case of that one host needs to be special.

4/
Once the the host is monitored it should take its hostname from OID or we should be able to override this to something else. Then we can view all monitored host in the same way as now in zabbix.

This is my idea of full autodiscovery. Feel free to comment or change.

Jiri

[NOB]

Hi,

just my 2 cents of input.

2/
Discovery process outlined above can work for not only SNMP but also for zabbix client or anything else. I am not sure how others but my brain tells me that the autodiscovery process should in general look like:

• create group
• set community string for group (rule)
• set network range for group (rule)
• scan network
• get OIDs
• create template
• put OIDs to template
• edit OIDs in template (disable/enable/edit)

(This is almost same principal as zabbix has now, but rules are created for group not for host.)

Jiri

This is fine for me. But, as soon as you mention zabbix agent,
I am missing "system.uname" and the equivalent for Windows
on your list.

We are distinguishing between basic OS monitoring (syslog, root filesystem, sshd) and application
monitoring (logfiles, open ports, application specific filesystems on SAN, NAS, etc.).
So what we like is to use a template based on the OS (and perhaps version).

That would be rather nice.

The current autoregistration (1.3.4) is limited but much better than
nothing, at all.
It'll save us a lot of time and we can change the template based
on the system info anytime.

I did not, yet, take a look what's in 1.3.5.

Norbert.

[Alexei]

This is fine for me. But, as soon as you mention zabbix agent,
I am missing "system.uname" and the equivalent for Windows
on your list.

We are distinguishing between basic OS monitoring (syslog, root filesystem, sshd) and application
monitoring (logfiles, open ports, application specific filesystems on SAN, NAS, etc.).
So what we like is to use a template based on the OS (and perhaps version).

That would be rather nice.

Note that currently ZABBIX 1.3.5 lacks discovery based on input from ZABBIX and SNMP agents, it will be supported in 1.4 though.

[Alexei]

Thanks all for the input, very handy indeed!

It seems that we have a great demand for a better (simpler) SNMP configuration and monitoring. We will try to address this in future releases.