Skip navigation

In a previous post, we covered Community works! - A simpler way to manage Orion email alerts based on an idea we took from the community.   Now it’s time for us to give back with an enhancement that, once you use it, you may wonder how you ever lived without it ;-)

Imagine this scenario, or perhaps, just look at your email if you’ve got that in front you.  You’ve received an alert notification that a node is experiencing issues.  What’s your typical next step?   For most users, it’s to open their Orion website, find the node, and drill down to the node’s details view to start investigating. 

The problem is this felt like one too many steps for most of you.  Why can’t you just drill down from the alert?   To solve this problem in Orion 10.0, we’ve added several new advanced alert variables that allow you to include a drill-down URL to the object referenced in the alert.  

Here’s how to use them…

1. Open Advanced Alert Manager (Start > Program Files > SolarWinds Orion > Alerting, Reporting, Mapping).

2. Click Configure New Alert to bring up your list of alerts and edit an existing alert or create a new one.

4. Navigate to Trigger Condition tab.  Notice the Type of Property to Monitor field is set to Node.   This is important because this allows you to reference the alert variables associated with that property type.   For example, if you wanted to alert on an Orion APM application or component monitor and reference those variables in your alert notification, you’d want to change this accordingly. 

image

4. Navigate to the Trigger Actions tab and select Send an E-Mail / Page.

image

5. Select the Message tab and click Insert Variable and you’ll see a list of variables to choose from.   Notice that NodeDetailsURL is now available (Yes, I almost cried the first time I saw it too).

image

6. Select Build Selected Variable and it will be automatically inserted in your email.   Now, when this alert triggers, this alert action will parse the variables and automagically include a direct drill-down link to the node the having problems in your email notification.

image

Still not impressed?   The good news is we didn’t stop with just the node URL drill-down variable.   This same approach works for interfaces, VMware machines, applications, monitors, etc.   As you install Orion modules, more URL drill-down options will be automatically added to your list of variables!

Well, we’re hopeful we’ve fulfilled at least part of our karmic duties with this new feature, but please try it out and let us know what you think!

 

In this post we bring you another sneak peek at some of the good stuff in the upcoming release of Orion 10, and this one is all about keepin’ it real when it comes to forwarding Syslog messages.  Many of you have Syslog messages sent to Orion where you may do some filtering or parsing before forwarding those messages on to another Syslog server or NMS.  Prior to Orion 10, when these messages were forwarded from Orion they would appear as if they were forwarded from the IP address of the Orion server, thus losing the IP of the actual source from which the Syslog message originated.  In Orion 10 we’ve given you a few additional options in terms of retaining the source IP when forwarding those Syslog messages from the Orion server.  Let’s take a look at some Syslog messages being sent to the Orion server located at 10.199.15.54.

syslog_orion_server.

Here we see a bunch of Syslog messages being forwarded to Orion from 10.199.15.64.  We are sending these Syslog messages from the Kiwi Syslog Generator at that IP.  Orion is then going to forward these messages to another server located at 10.199.15.40.  Let’s take a look at what those messages look like.

syslog_source_IP_54.

 

Notice the problem?  Although the source IP from which the Syslog messages originate is .64, Orion is forwarding the messages as if they came from .54.  In other words, once the messages reach 10.199.15.40, we’ve lost the the source IP from which the messages originated.  Let’s take a look at how to fix that.

syslog_edit_action_spoof.

Here we see the screen for editing the action for the Syslog rule that is forwarding our Syslog messages from the Orion server to 10.199.15.40.  Note the highlighted area.  You can now configure the action to retain the original source IP of the message.  There are a couple of ways to do this.  Here we have selected the spoofing option, which we’re able to do by having WinPcap installed on the Orion server.  Now that we’ve reconfigured the forwarding rule with these options enabled, let’s take a look at the Syslog messages again at 10.199.15.40.

syslog_source_IP_64.

Notice the two highlighted entries.  The Syslog messages are now showing the source IP from which they originated instead of the IP of the Orion server.  Voila! 

There are a couple of additional Syslog related features in Orion 10; more on those in a future post.

An alert is one thing. An alert with usable information is even better. Even better than that? An alert with NCM data. And that's what we have for you in NCM 6. The Release Candidate is coming up soon - if you'd like in on it and you're under active maintenance - send me a message and we'll get you fixed up. 

