C1CX

Achieving Monitoring Success with OnGuard

Mark — Tue, 15 Oct 2019 16:11:40 GMT

Monitoring systems are overloaded with complex data that can be difficult to parse. IT teams must act as detectives to weed out the noise, identify that a genuine problem exists, and diagnose and remediate it. Further complicating matters is the fact that many problems and issues can’t be detected and diagnosed based upon the data provided by applications. As a result, IT teams must employ a different set of methodologies to avert system outages. This article will share the steps to achieving monitoring success in spite of these challenges.

Monitoring has proven to be one of the more difficult components of IT for many years, perhaps because we make too many assumptions about how monitoring works and what the monitoring tools we use can actually do. We’ve all been mesmerized by demos at trade shows that boldly claim to have finally “cracked the code”! Unfortunately, after we purchase the tool, take it home, and install it, we begin the long, winding road to disappointment when it doesn’t do what we thought it would do. Alas, the tool just showed well on the trade show floor. Why is it such a struggle to find the holy grail of monitoring systems that can fix all of our problems? It’s simple: One tool alone can’t possibly fully monitor today’s complex IT environments—oh, and monitoring doesn’t work unless we have a full understanding of what’s really going on within our environment. In this article, I will review the monitoring issues around the data presented from our systems and applications and the steps to reaching a state of monitoring nirvana.

Step #1: Receive Comprehensive Data

One of the main issues with monitoring comes from a lack of understanding about the flow and value of data. First, let’s think about the initial source of the event we wish to monitor. Where does it come from? What does it say? Most tools are betting on the developers of software, hardware, and operating systems being able to provide clear, concise data that describes exactly what is going on with the code when something goes wrong.

If you ask software developers and engineers what percentage of their code base is for exception (error) handling, you will likely hear anywhere from 50 to 80 percent. Your initial reaction may be that this is a good number, but the key to handling exceptions in code is understanding the output.

Problems arise when we are unable to identify the full definition of the issue as soon as it arises. There is a subliminal miss when developers fail to consider that the error generated by their code is not being read by a fellow developer, but rather a managed services engineer who is keen on finding the needle in the haystack.

So, how significant of an issue is this? Well, let’s think back to the fateful December when Target got hacked. There were over 40 monitoring tools in place looking for security vulnerabilities or malicious behavior. Only one of the 40 found the issue, but it identified the behavior as “malware.binary.” What, exactly, does that mean? According to Quora, malware binary is “an executable program code which could also contain data/instruction for malicious malware program to run in your OS.”

Now, in hindsight, we understand what this means, but let’s think about the issue from when the Target hack occurred. What if the developer of the software spent another 12 seconds to type out something to the effect of, “malware.binary detected, found activity on system [insert the IP address] which indicates an infected system with malware, time to quarantine and take off the network”? If that didn’t work, the tool should have noticed the behavior was taking place on the point-of-sale systems—which are the kind of systems you really don’t want people to hack into, considering they contain credit card and other personal financial information.

At this point, you may be reaching the conclusion that the fix is a simple one: all we need is for developers to provide us with more comprehensive data. Not so fast. That is just the first step.

Step #2: Remove the Noise (and Solve Mr. Boddy’s Murder)

Even if we have perfect data that defines exactly what’s going on, we need to take the next step to remove the noise. In this case, noise is defined as things that are immaterial to the ability to understand what’s going on and what’s important. In other words, what’s important is defining, understanding, and resolving an issue—and if something isn’t contributing to doing any of these things, it’s noise.

Remember the statistic we shared earlier that in the course of developing code, programmers dedicate a large percentage to exception handling? Well, some of the exceptions that are encountered and reported are not truly problems that a monitoring application needs to further act upon. The true art is being able to identify which data points require further action within the context of the environment.

Think of it this way: In the game of Clue, we are tasked with solving Mr. Boddy’s murder, but the search for the killer is made simpler because we have a narrowed-down list of suspects, murder weapons, and locations to investigate. In the complex world of IT troubleshooting, a.k.a. detective work, it’s not that simple! Sometimes we don’t even know what we’re investigating. Chasing down false leads is a big part of the problem we need to resolve.

