1 2 3 4 Previous Next

Product Blog

54 Posts authored by: aLTeReGo

Server & Application Monitor 6.2 included a boatload of great new features that are going to be difficult to top, but that isn't going to stop us from trying. Here is a sneak peek at just a few of the items the team is diligently plugging away on.

 

  • Cloud Infrastructure Monitoring
    • Amazon AWS
  • Optional Agent for Linux Applications and Servers
    • Allows for polling host and applications behind firewall NAT or proxies
    • Polling node and applications across multiple discrete networks that have overlapping IP address space
    • Allow for reliable and secure encrypted polling over a single port
    • Support low bandwidth, high latency connections
    • Full end to end encryption between the monitored host and the Orion poller
    • Store and forward capabilities allowing the agent to operate independently of the Polling engine when network connectivity is lost
  • Numerous AppStack Environment enhancements
  • Real-Time Performance Analysis
  • Native Log File Monitoring
  • Web Interface design improvements
  • Active Directory Discovery
  • Application Template Assignment to Groups (Static or Dynamic)
  • Automated Network Sonar Discovery Import
    • Automatic monitoring of newly found nodes, interfaces, volumes, and applications based on discovery profile criteria

Since the release of Server & Application Monitor (SAM) 6.2, the team has been busily plugging away on a long list of new features and general product enhancements.  Chief among them are improvements to the aesthetics and overall design of the Orion web interface. While not the primary focus of this blog post, it is near impossible to post screenshots for some of what we've been working on without divulging some sneak peeks into the very early stages of this interface design refresh. A follow-up blog post is currently in the works that will go into detail and explain our multi-phased approach for delivering a fresh, clean, and modernized interface for all products that run atop the Orion platform. Suffice it to say, it is our aim to accelerate overall Orion web interface performance, dramatically improve usability for many of the most common tasks, as well as refine and enhance the product's visual appearance as part of this endeavor. Continue watching the Product Blog for more specifics surrounding the Orion UI redesign, as well as opportunities to provide feedback to members of our user experience team regarding these improvements. Your feedback might just earn you some much deserved Thwack points that can be redeemed for some cool SolarWinds SWAG!

 

With that prologue out of the way, it's time to run through a few notable new features we've been working on that are sure to put a smile on your face. As always, your feedback on features such as these is essential; and the absolute best time to provide that feedback is during betas. So if you're anything like me and would rather try out the new features yourself rather than simply read about them, then short circuit this post entirely and click the big red button below. Otherwise strap in, adorn your reading glasses (if you need them) and soak in the geek goodness below as I walk through some of the new features planned for this release and expose a few glimpses of the web interface redesign.

 

SAM 6.3 Beta button.png

 

Active Directory Discovery

One of the many aspects we wanted to focus our attention on improving within this release is how servers are discovered in SAM. Network subnets, IP address ranges, and lists of individual IP addresses might seem like natural options for those of us who come from a network centric background. However, for those possibly unfamiliar with the networks design or IP addressing schema, Active Directory in many instances provides much or all of the information needed about the servers residing on the network.


Active Directory discovery can be added as an additional discovery method to any new or previously existing discovery profile and used in conjunction with the three previously available methods for complete coverage across the environment. 


Similar to the other three methods of discovery, multiple Active Directory domains may be used in the discovery profile. This is especially handy for large organizations that may have multiple domains running in their environment due to mergers and acquisitions, separation of internal business units, or even lab vs. production systems. Also, unlike Active Directory authentication to the Orion web console, there is no requirement for the Orion server to be in the same Active Directory domain as the domain controllers used for discovery.

Discovery 2 - Add Domain Controller.png


Active Directory has the distinct advantage of allowing for more precise and targeted discovery within the environment. Instead of using a very broad discovery technique such as subnets or IP address ranges, you can more surgically discover only those items you wish to monitor, such as servers and/or workstations. This is particularly useful for organizations using class B "/16" (65,534 IP address) or class A "/8" (16,277,214 ip addresses) subnets, where sequential network scanning techniques may take hours or even days to complete successfully. In environments such as these, much of that IP address space is unused, but it still must be swept to determine which IP addresses are in use and are not part of the discovery process. Active Directory however, has a complete database of all hosts on the network which are members of the domain. Leveraging that database allows for a much more rapid scan of servers and workstations running on the network that could be monitored by SAM.


Discovery 3 - Add Domain Controller.png

Discovery 4 - Select OUs.png

Once you've added the Active Directory domain you wish to discover and click "Next" you are shown a complete listing of all Containers and Organizational Units (OUs) in the domain hierarchy. By default all OUs and Containers are selected, including any future Organizational Units that may be created after the discovery profile creation process is complete. Selecting the root level domain object toggles between select/deselect all, and the individual checkboxes on the left allow you to select the specific OUs to include or exclude from this discovery profile. The checkbox to the right of each OU listed designates whether to include any sub-OUs that may be created under that Organizational Unit in the future. For example: you have a root level Organizational Unit named "California" because you have only one office in that region today, located in Los Angeles. Later a new office is brought online in San Francisco. As a result you may decide to create two sub-OUs under California named "LA" and "SF" to manage group policy separately for each of those offices. The "Include Future OUs" option allows for these types of changes to occur within an OU, sub-OU, or domain without the need to update SAM's discovery profiles that are used for recurring nightly scheduled rediscovery of new devices in the environment. If not applicable or desirable in your organization, this option can of course be disabled.

 

Automatic Monitoring

Another primary area we focused on for this release is reducing or outright eliminating the maintenance overhead required to keep SAM up to date as new systems are brought online. Too many of us have been in similar situations where a new critical business system is brought up in the environment, and the first time there's a reported problem or issue with the system there's immediately an exchange of finger pointing that occurs amongst the responsible parties attempting to assign blame for why the system wasn't being monitored. As a result many organizations have implemented rigid policies and processes surrounding the provisioning of new systems in an attempt to mitigate these blind spots on the network. Unfortunately even the best laid plans aren't immune from human fallacy, even those with the best of intentions.

 

With that in mind we aimed to provide a mechanism that would ensure that as new systems were brought up in the environment that they would be monitored without relying on someone in the organization to manually add them to SAM for monitoring; or dig through the nightly Network Sonar Discovery Results to select which new items should be monitored. If adding individual devices manually is more your speed, or thumbing through the Network Discovery Results is how you enjoy spending your morning "me" time, those options continue to remain intact and unchanged in this release.

Discovery 5 - Automatic Monitoring.png

 

When selecting "Automatically Monitor" from the "Monitoring Settings" step of the Network Sonar Discovery Wizard you may continue on by clicking "Next" and accept the recommended defaults (only "Up" interfaces, non-removable media volumes, etc.) or use your own preferences by clicking the "Define Monitoring Settings" button. Clicking this button takes you through a mini-wizard where you are given the ability to define what you'd like automatically monitored should they be found during the Sonar discovery process. These options include, but are not limited to, interface type (trunk, non-trunk) , state (up/down/shutdown/etc.) upon discovery, interface name (contains, does not contain), interface description (contains, does not contain), volume type (Fixed Disk, Mount Points, etc), and AppInsight Applications. Additional steps may appear within the mini-wizard depending upon which Orion modules are also installed alongside SAM.

 

The next time the Network Sonar Discovery runs, either at the completion of creating the new Discovery Profile or its next scheduled run, any items found meeting the criteria defined within the profile not already monitored in Orion, will be automatically monitored by SAM.

 

For nodes managed via the optional Agent that was included as part of the SAM 6.2 release, these automatically become managed nodes in Orion by default when they first register with the Orion server or additional polling engine using Agent Initiated mode. Monitoring of these hosts however is limited to status, response time, CPU, and memory, without taking some additional step to select the specific items you'd like monitored on those hosts. The new automatic monitoring option shown here allows you to predefine those items just for agent managed nodes, agentlessly managed nodes, or all nodes in the environment depending upon the settings defined within the discovery profile.

Discovery 6 - Automatic Monitoring - Select Volumes.png

 

There's still more in store for this release, but we are eager and anxious to get your feedback on some of the features already starting to near completion. Please note that the absolute best time to provide feedback is during the beta, as things are still very fluid and there's plenty of time to fix bugs, make adjustments, and alter the design before release. That's right, betas are intended not only as a mechanism for finding bugs, visual defects, or other things broken in the code, but also to address usability issues and design flaws as well. If you are interested in taking SAM 6.3 for a spin and kicking the tires on some of these (and other) features, simply sign-up here. The only requirement for participation in the beta is that you own an existing license of Server & Application Monitor which is currently under active maintenance.