Ok, back to the blog topic. NCM 6.0 brings some really nice alert integration with Orion - so that when you get an alert - you can get additional configuration info and/or trigger some config management actions.

These include: 

1. backup the running config

2. trigger a script

3. show the last config changes

When might this be useful? Just imagine - you get an alert that says something has gone down. Knowing if something recently changed ("show the last config change" action) would really give you a head start on troubleshooting. 

It's a piece of cake to set these up. Just go to the Alert Manager in Orion - where you go to set up all your alerts. Click "New" and you'll see this screen. 

Name your alert, fill out any pertinent data in any of the other tabs, and proceed on to the tab "Trigger Actions." Here, you'll "Add a New Action." Scroll to the bottom - and look what's there... "Execute NCM Action."

 

Choose that one and you'll get a number of options: 

 

 

Fill in the blanks - and you're on your way. Another neat thing to note - is that these actions are stored in the $(Notes) variable - which means you can reference them in other alert actions. 

The more information you have in an alert - the faster you can fix the problem. Happy alerting!

Orion NPM v10.0 delivers quite a few new features.  One of those features revolves around the Orion Trap Server.  In previous versions of NPM, users could create rules on many aspects of an SNMP Trap, including the originating IP address, the community string, or the contents of the MIB (seen in the figure below as DNS Hostname, Community String, and Conditions).  One notable absence was that there was no way to alert on the Details field of a trap—also known as the Trap Variable Bindings.  This Details tab—highlighted in yellow below—is new to NPM v10.

 

The inability to alert on the Trap Details was a drag because that field contains a wealth of distinguishing data.  For instance, you might see 20 traps from the same server, same community string and IP (obviously) based on the same MIB, but there’s a key word that shows up in the Trap Details that makes some more important than others.  The only way to alert on these details previously was to go to the Conditions tab and figure out which OID was associated with the target information and work through it from that angle.

 

 

 

image

 

Let’s walk through an example of how to set up an alert on the Trap Details.

 

First, rules are created on the Trap Viewer, which you’ll find on your Orion server. 

 

 

 

image

 

 

 

Once launched, you’ll see a list of traps.  Click on the yellow yield-sign-looking icon to launch the settings dialog.

 

 

 

 

 

image

 

 

 

From the settings dialog, go to the Alerts/Filter Rules tab and click “Add Rule”

 

image

 

 

 

You can name the rule on the General tab, and you can set other restrictions on other tabs, but let’s assume that you just looking for traps that include a particular IP address in the Details field.  The new Details tab can look for strings such as an IP Address or a word.  Let me note that if you check the “Use Regular Expressions…” checkbox, you unleash a ton of power so that you can parse the text in virtually any way imaginable.  Now, keep in mind that regular expressions are not for the technically meek, but if your geek-fu is strong, it’ll do back flips for you.

 

image

 

Let’s assume you just want the simple string lookup, which, really, will fully serve most people most of the time.  Once you’ve filled out the string you want, you just need to add an alert action.  For the alert action, you might want to add a color to traps with the target IP address so that it’s easy to identify in your list.  Click ok and the rule will engage. 

 

image

 

As soon as you get a trap that fits the rule, the action engages.  You can see the results in both the Trap Viewer application and in the Orion Web Console.

 

image

 

image

 

So that’s it simple, but incredibly powerful if you want to be alerted on the contents of a trap.  There are other new trap-related features, but more about those in another post.

 

 

 

 

 
Technorati Tags: Orion,NPM,Traps,SNMP,Details
 

This is post #2 of our Orion NPM 10.0 Sneak Peak series, consider the following scenario - every Saturday at 2am we have a policy to reboot xyz devices.

 

Today, a user would have to go in weekly and setup a unmanage task within web node management in the web console.  With 10.0, this will become much easier as you will be able to define recurring unmanage schedules or recurring maintenance windows. For folks unfamiliar with the concept of “unmanage” (a very Orion specific term), this in essence allow you to define a time period when a node, interface or application will be down and you do not want to receive alerts on or have it show as down in the UI.

 