In summary, we know that within our complex unified communications (UC) and contact center (CC) IT environments, there is a wealth of information that becomes exposed via monitoring applications—but the quality of the information that our service engineers receive can sometimes leave much to be desired. Because of the network-based nature of our UC and CC applications, we require an end-to-end, multi-vendor approach to monitoring and management that is adept at weeding out the noise.

Step #3: Diagnose the Asymptomatic

Imagine that we have great data that tells us everything we need to know with no noise. Have we solved all of our issues? Not quite—and the next issue is a doozy.

Monitoring that’s based on waiting for data to be sent, captured, and analyzed accounts for a small percent of actual problems that occur. There are many issue types that cannot be caught by the standard method of what we call “traps” in monitoring.

Here are a few examples that can’t be monitored via standard Simple Network Management Protocol (SNMP) tools:

Logic errors: We configured our voice response system to be closed on Thanksgiving by date, but we forgot to update that configuration for the new year, and now we will be closed when we need to be open and vice versa. No monitoring application can monitor this since technically nothing is broken.
Bugs: Oh, bugs, you get us every time! We can’t monitor for something when we don’t know how it will perform. This is not referring to application failures that have known errors. We are talking about bugs that result in things just not working as expected.
Configuration errors: Yes, we could look for these, but they would not be represented in a failure in an error log/SNMP trap.
Compatibility: Whoa, now we are talking outside of a single system. How can we know if two or more things are compatible just by waiting for errors to be generated from an application?

The list keeps going, but you get the point. There is no single easy way to identify that something has failed and determine exactly what should be done about it.

I know what you’re thinking: Great, is there anything we can do to achieve true monitoring success (which we were fooled into thinking was such an easy feat when we witnessed that awesome demo on the trade show floor)? The answer is yes, but to get to that point, you need to think about monitoring differently.

Adopt the philosophy that there is a difference between good data and data that looks good.
Understand that a manual process to manage monitoring systems will create a cost that far outweighs the value of the things it can find—and that’s if you do it right.
Acknowledge that we can’t trust the data from developers and need to find a way to normalize the default messages to more meaningful instruction sets that describe the specific actions that must be taken.
Adopt another philosophy that if something is not “actionable,” then it shouldn’t be done. Graphs are pretty, but if you can’t make a business decision based on the data or measure the positive impact, then don’t bother creating or referencing them.
Accept that no one wants to keep their eyes glued to a screen, waiting for status updates. Skip the wasted cost of having humans sit around and wait for something to go red.
Recognize that no single tool, software, or method will work for all of your systems. You need a platform that can integrate and leverage the value of multiple tools and software.

We are all searching for ways to make the complicated easier to understand. You can achieve your monitoring vision— but you first need to understand the reasons why your current monitoring system doesn’t work and identify the steps to move into a mode that allows you to find the issues in your systems quickly and effectively.

Download the PDF of this Article

SD-WAN For Collaboration Cloud Deployments

Vicki — Tue, 08 Oct 2019 15:56:38 GMT

David Lover, Vice President, Strategy + Technology, ConvergeOne

ConvergeOne recently announced the availability of ConvergeOne Secure Connect, our new software defined wide area network (SD-WAN) managed services offer. In a nutshell, Secure Connect is a subscription-based, fully-managed SD-WAN that connects our customers’ networks to ConvergeOne Cloud Experience (C1CX) collaboration solutions. I know what you may be thinking: What is SD-WAN? It’s one of those terms that we’ve all heard of before, but few know what it really is, and why it’s a hot topic. Let’s dive a little deeper into SD-WAN and explore why Secure Connect is such a cool offer.

One of the things customers love about migrating to cloud-based Unified Communications (UC)/Contact Center (CC) is that they believe they no longer have to worry about the technology behind the scenes. They assume they can just subscribe to the experience, and everything will magically work. For me, the worst part about cloud-based UC/CC is that customers believe they no longer have to worry about the technology behind the scenes. Admittedly, they do get to stop worrying about a lot of it—but their LAN/WAN is something that they typically don’t get to stop worrying about.