If you frequent the various product and geek speak blogs here on Thwack, you've likely at one time or another stumbled upon some reference, and possibly sneak peek glimpses, into what has affectionately been referred to as the "AppStack". The Application Stack, or "AppStack" for short, is a term used to describe all the various moving parts that make up today's complex application delivery infrastructure. This begins at the bottom with the backend storage arrays where data is housed, through the various different virtualization layers, up to the server that hosts the application, until finally we reach the application itself. The AppStack Environment View shown below accompanies the SAM 6.2, VMAN 6.2, and SRM 6.0 beta releases.

 

SAM Button.pngVMAN Button.pngSRM Button.png

 

The image below isn't the latest incarnation of the Candy Crush sensation, but rather a visual representation of all the various infrastructure components that make up my lab environment. Historically, all of this status goodness was tucked away under each respective categories product tab. Correlation and association of these various objects was a mental exercise based on a working knowledge of the infrastructures initial deployment, or legacy information that has been passed down from systems administrator  to systems administrator before them. To make matters worse, todays infrastructure is dynamic and ever changing, so what you thought you knew about the organizational layout of your supporting infrastructure may have changed dozens, or even hundreds of times since it was initially deployed.

 

AppStack.png

 

The AppStack Environment provides a 10,000 foot overview of your entire environment. At first, this may seem a bit overwhelming as there's a lot of status information contained within a single view. To that end, our UX research team toiled tirelessly to ensure that the AppStack provides as much useful information possible, while reducing or completely eliminating any extraneous noise that could distract from identifying problems in the environment and their likely cause. Perhaps most unnerving to most when first presented with the AppStack Environment View is the lack of object names displayed. Well fret not my dear friend because our UX masterminds thought of everything!

 

In most cases, when trying to get a high level overview into the health status of the environment, you're trying to get as much information represented in as little real estate as possible. If the status is good (green) then likely it's not of any concern. For those objects that are in distress however, you may want to glean additional information into what they are before digging deeper. As with most things in Orion, mouse hovers are available extensively throughout the AppStack Environment view to expose information, such as the objects name and other important details. However, if you're trying to determine the object names for a multiple of objects in distress, a mouse hover is a fairly inefficient means for determining what those objects represent. To address this need you will find a "Show Names" link in the top left of the AppStack. Clicking on this link will expose the name of any object currently in distress. Object names for items that are up (green) remain hidden from view to reduce visual clutter, so it's easier to focus on the items currently in distress.

 

Show Names.png

 

 

The AppStack Environment functions as a status overview page that is valuable when visually attempting to identify issues occurring within the environment, such as in the case of a NOC view, or perhaps the view you keep on your monitor while you go about your usual daily routine.  Any changes in status are updated in real-time for all objects represented in the AppStack. No browser refresh necessary. What you see in the AppStack Environment view is a real-time representation of the status of your environment.

 

Leveraging application topology information gathered across various different products, from Server & Application Monitor (SAM), Virtualization Manager (VMAN), and the all new Storage Resource Monitor (SRM), Orion is now capable of automatically compiling relationships and displaying them in a meaningful fashion between all the various infrastructure components that make up the application stack. Object associations are updated and maintained in real-time, and automatically, as the environment changes. This is important in todays dynamic environments where VMs are vMotioned between hosts, and storage is so easily reprovisioned, reallocated, and presented to servers. If someone had to maintain these relationships manually, it would likely be a full time job that could drive a person insane!

 

Clicking on any object within the AppStack selects that item and displays all relevant relationships the object has to any other object represented within the AppStack Environment. In the case below, I've selected an Application that's currently in a "Critical" state. I can see in the selection bar that this is a Microsoft SQL Server; one I've been having a bit of trouble with lately, so I'm not at all surprised to see it in a critical state. From here I can see which server SQL is running on, the fact that it's obviously virtualized because I can also see the host, virtual custer, datacenter, and data store the VM resides upon as well. None of those appear to be my issue however, as their status is "green". Moving further down the AppStack I can see the volumes that the VM is using, the LUN where the Data Store this VM resides upon, and the Storage Pool itself. So far, so good. Wait a minute, what's that I see? The backend array this VM is running on appears to be having some trouble.

 

AppStack Selected.pngDouble clicking on the Array object, or selecting the array and clicking on the object name from within the selection bar (for those of you rocking a tablet or other touch enabled device) takes me to the Array Details view. There I can see the I/O on this array is exceptionally high. I should probably vMotion a few VMs off the hosts that are utilizing this array, or provision more storage to those hosts from different arrays and balance the VMs across them.

 

Selection Bar.png

 

In this example, the AppStack Environment view was able to cut through the all the various information Orion is capable of collecting across multiple products to expose a problem, provide context to that problem, and identify the root cause. This can be done across the entire environment, or custom AppStack Environment views can be created to focus on a specific areas of responsibility. Perhaps you're the Exchange Administrator, and all you care about is the Exchange environment. No problem! Creating a custom AppStack environment view is simple. You can filter the AppStack by virtually any property available in Orion, such as Application Name, or Custom Property by adding filter properties.

 

Narrow your Envionment.pngSave as New Layout.pngSave as new Layout Dialog.png

 

Once you've filtered the AppStack to your liking and saved it as new layout, you can reference it at any time from layout selector in the top right of the AppStack Environment view. These custom AppStacks can also be used in rotating NOC views for heads up displays, or added to any existing summary view.

 

In addition to this new AppStack Environment View, you will also find a contextual AppStack resource on the Details view of every object type that participates within the AppStack. This includes, but is not limited to...

 

  • Node Details (For Servers)
  • Application Details
  • Array Details
  • Group Details
  • Storage Pool Details
  • LUN Details
  • Storage Pool Details
  • Hyper-V Host Details
  • ESX Host Details
  • Cluster Details
  • Virtual Center Details
  • Datastore Details
  • Volume Details
  • vServer Details
New Layout - Microsoft Exchange.png

 

AppStack MiniStack.png

The AppStack Environment resource provides relevant contextual status information specific to the object details being viewed. The image on the right, taken from the Node Details view of the same SQL server shown in the example above, displays the relationships of all other monitored objects to this node. This context aware application mapping dramatically reduces time to resolution by consolidating all related status information to the object being viewed into a single, easily digestible resource.

 

Relationships aren't limited exclusively to the automatic physical associations understood by Orion however. These relationships can also be extended using manual dependencies to relate logical objects that are associated in other ways, such as SharePoint's dependency on the backend SQL server. This capability further extends the AppStack to represent all objects as they relate to the business service, and significantly aids in root-cause analysis of today's complex distributed application architectures.

 

Earn $100.00 & 2000 Thwack Points!

 

SAM 6.2, VMAN 6.2, and SRM 6.0 beta participants have been given a special opportunity to earn $100.00 and 2000 Thwack points simply for taking part in these betas and providing feedback. To participate you will need to sign-up to participate and install at least two beta products that integrate within the new AppStack Environment view.

 

If you already own Virtualization Manager, you can sign-up here to participate in the Virtualization Manager 6.2 beta, get it installed and integrated with SAM or SRM and you're well on your way to earning $100.00 and 2000 Thwack points. Please note though, that you MUST already own Virtualization Manager and be under active maintenance to participate in the Virtualization Manager 6.2 beta.

 

If you currently own Storage Manager, and are under active maintenance, you can sign-up here to participate in the SRM 6.0 beta. Install SRM alongside SAM or VMAN to earn yourself some quick holiday cash!

 

If you're not yet participating in the Server & Application Monitor 6.2 beta, then what are you waiting for? All SAM product owners under active maintenance are welcome and strongly encouraged to join. Simply sign-up here. If you also happen to own Virtualization Manager or Storage Manager, then now is a great time to try out these awesome combined beta releases, and earn a little cash in the process.

 

Space is limited, so please reply to this post letting us know that you're interested in participating. You'll not only fatten your wallet in the process, but you'll also be helping us to build better products! Here’s how it’s going down.

 

When:What you’ll do:What you receive:
When you receive the beta bits for 2 or more productsHave a 15 minute phone call with our UX team to review what to expect and tell us about your job and technical environmentMy eternal gratitude!
2 to 4 days after installing two or more participating beta productsSend us a 1 to 2 minute video telling us about your initial experiences with AppStack. You can make the video with whatever is easiest for you; most people use their phone.$50 Amazon gift card
7 to 10 days after installing two or more participating beta productsSend us another 1 to 2 minute video telling us about how you've used AppStack. What are your favorite things? What drives you crazy?$50 Amazon gift card
12- 14 days after installing 2 or more participating beta productsSpend one hour with us showing us how you use AppStack.  We’ll  meet using GoToMeeting so that you can share your screen and walk us through some typical use cases.2,000 thwack points