When you install or upgrade to 10.0, you will need to go to the additional components of the SolarWinds Customer Support portal where you can download this utility or if you are on the NPM 10.0 Release Candidate and want to check this out, send me a private message via thwack.  Once downloaded, unzip it into your SolarWinds/Orion folder on the Orion server as shown in the screenshot below.

 

image

 

Once extracted, open the Unmanage Editor.exe and you will be presented with a welcome and instruction screen as seen below.

 

image

 

Click on create a new task and select the nodes, interfaces and applications you wish to add.

 

image

 

Click add and select the duration or time period you want these item to be unmanaged for and select ok.

 

image

 

Now once you save the task you will receive a popup dialog indicating it has been saved and copied to the clipboard for use in an upcoming step.

 

image

 

 

 

 

 

 

 

 

 

 

 

 

 

So what does this produce on the backend when I saved it?  Since we are leveraging Windows Task Scheduler to handle the scheduling, this creates a .cmd file which has the appropriate switches and parameters Windows Task Scheduler needs to execute this.

 

image

 

You can either manually navigate to the Windows Task Scheduler or click on the Open Windows Task Scheduler within the Unmanage Utility and click on Add Scheduled Task.  As you walk through the wizard, when you get to the step to select the program to run, navigate to the /Orion/UnmanageUtility/Tasks folder and select the .cmd file you created for this job.

 

image

 

These next dialogs walk you through setting up the start time, date and frequency and which account to run this under.  This is a Windows account, not a SolarWinds account.

 

image 

 

image

 

And that’s it.  If you want to edit an existing job, you can go into the new unmanage interface and select edit and choose the job you wish to edit and then save it.  If you want to change the frequency or disable the job you can do this with the Windows Task Scheduler interface.

With Orion NPM 10.0 (currently in Why Should I Care About Release Candidates? phase), we’ve extended NPM’s virtualization monitoring support to VMware ESXi and vSphere 4.0 (a.k.a., ESX 4.0).  This is in addition to NPM’s existing support for VMware ESX 3.5.   We’ve heard from a lot of customers that are excited that they’re now able to monitor their entire VMware Host stack (ESX 3.5, vSphere, ESXi) from a single pane of glass.  However, the next logical question for many of them was how do I get all of my VMware infrastructure to show up on a single dashboard view?  Well, the good news is whether you’re looking to create a dashboard to appease management, other teams (e.g., the app and server folks), or you just want to show your Mom how virtual you are, it’s possible in Orion today with just a little elbow grease.   Here’s how…

First, you’ll want to create a new Orion view for your VMware dashboard

1. Navigate to Admin > Manage Views

2. Click Add View and enter a dashboard name (e.g. My VMware Dashboard) and click Submit

image

3. Use the “+” icon to add the All Nodes Resource and several custom HTML resources.   Add as many of the custom HTML items as you think you’ll need to display graph data from different ESX servers.

image

4. Click on 'Preview' and this new view should come up in a new window. You should see your All Nodes resource and all of your Custom HTML resources.

image 

Next, customize your new VMware Dashboard view to show data from your ESX servers
1. Click Edit on your All Nodes resource and change the title to “All ESX Servers”

2. Enter MachineType='VMware ESX Server' into the Filter Nodes (SQL) field and click Submit

image

3. Using another browser window, open the Orion website and navigate to the first ESX server you want to show data for in your dashboard

4. Find a graph you’d like displayed on your dashboard and click on the graph title to open it in a new window 

image

5. In your browser, click on 'Show page source' to see the HTML code for the graph (e.g. in Firefox, use View > Page Source).

6. Do a text search for “img src” until you find something like the following:

<img src="/Orion/NetPerfMon/Chart.aspx?ChartName=VMNetworkTrafficArea&Title=&SubTitle=&SubTitle2=&Width=640&Height=0&NetObject=N:195&CustomPollerID=&Rows=&SampleSize=60M&Period=TODAY&PlotStyle=&FontSize=1&NetObjectPrefix=N&SubsetColor=&RYSubsetColor=&ResourceID=34&ShowTrend=True" />

7. Copy this line including the closing “/>”

8. Go to your other window that has the preview of your VMware dashboard and click Edit on the custom HTML resource where you want that graph to appear.

9. Paste the html code into the ‘raw HTML’ field, change the titles as appropriate, and click Submit.