In most traditional cloud deployments, there’s generally a hard network demarcation between what the customer is responsible for and what the provider is responsible for. This can sometimes cause problems, as the traffic is still real-time media. It still requires an end-to-end network—all the way from the cloud to the desk phone or softphone—that has low latency, jitter, and packet loss. Network routing must account for this type of service. When customers have networks that aren’t ready for this Real-Time Transport Protocol (RTP) streaming traffic, we end up having to pump the brakes on the deployment and wait for the customer to resolve this issue.

Of course, ConvergeOne has services that can take care of this for the customer. However, I find that in these scenarios, the issue doesn’t boil down to a lack of expertise but the fact that most customers still think of their networks in old-school models, where the focus is on device-oriented IP addressing, subnetting, and routing. Those things don’t go away, but you can’t think of a network as a series of devices anymore. There are so many things that complicate this model. For example, solutions like wireless and mobility become problematic. You don’t really know where those devices will pop up on the network, so you can no longer think of the traditional LAN/WAN architecture as being helpful in defining traffic, bandwidth, and routing. Further, with the proliferation of devices that are not dedicated to just communication (evolving from desk phones to softphones, PCs, tablets, and smartphones), you must separate the streams/sessions and treat them independently

The bottom line is that a lot of our customers realize that they need to do a major overhaul of their network to accommodate the new cloud services that they are subscribing to.

One of the most common ways to resolve this—without doing a complete rip and replace of the existing network infrastructure—is to overlay an SD-WAN solution over the existing infrastructure. This lets the customer keep its OSI Layer 1-3 based network in place, while creating a virtual layer on top of it that can intelligently leverage it, shifting the focus to services and individual sessions. Don’t get me wrong: This is no easy task, and many companies lack the internal resources to properly deploy, manage, and maintain SD-WAN. The good news is that this is where ConvergeOne Secure Connect swoops in to save the day!

ConvergeOne recognized that many customers who are deploying collaboration in a subscription- and cloudbased services model would love to extend the network demarcation to the inside of their network, all the way to the end-user’s communication device of choice. They’d also love to consume this in the same way that they consume the cloud service: subscription-oriented, and fully managed. This is exactly what ConvergeOne Secure Connect provides—and it does it with RTP services like voice and video in mind.

Unlike other SD-WAN products that use static VPN tunnels (similar to MPLS circuits), Secure Connect uses the same kinds of per-session oriented security, embracing the more modern “zero-trust” models. Individual sessions get identified by “services” that have specific characteristics associated with them, and are routed dynamically across the various virtual paths. Because it is designed with collaboration in mind, we can optimize session routing decisions based on collaboration-oriented metrics like latency, packet loss, jitter, MOS scores, and so on. This gives ConvergeOne the appropriate control of the customer’s network, ensuring that we can deliver the best possible experience while leaving the foundation network and security in place.

One of the things I think is pretty cool about our Secure Connect offer is that it provides customers with flexibility: they can use their own existing WAN links or have ConvergeOne provide the WAN connectivity. For customers who have a great foundation to start with for SD-WAN, ConvergeOne can check to see if their existing network is right for Secure Voice Connect and, if necessary, make recommendations. For customers who don’t have an ideal network, or perhaps would like to consume their cloud-based UC/CC completely independent from their existing infrastructure and have it fully managed by ConvergeOne, we can provide the WAN carrier services as part of the solution. The latter version of the offer allows us to provide a true end-to-end communications solution for the customer, guaranteeing the best SLAs possible.

The benefits to the customer are innumerable:

Enhanced reliability of real-time applications
Rapid deployment of cloud communications to any location, regardless of network transport
High availability, leveraging multiple carriers and WAN transport technologies
Enhanced Quality of Service through packet-by-packet route selection
Reduced costs with less complexity and hardware overhead
Highly secure, zero-trust security that provides ultimate control and encryption of all sessions
As-a-service delivery in a single monthly subscription

Secure Connect is a fully market-ready solution that can be deployed with any of our C1CX solutions. If you want to optimize your collaboration cloud solution, it’s time to take advantage of SD-WAN’s business value.

Download the PDF of this article