TECHZEN Zenoss User Community ARCHIVE  

getRRDValue from Components\Interfaces

Subject: getRRDValue from Components\Interfaces
Author: Vaclav Cerny
Posted: 2017-08-10 12:02

Hello,

I would need to get value for threshold from Components\Interfaces. I normally  use for my thresholds function getRRDValue('data_point_name'), but I don't know the right path for individual interface, which is modeling under Devices\Components\Interfaces.

Thanks for you time.

------------------------------
Vaclav Cerny
United Networks SE
------------------------------


Subject: RE: getRRDValue from Components\Interfaces
Author: Patrick McMahon
Posted: 2017-08-11 10:19

Are you saying you want to reference a property modeled on the Interface component?
E.g. here.linkSpeed


------------------------------
Patrick McMahon
Sr. Client Services Engineer
Zenoss
------------------------------

Subject: RE: getRRDValue from Components\Interfaces
Author: Doug Syer
Posted: 2017-09-01 13:49

not enough information here but assuming you are trying do do something like do a threshold of interface errors as a % of packets.  

in the threshold:

here.getRRDValue('dpname') 

by the way I used to use this alot on interface thresholds to threshold on the % of packet errors.  so I had a threshold on the packets/sec and i was doing (here.getRRDValue('packetcounterdpname') or 1e12) *.005 (to get a threshold of > .5% errors/second) but...when i updated to the latest 4.2x RPS...it caused a major issue with the invalidation workers on the hubs..basically caused a backlog of work that caused the workers to disconnect from rabbit (some of those disconnect issues are fixed in newer code i believe but the bottleneck will still cause your invalidation to grow and potentially never get processed and can also cause config download issues ie silent polling failures)...

I think here.getRRDValue(X) will be fine for a limited amount of data points or if you have fast collectors or a single zenoss instance but at scale with a lot of collectors its dangerous...id use the calculated data source instead but that also can cause different bottleneck issues...those issues however are much easier to detect and not as catastrophic as silent config download failures etc.

that may all be fixed on Zenoss 5 or less of an issue we are migrating to that now but as a warning at a large scale (thousands/tens of thousands of interfaces in our case it is risky..)

------------------------------
Doug Syer
NWN Corporation
Waltham MA
7814723492
------------------------------


< Previous
Has anyone monitored Unix/Linux Syslog / App logs using SSH?
  Next
Value change threshold
>