image

10. Repeat this process for every ESX server graph you want to appear on your dashboard. You’ll notice in my dashboard below I’ve included several gauges from different ESX servers in addition to graphs.

image 

Finally, add your new VMware Dashboard view to your menu bar so you can easily navigate to it

1. Now that you have the items on the dashboard that you want to display, copy the URL address from your browser (e.g. /Orion/SummaryView.aspx?viewid=29).  

2. Navigate to Admin > Customize Menu Bars

3. Edit “Admin Menu Bar” and click Add New at the bottom left

image

4. Enter in a name for the menu bar item, the view URL you copied from the previous step (/Orion/SummaryView.aspx?viewid=29), and a description

5. Click OK and then drag and drop your VMware Dashboard menu item onto Selected Items list on the right

image 

6. Click Submit and you should see your new VMware Dashboard link appear on the menu bar

image

And, you’re done!!

Fear not, we’re certainly looking at streamlining the process moving forward…but, in the interim, isn’t it nice to get what you want today? And, the good news is once you’ve mastered this process, you can use this exact same approach for accomplishing many other use-cases (e.g., showing multiple data from multiple interfaces on the same page).  

If you’ve got other cool dashboard ideas, we’d love to hear them!   Please post them in comments.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I haven’t been with SolarWinds very long, but I’ve been here long enough to understand Orion alerts.  Although Orion NPM comes with some really useful and simple out-of-the-box alerts, advanced alerts can be intimidating, and creating some of the more complex alerts can be daunting.  Orion’s advanced alerting engine is very powerful, but this power comes with a learning curve.  The good news is you have some excellent resources available to you to help with that learning curve.

First, check out the Alert Lab on thwack.  This is a relatively new forum specifically dedicated to answering your questions on alerts.  In addition, a couple of thwack MVPs (sedmo and mrxinu) have graciously volunteered their time to helping us answer your alert related questions.  These guys are power users, so they know their stuff and are happy to help. 

Second, mcbridea has written a technical Understanding Orion Advanced Alerts on how to use advanced alerts in Orion.  This is an excellent paper, as evidenced by some of the thwack users who have posted positive comments on it.

Third, we have written several blog posts about alerts here on the product blog.  Check them out:

If there is a specific topic you’re interested in learning about (alerts or something else entirely), post your questions and comments about it on thwack.  If we see a lot of posts or questions on the same topic, we’ll blog about it.

Group policy is a security administrator's friend: it allows centralized administration of what a user can, and cannot do on their computer. While this is usually helpful and benign, it can also be a right pain when there are unintended consequences. 

Has this ever happened to you? 

You go home on Friday after a productive week at work, using Orion on a daily basis, and getting lots of good things done. Monday, you come to work ready to tackle the day, start up the Orion web interface and you see: 

"Access denied.: 

Or 

"Page cannot be displayed."

This is no way to start your week. It's not like you can't remember your password - the website won't even load!

While there are a bunch of things that could be going wrong, one common culprit is group policy. We get a lot of support calls when GPOs are dropped that limit access to Orion directories, or they disable access to the application pool services in IIS (below). 

 

The really annoying thing about group policy errors is that while we can fix them, they will usually "unfix" themselves when the policies are refreshed (usually every 5 minutes). So it's going to take a call to your security folks to get exempted from those certain GPOs going forward. 

Top Errors that Indicate You Have a Group Policy Problem

1. Suddenly, you get an "Access Denied" screen when you try to access the Orion website. 

2. You're heard talk that your systems have been recently hardened. 

3. You can't access the temp directories on your machine. 

 

What to do?

1. First of all, call your security administrator and see if they've implemented a new GPO. Chances are, you can track it down that way.

2. If you prefer to be armed with a little more data - you can check your event logs by following the directions here: http://technet.microsoft.com/en-us/library/cc749336(WS.10).aspx. Errors are easy to find in your logs - just go to: control panel -> administrative tools -> event viewer. Once you're there, choose "application" and sort them by "event." Anything in the 5000 range is a new group policy. You can see I have a few from a while back. 

 

Keep in mind that sooner or later you'll still have to address it with the security folks, otherwise the magic of group policy will keep undoing everything you've done. 

Filter Blog

By date: By tag: