10 Orion Platform Connected Use Cases You Should Know Part II

10 Orion Platform Connected Use Cases You Should Know


Part 2:

In Part 1 of the blog series, we looked at four examples of how functionalities on the SolarWinds® Orion® Platform helped solve problems more collaboratively, adding layers of insight to help solve problems quicker. We focused on network paths, their health and performance, traffic, devices and users of those paths, configuration issues, and how a change in one of these impacts the other. In this post, I’m going to highlight three more great examples. Let’s pick back up where we left off, and start with the 5th Orion Platform use case you should know.

5. Is the network fit to support the expected service levels?

When it comes to the next bit, I can't help thinking of a phrase we hear more often in recent times during our working day: “Could everyone on the call who’s not speaking please turn off their video?”

When dealing with deterministic applications on the network such as Voice over Internet Protocol (VoIP), you need to have the ability to measure jitter, packet loss, voice quality scoring, response time, etc. at the Internet protocol service level agreement (IP SLA) source. If this is below par, the end-user complaints will follow. So, how can we correlate this back to the responder, application server, connections – whatever? This is where VoIP & Network Quality (VNQM) works in tandem with Network Performance Monitor (NPM) to become a winning combination on the Orion® Platform for root cause analysis—giving you rich VoIP metrics and deep insights into network health and performance.

If I may veer slightly off-topic, it’s worth mentioning the accelerating trend to Software as a Service (SaaS)-based solutions and the transition to softphones here. The topic of cost reduction is always looming in the background. In relation to VoIP, some clients may find expensive SIP trunks being wastefully underutilized and unnecessary maintenance charges being paid for, like “shelved” physical phones. VNQM is a great tool to help root out these issues. For more on this, watch this video.

6.How to avoid wasting time rebuilding IP groups in NTA which have already been created?

This is an excellent use case allowing users of IP Address Manager (IPAM) and NetFlow Traffic Analyzer (NTA) to avoid duplication of work by referencing existing IP groups and using those within NTA to view group traffic or compose custom applications. We’ve enhanced our flow alerting to incorporate filters for IP groups and endpoints to complement this capability. For more information on this and a short tutorial, you can always check out our THWACK® Tuesday Tip.

Another integration worth mentioning is between IPAM and User Device Tracker (UDT) which refines troubleshooting during an IP address conflict to minimize downtime. When both of these modules are present, and IPAM flags an IP address conflict, the integration with UDT lays out detailed device and switch port information to aid in troubleshooting. Historical data on IP address usage reveals which device had the IP first. Using the remote shutdown option, you can immediately cut off the network connectivity of the problematic device.

While we're on the topic of IPAM, let’s throw in a final example and loop back to example 3, which we explored in Part I. This example was around the combination of NTA and UDT to root out bandwidth hogs. The IPAM and UDT integration makes filtering out rogue devices on the network easier by providing a single view of IP addresses and corresponding endpoint connection/location details. This enables improved troubleshooting and enhanced network access protection with a port shutdown. When both IPAM and UDT are installed, IPAM displays corresponding switch port details and user information within the same integrated view. This helps you quickly track down and resolve network issues before they cause significant problems. 

7. Was the change in server or application configuration the cause of the performance or outage?

We’ve had a few network examples; let’s look elsewhere in the stack.

When the performance of business services slow down or become unavailable, there can be many causes. This may turn out to be something external to the server(s) on which the service is running, such as network problems. Or, it could be that someone, either in error or worse, maliciously, implemented an improper configuration change to the server, database, application, registry entries, etc. The consequences may vary from mild to catastrophic—hopefully not the latter, but how do you attribute the issue to configuration change when this is the case?

Server Configuration Monitor (SCM) is designed to quickly reveal when server, application, or database configurations change, who’s changing them, what changed, and performance impact. This gives you the necessary visibility to troubleshoot faster, improve security, and demonstrate compliance. 

When a server is down or performing poorly, the change data collected by SCM can be combined with the performance, health, and availability metrics collected by other Orion Platform-based modules in a single visual timeline via PerfStackTm. Combining these two sets of data allows you to easily see if an application or server configuration change was the source of a performance issue or outage.

See you in Part 3 for the last few examples.

Thwack - Symbolize TM, R, and C