Orion Maps memory thresholds for Cisco ISE are not useful, how can we correct this?

In Orion Maps my Cisco ISE nodes are showing a yellow for excessive memory consumption. This is a false condition, the memory consumption is 26%, the buffer cache is making SolarWinds trigger the 80% threshold.

I understand why this is happening, how do we correct it? Obviously I can set any threshold I want on alerts. But this is the "are we ready to do business today" dashboard, and it is showing yellow alarms when our authentication system is at 26% memory consumption. SolarWinds should be able to give me the tools to do something useful here. A dashboard alert is still an alert, how do I set my thresholds for dashboard alerts?

George

Find more posts tagged with

npm

orion maps

cisco ise

Accepted answers

mesverrum

Sounds like you think im talking about a UNDP, im not. If you follow that link it is the place you go to change the memory calculation used on specific nodes and this does replace the native model and will control the status as it is displayed in maps and just about anywhere else in the platform. You can manipulate this, within the limits of what SNMP exposes. This is the most common response to people who want to make different assumptions than the Orion devs did with how to display the combination of memory buffers and free space and all in linux based systems. There have been replacement pollers for ISE floating around for about a decade, although the thwack migration a few years back made it hard to find some old posts and file attachments from the old forum.

Thing to keep in mind is SW could have just natively changed their default poller for these devices, but over the years they have been incredibly resistant to making changes that break existing alert rules for customers. So the pattern one should come to expect from SW is that they rarely go back and change how things work on their side to address edge cases, they usually just add new options for the users to control things on their end. Point is there is a built in way to work around the issue you have via the device studio.

adam.beedell

I think the answer is just "bulk set a new threshold against that 'volume' per ISE device"

All comments

mesverrum

Instead of using the out of the box top xx dashboard widgets you could just use a custom table widget, or roll your own SWQL custom query that only displays nodes that are violating their thresholds, and then just adjust the thresholds of individual nodes or disks instead of having a static 80% threshold across the board.

documentation.solarwinds.com/.../core-customize-thresholds-per-object.htm

keoki

This is a good response, if I was using the dashboard tool, but I am using Orion Maps. Orion maps allows me to display summary objects, so if the top level map objects are green, the entire environment is green. If there is a problem in a lower system, the operator can drill into the map to see the issues. We are one of the largest retailers on the planet, so creating a dashboard that is based on tabular lists quickly becomes unwieldy, and it is difficult to fold the whole enterprise state up into a single easy to read screen. I really like Orion Maps, it meets our needs, except that the thresholds are not readily configurable (so far as I know).

mesverrum

Orion maps almost always display based on the individual entity thresholds, so that link i sent should be the best solution for what you are asking. If something is red and you disagree then just tweak the thresholds until it is not longer violating.

Regarding the large retailer situation, I have been consulting in the monitoring and observability space for over a decade and for big customers I still mostly prefer tabular lists, but we apply filters to only show actionable data and would write my queries with enough case logic that they basically just told operations folks everything they needed to know and collapsed everything else out of sight and out of mind. Aiming at a 10,000' view full of green dots can give a nice feeling of satisfaction but mostly its just clutter and distractions.

mesverrum

re-reading your original post it feels like maybe you are trying to say that you think the actual data collection for the ISE is incorrect? The ISE is reporting 26% via maybe its internal CLI or some other way?

In Orion are you seeing the violation in relation to the RAM metric or is it inheriting a bad status from a volume?

First thought is I don't normally monitor buffer caches, they always report a high number because an empty cache is wasted space and they know how to empty themselves anyway without a human intervention. No real actionable data being collected so its just noise. If its the RAM calculation that you don't like you can actually redefine the way Orion calculates RAM for SNMP entities by messing around with a thing called the device studio documentation.solarwinds.com/.../core-creating-device-studio-pollers-sw2534.htm

adam.beedell

I think the answer is just "bulk set a new threshold against that 'volume' per ISE device"

keoki

Yeah, that was the first thing I tried to do, but I could only find interface settings.... but I found them now so you helped inspire me to push harder on thresholds.

Thresholds are the "wrong" answer, the better answer is to correct the poller so that it does the math using two oid's to derive the correct answer. HOWEVER this is the answer that is the best shortcut to tune the visual alerting.

adam.beedell

Glad it helped!

(Still not super sure based on the conversation how much of that value is custom polled vs OOTB. I think we're talking OOTB)
(It's possible to assign a custom thing mathing together the two other things, setting across the group and then disabling the old thresholds)
(or getting it by SLW as a bugfix or feature)
(90% of the time it's the quick fix until you find yourself doing that a lot right?)