SAM 6.2 Beta - Because sometimes you feel like a nut - Part 1

There's been quite a bit of chatter recently surrounding the hotly anticipated release of Network Performance Monitor v11, featuring the entirely new Quality of Experience (QoE) dashboard. At the center of what makes all of this amazing QoE information possible are Packet Analysis Sensors, which can be deployed either to the servers running the business critical applications themselves, or to a dedicated machine connected to a SPAN port which collects the same information completely out-of-band for multiple servers simultaneously. For all intents and purposes, these Packet Analysis Sensors could be considered specialized agents, solely dedicated to the purpose of collecting packet data from the network. But what if these "agents" could be used to monitor other aspects of the servers they were installed on, or leveraged to address many of the complicating factors and limitations associated with agentless monitoring? These were precisely the kind of questions we asked ourselves as we were developing the Packet Analysis Sensors for NPM.

What are these "complicating factors" you might ask? It depends on your environment's architecture. It's quite possible you have numerous uses for an agent today that you're not even aware of yet. Either due to network design obstacles or security requirements and concerns, there are many organizations that have had to make compromises regarding what they monitor, how, and to what extent. This has left blind spots on the network, where some servers or applications simply cannot be monitored to the full extent desired, or not at all in some cases. With the soon-to-be-released beta release of Server & Application Monitor (SAM) 6.2 we take Orion into a brave new world without compromise.

So what exactly are some of the challenges many of us face when attempting to monitor our server infrastructure and the applications that reside upon them? 

You can't get there from here

This is a typical colloquialism you might hear when visiting the great state of Maine, but has been adopted by the IT community commonly to refer to situations where there's no route between two network segments. In most cases this is because one or both networks are behind a NAT device such as a firewall, and there's simply no way to get to the private address space behind the NAT without creating port forwarders, 1:1 address translations, or establishing a site-to-site VPN between the two networks. With the new Agent included in SAM 6.2, these problems are a thing of the past. This new agent supports two different modes of operation. In the scenario on the left, the Agent is functioning in "Agent initiated mode", which means all communications are initiated from the server where the agent is installed. No direct route from the Orion server or additional poller to the monitored host is required. No port forwarding needs to be configured at the remote site, nor do you need a pool of public routable IP addresses at each remote site for 1:1 address translation to each device you wish to monitor behind the NAT. With the agent installed on the remote Windows host, you can perform essentially all of the same node and application monitoring that you normally would for agentless hosts within your network, across what would otherwise be disconnected networks.

You want me to open what?

Such is the reaction you're likely to receive when you ask the network/firewall admin what ports you need opened to monitor the servers located in the DMZ. As I discussed in one of my early blog posts "Portocalypse - WMI Demystified" the port range WMI uses for agentless communication can be enormous. While this range can be significantly reduced, it does require either manual registry modifications or creation of a custom group policy. A reboot of each server that has its WMI port range modified is also required before the changes will take effect. As if that weren't bad enough, WMI won't cross most NAT devices. If your internal network goes through a NAT to access the DMZ, you're very likely unable to utilize WMI for monitoring any Windows hosts in your DMZ. To eliminate these issues, the new agent included in this SAM 6.2 beta allows you to operate the agent in a "Server Initiated" mode. In this mode the agent operates over a single port (TCP 17790) similar to "Agent Initiated" mode. The difference in "Server Initiated" mode is that TCP port 17790 is listening on the host where the agent is installed and the Orion server polls information in a similar fashion to SNMP or RPC, instead of having it pushed to the Orion server in "Agent Initiated" mode. Zero ports need to be opened inbound to the internal network from the DMZ, and all communication is done across a single NAT friendly port.

Peekaboo - I see you!

Whether it's the NSA, those willing to perform corporate espionage, or the black hat hacker who hangs out at your local Starbucks, it's important to keep prying eyes from peering into your organizations packets. While SNMPv3 has existed for quite a long time, all versions up to and including Windows 2012 R2 still rely upon the older and less secure SNMPv2, a protocol which provides no encryption or authentication. While Microsoft's WMI protocol addresses the authentication aspects that are sorely lacking in SNMPv2, encryption is different matter altogether. While it's possible to force the use of encryption in the WMI protocol, this is not the default behavior and is seldom ever done. This requires modifications to WMI namespaces to force the use of encryption, a process that must be repeated on each host you wish to manage. Beyond that, your monitoring solution must also work with WMI encryption, something very few solutions on the market today support.

The Agent included in the SAM 6.2 beta has been designed from the ground up with security first and foremost on our mind. To that end, the agent utilizes FIPS compatible 2048 bit TLS encryption to ensure all communication between the Agent and the Orion Poller are fully encrypted and safe from would-be cybercriminals.

How slow can you go?

