SNMP traps + device mapping

Discussion:

harsszegi

2012-03-06 07:05:10 UTC

harsszegi [http://community.zenoss.org/people/harsszegi] created the discussion

"SNMP traps + device mapping"

To view the discussion, visit: http://community.zenoss.org/message/64961#64961

--------------------------------------------------------------
Hi,

maybe it is an obvious question, but couldn't really find it in the ZenOss event handling description guide.
My problem:

* I have a ZenPack, displays custom SNMP variables on a tab (i.e. I have some mappers that map a given SNMP variable to a device's local
variable)
* Some of the SNMP variables are being updated via SNMP traps
* The internal variables within the device are not updated "right" at the time of receiving the SNMP trap (thus, when the ZenOss even is being
generated from the trap), just "a bit later" (can't really tell you when).

How an I enforce mapping when a given event is being generated in ZenOss (i.e. my device mappers would map the updated SNMP variable
back to device variable at the time the trap is received by ZenOss).
Thanks,
--------------------------------------------------------------

Reply to this message by replying to this email -or- go to the discussion on Zenoss Community
[http://community.zenoss.org/message/64961#64961]

Start a new discussion in zenoss-users by email
[discussions-community-forums-zenoss--***@community.zenoss.org] -or- at Zenoss Community
[http://community.zenoss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2003]

Shane Scott

2012-03-06 16:42:35 UTC

Permalink

harsszegi

2012-03-06 20:27:36 UTC

Permalink

harsszegi [http://community.zenoss.org/people/harsszegi] created the discussion

"Re: SNMP traps + device mapping"

To view the discussion, visit: http://community.zenoss.org/message/64998#64998

--------------------------------------------------------------
Well yes, at least kind of. The scheduled modeling is done via SnmpClients as usual, they load up loads of OIDs.
There are a few though that are updated via SNMP traps as well. Actually these are also get updated via regular
modeling process, just that for me is not fast enough. Also tried using Event Manager, but that didn't help neither
as it is practically for event classes, but I needed individual events.
Anyhow I have figured it out, via using the event transformer + some Python scripts to enforce variable update
within the device + a commit at the end.
--------------------------------------------------------------

Reply to this message by replying to this email -or- go to the discussion on Zenoss Community
[http://community.zenoss.org/message/64998#64998]

Start a new discussion in zenoss-users by email
[discussions-community-forums-zenoss--***@community.zenoss.org] -or- at Zenoss Community
[http://community.zenoss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2003]

Shane Scott

2012-03-06 20:30:47 UTC

Permalink

harsszegi

2012-03-07 05:00:53 UTC

Permalink

harsszegi [http://community.zenoss.org/people/harsszegi] created the discussion

"Re: SNMP traps + device mapping"

To view the discussion, visit: http://community.zenoss.org/message/65015#65015

--------------------------------------------------------------
Shane,

maybe I don't see the full picture, but how could a synchronous (fast) modeler scale better compared to an asynchronous notification mechanism? I mean when the target device changes state (which is rare) it sends a trap to ZenOss. I.e. for a device it happens let's say 3 times a day at most (initialization, cover open, paper out). For 1000 devices, it is 3000 trap events. If I set a synchrnous modeler for 1 sec refresh, it means 86400 (60 refresh per minute)
SNMP get per device, that is 86400000 for all the devices.
What do I see wrong?
t.
ï»¿
--------------------------------------------------------------

Reply to this message by replying to this email -or- go to the discussion on Zenoss Community
[http://community.zenoss.org/message/65015#65015]

Start a new discussion in zenoss-users by email
[discussions-community-forums-zenoss--***@community.zenoss.org] -or- at Zenoss Community
[http://community.zenoss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2003]

Shane Scott

2012-03-07 05:25:09 UTC

Permalink

Shane Scott [http://community.zenoss.org/people/hackman238] created the discussion

"Re: SNMP traps + device mapping"

To view the discussion, visit: http://community.zenoss.org/message/65023#65023

--------------------------------------------------------------
harsszegi:

I see what you're doing better now. Judging by the trap meanings you reference, traps are a good way to do this, however, I don't think I'm following what you're talking about with zenmodeler in the initial post. Transforms or event commands can indeed do what them to do in this case and would be the best approach.

I think this all would have come across more clearly if you'd said something along the lines that you're trying to update attribute or property on a device object referenced in a trap event, if I'm understanding what you're looking for right.

I can't tell if you're being sarcastic or not in your reply. Forgive me if you're not, but it sounds like it.

Generally folks using ZenOSS are monitoring servers, services or network hardware. Sometimes even moderate sized instances can be very noisy depending on what's being monitored and the scope of the sysadmins control. Even yet, the volume of traps one could incur on a larger rollout would create an even more substantial overhead if processed in this manner in pre ZenOSS 4 instances.

The big items in ZenOSS which fail to scale well are 1) transforms, 2) plugin based reports calling getRRDValue and 3) Command datasources. It's not a complete list, but those are usually the least forgiving items. Keep them in mind when designing solutions.

Best,
--Shane
--------------------------------------------------------------

Reply to this message by replying to this email -or- go to the discussion on Zenoss Community
[http://community.zenoss.org/message/65023#65023]

Start a new discussion in zenoss-users by email
[discussions-community-forums-zenoss--***@community.zenoss.org] -or- at Zenoss Community
[http://community.zenoss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2003]

harsszegi

2012-03-07 05:33:46 UTC

Permalink

harsszegi [http://community.zenoss.org/people/harsszegi] created the discussion

"Re: SNMP traps + device mapping"

To view the discussion, visit: http://community.zenoss.org/message/65016#65016

--------------------------------------------------------------
Hi Shane,

"I can't tell if you're being sarcastic or not in your reply. Forgive me if you're not, but it sounds like it."

ï»¿
I wish I could be sarcastic :) because it would mean I know ZenOss to the deepest level so that I can judge
which approach is wrong or not. But that would mean I don't need this community forum, wouldn't it? :p

" I don't think I'm following what you're talking about with zenmodeler in the initial post."
Well initially I just wanted to force my collector plugin run via zenmodeler if a given trap is received, but that
would have also been an overkill as my collector plugin obviously gathers a lot more information than
this very specific OID (connected to the trap).

"you're trying to update attribute or property on a device object referenced in a trap event"
Sorry if I wasn't clear enough, but yes practically this is what I wanted to achieve, somewhat force an
"automated modeling" when a trap event occurs, so that the internal property of my device (that practically
reflects the state of an OID) is being refreshed at once.
--------------------------------------------------------------

Reply to this message by replying to this email -or- go to the discussion on Zenoss Community
[http://community.zenoss.org/message/65016#65016]

Start a new discussion in zenoss-users by email
[discussions-community-forums-zenoss--***@community.zenoss.org] -or- at Zenoss Community
[http://community.zenoss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2003]

Shane Scott

2012-03-07 07:36:54 UTC

Permalink