1 2 3 4 5 Previous Next

Product Blog

72 Posts authored by: bshopp Employee

This 60 minute training session on Orion Network Performance Monitor (NPM) and SolarWinds Application Performance Monitor will cover optimizing hardware configurations for Orion, installation, discovery, and base configuration, configuring reports and alerts, and leveraging the information that Orion provides.


To register and view please visit the following -  http://www.solarwinds.com/resources/webcasts/npm-and-apm-level-1-customer-training.html

As we posted Orion NPM – So what’s up next? some time back, there are many great new features we are working on for the next version of NPM.  We are currently wrapping up a successful Beta1 with a set of customers and are just about to enter into Beta 2 in the coming weeks. 

First, I would like to invite and encourage any NPM customers with active maintenance to sign up to participate in Beta 2 and give us feedback.  The earlier we get feedback, the more tweaks and changes we can incorporate into the product, plus you get to play with the new stuff early :)  If you are interested in Beta 2, you can sign up here.

For those of you that don’t have the bandwidth to participate in the beta, I wanted to walk through one of the new features in this release and allow you to give us some feedback via the blog as well.

So first, what’s going to be available in Beta 2?

  • IPv6 Support – ability to poll and monitor IPv6 nodes just like you can today with IPv4
  • SNMPv3 Trap Support – ability for Orion to receive & send SNMPv3 traps
  • Multi-CPU Polling – the ability to poll and visualize multi-CPU machine in Orion (see below)
  • Windows Server Polling (non SNMP) – since SNMP is not on by default on Windows, this now gives users the option to discover and poll Windows machines using WMI
  • Improved Topology (more accurate ConnectNow) – we are removing the dependency that Network Sonar must be used to gather topology, it will now be a polling job.  Also we have greatly improved the accuracy of L2 topology and added in L3 support.
  • Network Atlas performance improvements – faster loading of maps in the web console
  • Procurve 420 support – more out of the box Wireless support

If you can’t participate in the Beta, no worries, we will have a Beta 3 as well, so maybe then.

I wanted to take the rest of this post to discuss and get feedback on one of the items listed above, multi-CPU polling.  This is one of the smaller features, but cool none the less. 

How it works today for multi-CPU machines is we gather all the values, but then average them and that is what you see displayed in reports, charts, gauges etc.

As of the next version, you will be able to report, alert and visualize these types of machines by CPU.  So we do not plan to take away any of the existing resources, reports etc.  You will still have the gauge that does the average and the Min, Max and Average CPU Utilization chart.  What we will be adding is two new resources, as illustrated below in the first image, that will break out each CPU’s usage over time in a chart, but also the current value in a table format. 

Also, on the node details resource, we will add a row, as highlighted in the second image, that lists out how many CPU’s that machine has.  This new feature will not only work for Windows, as shown in the screenshot, but also other server OS’s and network gear.





Date/Time: Thursday July 7, 2011 @ 11:00 AM CDT      


GTW link: https://www1.gotomeeting.com/register/567572777




Please join us for an exclusive training session on Orion Network Performance Monitor (NPM) and SolarWinds Application Performance Monitor.


During this 60 minute training session we’ll cover:

  • Optimizing hardware configurations for Orion
  • Installation, discovery, and base configuration
  • Configuring reports and alerts
  • Leveraging the information that Orion provides

This training is most beneficial to current new users of Network Performance Monitor and Application Performance Monitor and will be hosted by Andy McBride, Technical Support Specialist and Jason Ferree, Technical Support Representative.

Title: A Case Study in Best Practices for Network Management


Date/Time: Thursday June 23, 2011 @ 11:00 AM CDT


Sign-Up:  https://www1.gotomeeting.com/register/390327232




Discover how SolarWinds IT management solutions are helping state, local and education organizations maximize their dollars and do more with less. Join us as we discuss the solutions and practices deployed by Monroe City Schools, and how they can be applied to other environments within the education, state and federal government space.

Lately I have had a couple conversations with some of you, and it became clear that there is some confusion lately on standalone vs. module in Orion means.  Do I get less functionality if I deploy one way or the other?