Up until this point, much of the noise surrounding the Server & Application Monitor 6.2 beta has been focused exclusively on a new optional agent that allows for (among many other things) polling servers that reside in the cloud or DMZ. More information regarding this new optional agent can be found in my three part series entitled "Because Sometimes You Feel Like A Nut" linked below.

 

 

If you can believe it, this release is positively dripping with other incredibly awesome new features and it's time now to turn the spotlight onto one that's sure to be a welcome addition to the product.

 

Since the advent of AppInsight for SQL in SAM 6.0, and AppInsight for Exchange in 6.1, you may have grown accustomed to the inclusion of a new AppInsight application with each new release. Well I'm happy to announce that this beta release of SAM 6.2 is no different, and includes the oft requested AppInsight for Microsoft's Internet Information Services (IIS).

 

 

HTML tutorial

 

DISCOVERY


As with all previous AppInsight applications, monitoring your IIS Servers with SAM is fairly straightforward. For existing nodes currently managed via WMI simply click List Resources from the Node Details view and select Microsoft IIS directly beneath AppInsight Applications. You will also see this option listed for any new IIS servers added individually to SAM and managed via WMI using the Add Node Wizard.

 

You can add AppInsight for IIS applications individually using the methods above, or en masse using the Network Sonar Discovery Wizard.  One-time Discovery and scheduled recurring discovery of IIS servers in the environment using Network Sonar are fully supported. Either method will allow you to begin monitoring all IIS servers running in the environment quickly and easily.

 

AppInsight for IIS has been designed for use with IIS v7.0 and greater running on Windows Server 2008 and later operating systems. To monitor earlier versions of IIS such as 6.0 and 6.5 running on Windows 2003 and 2003R2 respectively, you should use theInternet Information Service (IIS) 6 template available in the Content Exchange.

 

AppInsight for IIS discovery is currently limited to WMI managed nodes. For nodes managed via SNMP, ICMP, etc. you can manually assign AppInsight for IIS to the node no differently than any other application template in SAM.

List Resources.png

 

Network Sonar One Time Discovery.png

Network Sonar Discovery Results.png

 

CONFIGURATION

AppInsight for IIS Configure Server.png

AppInsight for IIS leverages PowerShell to collect much of its information about the IIS server. As such, PowerShell 2.0 must be installed on the local Orion server or Additional Poller to which the node is assigned. PowerShell 2.0 must also be installed on the IIS Server being monitored. Windows 2008 R2 and later operating systems include PowerShell 2.0 by default. Only if you are running Orion on Windows 2008 (non-R2) or are planning to monitor servers running IIS 7.0, will you need to worry about the PowerShell 2.0 requirement.

 

Beyond simply having PowerShell installed, Windows Remote Management (WinRM) must also be configured. This is true both locally on the Orion server, as well as on the remotely monitored IIS host. If you're not at all familiar with how to configure WinRM, don't worry. We've made this process as simple as clicking a button.

 

After discovering your IIS servers and choosing which of them you wish to monitor, either through the Add Node WizardList Resource, or Network Sonar Discovery, you will likely find them listed in the All Applications tree resource on the SAM Summary view in an "Unknown" state. This is because WinRM has not been configured on either the local Orion server or the remotely monitored IIS host. Clicking on any AppInsight for IIS application in an "Unknown" state from the All Applications resource launches the AppInsight for IIS configuration wizard.


When the AppInsight for IIS configuration wizard is launched you will be asked to enter credentials that will be used to configure WinRM. These credentials will also be used for the ongoing monitoring of the IIS application once configuration has successfully completed. By default the same credentials used to manage the node via WMI are selected. Under some circumstances however, the permissions associated with that account may not be sufficient for configuring WinRM. If that is the case, you can select from the list of existing credentials available from your Credential Library, or enter new credentials for use with AppInsight for IIS.

 

Once you've selected the appropriate existing, or newly defined credential for use with AppInsight for IIS, simply click "Configure Server". The configuration wizard will do the rest. It should only take a minute or two and you're up and monitoring your IIS server.

 

If configuring WinRM to remotely monitor your IIS server isn't your jam, or if perhaps you'd simply prefer not using any credentials at all to monitor your IIS servers, AppInsight for IIS can be used in conjunction with the new optional agent, also included as part of this SAM 6.2 beta. When AppInsight for IIS is used in conjunction with the agent you can monitor IIS servers running in your DMZ, remote sites, or even in the cloud, over a single encrypted port that's NAT friendly and resilient enough to monitor across high latency low bandwidth links.

 

MONITORING

 

Sites and Pools.pngAs with any AppInsight application, AppInsight for IIS is designed to provide a near complete hands off monitoring experience. All Sites and Application Pools configured on the IIS server each appear in their respective resources. As Sites or Application Pools are added or removed through the Windows IIS Manager, those Sites and Application Pools are automatically added or removed respectively from monitoring by AppInsight for IIS. This low touch approach allows you to spend more time designing and building your IT infrastructure, rather than managing and maintaining the monitoring of it.

 

Each website listed in the Sites resource displays the current status of the site, it's state (started/stopped/etc.), the current number of connections of that size, the average response time, and whether the side is configured to automatically start when the server is booted.

 

It is all too common for people to simply stop or disable the Default Web Site or other unused sites in IIS rather than delete them entirely. To reduce or eliminate false positive "Down" alert notifications in these scenarios, any sites that are in a Stopped state when AppInsight for IIS is first assgined to a node are placed into an unmanaged state automatically. These sites can of course be easily re-managed from the Site Details view at anytime should you wish to monitor them.

 

The Application Pools resource also displays a variety of useful information, such as the overall status of the Application Pool, it's current state (stopped/started/etc.), the current number of worker processes associated with the pool, as well as the total CPU, Memory and Virtual Memory consumed by those worker processes. It's the perfect at-a-glance view for helping identify runaway worker processes, or noisy neighbor conditions that can occur as a result of resource contention when multiple Application Pools are competing for the same limited share of resources.

 

As one might expect, clicking on a Site or Application Pool listed in either of these resources will direct you to the respective Site or Application Pool details view where you will find a treasure trove of valuable performance, health, and availability information.

 

SERVER EXECUTION TIME

Response Time.png

 

The release of Network Performance Monitor v11 included an entirely new method of monitoring end user application performance in relationship to network latency with the advent of Deep Packet Inspection, from which the Quality of Experience (QoE) dashboard was born. The TopXX Page Requests by Average Server Execution Time resource is powered by the very same agent as the Server Packet Analysis Sensor that was included in NPM v11. AppInsight for IIS complements the network and application response time information provided by QoE by showing you exactly what pages are taking the longest to be served up by the IIS server.

 

This resource associates user requested URLs with their respective IIS "site", and its average execution time. Expanding any object in the list displays the HTTP verb associated with that request. Also shown is the date and time of the associated web request, the total elapsed time, IP address of the client who made the request, and any URL query parameters passed as part of the request.

 

New linear gauges found in this resource now make it possible to easily understand how the value relates to the warning and critical thresholds defined. Did I just barely cross over into the "warning" threshold? Am I teetering on the brink of crossing into the "critical threshold? These are important factors that weigh heavily into the decision making process of what to do next.

 

Perhaps you've just barely crossed over into the "warning" threshold and really no corrective action is required. Or maybe you've blown so far past the "critical" threshold that you can barely even see the "good" or "critical" thresholds anymore and a full scale investigation into what's going on is in order. In these cases, understanding where you are in relation to the thresholds defined is critical to determining both the severity of the incident, as well as measuring a sufficiently adequate response.

 

Server execution time is the time spent by the server processing the users request. This includes the web server's CPU processing time, as well as backend database query time, and everything in between. The values shown in this resource are irrespective of network latency; meaning, page load times will never be better than what's shown here in this resource without backend server improvements, regardless of what network performance looks like. Those improvements could be as simple as rebuilding database indexes, defragmenting the hard drive, or adding additional RAM to the server. Either way, high server execution time means users are waiting on the web server or backend database queries to complete before the page can be fully rendered.

 

AppInsight for IIS - Management.png

REMEDIATION

 

What good is the entire wealth of information that AppInsight for IIS provides if there is no way to remediate issues when they occur?

In addition to a powerful assortment of key performance indicators, you will notice new remediation options available within the Management resource of the AppInsight for IIS "Site Details" and "Application Pool Details" views. Within each respective resource is the ability to stop, start, and even restart the selected site or application pool, as well as unmanage. Remediation actions executed through the web interface are fully audited, no differently than terminating processes through the Real-Time Process Explorer, or stopping/starting/restarting services via the Windows Service Control Manager.

