weathermap to show int status instead of traffic utilization

[Howie]

That sounds good!

You are right. They are usually shared, but it is also normal to have different sets of credentials per customer for example, thinking on large deployments.
I wouldn't include the hostname, if we are talking about shared profiles in most scenarios.
Will you be able to create as many profiles as you want?

Yes, it would just be a series of SET variables. There's no (deliberate) limit on those.

How would you store the credentials? I've never used wm standalone but I haven't seen any option to create set of variables or parameters apart from the .conf files. Will that include a new menu option on wm editor? What are the options?

Well, it would be SET variables in the top of the map config (or in the cacti database if you use the 'special settings' feature on the map management page). OR, with the 'import' option (#3) above, they wouldn't be stored anywhere, just fetched from the Cacti device settings just before the map is calculated. That's why I like that option - there's nothing to keep up to date (apart from the host_id you are importing from, if the map moves to a new Cacti box), and nothing sensitive in the map config file.

So you could have something like:

Code: Select all

# import the snmp settings from a device for each environment
SET snmp_CORENETWORK_import 2
SET snmp_CUSTOMER1_import 22
SET snmp_CUSTOMER2_import 33

[......]

LINK link2323
   TARGET snmpv3:CUSTOMER2:10.1.1.22:1.3.6.1.2.1.2.2.1.8.10:-

[Pucho]

Sounds promising. I think that'll do it and no sense on making it more complicated.

My current setup involves cacti so I'm happy with the import option. I think the only ones concerned about plaintext password will be those running standalone wm.

I'm looking forward to enjoy this improvement.

[aftershocks]

Hey Howie,

Just curious... It is possible to change the bandwidth label based on utilization? So the link colour is based on interface status, but then the label is based on utilization.... That would be pretty cool..

Thanks...

[aftershocks]

I have a question Howie...

So I have the interface status working perfectly fine, thanks to you... There was a time where it was showing incorrectly, but not because of the configs...

The setup is this.... There's a circuit... It spans across data centers...

Device A is in DC1 and Device B is in DC2.... This circuit is of course, provided by a ISP.... so Device A and Device B are not "directly" connected... They connect to a PE upstream..

Now, the experience I had was that the Device B side connecting to the PE device - the link went down...

However, since I can only specify one TARGET only, it just so happened, I specified the Device A side for the interface status... Which was "up" at the time even though the connection is broken on Device B side..

Is there a way I can have 1 arrow from the Device A side for one TARGET and the other arrow connecting to the Device B side another TARGET? That way it will show RED for the side that Device B is connected too.. But GREEN for Device A.. Half and half...

Does that make sense or did I confuse you?

Thanks!

[Howie]

You can have as many targets as you want, and they can contribute to either the 'in' or 'out' side of a link, or both... (actually there is a limit on the length of a config line, it turns out, but it's 4000 chars or so and can be increased).

With SNMP and rrd files, you specify two DS names, one for 'in' and one for 'out' on each target string. If either one is '-', then that target doesn't contribute to that side of the link.

At the end, all of the target strings are summed, for in and for out and the result is used to figure out the colour.

So:

Code: Select all

LINK inter-dc-1
   NODES dc1edge dc2edge
   TARGET dc1_iface_state.rrd:if_status:-  dc2_iface_state.rrd:-:if_status

Would do what you want, with rrd files. The same works with SNMP targets - just replace the OID with '-' instead.

Make sense?

[aftershocks]

Ohhh that kind of make sense.. Let me give it a shot... I'll let you know how it turns out..

As always, thanks Howie!

[aftershocks]

I think I got it working now Howie.. I just gotta test it in the event of a failure..

I do have another question.. You mentioned that you can specify as many targets as I wish on either the IN or the OUT... If I specify multiple targets say, the IN, how does it know to change colours? So this is just an example...

I specify two targets on the IN stream... 1. Interface status and 2. Bandwidth... I want the link to stay green when it's UP but also, have it change colour based on utilization... I mean, even if I have the SCALE defined for each target (interface status and bandwidth), which one will take effect/precedence when it comes to colour?

[Howie]

I've been meaning to make some kind of video or diagram about this, to illustrate the stages...

1) each of the space-separated parts of the TARGET line are collected from whatever source they come from -> that gives you two numbers for each part - in and out. Some plugins only set 'in', or set both to the same, but there are always two values.

2) all of the 'in' are totalled, and all of the 'out' are totalled. If there are any prefixes on the targets (like 4* or '-') these are applied.

3) each total is compared to the BANDWIDTH/MAXVALUE to get a percentage for in and out. BANDWIDTH also allows for separate in/out maximums, if you have something like an ADSL link.

4) Unless you specifically say to use the absolute total in a USESCALE command, the percentages of the totals are used to decide the colour for the in and out sides of the link. In the case of a NODE, whichever one you specified in the USESCALE is used. Nodes still have 'in' and 'out', but only one colour is needed.

Most of those values get stuffed into variables where you can get to them using {link:this:something} in labels or comments. E.g. you can have the colour come from a percentage and add a comment (or bandwidth label) on the link with the absolute value if you wanted to. Percentage is generally easier, because even for different sized links, 75% full is bad. When you get away from bandwidth, there's more reason to think about absolute scales. However, the default for nodes (not links!) is that MAXVALUE is 100, so for anything with a total less than 100 like interface status, it doesn't make any difference.

[aftershocks]

Thanks for the detailed explanation, Howie! Much appreciated...

[Howie]

Going back a thread (there are at least 3 different problems in this thread!)... I have the SNMPv2c and SNMPv3 with the profiles and profile-import that we talked about, working now It's nice. It'll be in 0.98a or whatever it is called. In theory, it'd work with 0.98, actually.

[Pucho]

Going back a thread (there are at least 3 different problems in this thread!)... I have the SNMPv2c and SNMPv3 with the profiles and profile-import that we talked about, working now It's nice. It'll be in 0.98a or whatever it is called. In theory, it'd work with 0.98, actually.

Very very good news! I've been stalking this thread waiting for this hehehe

btw, wm is using php-snmp extension right? I had to unload that extension to force cacti to use net-snmp package because I was getting tons of "Partial Result". I haven't investigate much about it..

[Howie]

It does, yes. I've never had too much trouble with having it enabled (over quite a few years).

[Pucho]

Is it on the master or one of the branches? I'm keen to test it.

[Howie]

You want the most recent commit on the database-refactor branch.

At some time soon, I'll probably fold everything up back into master, and move to proper feature branches etc.

[Pucho]

So far I tested this

SET snmp_core_import 61 (manually added to the snmp.conf file)

Node config
TARGET snmpv3:core:X.Y.Z.5:1.3.6.1.6.3.10.2.1.3:- (added from web editor)

and I'm getting

11/04/2016 08:32:04 AM - WEATHERMAP: Poller[0] WARNING: [Map 43] snmp.conf: ProcessTargets: NODE node05268, target: snmpv3:core:X.Y.Z.5:1.3.6.1.6.3.10.2.1.3:- on config line 46 of /usr/share/cacti/plugins/weathermap/configs/snmp.conf was not recognised as a valid TARGET [WMWARN08]

I've got the whole debug of this map if you want, but couldn't see any other error.

I'll update this while testing the rest of it.

EDIT: wait a minute, my mistake, i wrote snmpv3 and it's snmp3/snmp2c. I'll update in a minute hehe

Cheers,