Not all protocols are created equal. WMI and RPC may be right at home on todays gigabit Ethernet networks, but that is because these protocols were designed almost two decades ago as LAN protocols. These protocols were never designed to traverse bandwidth-contentious WAN links,nor function in high latency environments or across the internet. Attempting to use either of these agentless protocols in these scenarios is very likely to result in frequent polling timeout issues. Roughly translated, this means you are completely blind to what's going on.

The Agent in SAM 6.2 eliminates the issues associated with these protocols by utilizing the standards based HTTPS protocol, which is both bandwidth-efficient and latency-friendly. This means the agent could be used to monitor such extreme scenarios as servers running on a cruise ship or oil platform in the middle of the south pacific from a datacenter in Illinois via a satellite internet link without issue, something that would be otherwise impossible using traditional agentless protocols such as WMI or RPC.

What does this mean for Agentless Monitoring in Orion?

There are still plenty more challenges this new Agent is aimed at addressing that I will cover in a follow-up post. In the meantime, however, you might be wondering what this means for the future of agentless monitoring capabilities that Orion was built upon.

Absolutely nothing! SolarWinds pioneered the industry in agentless monitoring, and remains 100% committed to our "agentless first" approach in everything that we do. SolarWinds will continue to push the boundaries of agentless technologies to the very limit of their capabilities and beyond. We will continue to lead the industry by being at the forefront of new agentless technologies as they emerge, now or at any time in the future.

Agent vs Agentless - The war rages on

The war between agent-based and agentless IT monitoring solutions has gone on as long as there have been things in the environment that needed to be monitored. Agentless monitoring solutions have always had the advantage of not requiring any additional software that needs to be deployed, managed, and maintained throughout the devices lifecycle. There is typically little concern over resource contention on the host being monitored because there is essentially zero footprint on the machine in an agentless configuration. Due to the nature of agentless monitoring solutions, they can be deployed and providing value within a couple of hours in most environments. Agent based monitoring solutions typically require rigorous testing, as well as going through a tedious internal configuration change approval process before any agent software can be deployed into production. Agent deployment is commonly a manual process that requires running the installation locally on each server before they can be monitored. Then there are the security concerns associated with having any piece of software running on a server that could potentially be exploited by a hacker as a means of entry into the system.

If Agentless is so great why did SolarWinds build an Agent?

If the agent vs agentless war has taught us anything, it is that each approach has its own unique advantages and disadvantages. There is no single method that suits all scenarios best or equally. This is why we fundamentally believe that for full coverage, any monitoring solution you choose must provide excellent agentless monitoring capabilities, as well as provide an optional agent for those scenarios where agentless monitoring simply isn't feasible or prudent.

We here at SolarWinds believe that, given our agentless heritage, we are uniquely qualified to understand and address many of the problems that have plagued agent-based monitoring solutions of the past. It is our intent to make agent-based monitoring as simple and painless as agentless monitoring is today.

Ok, so what exactly does this agent monitor anyway?

The agent included in SAM 6.2 will be capable of monitoring virtually everything you can monitor today on a WMI managed node in SAM. This includes, but is not limited to node status (up/down), response time, latency (all with no reliance on ICMP), CPU, Memory, Virtual Memory, Interfaces, Volumes, Hardware Health, Asset Inventory, Hyper-V virtualization, as well as application monitoring. This very same agent can also be utilized as a Packet Analysis Sensor for deep packet inspection if so desired and appropriately licensed. The agent is officially supported on the following Windows operating systems.

• Windows 2008
• Windows 2008 R2
• Windows 2012
• Windows 2012 R2

While the agent should also work on Windows 2003 and 2003 R2 hosts, these operating systems are not officially supported. Non-Windows based operating systems such as Linux/Unix are also not supported by the agent at this time. If you are at all interested in a Linux/Unix agent for SAM that provides monitoring of Linux/Unix systems and applications, you can vote for this idea here.

Sounds good, but how much is this going to cost me?

The agent software is essentially free. You remain bound by the limits of the license you own regardless of how you're polling that information, either via an agent or agentless. For example, if I own a SAM AL150 license, I can monitor 150 nodes, volumes, and components. This remains true if I'm monitoring those servers with an Agent installed or agentlessly.

Sign me up already

There's still plenty more agent stuff to talk about, including additional scenarios where the agent could be used to overcome common obstacles you might encounter with agentless monitoring. In my follow-up post I will discuss some of those as well as cover the various different agent deployment options and agent management, so stay tuned for more information.

If you're anything like me, you'd much rather try something out yourself then read about it. Fortunately for you this new Agent is included as part of the SAM 6.2 beta, which will be available soon. If you currently own Server & Application Monitor and it's under active maintenance, you can sign-up here. You will then be notified via email when the SAM 6.2 beta is available for download.