First, let me set some context for those of you not familiar with what I am talking about.  Until recently, if you wanted to purchase our SolarWinds Application Performance Monitor (APM) or SolarWinds IP Address Manager (IPAM) product, then you had to own Orion Network Performance Monitor (NPM).  Now, with the most recent releases of both of these products, this is no longer true.  We also just recently released a new product, SolarWinds User Device Tracker (UDT), which can be installed either way as well.


So why do this?  It seems confusing.  There are two main reasons:

  1. Some folks came to look at SolarWinds whose need was just for Application Monitoring or IP Address Management, but they already owned an NMS and didn’t need or want to purchase our NPM product.
  3. In other cases, we had existing customers of NPM and other teams/groups within their organization saw it, learned that we had APM for apps and servers, and they wanted it; however, the two groups did not want to share the same database because they had different approaches to the product (or they just hated each other, or whatever). 

Question: Do I get different functionality by installing standalone vs. a module?  Meaning do I get functionality by installing one way that I do not get installing the other way? 


Answer: No, they are identical in functionality.  The only difference is that if you own NPM currently, then purchase APM and choose to deploy standalone and not as a module.  In that case, you would now have two web consoles, two database, etc. so you will lose the single pane of glass.  I have put together an image, below, to help illustrate this.




Question: If I want to deploy as a module, does NPM have to be the base or can any standalone product be the base/initial product. 


Answer: Any standalone product (with the exception of NCM) can be the base product and the other standalone products can be installed on top as modules.  The only products which have any relationship/dependency is IPSLA Manager and NTA, which both require NPM to be present, see the below image as an example.






The ultimate goal of this decision on our part was to give customers more flexibility in deploying our technology.


So which Orion-family products can now be deployed as either stand-alone or a module and which can only be deployed as a module for Orion?


Stand-alone or Module:

  • NPM
  • APM
  • IPAM
  • UDT

Module Only (requires NPM):

  • NTA
  • IPSLA Manager

Virtualization Manager (formerly Hyper9) and Storage Manager (formerly Storage Profiler) live on a different platform, and while we do have or will have integrations with these products, the standalone vs. module discussion doesn’t apply.


The Magic 8 Ball in Orion

Posted by bshopp Employee Apr 14, 2011

I walk into one of our Development Managers office on a weekly, if not daily basis, asking for a feature or bug fix and to mess with me he has a magic 8-ball on his desk he likes to shake up and make the decision.  I am sure almost everyone has either owned or played with one of these things where it gives you responses like “outlook does not look good”. 



I bet most of you have come across a situation where a manager or someone else comes up to you and ask questions like:

  • when is that disk drive going to run out of space?
  • how far out are we from maxing out the capacity in the link out to the Internet?
  • based on historical usage of the CPU on this box, when are we going to max it out?

It is a bit like pulling out the magic 8-ball and giving it an nice big shake.


Well not anymore.  There is a cool, little feature in Orion which many folks do not know about which allows you to do trending analysis, with much more accuracy than the good ole’ Magic 8-ball.


We use a method called “Least Square” to perform this analysis.  If you are interesting in reading all the geeky stuff on this algorithm, check it out here.


Let’s walk through how do do this in Orion using the disk drive example above.  Your manager comes in and is doing budget planning for the next year and need to know if this specific server is going to need a drive upgrade or not.  In the Orion web console you drill down to the server in question and select the drive and get a nice chart like you see directly below.  It looks boring and flat and only using 14gig of 39.9gig, plenty of room for the next year right? 




If you now select “Edit Chart” in the drop down you will get a new page, where under the Time Period heading, you can select custom.  Enter a date in the past and then a date in the future, say six months out and click refresh.




The result will be chart where based on the historical we have gathered and stored you can see you have plenty of room and overall is on a downward trend.






This feature work with Volumes, Interfaces, CPU, Memory, etc. 


Still keep the Magic 8-ball on your desk to mess with people, but now you can give you manager much more precise data for their budget capacity planning exercise.

It has been a busy week and a half in the browser world with both IE9 and FF4 being released to the world.  Like myself, many of our customers either have already upgraded or want to upgrade their browsers to the latest and greatest, but have called us to see if we support them yet.


