Report is showing incorrect information

I have a report that runs monthly for some of our sites that pulls in the availability of the FW, APP, and DB server. However, the FW percentage is much lower than the APP and DB servers. This doesn't make any sense...how can the two nodes that depend on the FW have a higher availability than the FW?

The sites are in order too.

As you can see below the site second from the bottom has 90.262% availability, where as the APP and DB servers have 100% availability...how?!

Find more posts tagged with

report writer

Availability

report

Accepted answers

All comments

rschroeder

You asked "how can the two nodes that depend on the FW have a higher availability than the FW?"

The answer might lie in discovering which APE's poll each resource. I don't know if you have Additional Polling Engines (APEs) but imagine you do. Now imagine a polling engine is installed that is local to the App Servers and DB Servers, and is configured to poll them and report their availability. That APE isn't monitoring any firewalls.

Now imagine a different poller, perhaps across a WAN or VPN pipe, is responsible for polling the firewalls at all sites.

If the WAN or VPN should fail, or experience enough congestion to be dropping packets, Solarwinds will report the firewall availability as low, while simultaneously using data from APE's that are local to the Servers to report their availability is higher. In this case availability all depends on the point of view of the polling engine responsible for the resources being polled.

Do you have the same poller(s) monitoring the same servers and firewalls? Or did you separate polling based on logic that works for your reporting to administration? By this, I mean that availability statistics are sometimes considered most important when they apply to the users of one resource and not another. For example:

Three sites, A, B, and C have servers and firewalls AND Additional Polling Engines.

Site A is your main hub site, and its APE monitors all the remote firewalls.

Sites B and C have local APE's that monitor servers within these sites--local to the APE. Maybe this was done to show the actual latency between local users and their local servers.

Your Availability Report naturally shows better up time for servers because their polling (by a local APE) is not affected by WAN or VPN problems. And your report also shows less availability for firewalls than for servers because the firewalls sometimes are not able to respond to the Site A's polling engine due to WAN or Internet challenges.

rmullal

Thank you for the detailed explanation. This makes more sense.

All those node are indeed scattered across multiple different polling engines. I guess the solution would be to put all these nodes on the same polling engine?

d09h

If SNMP polls go unanswered (one possibility), consider regaining some visibility with traps or syslogs. Consider monitoring the upstream interface of the downstream device and the downstream interface of the upstream device.

rschroeder

Putting all monitoring of remote servers and firewalls on the same polling engine is one way of generating data, but only you and your management team can decide if it's the right way for your users.

From my "network-centric" remote-support point of view, I'm sitting in the middle of the network, relying on Solarwinds to tell me conditions at ALL sites, no matter how far away they are, no matter what resources they may have locally.

I'm responsible for ensuring connectivity remains available between all points on our network, no matter whether they pass across VPN tunnels, are located in the cloud, or are directly connected LAN or WAN sites. And my reports only show connectivity solely from my centric point of view.

Let's talk about remote users working across the network at a distant site. Maybe that site is SO distant that Management decided those users need their own local resources in some situations. They may have their own local databases, servers, DIA, SAN, apps, etc. If I monitor those systems from my location, the statistics don't show an accurate set of data from remote users' points of view. Maybe I see 100 milliseconds of latency between my site and a server a thousand miles away. And I might know that the mission-critical application users rely on can only tolerate 20 milliseconds of latency. Statistics generated from my location would prove users can't be successfully accessing their important application because of the high latency.

Buy THEY don't have high latency at all . . . We know that they have their own local server and database at their site, with sub-millisecond response to their local needs. So I install another polling engine at their site to measure their actual latency from their point of view, not from mine. Their local polling engine only polls their local systems, and then it reports that latency to NPM's main instance, which publishes it to my NPM front page. And the stats look good--they show what those remote users are seeing for local latency to resources they need.

But! I don't want to rely on that distant poller to tell me if that remote firewall or router is up and running. I need to know that data from MY point of view for corporate availability reporting. So I use my poller at the center of my network to monitor the remote site's firewall, but NOT monitor the remote site's servers and database and LAN switches; I leave that up to the local APE at the site.

Sometimes I'll poll two different devices at that remote site from two different APE's--one for local uptime/availability, another to prove the WAN or VPN pipe is up and running from my site's point of view. This has caught several WAN provider errors, and been a huge help in identifying them.

Now my report is accurate from a corporate availability point of view AND from the remote users' point of view.

The key item is deciding what data is important to which users, and then setting up your pollers to properly represent the data accurately from the right points of view.

rschroeder

This is a good reminder! Thanks d09h.

SNMP traps and syslog messages are BOTH required for the right data to reach a network administrator.

When Solarwinds only uses ICMP to determine availability, it gives us only one part of the picture. Set up traps AND syslog information to be sent from your switches, routers, and firewalls to an appropriate receiver that you can easily query and review. Even better: make that receiver a SIEM that analyzes traffic patterns and alerts you when malicious or suspicious behavior / traffic are happening.

Don't forget to size that receiver or SIEM appropriately for the task at hand. Some like to receive debug-level info from Cisco firewalls and wireless controllers, so they have all the pertinent data to discover problems and report them. But the amount of traffic that can be generated by firewalls and WLC's can overwhelm a logging reporter or SIEM if it isn't sized appropriately for the demand. Learn what your total messages per second will be at the maximum expected rate and size your logging reporter or SIEM to meet that demand before buying. And add some extra size to the SIEM or logging system for future growth. You don't want a logging system that can handle today's needs but not those that are added into your network in the next few years.