Product Blog

October 2009 Previous month Next month

If you’re trying to meet specific reporting requirements while at the same time hoping to optimize database storage requirements, the question of how Orion NTA data compression works will inevitably come up. With some help from the dev folks, I feel like I understand it enough to try to explain it to everyone else ;-)


Orion NTA performs compression on flow data by combining older flows by conversation and summing up the total traffic numbers. So, it’s still the same old flow data you knew and loved, but just summarized to save database space and improve resource and report loading times on historical data.


By default NTA retains:

  • 1-minute granularity for the last 60 minutes of data. After 60 minutes, it gets collapsed into 15-minute segments (“keep uncompressed data” setting in NTA global settings).
  • 15-minute granularity for 24 hours. After 24 hours, it gets collapsed into hourly data (CollapseTrigger2InHours option in NetFlowGlobalSettings table = 24)
  • Hourly granularity for 3 days. After 3 days, it gets collapsed into daily data (CollapseTrigger3InDays option in NetFlowGlobalSettings table = 3)
  • Daily data for 30 days. After 30 days, the data expires and it is deleted (RetainCompressedDataInDays option in NetFlowGlobalSettings table = 30)

It’s important to map your reporting granularity requirements to the appropriate NTA compression settings. For example, if you need 1-min granularity on the last 3 hours worth of data, you’ll want to set “keep uncompressed data” in NTA global settings to 180 minutes.


WARNING: Before changing any of the default compression settings, make sure the changes are absolutely necessary. Adjusting compression settings to retain granularity for longer periods will increase the amount of DB storage required and may impact reporting and website loading performance.



Orion’s Advanced Alert Engine is a powerful way to set up alerts on possible events in your network.  A big part of what makes it so powerful is the ability to create a wide variety of logical statements via the user interface.  So if you want an alert when a node goes down, but not if that node is named Stan, Kyle, or Cartman, then you can set up a trigger condition that will evaluate each down node and if it matches your conditions, the alert is fired.  If not, then it lets the event pass without a remark. 

What’s happening on the back end of the advanced alert engine is that it’s running a SQL Query.  The trigger condition that you create is actually generating that SQL Query.  The alert engine then executes that query every X minutes, and if it evaluates to true, it fires.

One thing that sometimes trips up users is the way the trigger conditions are constructed.  Each trigger has at least one Condition Group.  The Condition Group is a set of statements that are evaluated together.  Each Condition Group has one of the following logical operators that define how the different statements are treated:  All, Any, None, and Not All.





All and Any are fairly straightforward.  All roughly means “AND”.  If I say,

Trigger if all of the following are true:

Node is Down

Node Name is Kenny

then the whole statement is true only when a node named Kenny is in a Down state. 

Any roughly means “OR”.  If I say

Trigger if any of the following are true:

Node is Down

Node is Warning

then the whole statement is true if a node is in a Down or Warning state.  My recommendation to users is that you stick to All and Any.  They are simple, and I can’t think of a logical statement that you cannot accomplish using all or any.

What about None or Not All?  What do they mean, and why did you include them if you don’t think we should use them?  Well, second part first.  We included them because the control that the advanced alert engine uses to turn your statements into SQL Queries is something we license, and it came with all four logical operators, even though we only wanted two of them. 

What do they mean?  None is roughly the same as saying “not any” or “not a single one”.  If you have a series of statements where None is the operator then the engine will look at each statement under it and if any of those individual statements is true, it will construe the whole Condition Group as false.




Trigger if none of the following are true:

Node is Up

Node Name is Chef

This alert will trigger when node is in any state other than up, unless the node is named Chef.  Note that you could just as easily create an alert with an all that accomplishes the same thing:  Node is not Up and Node Name is not Chef. 

Finally, Not All is roughly the same as saying “at least one is false”.

Trigger if not all of the following are true:

Node is Up

Node Name is Chef

With the logical operator changed, this alert will now trigger any time a node is in any state other than up, but it will also trigger if the node name is anything other than Chef, which would make this alert pretty much useless.