IIS Alert Trigger Action.png
In conjunction with one of the many other improvements also included in the SAM 6.2 beta, it is now possible to automate these IIS remediation actions from within the all new web based Alert Manager. Not only can you say, restart a site that has failed, or stop an Application Pool that's running amuck, but you can perform those remediation actions against any IIS site or Application Pool in your environment regardless if it's the site or application pool in distress. This is important for complex distributed applications where issues with backend application servers or database servers may require a restart of the frontend IIS site or application to resolve. Now this can be completely automated through the Advanced Alert Manager, and you can get some much need shuteye.


These are just a few of the capabilities of AppInsight for IIS. If you'd like to see more, you can try it out for yourself by participating in the SAM 6.2 beta. To do so, simply sign-up here. We thrive on feedback, both positive and negative. So kick the tires on the new SAM 6.2 beta and let us know what you think in the SAM Beta Forum.

 

Please note that you must currently own Server & Application Monitor and be under active maintenance to participate in this beta. Betas must be installed on a machine separate from your production installation and used solely for testing purposes only. Also, if you're already participating in the NPM v12 beta, the SAM 6.2 beta can be run on the same server, alongside the NPM v12 beta.

As promised, the long awaited and highly anticipated Server & Application Monitor (SAM) 6.2 Beta is now available for download. The premiere feature of this SAM beta is the new optional agent, which is intended to address key environmental scenarios where conventional agentless monitoring techniques are either impractical or impossible to leverage. Some of these scenarios include, but are not limited to, monitoring Windows hosts within the DMZ over a single fixed port; monitoring servers in remote branch offices over high latency, low bandwidth connections; or monitor the servers you have hosted in cloud based services, such as Amazon EC2, Azure, or Rackspace. For even more examples you can check out Part 1 and 2 of this blog series at the links below.

 

 

If you can believe it, I still have plenty more examples of where this agent might prove beneficial in your environment. I'll be covering more of those in another follow-up later on. For this post though, I want to cover a few of the different agent deployment methods available in the beta.

 

As discussed earlier, most agent based solutions rightfully deserve the negative reputations they have received over the years. Many of the negative connotations associated with those solutions surround abysmal management of the agent software on which they are dependant. With SolarWinds heritage of simplicity and strong emphasis on ease of use in all things we do, we firmly believe we are uniquely qualified to address many of the problems that have long plagued agent based solutions of the past. The first way in which we address this is by making the agent optional.  Striving to be the absolute best agentless management and monitoring solution is in our DNA and will remain so for the foreseeable future.

 

Everyone knows that the biggest headaches suffered at the hands of typical agent-based solutions has been the initial deployment and continual upkeep of the agents themselves. Agentless solutions allow you to install software on a centralized server and you're up and monitoring in no time. As new versions are released, you simply upgrade the server where the monitoring solution is installed and you're back up and running. The only thing left to do at this point is hit the big red button you got from your local office supply chain and call it a day.

 

With this in mind, as we set out to build this agent we were determined to ensure that it was not only incredibly powerful and flexible, but that is was also simple to deploy and easy to maintain. Not just easy in comparison to previous generations of agent based solutions, but "easy" by even agentless standards. If you would like to try out this new agent included in the SAM 6.2 beta and follow along, click the button below to sign-up.

thwack-blue.png

Agent Deployment - Add Node Wizard

 

For servers within your environment, Agent deployment is as simple as adding a new node to Orion. From within the Add Node Wizard you will notice a new "Agent" option listed alongside the familiar ICMP, SNMP, WMI, and External polling methods. After entering the IP address, hostname or fully qualified domain name of the server you wish to monitor, choose Agent as the method for polling the node. Selecting this new Agent option then prompts you to provide administrative credentials. These credentials are used solely for the purpose of installing the agent on the remote host. Once the agent is fully deployed to the remote host, the Local System account will be used for all node polling functions. After the credentials have been entered click "Next". Orion will then validate the credentials entered and check to see if the Agent software is already installed on the host. If it is not, you will be prompted to install the Agent software. Clicking "Start Install" will then begin the process of remotely deploying the Agent to the host, and a progress indicator will appear denoting the progress of the installation. Remote agent deployment typically takes a minute or two to complete, but across WAN links installation may take longer. If you don't feel like waiting around for the installation to complete you can click on the "Go to Manage Agents while install continues" link in the progress window. Deployment and installation will continue in the background allowing you to work on other things while you wait. If you choose to leave the Add Node Wizard during agent deployment you will be notified via the Notification Banner at the top of the screen once the agent is installed. Clicking on the notification within the banner takes you to the Manage Agents view where you are given the opportunity to choose the resources you wish to monitor on the node.


If you opt to continue through the Add Node Wizard process throughout the installation of the agent, you will be walked through the rest of the existing Add Node Wizard process flow that you are likely already familiar with. You will be prompted to select which resources on the host you wish to monitor (Volumes, Interfaces, Hardware Health, Asset Inventory, AppInsight applications, etc.) as well as select which application templates you'd like to assign to the node. The final step of the Add Node Wizard allows you to review the node properties, update any Custom Properties, or revise any node thresholds and polling intervals. When you're done reviewing the node properties, simply click the "Ok, Add Node" button to complete the process of adding the agent managed node to Orion.

Agent Deployment Wizard

 

If deploying agents individually isn't your speed, you can opt instead to deploy agents to multiple endpoints simultaneously from within the Orion web interface using the Agent Deployment Wizard. Located under [Settings -> Manage Agents] appears the "Add Agent" option. Clicking this button will walk you through the process of deploying the agent to any existing managed Windows node within Orion. You can also specify the IP addresses of Windows hosts within your environment that are not yet Orion managed nodes. To deploy an agent to an existing managed node in Orion, select it from the grid displaying the full list of WIndows nodes managed in your Orion environment. To deploy the agent to Windows hosts not yet managed by Orion, simply enter the IP address or hostname and click "Add to list". Once you've compiled the full list of hosts you wish to deploy the agent to, click "Next" to proceed on to the next step within the Wizard.

 

The next step is to provide credentials for deploying the agent to the selected hosts. You can select each host individually or multiple hosts in bulk and assign credentials to use for agent deployment. Credentials are validated as they are assigned to hosts, which helps eliminate potential agent deployment failures. When all hosts have valid credentials assgined you can click the "Deploy Agent" button to begin the agent deployment process.


While agents are being deployed you can continue working within the Orion web interface and will be notified via the Notification Banner at the top of the screen once the agents have been deployed. Clicking on the notification within the banner takes you to the Manage Agents view where you are given the opportunity to choose the resources you wish to monitor for each node. At any time you can check the progress of the Agent deployment process by going to "Manage Agents" under "Settings". This is also where you will find any potential errors related to agent deployment processes or edit agent settings.


Regardless of which push deployment method used, be it the Add Node Wizard or the Agent Deployment Wizard, you will need to ensure that TCP Port 445 is open from the Orion server to the hosts you wish to deploy the agent. The agent must also be able to communicate back to the Orion server over TCP Port 17778. For more information on agent deployment requirements you can reference the NPM v11.0 QoE Agent Deployment Guide.

Mass Agent Deployment Option

Mass Agent Deployment Option.png

Agent deployment from within the Orion server itself may be the easiest way to manage one, or even dozens of hosts within your environment, but what if you need to manage hundreds or even thousands of hosts using the agent? What if the hosts you're trying to manage are outside your environment and aren't directly accessible from the Orion server via RPC, such as host in the cloud or at a branch office behind NAT?


In cases such as these, it may be beneficial to utilize a software distribution solution to deploy the agent to the hosts you wish to manage. These can be software distribution tools built natively into Windows such as Group Policy, or commercial products like System Center Configuration Manager or SolarWinds Patch Manager to name a few. If you have servers running in the cloud, such as Amazon EC2 you may want to bundle the Agent as part of the server so that any dynamic elastic instances created are also managed in Orion. If you happen to be hosting servers on Azure, you can leverage Web Deploy to distribute the Agent to those servers as well. Really any solution that allows you to distribute MSI packages can be utilized to deploy the agent software.


You will find everything you need for mass agent deployment within the Orion web interface under [Settings ->  Agent Settings -> Download Agent Software] as pictured on the left. All agent settings that will be used during deployment can be preconfigured here, such as agent communication method ("Agent Initiated" or "Server Initiated"), as well as which polling engine the agents should communicate with. In the case of Agent Initiated Communication, you can specify an alternate IP address, hostname, or Fully Qualified Domain Name the agent should communicate with in the event the Orion server itself is hidden behind a firewall using address translation.


All preferences selected within this web interface are contained inside the Microsoft Transform (MST) file, which serves as the configuration setting for the Windows Installer (MSI) Package. Both the MST and MSI files are used together in conjunction with your software distribution mechanism of choice to deploy the agent software with the preferences selected here.


