If you have Solarwinds Network Performance Monitor [NPM] tool and more than a few Wifi Thin Access Points in your environment, I'll bet you've been tempted at some point to create a "WAP MAP" using the Network Atlas map maker, but were then frustrated when Network Atlas was unable to access any of the variables (SQL fields) that might be interesting.
If only you had a few of these:
You could have a one of these...
Oh bother! What to do, what to do, what to do...??
Well, now there's a solution. With a little bit of time, the Orion NPM Admin Guide, and some super-secret tinkering under-the-hood, you too can create your very own WAP MAP just like mine! Here's how...
Using Network Atlas
Well, first things first... if you're a newbie to NPM you might not even know what Network Atlas is or how it could be useful. Network Atlas is a program that comes with Orion though you have to download it the very first time you use it and install it on your system. Consult your Orion NPM Admin guide for the location.The Network Atlas program allows you to create custom maps which detail the various resources in your environment complete with live information such as Status, Uptime, Bitrate, or whatever else is important to you about an item, which can then be displayed on any Orion page. Simply edit the page, select one of the "Map" applets to add to your page, then edit the Map Applet and choose the map you created. Voila! One nifty new map to display!
Here's an example of one of ours:
In our environment we have maps which detail our network backbone, our critical servers and services, the key infrastructure of our various sites, etc. While the Network Atlas program is a little clumsy to use (it really is, I'm just sayin...) if you put some time and effort into getting to know it (and its quirks) it can produce some cool and useful maps for you to use in your NOC. Once you have the Network Atlas tool installed and have had a chance to play around with it a bit, you're ready to begin. Basically, when you add an object to the map, you can incorporate some special variables (aka "Properties") associated with the monitored object class (type) into the caption associated with the item. If you get clever about it, you can build up some pretty sophisticated maps.
I will assume from this point you're familiar with the program and/or know where and how to read the Admin Guide.
Sooner or later however, you will undoubtedly want to do something more advanced at which point you'll discover just precisely where the "edges" are in the program-- meaning where it stops being helpful. For all its usefulness, Network Atlas has a few warts and limitations, some minor, some more serious. For example, one minor thing you can't do is mix the text styles contained within a single label. It won't let you, say, edit the label to make a big title with smaller sized details all in one label. But of course, you can cheat a little and add a second label-- a generic label-- and then edit that to create the title and then use the original label to assign the details. Optionally you might assign a custom hyperlink to the title label, such as the URL which corresponds to the WAP Controller's page for that WAP device-- which is exactly what we did-- but of course you can choose whatever URL makes sense for you.
The "real" label, meaning the one which is associated with the object itself. You can recognize it by the tiny, thin line running from the label to the object itself. You can edit the "real" label to include specially-formatted variable strings which correspond to various details of interest. When the map is finally rendered in Orion, the variables will be replaced with the "live" data corresponding to that object. For instance, if you're working with a NODE object, you might use the "${NodeName}" and "${IP_Address}" variables to fill in the name of the node and it's address, and so on. You can consult the Admin Guide for a list of variables which are available for use in the Network Atlas. In this way you can add all sorts of useful information related to the object to your map. What you can't do though, unlike in a number of other areas in Orion, is retrieve information that is not contained in the base table for the particular object type (e.g., Node, Interface, etc.) Network Atlas does not support the use of custom SQL variable types. So if the information you want is stored in some other table, you're out-of-luck.
In our case, I wanted to create a WAP MAP to illustrate our WiFi environment to show the number of clients and the I/O bit rate for the individual WAP devices. The trouble is, we use "Thin" Access Point devices which are managed by a central WAP Controller. In setting up Orion to monitor the WAP environment, Orion realizes that the WAP controller is a WAP controller and then goes on to discover the various thin Access Points hiding behind it. So far, so good. Unfortunately, as a result, there are no specific nodes in Orion which correspond to the individual WAP's themselves which makes them difficult to use in Network Atlas. Even if you create ICMP stand-in devices, all you really get is "Availability" (via ICMP / Ping)-- which is only mildly interesting and probably not worth all the trouble.
As it happens, Orion DOES, in fact, have good, solid, interesting information about the WAP devices but keeps all that WiFi goodness stashed away in a different table which you can't access from the Network Atlas. If you pull up a database tool though, and start digging through the Solarwinds Orion database, you'll eventually discover two tables that seem like they could be useful. The first one, cleverly called "Nodes", keeps information about-- Nodes, go figure. The second one called, somewhat cryptically, "Wireless_AccessPoints"-- might take you an extra moment to work out what it's for...
If only there was a way to get at that information. If only Network Atlas could somehow be convinced to use SQL variables...
It turns out, if you're willing to be sneaky, there IS a way...
Here's the secret!
1. CREATE STAND-IN WAP DEVICES WITH "ADD NODE"
What you want to do first is create some stand-in nodes for each of your thin WAP devices-- Yeah, I know I said it wasn't worth it before, but that was then, and this is now-- and we have a plan now-- we're gonna need 'em for placeholders. So go ahead and add them and make certain the IP Addresses are all set correctly. Use the normal "Add a Node" activity in the Orion NPM web site to add the nodes. All you need to do is set them up as "ICMP" style nodes. Although, if you can set them up some other way (i.e., SNMP) to get more information so much the better. Then go find your newly-added devices in the Nodes table and verify they have the IP Address ("IP_Address" field) you expect. Each WAP device should already have a corresponding entry in the Wireless_AccessPoints table, so look them over and verify that the IP Addresses are entered correctly for each device in both tables. Also note to yourself that the address column in the Nodes table is named "IP_Address" whereas the column in the Wireless_AccessPoints table is "IPAddress". The difference seems minor but it's very important since we'll be using those columns later to tie ("Join") together the two tables. (Get a DBA to help you at this point if you're not sure about how to access the tables directly in the database, or aren't sure what a database "Join" is).
2. CREATE YOUR MAP IN NETWORK ATLAS
Use Network Atlas to create your map. In our case, I started with an image of our building map to use as a background. Then I placed "dots" on the bitmap along with circles that correspond to the range-radius of the WAP device-- there's no rocket science to it though, it's just that I have walked the floor many times with a hand-held WiFi meter and so I have a pretty good idea of where the hot and cold spots are. I just drew the circles according to my best guesses. You're welcome to be more scientific about it if you like.
Then look down the left side and find your WAP device placeholders and drop them onto the map wherever you want them to be. You can see how I did it in the large screenshot at the top. I've also annotated a close-up view of one just below so you can see better how it's constructed.
Then add a plain-vanilla label nearby (assuming you want a large title and smaller details) to suit your preferences. You can edit the titles with variable instances if you like, "${NodeName}" and "${IP_Address}" might be interesting ones. You can consult the list in the Admin guide or else search online, if you wish, to find others.If you have the "Advanced Alert Creator" tool that comes with Orion, most of the variables it can generate for your object type will also work here just fine. Edit the labels to suit your preference. When you get around to adding the details, that's when we'll take our next step.
Below I've included a close-up of a label in the process of being edited showing examples for how the variables can be incorporated into the text.
3. CREATE CUSTOM NODE PROPERTIES FOR WAP DEVICES
What we're going to do is trick the database into copying the information from the Wireless_AccessPoints table into the Nodes table whenever it gets written to or updated. But before we can do that, we'll need a place to store that data in the Nodes table. We can easily add fields to the Nodes table using the Custom Property manager, which can be found in the Admin area of the ORION NPM web site. You'll want to add the following custom properties. The order doesn't really matter, except that if you ever look them up in the database table directly, they will be in whatever order you added them, so if that matters to you, then take that into account and enter them accordingly. Likewise, the names can be whatever you want but will be used in writing the trigger and will become the variable names you'll use in the Network Atlas, so again choose accordingly. (You can see an example of their usage in the screenshot above).
Property Name | Property Type | Description |
---|---|---|
WAP_Clients | Integer Number | Number of Client Sessions Attached to the WAP Device |
WAP_InBps | Floating Point Number | Input Bitrate of the WAP Device |
WAP_OutBps | Floating Point Number | Output Bitrate of the WAP Device |
WAP_InPps | Floating Point Number | Input Packets per Second of the WAP Device |
WAP_OutPps | Floating Point Number | Output Packets per Second of the WAP Device |
Here's some screenshots to help you with adding your custom properties:
1. Go to the "Manage Custom Properties" page and press "Add Custom Property"
2. Select the Object Type for the property. (This selects the underlying table into which to add the field corresponding to the new property)
3. Enter the Custom Property Name, Description and Data Type
4. Skip this step, you don't need to assign any values
5. Repeat the above for each new property required.
(Reminder: "WAP_Clients", "WAP_InBps", "WAP_OutBps", "WAP_InPps", "WAP_OutPps")
4. CREATE A DATABASE CUSTOM TRIGGER TO COPY REQUIRED FIELDS
The secret to making all of this work lies in the creation of a custom trigger in the Orion database which will automagically copy the information from the Wireless_AccessPoints table over to the Nodes table whenever it gets added or updated. Once the fields are copied into the Nodes table, they will then be available as "Custom Property" variables for use in Network Atlas (and anywhere else that permits the use of Custom Property variables, such as Email Notifications, etc.). The type of trigger we'll be writing is called a "Trigger on INSERT, UPDATE or DELETE" style. Don't worry, we won't be DELETING anything, but we will be using the INSERT and UPDATE hooks it offers to copy the various fields from the Wireless_AccessPoints table to the Custom Property fields we just created in the Nodes table. Once created, the trigger will fire (do it's thing) whenever data is written into the Wireless_AccessPoints table-- no matter how it gets written there. Which means, that once it gets created and takes effect, we won't have to do *anything* else, it will all just work, as if by magic. Whenever the normal, usual Orion NPM process(es) updates the Wireless_AccessPoints table-- however it does that now-- the custom fields in the Nodes table will also get updated as a side-effect. (Note that if you ever update Orion such that the database gets re-installed, you may need to re-enter the trigger to restore the functionality).
If you're at all, even just a little bit, nervous about working directly with your database, get a DBA type person to help you out. (Or, if you can't locate a DBA, maybe there's someone else in the office who's gullible er, willing-- that you could pin it on if it all goes horribly wrong...) Oh, and now would probably be a good time to warn you to backup your database before doing this-- and that I'm not responsible if it destroys your data, grows hair on your palms, or brings back your ex-wife...
Here's what we did:
USE SolarWindsOrion IF EXISTS (SELECT name FROM sysobjects WHERE name = 'trigg_Insert' AND type = 'TR') DROP TRIGGER trigg_Insert GO CREATE TRIGGER trigg_Insert ON Wireless_AccessPoints FOR INSERT, UPDATE AS Begin DECLARE @Action as char(1); SET @Action = (CASE WHEN EXISTS(SELECT * FROM INSERTED) AND EXISTS(SELECT * FROM DELETED) THEN 'U' -- Set Action to Updated. WHEN EXISTS(SELECT * FROM INSERTED) THEN 'I' -- Set Action to Insert. END) if @Action in( 'I' , 'U') BEGIN update N set [WAP_Clients] = [Clients], [WAP_InBps] = [InBps], [WAP_OutBps] = [OutBps], [WAP_InPps] = [InPps], [WAP_OutPps] = [OutPps] ---select * from inserted i join Nodes N on N.IP_address = i.ipaddress END END
Be aware that the database name for your database might be (and probably IS) different!!! So double-check the database names and such just to be sure. Also notice that the names of the fields are exactly the same as the names of the Custom Properties that we created above. So spelling and punctuation matters! Make sure everything matches before you're submit the query. When you're ready, enter the above Trigger code into the database (as a query is fine), and it will take effect immediately. Every time Orion updates the WAP information stored in the Wireless_AccessPoints table, it will automagically be updated in the Nodes table too. Pretty cool, huh?
So now you can use the Custom Properties we created earlier in the Network Atlas as live variables which will contain the WAP device information, and you can go impress your boss with your spiffy new WAP MAP!
You never know, he just might even give you a raise!
(Hey, you know, it could happen...)
If you have comments, suggestions or questions, I'm happy to hear 'em. If your ex-wife really does come back, don't forget, I warned ya!!
John Whitten