There’s a more formal and detailed explanation in the Orion Admin Guide called Understanding Condition Groups.  My advice is stick to All and Any.  Every time I’ve seen anyone try to use None or Not All, they get unexpected results and end up more frustrated than satisfied.   


So Cisco today announced availability of the Cisco ISR next generation, you can read more about it here or here.


Coming up to this release, we have been working with Cisco to ensure interoperability with the Orion family of products and that it works out of the box, which it does with the latest shipping versions of Orion products.


However, my main reason for this post is one of the cool new features with the new ISR.  With the ISR G2, you only need to install a single image file and then you get licenses from Cisco to evaluate or enable after purchase on the box.  For those of us that have been around for awhile, this is pretty cool since you don’t have to download a new IOS image and schedule an upgrade, you just need to install the new license.


Based on this change, we worked to put together an add on package to help you see what you have licensed and installed on the ISR G2 in your Orion node details page.  This add on package for Orion NPM can be found Cisco ISR G2 Licensing on the thwack content exchange.  Included in there are three things:


1. Node Details resources to give you visibility into the various licenses on the ISR box and their current status, see screenshot below.


2. Report template to allow you to schedule and deliver this data to others


3. Alert to let you know when your license will be expiring soon so you can plan for it


Additionally, for installing and configuration of licensing, Cisco License Manager (CLM) can be used.


For more information about Cisco License Manager, please visit:






“What happened to VoIP?”  This is one of the first questions people have asked about the new Orion module, IP SLA Manager.  The answer is nothing has happened to the old VoIP module; we just made it better.  Before I elaborate, let me take a few steps back.

Cisco has this really cool technology called IP SLA which enables you, the network engineer, to run a series of tests that can help you assess the health of your network from the perspectives of each of your remote sites.  Why is this important?  You may know everything is fine between you and your office in New York, and you may know everything is also fine between you and your office in San Francisco, but what about connectivity between San Francisco and New York?  This is where IP SLA can help.

These tests are actually called ‘operations’ in IP SLA lingo. For example, if you wanted to check call paths between your VoIP call managers, you would create a VoIP UDP Jitter operation, specifying one device as the source and the other as a target.  Once you’ve created the operation, you can start collecting call path metrics between those devices.  This and other similar use cases are what drove us to release the VoIP module for Orion.

As it turns out, IP SLA supports many operations other than just VoIP, things like measuring the round trip time to access a web page (HTTP), or measuring the time it takes to request and receive a reply from a DNS Server (DNS), or measuring the response times between IP SLA nodes (UDP Echo).  Many of you VoIP customers asked us to support these operations as well, and we have kindly obliged. We took the VoIP module, added support for these IP SLA operations (in addition to several others), and renamed the module ‘IP SLA Manager.’

Some of you are asking, 'I've already been creating IP SLA operations on my routers... what's so great about IP SLA Manager?"  The answer to this is ease of use.  If you've been manually creating operations using CLI, you will appreciate IP SLA Manager's easy to use web interface for creating IP SLA operations.  A wizard will walk you through the process, and, once operations have been created, Orion will start tracking historical data on these operations.

If you’d like to learn more about IP SLA, our Head Geek has a great video here.  We’ve also written a white paper on the ‘Basics of IP SLA,’ which you can find New to Networking Volume 2 - Basics of IP SLA .  Lastly, you can try out IP SLA Manager for free; you can download it here.

One of the questions I regularly answer on thwack is which NCM component to install where and how to enable integration of NCM with NPM.   Specifically, where to install the 2 different executables included in the NCM download.  

To help clarify deployment, here’s a quick overview:

  • NCM “Server” executable – installs the NCM server, client application, and standalone website.   These components can be installed on the same server you installed NPM or on a completely separate server.  PLEASE NOTE: Installing this executable on the same server as NPM does NOT automatically enable integration with NCM.  You still need to install the NCM integration module described below.
  • “NPM integration” executable – installs the NCM integration module on your Orion NPM website.  This component must be installed locally on your Orion NPM server.  After installation and configuration wizard has finished, you will see a Network Configuration Manager link show up in your Orion NPM website.   