As agents are deployed within the environment or new cloud instances pre-packaged with the agent software installed come online, these hosts will begin registering with the Orion server and become managed nodes within Orion automatically. Thus dramatically reducing management overhead. As agents automatically register with the Orion server and become managed nodes within Orion, admins will be apprised through the Notification Banner at the top of the Orion web interface. Automatic registration and node management can, of course, be optionally disabled under [Settings -> Agent Settings -> Define Global Agent Settings] for environments where this behavior may not be desirable. When these options are disabled, agents must be individually allowed to register using the [Add Agent -> Connect to a previously installed agent] option located under Manage Agents section of the Settings view.

Manual Agent Deployment Option

 

 

If deploying the Agent software from within the Orion web interface isn't possible, due to NAT, firewall policies, or access control lists, and group policy or other software deployment mechanisms aren't really your thing, the agent can of course be installed manually on the host you wish to monitor. The agent software can be downloaded from the Orion web interface under [Settings ->  Agent Settings -> Download Agent Software] from the host where you plan to install the Agent software. Alternatively the agent installer is a mere 16MB in size, which is small enough for most environments that it can be emailed to engineers in the field as they bring new services online.

 

During the manual installation of the the Agent you are prompted to provide information, such as the IP address of the Polling Engine the agent will communicate with and your Orion credentials so that the agent can connect and register with the Orion server. Once the installation is complete the host where the agent was installed will automatically register with the Orion server and become a managed node. You will also be notified via the Orion web interface in the Notification Banner that a new agent has registered with the Orion server and become a managed node.Clicking on the notification within the banner takes you to the Manage Agents view where you are given the opportunity to choose the resources you wish to monitor on the node. If you would rather be notified via email, syslog, SNMP Trap, etc. you can optionally configure an alert to notify you of any new agents registered with the system.


Agent Management

Global Agent Settings.png

 

One of the biggest headaches associated with traditional agents has been maintaining them as new versions are released. Commonly, once the management server itself is upgraded you are blind to what's going on within the environment until all agents are also updated to the same version as the server. This means that a coordinated effort is required to properly upgrade the management server and all associated agents simultaneously to limit the amount of time you're without visibility into the environment. The additional overhead and orchestration required to successfully accomplish such an endeavor is commonly deemed not worth it, and upgrades are avoided unless deemed absolutely essential. Even then, the process is nightmarish at best.

 

While developing the Agent it was our intent to make it as much of a hands off experience as agentless monitoring is today. This means building an agent that is completely self maintaining. As new versions of SAM, NPM, or other products that utilize the Agent are released, the agent automatically updates itself once the Orion server is upgraded. Agents update themselves over the same communication channel the agent uses for polling, allowing agents that were deployed to hosts behind firewalls, proxies, or in the cloud to be updated simply and transparently.

 

For instances where automatic agent updates may not be desired, this feature can be disabled both globally or on an individual agent by agent basis from within the Orion web interface. In the event automatic agent updates are disabled, you still have the ability to approve agent updates manually through the Orion web interface. This affords you the ability to control exactly when agent updates occur on an individual agent by agent basis without the need to manage agent updates separately through other software distribution methods.

Delete Agent Node.png

Another common point of contention associated with agents is cleaning up after them. Accidentally deployed an agent to a server you didn't mean to monitor, but don't want to deal with the hassle of uninstalling the agent? No problem. Whenever you attempt to delete an Agent managed node in Orion you are given the option to uninstall the agent software from that host. This works for individual nodes deleted from Orion or multiple nodes selected at the same time. Unlike agent deployment however, uninstalling the Agent from the Orion web interface does not require connectivity to the agent managed host via RPC. Instead, the uninstall command occurs over the same communication channel the agent uses for polling. This means you can remotely uninstall agents that were deployed to hosts behind firewalls, proxies, or in the cloud from the comfort of the Orion web interface.


These are just a few of the ways this new agent is designed to make management and monitoring simpler than other agent based products you may have used in the past. All these great new capabilities are available now in the latest Server & Application Monitor 6.2 beta. If you currently own Server & Application Monitor and are under active maintenance we would love you to try out the new agent and give us your feedback. Simply sign-up here to download the SAM 6.2 beta and participate.

As promised in my earlier blog post entitled, "SAM 6.2 Beta - Because sometimes you feel like a nut - Part 1," here are some additional scenarios where the new agent included in the forthcoming Server & Application Monitor 6.2 beta could prove beneficial in ways you may not have even thought of yet. (As a reminder, SolarWinds remains firmly committed to our "Agentless First" approach for virtually everything we do!)

 

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:

 

 

SAM6.2Beta Button.png

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.

 

Passive vs Active.png

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 EC2 because 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

 

Agent Connecivity Failure.png

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.

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.


HTML tutorial

 

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

Agent Initiated Communication.png

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?

Agent Server Initiated.png

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.

We've just wrapped up the Server & Application Monitor 6.1.1 Service Release, meant to address any major outstanding issues identified in SAM 6.1 since its official release. Now it's time once again to turn our attention to the future of Server & Application Monitor. With that said, below is a list of items the team is currently working on.

 

  • AppInsight for IIS
    • Sites
    • Application Pools
  • Optional Agent for Monitoring Windows Applications and Servers that addresses the following needs:
    • Allows for polling host and applications behind firewall NAT or proxies
    • Polling node and applications across multiple discrete networks that have overlapping IP address space
    • Allow for reliable and secure encrypted polling over a single port
    • Support low bandwidth, high latency connections
    • Polling nodes across domains where no domain trusts have been established
    • Full end to end encryption between the monitored host and the Orion poller
  • Application stack integration and visualization (E.g. visual mapping through the entire application stack to help identify root cause of performance and availability issues)
  • Performance & Scalability Improvements
  • Web Based Advanced Alert Manager
  • Packet-level Traffic Analysis and Classification
  • Web Based Syslog and Trap Management
  • Unmanage Behavior Improvements
  • Disk Volume Capacity Forecasting
  • Mandatory Custom Properties
  • Independant Volume Thresholds
  • Hardware Health Improvements
  • Support for SQL Server 2014

 

PLEASE NOTE:  We are working on these items based on this priority order, but this is NOT a commitment that all of these enhancements will make the next release.  We are working on a number of other smaller features in parallel.   If you have comments or questions on any of these items (e.g. how would it work?) or would like to be included in a preview demo, please let us know!

Server & Application Monitor 6.1.1 Release Candidate is now available for all SAM customers under active maintenance through your Customer Portal. Release Candidates are fully supported and upgradable to the final release when available. If you are experiencing any of the issues outlined below, we recommend downloaded the SAM 6.1.1 Service Release and upgrade now.

 

Fixed Issues and Additions in this Release

This release of SAM includes the following fixes and additions:

Version 6.1.1

Fixed Issues:

  • An issue where certain Asset Inventory resources were displaying volumes that were not appearing in the web console has been fixed. a
  • The Exchange database file size default limit was increased in size from 50 GB to 1 TB, and can now be configured manually in the following file: SolarWinds.APM.BlackBox.Exchg.Collector.dll.config.  The 50 GB limit made it difficult to determine proper thresholds. b
  • An issue where AppInsight for Exchange incorrectly calculated the limit for any mailbox database on Exchange 2010 Standard Edition at 50GB has been resolved. c
  • An issue where a PowerShell scripts are unable to run because user accounts and the Exchange server are from different domains has been resolved. d
  • An issue where AppInsight for Exchange threw an error citing, Exchange Version Mismatch, has been resolved. e
  • A conflict between:
    • Windows Scheduled Task Manager and templates of the same name causing the former not to function properly, has been fixed. f
    • AppInsight applications and templates of the same name causing the former not to function properly, has been fixed. m
  • An issue where certain Asset Inventory resources were showing duplicate records due to external updates has been fixed. g
  • AppInsight for Exchange now has the ability to poll all mailboxes within a domain forest. Prior to this fix, AppInsight for Exchange could only poll root mailboxes.  
  • A memory leak has been fixed. This leak occurred during the attempted initialization of certain performance counters resulting in performance counters endlessly attempting to start. i
  • An issue where some physical servers being monitored were falsely reporting a child Warning status has been fixed. j 
  • AppInsight for Exchange now supports Windows 2008 (non-R2). k 
  • A timeout setting has been increased for Linux script execution which now prevents a script execution error. l
  •   A Linux script execution error has been fixed. n, p, q
  • After  upgrading to SAM 6.1, an issue where the variables, ${Threshold-Statistic-Critical} and ${Threshold-Statistic-Warning} no longer populated, has been fixed. o
  • An issue where certain Asset Inventory resources were showing duplicate records due to external updates has been fixed. g
  • AppInsight for Exchange now has the ability to poll all mailboxes within a domain forest. Prior to this fix, AppInsight for Exchange could only poll root mailboxes.
  • A memory leak has been fixed. This leak occurred during the attempted initialization of certain performance counters resulting in performance counters endlessly attempting to start. i
  • An issue where some physical servers being monitored were falsely reporting a child Warning status has been fixed. j
  • AppInsight for Exchange now supports Windows 2008 (non-R2). k
  • A timeout setting has been increased for Linux script execution which now prevents a script execution error. l

 

