4 Common Myths in Network Monitoring
4 Common Myths in Network Monitoring
Let's debunk some of the common misconceptions about network monitoring.
Join the DZone community and get the full member experience.Join For Free
Before we start, I want to debunk one myth — the number in the title is not relevant. I have named these four off the top of my head and I want to share them after having spent a decade in the network monitoring space, or as Gartner calls it NPMD.
1. SNMP Is Dead
If there is one thing that has been constant in network monitoring over the last two decades, it has to be Simple Network Management Protocol or SNMP. It has been natively supported in almost all types of networking hardware offered by every major vendor. You have a generation of network operations teams using and relying on SNMP for network management.
I believe this myth or perception is more often used during discussions in the context of SDN or cloud, which is primarily an API-based architecture. However, for traditional datacenters, there is no way SNMP is going away, for now, when even new hardware has a native SNMP agent support. One major reason for this decision is that all traditional hardware and existing monitoring intelligence are heavily based on metrics collected from SNMP.
I completely agree that, going forward, more data will be exposed through telemetry, and monitoring tools have to adjust to this paradigm shift. SNMP has its limitations for modern networking, and vendors seem interested in investing in telemetry for a better, long-term solution.
2. Zero-Touch Self-Certification of New Device or Datasource
There is another version of this: "I should be able to use your networking monitoring tool to automatically add support for any device..."
Self-certification is a challenging use case, and though we have had great success with devices supporting SNMP, we can't replicate the same for those datasources, which use variations of standard protocols (JMS, HTTP REST, JDBC, and SCP) and various data formats (JSON, CSV, and YAML).
I have often come across same question from customers and wondered how best to describe the technical aspect preventing this goal of zero-touch self-certification. There will always be human intelligence required to understand, filter, and transform data to metrics. As a monitoring vendor, we can make this job easier by providing templates or a nice GUI, but it will still need to be driven by network engineers and not application developers.
3. SD-WAN Is a Replacement for MPLS
To start with, this comparison is incorrect. SD-WAN is an overlay technique, which allows for application-aware routing based on policies. MPLS is an underlay technique that routes traffic based on labels and comes with SLA, which is, thus, suitable for branch-to-branch connectivity.
SD-WAN surely needs some underlay to transport data (e.g. MPLS, LTE, Broadband) and, as such, should not be seen as replacement. It will be more appropriate to say that SD-WAN technology compliments MPLS.
Enterprises do acknowledge advantages of SD-WAN in terms of transport utilization, bandwidth requirement for SaaS applications, and CapEx, but that doesn't mean they are replacing MPLS. One of our customers (a US-based financial institution), which uses both MPLS and broadband, summarized nicely by calling their SD-WAN deployment a hybrid WAN where dual MPLS is preferred for large offices and SD-WAN is preferred for small/medium offices.
4. Network Monitoring Is Not a Priority After Moving to the Cloud
Your cloud provider will not, and should not, triage your network connectivity and performance issues. Cloud providers don't have any obligation to define metrics, collect them, and generate meaningful events/alarms on your behalf. Plus, they don't have visibility inside your datacenter or applications traffic usage. Moving your applications to the cloud or using cloud infrastructure does not mean that all your networking issues are solved.
Enterprises who have extended their datacenter in the cloud with a VPN connection or a dedicated AWS DirectConnect, like service, have bigger challenges and must evaluate cloud monitoring use cases before selecting any network monitoring tools. This is a good use case for hybrid monitoring, where data from SNMP (datacenters) and REST (cloud provider) must be collected, correlated, and presented in a unified way.
Wanted to share a bit more about flow data, but this blog has already summarized it nicely.
As always, I welcome your feedback and comments.
Opinions expressed by DZone contributors are their own.