One last tip: When upgrading from previous versions of NCM, don’t forget to also upgrade your NCM integration module at the same time.  Otherwise, you won’t see any of the cool new features!    For example, the NCM 5.5.1 integration module now allows you upload and download configs, execute scripts, and run inventory and compliance reports directly from your Orion NPM 9.5 website! 



I see on thwack here and there users posting regarding their web console and it sometimes being slow and what could be causing that.  Usually I tell them to open a support ticket since it is hard to diagnose via a forum, however, I wanted to try and compile what our Support Techs typically ask when you do open a case with Support.  I have compiled this list of potential items to look at below.


· Do you have Microsoft SQL Server running on the same box as Orion?  If so, you may want to look to moving it off box if you are monitoring quite a few things.  SQL is typically a memory hog.


· Check the average write disk queue length on the disks that the Orion database is writing to.


· Make sure no other corporate back-up programs might be running during the time the slowness is happening.


· Do you have a shared Microsoft SQL Server with multiple database instances that the Orion database is on?  What are those other database doing?  Are they starving the Orion database?


· How much memory is the Microsoft SQL Server allowed to use?  The more the better, especially as you add additional modules on top on Orion NPM, but on average 3 GB is a good starting point.


· How many users are using the website when the slowness is happening?  Do you potentially need to look at adding an additional web server?


· How many resources do you have on the page that is experiencing the slowness?  If a lot, if you reduce it, does the page perform better.


· Do you have real-time anti-virus running on the Orion server?  If so, you may want to look to exclude the inetpub directory and also if possible the SolarWinds directory.


· On the Orion server do you currently have NPM and other Orion Modules?  If so, make sure the specs on your box are up to snuff to handle them.


· Make sure you are on the latest version and if you cannot upgrade, at least the latest service pack for Orion


· Are you sending a lot of Syslog Messages and SNMP Traps to the Orion Server, on the order of tens of thousands?


· How many elements are you monitoring with Orion?  If you are running upwards of 8,000 elements with out of the box default polling setting, it might be time to get another poller


If you do try these and it is no better, by all means, please open a support ticket, but when you do, be sure to submit Orion diagnostics with the ticket as that will be one of the first things they ask from you.

This is the first post of a new effort here at SolarWinds.  We are kicking off an Orion product team blog.  Why would we do this?  The product team already monitors thwack, our community forum, and responds to user comments and questions many times every day.  So, you might ask, what else could we possibly have to say?  Lots, actually.

With thwack, we're reacting to users, and we're committed to continuing that ongoing conversation.  With this blog, our desire is provide a proactive channel where we can talk to users about Orion.   In this blog, we're going to assume that the reader owns and uses Orion and its modules.  That assumption gives us the freedom to talk about nitty gritty details of the product and its features.  Prospective customers are welcome to read and may benefit from doing so, but our goal is to provide a service to existing customers.  In fact, in a future release of Orion, we intend to make the blog available right in the product in order to make the content as readily accessible as possible for all customers.

What are we trying to accomplish? 

  1. First and foremost, we want to provide some content that might fall in the "tips and tricks" category.  We talk to and hear from so many customers who have done really interesting things with Orion, and we want share some of their creativity more widely.  We also talk to new customers who like Orion and suspect (correctly, more often than not) that they are only getting a fraction of the value of the product. The Orion family strives to be easy, yet powerful, which means that the "meat and potatoes" of the product can be accessed without much effort, but over time, ever more power reveals itself.    We want to accelerate that revelation process.  
  2. The other thing we expect to do is talk about features-new and old-and the rationale behind them.  Product Management and Engineering work closely on the design of each feature, including end user feedback as much as possible.  In the end, we spend a lot of time on the features, and we care about the details.   And since you're the consumer of these features, we figure you all care about them, too, and will be interested as well.  We know our spouses aren't.  We've tried talking to them, and frankly, we're tired of the eye-rolling when we try to tell them excitedly about the new, cool thing we just released.   So, we'll tell you about the features instead.  We'll explain what we were trying to accomplish, why we made the design decisions we made, and all the inside dirt.

We encourage comments and we'll respond.  It's just another channel for our ongoing dialog about Orion.  Please add this blog to your RSS Reader or set up email notifications if you're interested in this content. 

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.