The formal answer is no, not with the shipping products today.  We plan to support them in versions later on this year depending on the product you are asking about (Orion, Profiler or Hyper9).  For Orion, we plan to add support for these two product versions in the next release of size, including dropping support for IE6.  I blogged about this a few weeks back and you can read Announcement of end of support for Internet Explorer (IE) 6 in next Orion NPM version. Also, when I say release of size, this does not mean a Service Pack or a Service Release. 


If you choose to brave out on your own and use these browser versions, there are a couple issues we know about.  The largest one is with Firefox 4, in which if you currently try to go to the Orion web browser from your PC, you will get the mobile view of Orion instead.  Here is a manual workaround to this.


On the Orion server, open <drive_installed_on>:\Inetpub\SolarWinds\bin\web_browsers_patch.xml  
Add section within Devices section:   
<!--  FireFox4 -->   
        <device user_agent="Mozilla/5.0 (rv:2.0b10) Gecko/20100101 Firefox/4.0" fall_back="firefox" id="firefox_4_0">   
            <group id="product_info">   
                <capability name="model_name" value="4.0" />   


That’s it, any questions, please feel free to let me know.


We added a feature back in Orion NPM 10, however, over time I have gotten this questions from folks and seen Parsing Trap Text For Alerting on thwack come up asking if you could do this in Orion and if so, how? 


Background on the problem people are trying to solve:


An SNMP Trap sent from a device is a general blob of data with some standard data followed by vendor defined information called variable bindings; see the example below for how this looks.


These traps have additional information sent with them called variable bindings. These extra variables contain information relating to the trap and ya’ll don’t want to have to visually parse each trap manually.  What you have asked for is some sort of variable notation allows the capability to format and display these variable bindings as needed.  


With this ability you can format an email notification with the separate variable bindings.  So instead of receiving an email with the block of text below in the example, you can get only the specific information you care about.


An example of of our community members posted on thwack was this.


What I want is the "apSvcTrapEventText" line with just "Service:test State:suspended" in the email.  How do I format the email text to get it?


When creating the email notification template in Orion, you can do something like this below, where ${vbdata3} equals the value associated with the third listed trap variable.




${Caption} - ${vbdata3}