Table of Fixed SAM Issues

The following table provides the internal Development ID numbers and external support ID numbers for fixed SAM issues as well as new feature requests in this release. Search in the support ID number column for the number assigned to your support case.

 

SuperscriptSupport ID numberDevelopment ID number
a591714321074
b586749318056
c603164328359
d591412320755
e593737321838
f, m594985, 602168323456, 328549
g576182312166
h581448314906
i490700255402
j577567312188
k596422324735
l599218326004
n, p, q594888, 583631, 601187323753, 325219, 327131
o598659325679

We here at SolarWinds are continuously looking to improve our products in both functionality and user experience. Failover Engine (FoE) as you can imagine, doesn't get a tremendous amount of feedback from the Thwack community. This is because FoE is akin to the spare tire sitting in the trunk of your car. You hardly ever think about it until you need it. With that in mind, I've compiled a few thought provoking questions that I hope will engage those of you in the community to think about how you use FoE. This should help to give us a better understanding how and where we can improve FoE in the future,

 

What has your experience been like Installing/Upgrading FoE?

In an Failover Engine LAN Configuration How do you Maintain the Standby Host?

Are your Failover Engine member servers joined to the Domain?

How do you prefer to manage administrative tasks in Failover Engine?

What is the primary reason your Orion server is down?

How much redundancy is enough for your environment?

At first glance, Server & Application Monitor (SAM) 6.1 might sound like it's a "minor" release. However, with the mountain of new features we've managed to cram in, 6.1 is anything but minor. In previous blog posts I discussed Windows Scheduled Tasks and JSON/XML monitoring, as well as Sustained Threshold Conditions that can be used to squelch nuisance alerts. Despite more than half a dozen additional new features in this release I haven't even talked about yet, such as new SOAP Monitor, Drag & Drop resources (that's right, I said drag and drop), and a new Web-Based Report Scheduler, much of the buzz surrounding SAM 6.1 has centered around AppInsight for Exchange. This is likely due to the success of AppInsight for SQL in the SAM 6.0 release, coupled by the tease that was my previous blog posting entitled "Introducing AppInsight for Exchange - Server & Application Monitor 6.1 Beta 2 Sneak Peek". In that post I gave readers a very early glimpse into AppInsight for Exchange, that barely scraped the surface of what this new application monitoring capability provides. So today I'll attempt to satisfy some of that curiosity by showcasing some of the other functionality included in AppInsight for Exchange.

 

I first cut my teeth back in the day of Exchange 5.5. Since that time I've seen tremendous improvements in Exchange scalability, reliability, and performance. As a consequence of these improvements however, Exchange has become significantly more complex to manage, monitor, and maintain. Simply isolating a performance bottleneck in your Exchange environment can be akin to playing a bad game of "Where's Waldo".

 

AppInsight for Exchange ends the madness by centrally consolidating all information about each mailbox database and its copies across all mailbox servers in the Database Availability Group, into a single Mailbox Database Details view. It is within this Mailbox Database Details view where you will find all relevant information pertaining to that specific individual mailbox database on the server, as well as all other servers where a copy of that database resides.

 

Information including last full and incremental backup, number of mailboxes in the database, average mailbox size, and default storage quotas applied at the mailbox database are all easily at hand.

Database Details.png
Database size and disk io.png

The Database Details view also contains multi-server performance, health, and availability information that should make troubleshooting common mailbox database issues a breeze.

 

For example, in the screenshot to the left you can easily identify where the mailbox database resides on each servers file system, the size of that mailbox database, and how it relates to the amount of free space on each servers volume. You can also identify disk I/O performance issues across servers by seeing the Disk Queue Length, Latency, and total IOPS for the volumes on each server where a copy of that database resides.

 

Similar resources also appear in this view for Transaction Logs, showing additional detail such as the total number of transaction log files, as well as their cumilitive total size on disk.

 

All this information allows you to easily spot problems before they start. There's nothing worse, or more preventable than a database dismounting because the volume it's located on has run out of space. With AppInsight for Exchange, now you can be proactively alerted and take corrective action before it impacts your users.

Now let's say your mailbox database was running out of space. Where do you go, and what do you do now? You could move the mailbox database to a different volume that has more space. If you have more unallocated storage you could even extend the volume. Both of those options require heavy lifting, and likely some downtime.

 

What if you could easily identify the offending user mailboxes that are taking up a large percentage of space in the database? You could then either hunt those users down and ask them them to clean up their mailbox, or move them to another mailbox database that has more available space.

 

The "Users By Mailbox Quota Used" and "Users By Mailbox Size" resources allow you to view each and every user mailbox, its total size, amount of space all attachments in the mailbox are consuming, total number of attachments, and percentage of quota used. This information is available in each mailbox database view, as well as across the entire Exchange environment.

 

You can even spot dormant mailboxes easily within the same resource by viewing the "Last Accessed" date.

Users By Mailbox Quota Used.png

From this resource you can drill down even further into the User Mailbox Details view. Here you can see the quota limits applied to the individual users' mailbox, the Active Directory Organizational Unit where this user resides, and can even click their Primary SMTP Address to notify them that some mailbox cleanup is required.

 

Before you do that though, you might want to get a better understanding of how this user is using their mailbox. Perhaps they recently received several very large email attachments that they could move off onto the file server. Maybe this user regularly receives a large volume of incoming email. This could be normal given their job function, or indicative of ineffective SPAM filtering.

 

With AppInsight for Exchange you can easily visualize each users historical mailbox usage, identify trends such as the growth of a user's mailbox over time, and the total size of all attachments within the users mailbox over the same period. You can also gain insight into the volume of mail sent and received by the user each day, both internally and externally.


This information allows you to make informed decisions before extending users mailbox quotas or adding additional storage to the Exchange server. This information can also be included in alerts that give helpdesk staff a heads up as users approach their quota limit.

Mailbox Details.png
Total Mailox and Attachments Sizes.pngReceived Mail.png

What if the problem you're facing was the other direction? Instead of a massive influx email or attachments driving the users mailbox size, it was malicious activity the end user wasn't even aware of? The Users By Messages Sent resource helps identify mailbox abuse caused by potential trojans, botnets, or otherwise unscrupulous activity. Should your users mailbox be taken over by such mass mailing marauders, AppInsight for Exchange makes identifying this unusual traffic a trivial affair.

 

AppInsight for Exchange also allows you to report on the mobile devices being used in your environment, the operating system version running on those devices, as well as the last time any device was used to connect to Exchange via ActiveSync.

 

This information is available on any individuals Mailbox User Details view. It is also available as an out of the box report that lists all mobile devices in use in your organization and their respective owner.

 

Until now, SAM 6.1 has been available only to a select number of beta participants, but that's no longer the case. As of today, all current SAM customers under active maintenance can download and install the official SAM 6.1 Release Candidate simply by signing up here. Upgrading of your existing production Server & Application Monitor installation is also fully supported. So give AppInsight for Exchange, or any of the over a dozen other improvements in this release a go, and tell us what you think!

Users By Messages Sent.png

Synced Devices.png

 

SAM 6.1 RC button.png

In my previous blog post I introduced you to several cool new features we've been working on for the next release of SolarWinds Server & Application Monitor (SAM). From sustained status conditions that are sure to help squelch nuance alerts, Windows Scheduled Task monitoring, and JSON, SAM 6.1 was already shaping up to be a pretty awesome release.

 

It's now time to take the wraps off SAM 6.1 Beta 2, and just in time for Christmas. If you've been wondering what to get yourself for the holidays, or fear that after all the presents have been unwrapped you'll have amassed a years supply of tube socks, silk ties, and ugly sweaters, you needn't worry. We have just the thing that's sure to put a smile on your face this holiday season.

Sign-up to Download SAM 6.1 Beta 2.png

 

AppInsight for Exchange

 

The overwhelmingly positive feedback we received from the community regarding AppInsight for SQL since its debut in SolarWinds Server & Application Monitor 6.0 has been so phenomenal that we just couldn't stop there. The next obvious choice to get the full AppInsight treatment had to be Microsoft's Exchange. Both SQL and Exchange are complex business applications that are at the very center of most organizations' IT universe. In almost all cases, end users directly (or indirectly) interact with these applications on a continual basis. Be it for basic internal and external communications, data entry, billing, ordering, etc. SQL and Exchange tend to touch so many individuals both inside and outside the organization, that it's imperative that their health, performance, and availability is continuously monitored.

 

