For those who need an agentless alternative to monitoring certain aspects of their environment, the new and optional agent is yet another powerful tool in your arsenal. Where you might wield this new weapon is entirely up to you.
Below are three additional examples in a continuing series where I outline some of the tangible benefits of the agent. If you'd like to kick the tires on the new agent, please feel free to participate in the SAM 6.2 beta. We'd love to get your feedback. Simply sign-up by clicking the link below:
Head in the Clouds
Monitoring applications and servers running in the cloud using traditional agentless protocols is fraught with issues. For instance, by default, the WMI protocol is not fully encrypted, nor will it traverse NAT boundaries. WMI also requires a healthy number of open ports to function properly, not to mention that it's a fairly chatty protocol that doesn't tolerate bandwidth congestion or high latency conditions very well. Problems like these are further exacerbated by the fact that many ISPs block RPC traffic on the internet due to the protocols historical association with worms and hacker exploitation.
Unfortunately, the SNMP protocol fares only slightly better than WMI. Currently, all versions of Windows still rely upon SNMPv2, which provides no authentication or encryption. While SNMP has been designed to work in harsh bandwidth contentious environments, as well as traverse firewalls with ease, there still remains an ever decreasing amount of useful information available that can be collected from Windows devices via SNMP. This fact alone, coupled with Microsoft's recent depreciation of SNMP in Windows 2012, suggests that no further dependency should be built on the protocol for monitoring Windows devices.
The agent included in the SAM 6.2 beta allows you to monitor servers hosted by cloud based services such as Amazon EC2, Rackspace, Microsoft Azure, or virtually any other Infrastructure as a Service (IaaS).
Agents installed on Windows servers hosted in the cloud are then monitored by Orion no differently than any other server in your environment. Each agent can be configured independently to operate in the mode that best suits your needs. For instance, you may want to use Server Initiated mode for servers hosted on Amazon EC2because they all have publicly routable IP addresses. Conversely, you may want to use Agent Initiated mode for servers you're hosting in Azure because these servers may be hidden behind a NAT.
Each agent can also be configured to communicate with a specific Orion server or additional poller for load distribution.
Once deployed, the agent eliminates the issues associated with the WMI and SNMP protocols outlined earlier. All communication between the Orion server and the agent occur over a single fixed port. This communication is fully encrypted using 2048 bit TLS encryption. The agent protocol not only supports NAT traversal, but also supports passing through proxy servers that require authentication. The protocol the agent uses has been designed from the ground up to be extremely efficient and operate in low bandwidth, high latency environments. This makes it ideal for monitoring servers located in the cloud.
Finally, the agent is far more secure than either WMI or SNMP simply because there are no listening ports at the endpoint when using the Agent Initiated mode. This means there is zero attack footprint exposed by the Agent on the monitored endpoint that could be leveraged and exploited remotely by hackers or cyber criminals. Both SNMP and WMI expose listening ports on the host where they are running, making the agent a much more attractive option for monitoring servers running in the cloud.
You can't keep a good agent down
Unlike traditional agentless monitoring techniques, the Agent included in the SAM 6.2 beta is resilient to failure. In the unlikely event the Orion Server or Additional Poller were to go down for any reason, agentless monitoring of any hosts or applications monitored by that poller stops until that server is brought back online. This leaves gaps in performance charts and availability reports. This is also true for other types of failures that can occur anywhere in between the poller and what's being monitored, such as network equipment issues, WAN circuit problems, or VPN tunnel hiccups.
The agent, on the other hand, operates independent of the poller it's associated with and continues monitoring the server and its applications, regardless of whether or not it can communicate with the poller. Once connectivity to the poller is restored, the agent then forwards the results of its monitoring during the outage to the poller for processing, All gaps in the data will be filled with the data collected by the agent that would have ordinarily been lost if the host were being monitored without an agent.
These were just a few additional scenarios where you might find using an agent beneficial in your environment. As previously stated, the new agent is completely optional and intended to address specific needs where agentless monitoring of Windows hosts is either difficult, or simply not possible. As my final example demonstrated, there are other advantages the agent can provide to complement your agentless monitoring architecture. I will outline more examples in a follow-up posting, as well as provide a walkthrough of some of the agent deployment methods that are available in the beta.
The SAM 6.2 beta is not yet available, but will be very soon. If you would like to sign-up to participate in the beta, you can do so by completing a short survey. You need only be an existing SAM customer under active maintenance. Once available, you will be notified via email with a download link to the SAM 6.2 beta.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community.
More than 150,000 members are here to solve problems, share technology and best practices, and directly
contribute to our product development process.