03/08/2011 08:20 : ARROWPOINT-SVCEXT-MIB:apSvcTransitionTrap SNMP Trap  
Received Time:3/8/2011 8:20:32 AM  
Variable Bindings  
sysUpTime:= 2 days 13 hours 35 minutes 55.25 seconds (22175525)  
snmpTrapOID:= ARROWPOINT-SVCEXT-MIB:apSvcTransitionTrap (  
apSvcTrapEventText:= Service Transition - Service:test State:suspended  

Let’s walk through an example of this in the product.

  1. On the Orion server, open the SNMP Trap Viewer
  3. As you can see I have a specific trap, but I don’t want all the information included within it, I just want SysUpTime     
  5. Create a new trap rule in the SNMP Trap Viewer and define your filters to narrow down to the specific trap you are interested in.  In this example, I did it by IP Address.
  7. On the Alert Actions tab, select add a new alert action.  I chose log to a file, but this would work with the others as well, including email
  9. In the dialog “Message to Log File” I entered in three variable.     
    • Date/Time Stamp
    • Name of the first trap variable
    • Value of the first trap variable         
  11. In my text file I chose to log to, there is an entry for each trap I have received that matched this rule.  As you can see, instead of getting the entire trap message, I only get the value as defined by my variables in step #5 above.     

That’s it, pretty straight forward. 

When I talk with a customer and get the question, “how does Orion scale?” My answer is the customer can choose one of two ways to scale.

  1. By adding Orion Additional Pollers to scale horizontally
  2. By deploying multiple Orion instances and rolling up into the Enterprise Operations Console

In this post, we are going to discuss the Enterprise Operations Console or EOC for short.  EOC’s main functionality is to aggregate data from multiple Orion server installations and to display it in a similar fashion as the Orion Web Console.


Take the below first graphic, you have a worldwide network with teams responsible for managing their respective geographies, so an Orion installation resides in each North America, EMEA and APAC.  The global NOC and Management Team requires a single rollup of all servers into a single installation for status, alerting, reporting etc.

Orion EOC aggregates the current status of your Orion NPM servers and presents this data in the Orion EOC Web Console. Administrators can restrict what Orion NPM data each Orion EOC user is permitted to see. These restrictions can be set on an individual basis by customizing user settings and on a group basis by defining roles.



In the EOC web console, here is what you would see as illustrated in the second screenshot below.  One of the common misconceptions about EOC is that it pulls all the data from each of your Orion servers into the EOC database.  In actuality, EOC pulls high level information like current status, alerts, events, syslog and traps.  Any data beyond that, when you click on that item in the web console, you are seamless redirected behind the scenes to the Orion server that item resides on.  Let’s walk through an example.

  1. Looking at my EOC dashboard I see that under the “Global Nodes with Problems” resource, that Switch sales is down.
  2. I click on switch sales and am automatically redirected to the node details page for device Switch sales and logged into the Orion server Orion America as that is where that node resides for monitoring

I can now perform my investigation and go right back to my global EOC dashboard.


Now that we have gone through a high level of what EOC is an example use case, let’s get in deeper on how it works.  I have taken my first image from above, but broken it down to a “how it works” level.  EOC is comprised of 4 main components:

  1. Orion Poller
  2. Information Service
  3. Website
  4. Database.


EOC pulls the following type of data through the Orion Information Service:

  • Alerts, Events, Syslog, Traps (last 24 hours worth of data)
  • Node, Volume, and Interface data (no historical data)
  • APM data (no historical data)
  • NetFlow (no historical data)
  • IPSLA Manager (no historical data)
  • Wireless (no historical data)
  • NCM (no historical data)
  • UDT (no historical data)
  • IPAM (no historical data)
  • Support for displaying Orion Groups

The Information Service (IS) module will exist in both EOC and Orion products. The service will provide a single point of communication and a simple and efficient mechanism to query the servers.  All communication with the IS module is encrypted using SSL and is on port 17777.

The Communication module uses Windows Communication Foundation (WCF) as the basis of its communication mechanism which allows other applications, websites, scripts, and application modules to seamlessly communicate with it. WCF also provides secure, reliable, and several transport and encoding options. It will allow us to easily build several types of messaging protocols such as REST, SOAP, etc.

The IS module provides a simple query interface that allows the client to execute a read-only query written in SolarWinds Query Language (SWQL). SWQL is very similar to the commonly used SQL language with a few deviations.

When typically asked how does EOC scale or how many Orion server can EOC handle, as a typical rule of thumb I say a customer roll up 20-25 SLX’s into a single EOC instance.  With this being said, if they want to roll up more smaller installations, they can, as long as the total number of elements feeding into the EOC is not more than about 600k.

We also get frequently asked some rough ideas on how much traffic to anticipate between the Orion servers and EOC.  While this is very variable, the below chart can start to give you an idea of what to expect.


















625 KB









700 KB









822 KB









479 KB









1.183 MB






3 Apps, 37 Components

1 Source


1.277 MB

There you have it.  From high level what is is, down to how it works, hopefully this helps shed some light in one of the many different ways you can deploy the Orion family.

In two previous blog posts I have introduced the Failover Engine and walked through some common Q&A we received right after launching the Failover Engine last year.

In this blog I wanted to get down into the nuts and bolts of how the Failover Engine actually works under the covers.  When it comes to protecting an application, there is more to it than just watching the services. You need to watch and protect the entire Application stack.  On your Orion server, the following components exists:

  1. Services
  2. Registry Settings
  3. File System Structure
  4. Web Server (IIS)

We could just watch the Orion services and be done with it, but the problem with this is that you must then maintain your secondary failover server with the exact same configuration and settings manually.  If/when a failover condition occurs and your end users notice reports or setting changed or missing, then you are going to get a call.  Also, what if the problem is not with Orion itself, but something is going on with Microsoft IIS?  Since the Failover Engine is watching and protecting the four areas above, as also illustrated in the below image, you do not have to worry about these scenarios as they are covered.  




Let’s walk through each of these four areas in further detail.

  1. Services   
    As shown above the Heartbeat is checking periodically that all the services are up and running.  The Heartbeat portion of the application is responsible for the data replication, switchover and failover processes.  The protected service list is created dynamically by looking at a specific registry setting that we write to on product installs.  So as long as you have the appropriate license, if you install a new module then protection is automatically picked up. For the given services being monitored, within the Failover Management client you can specify behavior (you can define up to three steps per service), like which services are the most critical and when to initiate a failover. Example, SolarWinds Syslog Service:
    1. Service fails
    2. First attempt- restart the service
    3. Restart fails – second attempt restart the entire Orion application
    4. Syslog service still fails, then initiate a failover to the secondary server
  2. Registry Settings   
    As I discussed above, there are key critical registry settings the Failover Engine watches and replicates between the primary and secondary server (more details on replication below).  These include things like licensing info, SolarWinds directory locations and registered SolarWinds services.  This is the reason you don’t have to buy two copies of Orion.  Since only one copy Orion is running at any given time and the registry is in sync you don’t need two license keys.     
  3. File System Structure   
    With Orion most data is stored in the database, so why is this important?  There are files which are important to the use and operation of the product which need to be replicated across servers.  Examples include report template definitions as you may create a set of custom reports.  From a back end operational standpoint the service SolarWinds Job Engine has a small database we install that handles the job dispatching and processing, which is also very important to keep in sync.  Here are some key items to know about the replication portion of the Failover Engine
    • If for some reason the channel between the two servers is broken, the Failover Engine will queue up the replication changes .  When connection is re-established, we will restart replication to verify data sets are the same.
    • Near real-time byte level data replication is provided between the active and passive servers.  Byte level replication ensures that only file deltas are replicated and not whole files or transactions.
    • Near real-time byte level replication works within the Windows kernel to ensure that near real-time data changes are sent from the active to the passive (secondary) server and once the process is complete. Below is a basic overview of how this process works.
      1. Data change is requested
      2. Failover Engine Filter Driver intercepts the request at the I/O leve
      3. Failover Engine Filter Driver checks the replication settings to see if this change needs replicatin
      4. Failover Engine Filter Driver generates a unique sequence number for the replication reques
      5. Failover Engine Replicates the data and also sends the change on to the windows file syste
      6. Windows commits the data change and sends confirmation to the application laye
      7. Failover Engine Filter Driver intercepts the confirmation
      8. Failover Engine replicates the confirmation to the passive server if require
      9. Data change process is now complete
  4. Web Server (IIS)   
    Orion services can be up and running just fine, but users may be complaining that the web console does not come up or is slow.  Is IIS running?  Failover Engine watches IIS at a service level; you can also define checks & tests to ensure the website is up and responding within an acceptable period of time.

Let’s switch gears now to licensing/packaging. Since one of my previous Failover Engine posts, APM and IPAM have released new versions which can be deployed as a module (as you could always do), but now both can be installed standalone without requiring NPM as well.

We still license by what we call a “primary product” per server. Previously, what was classified as a primary product were Orion NPM, APM and NCM.  This is where the change comes in, prior to IPAM 2.0 you could only install IPAM as a module, we didn’t charge for protecting it.  If you still deploy it as a module, this remains true.  If you purchase IPAM and choose to deploy it standalone and desire Failover Engine protection, then you will need to purchase the Failover Engine for One Primary Product.  Now that we have release SolarWinds User Device Tracker or UDT, it also behaves the same way IPAM does here.

Let’s walk through two different examples.

  1. Orion NPM, IPAM and NTA – you will need Failover Engine for One Primary Product.  Since NPM is considered a primary product and IPAM is installed as a module, you get protection for IPAM for free.
  2. Orion IPAM only – you will need Failover Engine for One Primary Product.  Since you are deploying IPAM as a standalone you will need to purchase a license to protect it.

One last scenario with the release of UDT or User Device Tracker.  Since IPAM and UDT are not considered "primary products" as described above, what if I purchase UDT and IPAM and want to protect both of them with FoE, what do I need to buy?  The answer is you just need an FoE for One primary product in this scenario.

Any questions or comments, please post them.  As I have illustrated in this post and the two previous posts I referenced at the start of this post, the Failover Engine product is very feature rich and more than just High Availability/Disaster Recovery, but more about Application Availability.

A long, long time ago in the year 2010 if you wanted to run Orion APM and IPAM you had to own Orion NPM.  With the launches of APM 4.0 and IPAM 2.0 earlier this year you can run either product as a module or standalone – that is, without installing NPM first.  To enable this we had to remove the dependency of requiring NPM.  So over the past year we have been making this separation into what we call “Orion Core”.


Obvious next question is “What is Orion Core?”  Orion Core is the base set of infrastructural functionality or services needed for a product to run standalone.  Examples include user authentication, syslog, traps, reporting, website, database etc.


Our goal was to make the concept of Orion Core as seamless and transparent to you, the end user, as possible.  As an example of this, let’s say you purchase APM.  What you download APM from the Customer Portal, it is one set of bits as you can see in the below screenshot.  After you download and as part of the installation process, we automatically figure out if you are installing on top of some other Orion product as a module or if this is a standalone installation.




So at the footer of the Orion web console, you now see the below screenshot in the latest versions.  Most users should never need to worry about Orion Core.  For a few of you, however, understanding what Orion Core is would be helpful, and specifically, those are the folks with Additional Pollers and Additional Web Consoles.




As many of you know, we only charge customers for the initial instance of an additional poller or additional website per Orion installation.  Since in the past everything in the Orion family required NPM in order to be run, you saw Orion NPM 10.0 Additional Polling Engine or Orion NPM 10.0 Additional Web Server in the customer portal.


Example from the past:  I have Orion NPM & APM on a single server.  I have purchased an additional polling engine.  I download my Orion NPM 10.0 Additional Polling Engine and install it and since APM supports an additional poller as well, I can install the APM additional poller at no additional cost to me.


Even though customers can now purchase APM standalone, this scenario is still valid and true.


The new scenario is I purchase Orion NPM, APM and a single Orion Additional Poller.  As outlined in the below diagram, I am going to install Orion NPM and APM on different servers since different teams will be responsible for using and managing their installation.  Both server installations each need an additional poller for scale.  Can I use the single Orion Additional Poller purchased on both servers?  The answer is no, the user will need to purchase one more Orion Additional Poller.




Below is what you now see in the customer portal for Orion Additional Polling Engine and Additional Web Server.  Since this is specific to the Orion Core version I discussed earlier we can’t put a normal product version on it like NPM 10.1 or APM 4.0 since it could be used on either.




Key takeaway from this thread is the following:

  • If you don’t own Orion Additional Pollers or Additional Web Servers, don’t worry about Orion Core
  • If you do own an Orion Additional Poller or Additional Web Server, make sure what you download and install matches what is in the web console for the Core version (aka 2010.2 or 2011.1 etc.)

The internet browser market has been very busy in the last year in terms of new versions and adoption of new browser platforms. 

  • Internet Explorer 9 is currently in Release Candidate
  • Firefox 4.0 is currently in Beta

You can view usage statistics for last month, but also over time here - http://en.wikipedia.org/wiki/Comparison_of_web_browsers


With each release we evaluate usage statistics available on the web, but also looking at data from thwack.com and solarwinds.com.


As we are in planning stage for the next NPM release, when we release this version (meaning later this year), we will be formally dropping support for Internet Explorer 6.

The NPM team is busy at work on a number of highly requested enhancements:

  • Web performance improvements
    • General tweaks and enhancements to web console
  • Improve Orion product/module integration user flow
    • Enhance UI navigation linking together data between products and more intuitive layout of data on pages
  • Improved View Management/Graphical Reporting
    • Usability enhancements on creating new Views or Dashboards within the Orion web console and scheduling those to be delivered as reports to end users
  • User Audit Trail Tracking    
    • Ability to determine who did what and when in the Orion system. e.g. add node, delete node, add interface etc.
  • SNMPv3 traps
    • Ability to receive not only SNMPv1 or v2 traps, but also SNMPv3 traps.
    • IPv6 Support
      • Ability to add and poll device via IPv4 or IPv6
    • Internationalization
      • Stronger support for users installing and running NPM on non-English operating system

    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!

    Over the past couple of months the Product Management team has been walking through all the new features in 10.1 and another one of the key features I would like to touch on a bit is our addition of native out of the box support for the Cisco Unified Computing System or UCS for short.


    So what is this UCS thing?


    When Cisco first announced the UCS, the industry positioned this as Cisco’s entry into the server market.  The UCS is designed to allow customers to build programmable data center infrastructure optimized for virtualized resource, as well as memory-intensive bare-metal workloads.. It is also intended to manage all physical and logical UCS elements—servers, I/O, VMs, etc-- as a unified environment and support applications and services from leading vendors, including Microsoft, EMC, VMware, Red Hat and Novell.


    I borrowed the below graphic from the cisco.com website to help illustrate the pieces that go into the UCS chassis.




    Why did we add support for the Cisco UCS in NPM 10.1?  Two primary reasons:

    1. Based on the increased support demand for the Cisco Nexus product lines, we felt the next natural step was to also support the UCS.  As you can see here in NPM 10.1 UCS Monitoring - Adding Blades, SNMP Possible? thread, there has already been quite a bit of discussion on thwack about UCS support in Orion.
    3. It is my opinion that the line that used to exist between the server, application and networking teams are blurring together.  No longer does the network end at the wall jack or the switch port.    
      Ex. 1 – VMWare vSwitch and vDS or virtual distributed switch resides on the ESX server that contains a software based switch.  Who owns and manages this?     
      Ex. 2 – the Cisco UCS includes a fabric interconnect with physical Ethernet ports and fibre channel ports, which distributes converged traffic through “extended line cards” to server blades with virtual ports running VN-Link technology.

    As these complexities of running your IT infrastructure increase, so must your IT Management solutions.


    I can already hear your next question, “Can’t I just use the UCS Manager software.  Why do I need Orion?”  Orion is not meant to replace UCS Manager.  UCS Manager is great for advanced provisioning and management of the UCS itself, but does not extend to other types of infrastructure.  Orion NPM provides the following advantages:

    • single pane of glass to monitor your wired and wireless infrastructure, as well as your servers (both physical and virtual) and applications
    • UCS Manager only retains a week’s worth of historical data, whereas Orion can retain it for as long as required
    • Orion is pulling UCS information directly from the UCS API as well as SNMP, which allows Orion to report and alert on UCS events

    Let’s walk through adding a UCS chassis to Orion and what it looks like after we start monitoring it.  You will notice in adding a new node there is a new check box dialog for UCS Manager credentials.  Also, you will want to enter in the primary fabric interconnect IP Address of the chassis as this is what we will use to monitor the UCS.




    Once added and we start polling the key new data we are gathering as shown in the screenshot below:

    1. Fabric Interconnects status
    3. Chassis and blade status including fan and power supply (PSU) status
    5. UCS Events (polled from the API)
    7. Fibre Channel information including Connectivity Unit Status, VSAN’s and WWN Port information



    We are also gathering port/interface data for all the virtual interfaces, fabric interconnect ports etc. as seen below.




    Screen shot 2010-11-22 at 10.02.29 AM






    Tell us what you think.  Are you using Cisco UCS?  What else would you like to see in Orion as it pertains to monitoring Cisco UCS?


    Also if you are going to Cisco Live in London, come on by the SolarWinds booth to learn more about UCS and Orion NPM 10.1 and get some cool free geeky stuff.  We will be in booth # G4.

    As you can see in It’s Showtime!  Orion NPM 10.1 is officially GA! post Chris wrote, we have discussed a handful of the features already in NPM 10.1.  As part of the next installment of this “Meet the Features” series, I wanted to walk through a handful of new related features, which I have listed out below.

    • A dedicated alert view made for mobile web browser to allow you to view and acknowledge alerts from your phone
    • Receive an email alert notification and directly from your email whether on your PC or mobile device, acknowledge that alert by clicking on a link
    • Enable, disable, and delete Advanced Alerts in the web console
    • Ability for users to add notes to alerts in the web console
    • Just like in Report Writer, you can use SQL to create advanced alerts you cannot create through the built-in trigger creation interface

    Mobile View:

    We heard many times from users, “hey, why don’t you have an iPhone app"?”.  My reply is, I am an Android user, so no way we are just doing an iPhone app. :)  Kidding aside, we wanted to provide a method for users of all phones to be able to leverage Orion and not just limit it to one vendor, NPM is after all multi-vendor network monitoring right? 

    In your web browser just put in the url to your Orion server.  If for some reason your phone does not auto-detect that is is coming from a mobile browser, then all you have to do is at the end of the URL add ?ismobileview=true.  Here is a URL from my Orion install,

    Mobile Network Monitoring Views

    Acknowledge alerts via email:

    Continuing on the phone discussion topic, most of us monitor and respond to emails on our phones.  It is much easier to take a phone with us when we go to meetings or are out to lunch, etc.  Many folks are also connected via WiFi to their internal wireless network or have a VPN client loaded on their phone, so they never even need to boot up their laptop to do some things. Now on top of having a mobile views to acknowledge an alert in Orion, you can also do this via your email as well.

    To set this up, follow these steps.

    1. Edit an existing or create a new Advanced Alert
    2. Select the Trigger Actions tab
    3. Choose Add New Action and select Send an Email/Page
    4. Click on the Message tab and select Insert Variables
    5. Select the General Category and there will be a variable in there called AcknowledgeURL
    6. Select Build Selected Variable and in the message body of the email you will see a variable that looks like this ${AcknowledgeURL}.
    7. Now when you receive an email alert, there will be a link you can click which says “Click here to ack this alert”

    Enable, disable, and delete Advanced Alerts in the web console:

    As many of you know, to add, edit and delete alerts in Orion, you have to RDP to the Orion server.  You have thoroughly beat me up on this on thwack and will continue to into the future, however, we did do some things in 10.1 to start to make this better.

    If you navigate to the Settings page, there is a new section to manage Advanced Alerts, see below screenshot.


    You have the ability to enable or disable an existing alerts, delete an alert or edit some basic setting within an alert.  To be clear, what you still need to RDP to the server to perform is to create a new Advanced Alert, change the trigger/reset conditions or alert actions.


    While we are not all the way there and you still need to RDP to Orion to perform some functions, you can see here we are making forward progress on bringing more to the web console for ease of use and management.

    Ability for users to add notes to alerts in the web console:

    With the launch of NCM 6.0 we started this feature and finished it off in 10.1.  We heard from many folks, when an alert fires, I want to be able to append information to that alert for the engineers to help the research the issue, but also to put general notes on what they have done to investigate the issue and what the resolution was.  If you have NTA, you can put Top Talker information into alerts now or if you have NCM you can have a show command be run on the device when an alert triggers and the output put into the notes section of the alert.  This gives engineers more data at their fingertips much quicker to troubleshoot and resolve the issue.  If you click on the alert name you will now get a popup in which you can enter text as you can see in my below example.




    Advanced SQL Advanced Alerts:

    Whew, had to say advanced twice in the title of this section, must be a powerful feature then huh? :)  The native Orion interfaces provide a lot of flexibility in creating Advanced Alerts, just like we do in Report Writer and can solve most of their use cases that way.  However, we hear from folks of the desire to do use cases, which the native UI can’t construct today.  So what we have added to Advanced Alerts is what I call an “escape hatch” to handle more of those complex use cases you can now create your own SQL queries to do checks on the Orion data.

    1. Create a new Advanced Alert and under the Trigger Conditions tab select the dropdown at the top of the dialog and at the bottom of the list, there is a new option called “Advanced SQL Alert”.  See below screenshot for further reference.    
    2. image

    3. You can select against which element you want to inspect; node, volume, etc. and define the SQL query    

    That’s it, easy to setup.  And don’t worry, we have also added a fail safe for this feature.  If someone writes a SQL query that is completely horrible and hammers the SQL database and take longer than 60 seconds by default, then we automatically kill the thread, disable the alert and log a notification to the Orion Event Log.  This timer is configurable on a global basis under the Polling Setting option in the Setting page.

    A lot of content in this post, but I am just too darn excited about the NPM 10.1 release to break this out into 4 posts and string you along.  I want to get as many of you folks as possible upgraded to 10.1 and checking these features out and giving us feedback on what we did right and anything we did wrong (hopefully nothing :)).

    There is a NPM 10.1 Features Highlight webinar on Thursday, December 9th where you can learn more.  You can read about it Orion Training session: Orion NPM 10.1 New Features in a post Denny wrote and sign up.   

    Filter Blog

    By date: By tag:

    SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.