If you're not at all familiar with AppInsight for SQL, or the AppInsight concept, below is an excerpt from one of my previous blog posts in which I attempt to explain it.

 

AppInsight provides a whole new level of application monitoring detail that was previously very difficult, if not impossible to achieve using Application Templates. AppInsight is not a direct replacement for Applications Templates but rather an entirely new monitoring concept within SAM. Application Templates remain the primary method for quickly monitoring virtually any commercial, open source, or home grown application imaginable. In contrast, AppInsight is more akin to an entirely new product deeply embedded within SAM; designed from the top down to solve common, yet complex problems for a specific application, rather than merely a new feature.

 

Discover


As with AppInsight for SQL, monitoring your Exchange Mailbox Servers with SAM is a fairly simple, straightforward affair. For existing nodes currently managed via WMI simply click List Resources from the Node Details view and select Microsoft Exchange Server directly beneath AppInsight Applications. The same is also true for any new Exchange servers added individually to SAM and managed via WMI using the Add Node Wizard.

 

Exchange Servers can be added both individually using the methods above, or en masse using the Network Sonar Discovery Wizard. Both one-time and scheduled re-occurring discovery of Exchange servers in the environment using Network Sonar are fully supported. Either method will allow you to begin monitoring your entire Exchange environment in record time.

 

Please note that AppInsight for Exchange has been designed exclusively for Microsoft® Exchange 2010 and Exchange 2013 Mailbox Role servers. This option will not appear for nodes running previous versions of Exchange or servers running other Exchange roles, such as the Client Access role.

AppInsight for Exchange List Resources.png
Network Sonar AppInsight for Exchange.png
Network Sonar Scheduled Discovery Results - AppInisght for Exchange.png

Configure

 

AppInsight for Exchange uses PowerShell to collect virtually all information from the Exchange server. As such, PowerShell 2.0 must be installed on the local Orion server or Additional Poller that the node is assigned to. PowerShell 2.0 must also be installed on the Exchange Server being monitored. Windows 2008 R2 includes PowerShell 2.0 by default. If you're already running Orion on Windows 2008 R2 or greater and plan to monitor Exchange running on a Windows 2008 R2 server, you needn't worry about the PowerShell 2.0 requirement. Microsoft has taken care of that for you.

 

Beyond simply having PowerShell installed, Windows Remote Management (WinRM) must also be configured. Both locally on the Orion server, and on the remotely monitored Exchange Server. Fear not though; we've made this process incredibly simple and completely painless.

 

After discovering the Exchange mailbox servers running in your environment and choosing to monitor them, you may find them listed in the All Applications tree resource on the SAM Summary view in an "Unknown" state. This is likely due to WinRM having not been configured on either the local Orion server or the remotely monitored Exchange mailbox server. Clicking on the AppInsight for Exchange application that is in an "Unknown" state from the All Applications resource launches the AppInsight for Exchange configuration wizard.

Zero Config Basic.png

The AppInsight for Exchange configuration wizard will prompt you for credentials to configure and monitor the remote host. By default, credentials used to manage the node via WMI are selected. However, under some circumstances, such as using the local administrator account to manage the node, these permissions may not be adequate for monitoring Exchange. If that is the case, you can select from the list of credentials available from your Credential Library, or enter new credentials for AppInsight for Exchange to use. The account used for AppInsight for Exchange should have Exchange Admin Role permissions.

 

Once you've selected existing, or defined new credentials for AppInsight for Exchange to use, simply click "Configure Server". The configuration wizard will do the rest. It should only take a minute or two and you'll be up and monitoring your Exchange mailbox server. Easy peasy, and no agent required.

 

So what exactly is this magic "Configure Server" button doing anyway? Well nothing that couldn't be done manually with a bit of effort. Quite simply the "Configure Server" button pushes a self signed certificate to the Exchange Server and configures WinRM to function in a secure encrypted fashion between the two hosts. Steps for manually configuring your Exchange Server, as well as creating a least privilege user account for monitoring your Exchange mailbox servers using AppInsight for Exchange will be available in the SAM Administrators Guide once SAM 6.1 is officially released.

 

Monitor

 

An Exchange environment is typically comprised of multiple Mailbox Databases. Much like SQL databases, each mailbox database has its own independent status that tells the administrator how that database is currently being used (or not used in the case of databases that are "Dismounted"), as well as the health of that database. In the Mailbox Database Status resource, located on the Application Details view we see all of the databases running on this Exchange server. All but one is in a "mounted" state, but the SAMDB03 database does not appear to be running on its "preferred" server, as designated by its Activation Preference. For smaller environments where two or more Exchange Servers running in a DAG (Database Availability Group) are sitting next to each other, this might not be an issue. For larger distributed environments, losing track of where your mailbox databases are running can lead to end users complaining about email performance problems or worse. For example, If your office was headquartered in Boston, but have a DR facility in your satellite office in Shanghai, the last thing you want is all the traffic from the users in the Boston office traversing the WAN to access their mailboxes from the Shanghai server.

Mailbox Database Status.png
As obvious as that sounds, this can and does occur for simple, sometimes seemingly stupid reasons. For example, applying Windows Updates to the Exchange server in Boston, but failing to move those mailbox databases back over from Shanghai after the reboot. It's important to know which server in the DAG your mailbox databases are mounted, and be notified when they're not mounted on the appropriate server.
Replication Status Checks.png

The Replication Status Checks resource, also on the Application Details view, checks all aspects of replication and replay status to provide a complete overview of the mailbox server in the Database Availability Group (DAG). This allows you to proactively monitor continuous replication, the availability of the Active Manager, and the health and status of the underlying cluster service, quorum and network components, to name a few.

 

In the event of a replication status check failure you will be notified both visually through the UI, as well as through your normal alerting mechanisms. Clicking on the "More" link for any failed Replication Status Check displays the full details of that failure.

Each mailbox database on your Exchange server is a time bomb ticking down until ultimately it runs out of space. Be it from mailbox database limits imposed by the Standard Edition of Exchange, NTFS file size limitations, or simply running out of free space on the volume where the mailbox database is stored, it's only a matter of time before the mailbox database hits the wall. When that time comes, it's certain to negatively impact any and all users whose mailboxes reside on that mailbox server.

 

To stay ahead of the game it's imperative that you have a good understanding of how your mailbox database size relates to these limitations. This will allow you to be proactive in your approach to managing your mailbox databases, and the individual mailboxes that reside within.

Mailbox Database Size and Space Use.png

Alerting

 

This is precisely the kind of information that the Mailbox  Database Size and Space Use resource provides. Not only does this resource list all mailbox databases managed by the mailbox server, their current size on disk, and the amount of white space remaining within the database, but the linear gauge also shows the percentage of the mailbox databases usage as it relates to such things as remaining free space on the volume, and file size limits imposed by Exchange edition/version or the NTFS file system. This information is then available for reporting, trending, and of course, out of the box alerts so you can be notified proactively and avoid such crisis altogether.

 

This was just a tiny glimpse into a few of the powerful new capabilities included with AppInsight for Exchange. If you'd like to try it out for yourself, don't hesitate! Sign-up here to download SAM 6.1 Beta 2 today. You need only own an existing license of SolarWinds Server & Application Monitor, and be under active maintenance to participate.

 

Your feedback (both positive or negative) is what we thrive upon. It serves either as confirmation that we're on the right track, or that adjustments and improvements need to be made. Either way, it's what helps us to build great software.

AppInsight for Exchange Out of the Box Alerts.png

So here we go again! Time to kick off the next release of SolarWinds Server & Application Monitor with the first official beta, and grab a quick first glimpse into several of the cool new features we've got lined up for SAM 6.1.

 

Not to be confused with SAM 6.0.1, the Service Release containing many important bug fixes for SAM 6.0 and available for download now through the Customer Portal, SAM 6.1 is the next major "feature" installment in the series. If you'd like to participate in the SAM 6.1 beta you can do so by signing up here. Feedback is crucial during the beta phase of development because there's still plenty of time to make important tweaks and adjustments that can make all the difference in the final release. If you've never participated in a SolarWinds beta before, now is a great time to start. Not only do you get to play with all the great new features first, but it's also an excellent way to help shape the future of the product.

 

Windows Scheduled Tasks

 

At one time or another, every systems administrator has had to rely (albeit sometimes begrudgingly) on Windows native Task Scheduler to automate some routine process. Be it automating backups, disk defragmentation, antivirus scans, etc., the Windows Task Scheduler has undoubtedly played an important role in ensuring your infrastructure is properly maintained. However, even as the Windows Task Scheduler has improved over the years, real-time visibility into the success or failure of those tasks across the enterprise has remained, for the most part, an enigma.

 

In SolarWinds never ending pursuit to provide greater levels of visibility into the critical componentry that make up your IT infrastructure, we sought to resolve this visibility gap by introducing the Windows Scheduled Task Monitor as part of the SAM 6.1 beta release.

 

Elegant in it's simplicity, SAM's Windows Scheduled Task Monitor for the first time provides you with at-a-glance access to the state and status of the scheduled tasks configured on your Windows hosts. In addition to simply seeing what tasks have been configured on the host, their current state, and their last run result, SAM 6.1 includes a new pre-configured out-of-the-box alert which will notify you of any task execution failures that occur. You will also find new web based reports that allow you to view all scheduled tasks configured across all servers in your environment, as well as a dedicated Task Failure Report you can view or have emailed to you on a regular basis.

Windows Scheduled Tasks.png

 

When monitored, you will find the Windows Schedule Task resource pictured above on the Node Details view of the monitored server. This is because Windows Scheduled Tasks are not applications in the conventional sense. As such, they are treated somewhat special in SAM and given a prominent resource of its own amongst other host specific information on the Node Details view.

WIndows Scheduled Task Add Node.png

Several options are available to enable SAM's new Windows Scheduled Task monitor. When adding a new, or listing resources on an existing WMI managed node, you will be provided an option to select Windows Scheduled Tasks. The same as you would for volumes or interfaces.

 

If enabling this feature one node at a time isn't your speed, you also have the option of leveraging the Network Sonar Discovery Wizard. The Network Sonar Discovery Wizard allows you to quickly and easily enable the Windows Scheduled Task monitor en masse across all Windows hosts in your environment, or surgically enable this feature only on a select group of nodes.

 

Both one-time discovery, and scheduled reoccurring discovery options are available to enable the Windows Scheduled Task monitor. If using the scheduled discovery option you will have granular level control over which hosts the Windows Scheduled Task Monitor is enabled, as seen in the screenshots below. Hint: If the image is too small, click on it to zoom in and see the full size image.

 

The new Windows Scheduled Task Monitor in SAM 6.1 supports monitoring tasks configured on Windows 2003, 2003R2, 2008, 2008R2, 2012, and 2012R2.

Windows Scheduled Tasks - Scheduled Discovery.pngWIndows Scheduled Task Network Sonar Discovery.png

JSON

 

Web Services APIs such as JSON are the glue that bind modern applications together, usually across different servers, allowing for the exchange of information between them. As end users become reliant upon applications built on these web services, it becomes increasingly more important to monitor those applications to ensure they're functioning as expected. The simplest, and most obvious method for monitoring those applications is to query the back-end server directly, using the same web service API method that the front-end web application would use. From the server's response we can determine the web services availability (up/down), latency (response time), as well as validate the content returned as a result of that query.JSON.png

From within the HTTP/HTTPS Component Monitor settings, you will find three new options (Host Request, Content Type, and Request Body) that allow for the monitoring of restful web service API's, such as JSON and XML. Three new methods (Put, Post, and Delete) are also provided, in addition to the existing "GET" method that has historically been the default and only method available for the HTTP/HTTPS User Experience Monitors prior to SAM 6.1.

 

Sustained Thresholds

 

Last, but certainly not least, 6.1 includes additional improvements to how thresholds are handled in SAM. While tremendous strides were made to how thresholds are calculated in the SAM 6.0 release with the introduction of the Threshold Baseline Calculator, that feature served to provide meaningful context to already collected data. In other words, to answer the proverbial question "What's normal for my environment?" and then suggest recommended warning and critical thresholds based on that information; however, as anyone who's been monitoring IT infrastructure for a while will tell you just because a threshold was crossed once, doesn't mean it's a significant issue that requires immediate attention.  After all, who enjoys being woken from their slumber at 3am to a nuisance alarm telling you that the % Processor time on one of the servers spiked momentarily. If the alert requires no action on your behalf, then more than likely it wasn't worth you waking up for. Alert notifications should be about providing actionable information that requires some level of user intervention to resolve. While some metrics, such as the amount of free space remaining in your SQL database might only get worse over time, thus requiring immediate attention when it dips below a reasonable limit, other metrics can vary wildly from one poll to the next. This is where sampling can play an important role in reducing, or even eliminating the number of nuisance alerts that flood your inbox on a regular basis.

 

In SAM 6.1 you will find new options for defining sample criteria for both warning and critical thresholds associated with each monitored metric of an application. By default, both warning and critical thresholds are evaluated after a single successful poll. This is the exact same behavior as all versions of SAM prior to 6.1. In addition to the single poll evaluation, you will find options for defining criteria for multiple consecutive polls, as well as a method for defining the number of samples that must exceed the threshold for a configured sample size before the condition is met and the status of that component monitor is changed.

 

Sustained Thresholds.png

 

Sustained conditions in SAM 6.1 can be defined independently for both warning and critical thresholds to provide maximum flexibility. Both "X Consecutive Polls" and "X out of Y Polls use a sliding window approach to evaluating thresholds. After each poll, the conditions defined for the threshold are evaluated based on the bounds of the sample size. Put simply, that means that after each poll a new sample is collected and added to the evaluation, while the oldest sample is removed from evaluation. Below, I provide two examples. The first example on the left demonstrates the "X consecutive polls" method. In the left column I show the numerical value collected from the poll (the sample). In the right column I show the status of the component as defined by the sustained condition. The "Sample Size" in this example is "3", meaning that three consecutive polls/samples must exceed the threshold of "80" before the status should change to "Warning".

 

Warning = Greater Than 80 for 3 Consecutive PollsWarning = Greater Than 80 for 3 out of 5 Polls
Polled ValueStatus
65UP/Green
77UP/Green
88UP/Green
85UP/Green
89Warning
83Warning
46UP/Green
81UP/Green
22UP/Green
Polled ValueStatus
65UP/Green
82UP/Green
34UP/Green
95UP/Green
88Warning
90Warning
35Warning
25Warning
15UP/Green

 

The second example demonstrates the "X out of Y polls" method. While the "Sample Size" for evaluation in this example is "5" polls, any three of those 5 polled samples must exceed "80" before the status of this component would change to "Warning". Using the same sliding window approach as the first example, with each successive poll a new sample is collected, while the 6th sample is dropped from evaluation.

 

While somewhat similar functionality has existed within the Advanced Alert Manager for some time now, aiding in reducing the number of nuisance alarms, each individual component monitor that has unique threshold criteria has required its own separate alert definition. Not only is this a tedious and time consuming process to initially setup and configure, but it also necessitates the additional overhead of managing and maintaining what can be an unruly number of alert definitions.

 

Sign-up Now

 

We'd love to get your feedback on these new features. So tell us what you think in the comments section below, or better yet, sign-up here to download the latest SAM 6.1 beta and try them out for yourself!

 

Please note that you must currently own a copy of SolarWinds Server & Application Monitor that is under active maintenance to participate in the SAM 6.1 beta.

To receive updates on the SAM roadmap, JOIN thwack and BOOKMARK this page.

 

The mad scientists of the SAM team have now fully recovered from the marathon release that was SAM 6.0; and as such it is time once again we turn our attention to the future of SAM. Below is a listing of several of the new features they're brewing up in the laboratory.

 

  • AppInsight for Exchange
  • JSON Monitoring
  • SOAP Monitoring
  • Independent Thresholds for Node CPU Utilization, Memory Usage, Response Time, and Packet Loss
  • Windows Scheduled Task Monitoring
  • User Definable Sustained Status Condition Alerting
  • Optional Agent for Monitoring Windows Applications and Servers
  • Application stacked integration and visualization (i.e. visual mapping through your entire application stack to help you answer the question, "Why is my app slow?")

 

PLEASE NOTE:  We are working on these items based on this priority order, but this is NOT a commitment that all of these enhancements will make the next release.  We are working on a number of other smaller features in parallel.   If you have comments or questions on any of these items (e.g. how would it work?) or would like to be included in a preview demo, please let us know!

Please join us for a monthly product update from the SolarWinds Product Management team. The team will cover what’s new, what’s coming, what we’re thinking about for future releases, tips & tricks, and cross-product capabilities.


Each session will be hosted by one or more product managers, and will be very collaborative. We want to hear your thoughts, questions, and requests.

On August 21, we’ll do a sneak peek into our progress with NPM Vnext, and we’ll discuss new developments with our Systems portfolio. We’ll set aside plenty of time for your thoughts, opinions, and questions.

 

IF YOU WOULD LIKE TO ATTEND THIS WEBCAST, PLEASE REGISTER HERE!

Filter Blog

By date:
By tag: