THIS CONTENT HAS BEEN MOVED TO GITHUB: https://github.com/sweenig/urlextender
Showing posts with label NPC Browser View. Show all posts
Showing posts with label NPC Browser View. Show all posts
Thursday, February 12, 2015
Friday, August 16, 2013
Device level context switching
UPDATE: I've developed some code to make this a regular view that can be dragged onto the page without any configuration required. The following code will create the standalone view and add it to all four device context pages:
UPDATE: I've rewritten this widget to make it easier to implement. Now instead of having to specify the {Item.ItemID} variable in the browser view URL, the widget just grabs the information from the parent URL. This is also better because any additional arguments you had in the URL will continue through to the other context pages. Here's the updated code:
Now all you have to do is point to this widget in your custom content directory.
Enjoy!
You may not know about it, but NPC classifies every device as either a router, switch, server, or device. The device category is for every type of device that isn't a router, switch, or server. This is too bad because NetVoyant actually has an extendable list of device classifications; you can make as many as you want. However any additional classes will show up in NPC as 'devices' because NPC doesn't understand them. This is fine in most cases. However, certain cases will cause problems.
For example, if I have an F5 load balancer and I'm monitoring the device in SuperAgent as well as NetVoyant, NPC has to choose whether to classify the device as a server (as SuperAgent reports it) or as a device (since NetVoyant either classifies it as 'other' or 'load balancers' if you've classified it). Turns out the NV classification is last on the list. If a device is monitored by RA or SA, NPC will classify it as a router or server, respectively, regardless of what classification exists in NV.
In this case, what I usually do is instruct customers how to switch from one context page to another after drilling in. For example, after I drill into the F5 and get to the server page, I would update the URL to read pg=d instead of pg=s. This loads the device page for the F5 instead of the server page. This can be handy since the device page may have specific F5 views on it that don't appear on the server page.
In order to make this easier, I built a simple html page that can be loaded into a browser view that will allow quick switching between all four context view types. Here's the page:
Link to this page from a browser view with a title like 'View this device as a...' and a URL like this:
UPDATE: I've rewritten this widget to make it easier to implement. Now instead of having to specify the {Item.ItemID} variable in the browser view URL, the widget just grabs the information from the parent URL. This is also better because any additional arguments you had in the URL will continue through to the other context pages. Here's the updated code:
Now all you have to do is point to this widget in your custom content directory.
Enjoy!
You may not know about it, but NPC classifies every device as either a router, switch, server, or device. The device category is for every type of device that isn't a router, switch, or server. This is too bad because NetVoyant actually has an extendable list of device classifications; you can make as many as you want. However any additional classes will show up in NPC as 'devices' because NPC doesn't understand them. This is fine in most cases. However, certain cases will cause problems.
For example, if I have an F5 load balancer and I'm monitoring the device in SuperAgent as well as NetVoyant, NPC has to choose whether to classify the device as a server (as SuperAgent reports it) or as a device (since NetVoyant either classifies it as 'other' or 'load balancers' if you've classified it). Turns out the NV classification is last on the list. If a device is monitored by RA or SA, NPC will classify it as a router or server, respectively, regardless of what classification exists in NV.
In this case, what I usually do is instruct customers how to switch from one context page to another after drilling in. For example, after I drill into the F5 and get to the server page, I would update the URL to read pg=d instead of pg=s. This loads the device page for the F5 instead of the server page. This can be handy since the device page may have specific F5 views on it that don't appear on the server page.
In order to make this easier, I built a simple html page that can be loaded into a browser view that will allow quick switching between all four context view types. Here's the page:
<html>
<script type="text/javascript">
var url1='<a target="_top" href="/npc/Default.aspx?pg=';
var str=location.search;
str=str.replace("?ItemID=","");
document.write(url1 + 'r' + '&DeviceID=' + str + '">Router</a> ');
document.write(url1 + 'sw' + '&DeviceID=' + str + '">Switch</a> ');
document.write(url1 + 'd' + '&DeviceID=' + str + '">Device</a> ');
document.write(url1 + 's' + '&DeviceID=' + str + '">Server</a> ');
<a target="_blank" href="http://stuart.weenig.com/2012/08/device-level-context-switching.html"><img src="/npc/images/DialogQuestion.gif" border=0></a>
</script>
</html>
Link to this page from a browser view with a title like 'View this device as a...' and a URL like this:
/content/viewdeviceas.html?ItemID={Item.ItemID}
As long as this page is named 'viewdeviceas.html' and it's hosted under a virtual directory on NPC's IIS web server with an alias of 'content' it should load just fine. Give it a height of 33, turn off the border and hide the scroll bars. This makes an excellent small browser view that can go right at the top of the page, displayed right under the page tabs.
Monday, May 20, 2013
Setting a default group for an NPC report page
UPDATE: An additional tool now available: autorefresh.html. This widget uses its own script to handle automatically refreshing a page. It does not call the built in Auto-Refresh capability of NPC. You provide the number of minutes between refreshes in the browser view url: /custom/autorefresh.html?interval=5
UPDATE: An additional tool now available for download lets you set the default timeframe for a page. Do you have a page that you always want to show the last 24 hours of data? Just add this widget.
UPDATE: The newest version is out. I updated the script to fix a problem when going back to NPC when a page using the default page context setter was used. I also have released a modified version that allows you to set the default IP SLA test type on an IP SLA test report page.
UPDATE: An additional tool now available for download lets you set the default timeframe for a page. Do you have a page that you always want to show the last 24 hours of data? Just add this widget.
UPDATE: The newest version is out. I updated the script to fix a problem when going back to NPC when a page using the default page context setter was used. I also have released a modified version that allows you to set the default IP SLA test type on an IP SLA test report page.
Page IPSLA Type Default
Page Group Default
Wednesday, March 6, 2013
Page Retirement Methods
Continuing my effort to document the various ways I've used the ODBC connector for the NetQoS products, here's my next query and controls I've built and that I use in production. Today's query comes from a need to notify users that a particular page is being retired. Instead of immediately deleting a page and having to deal with confused users, I used the browser view to display a banner telling the users that they have X days until the page is retired. This could be done manually by creating a different static HTML page display a different date for each page, but I wanted a way to make it easy.
First of all, I didn't want to have to rebuilt the banner for each page that is going to be retired. So, I needed a way that each instance of the banner have a way to store an individual expiration date. I also wanted a way for users who don't want their precious pages deleted to notify me. A simple email would have done, but that would have almost always involved an immediate ping back to the user asking which page. So, the banner needs a way to start an email and automatically put the URL to the page.
The implementation is pretty easy.
Now that you've marked a couple pages to be retired, you can use an ODBC connection to display all those pages. Here's the SelectCommand and OdbcConnection String to put in the configuration.xml:
To create the view, run the following SQL commands against the NPC server:
First of all, I didn't want to have to rebuilt the banner for each page that is going to be retired. So, I needed a way that each instance of the banner have a way to store an individual expiration date. I also wanted a way for users who don't want their precious pages deleted to notify me. A simple email would have done, but that would have almost always involved an immediate ping back to the user asking which page. So, the banner needs a way to start an email and automatically put the URL to the page.
The implementation is pretty easy.
- First of all, get this first section of code, update 'email@company.com' to your email address on the fourth to last line and save it as pageexpiring.html in your custom content directory. Download a copy of the code here.
- Then put a browser view on the page to be retired and set the URL to point to pageexpiring.html in your custom content directory and save the view. When the page refreshes, you should see a message saying that the page has been scheduled to be retired on an unknown date.
- To add a specific date, edit the browser view and append ?expirationdate=3/31/2013 to the URL (replacing 3/31/2013 with the page retirement date).
- Repeat steps 2 and 3 for any remaining pages to be retired.
Now that you've marked a couple pages to be retired, you can use an ODBC connection to display all those pages. Here's the SelectCommand and OdbcConnection String to put in the configuration.xml:
To create the view, run the following SQL commands against the NPC server:
Friday, June 1, 2012
NetVoyant Duplicates Finder
UPDATE: This method has been replaced by the ODBC method.
I've been working for a while now on a good way to find and remove duplicates from NetVoyant. Luckily, there is a web service that can delete devices (more on NetQoS web services). All you need is the device IP address and the poller (to build the web service URL). I played around for a while trying to build something in a windows batch file and couldn't get it to do what I wanted to do. So, I reverted to Perl (which I probably should have done from the beginning). Anyway, the result is a script that can be run regularly on the NetVoyant master console. The output is a CSV file and an html file. The CSV file contains the output from the brains of the duplicate finder script, namely: a list of every device that exists more than once in the NV system, along with the device properties including the poller. The CSV file is output to the script directory. The script can be configured to output the html file wherever you want.
After that, the script uses perl to wrap the data in the CSV into an html widget. The widget shows the same data as the CSV as well as a link on every line to delete the device. As long as the NV pollers resolve by name, the link should work to delete the device and its corresponding scope. If you only want the CSV, edit the batch file and comment out the call to the Perl script (i.e. put 'rem' in front of the line that start with the word 'perl').
If you do want the HTML, you'll need to install Strawberry Perl and download a couple of modules. Installing Strawberry Perl on the NetQoS boxes isn't a new thing. Most of the developers and support guys have Perl installed on their test boxes and I've had it installed on many customers' boxes. The install doesn't require a reboot and you can take all the defaults. After doing the install, open a command prompt and type the following:
After that, all you need to do is download the zip and extract the files to somewhere on your NVMC. Setup a scheduled task to run the batch file every so often. The web page doesn't update unless the script runs (it doesn't refresh the list of duplicate devices simply by refreshing the page).
To get the script to output the html file to somewhere other than the script directory, go to the makehtml.pl file and modify the line that starts with 'my $outputfile = ' and update the output file path and name. For example:
That's it. You're done. You can use the browser view to put the resulting html file on an NPC page if you've designated a destination that is served up by the NVMC's IIS web service.
Enjoy! If you have improvements, please let me know so I can update the source.
P.S. If you don't have internet access on the box, you won't be able to install the Text::CSV modules to install (since they come from the internet). The solution is to download the Text::CSV and Text::CSV_XS tarballs and extract them using winzip or winrar or 7z. You might need to extract several times until you get just the folder with the files in them. Then copy them to the NVMC. Open a command prompt and cd to the directory containing Makefile.pl (you'll have to do this for each one). Then execute the following:
I've been working for a while now on a good way to find and remove duplicates from NetVoyant. Luckily, there is a web service that can delete devices (more on NetQoS web services). All you need is the device IP address and the poller (to build the web service URL). I played around for a while trying to build something in a windows batch file and couldn't get it to do what I wanted to do. So, I reverted to Perl (which I probably should have done from the beginning). Anyway, the result is a script that can be run regularly on the NetVoyant master console. The output is a CSV file and an html file. The CSV file contains the output from the brains of the duplicate finder script, namely: a list of every device that exists more than once in the NV system, along with the device properties including the poller. The CSV file is output to the script directory. The script can be configured to output the html file wherever you want.
After that, the script uses perl to wrap the data in the CSV into an html widget. The widget shows the same data as the CSV as well as a link on every line to delete the device. As long as the NV pollers resolve by name, the link should work to delete the device and its corresponding scope. If you only want the CSV, edit the batch file and comment out the call to the Perl script (i.e. put 'rem' in front of the line that start with the word 'perl').
If you do want the HTML, you'll need to install Strawberry Perl and download a couple of modules. Installing Strawberry Perl on the NetQoS boxes isn't a new thing. Most of the developers and support guys have Perl installed on their test boxes and I've had it installed on many customers' boxes. The install doesn't require a reboot and you can take all the defaults. After doing the install, open a command prompt and type the following:
D:\>cpan Text::CSVPerl will download and install the necessary modules and return you to the command prompt when its done.
D:\>cpan Text::CSV_XS
After that, all you need to do is download the zip and extract the files to somewhere on your NVMC. Setup a scheduled task to run the batch file every so often. The web page doesn't update unless the script runs (it doesn't refresh the list of duplicate devices simply by refreshing the page).
To get the script to output the html file to somewhere other than the script directory, go to the makehtml.pl file and modify the line that starts with 'my $outputfile = ' and update the output file path and name. For example:
my $outputfile = 'D:\\NetVoyant\\Portal\\WebSite\\dupslist.html'Perl requires a double backslash since a single backslash is the escape character.
That's it. You're done. You can use the browser view to put the resulting html file on an NPC page if you've designated a destination that is served up by the NVMC's IIS web service.
Enjoy! If you have improvements, please let me know so I can update the source.
P.S. If you don't have internet access on the box, you won't be able to install the Text::CSV modules to install (since they come from the internet). The solution is to download the Text::CSV and Text::CSV_XS tarballs and extract them using winzip or winrar or 7z. You might need to extract several times until you get just the folder with the files in them. Then copy them to the NVMC. Open a command prompt and cd to the directory containing Makefile.pl (you'll have to do this for each one). Then execute the following:
perl Makefile.PL && dmake && dmake test && dmake installDo Text::CSV first, then Text::CSV_XS.
Thursday, May 24, 2012
NPC and NetVoyant Web Services Gadgets
In combination with my method of inserting custom content into NPC, I've created a couple of gadgets that can be added to NPC. These gadgets give the viewer access to the NPC and NetVoyant web services that can be used to import and export group definitions, add devices to NetVoyant for polling, delete devices from NetVoyant, and delete discovery scopes from NetVoyant.
I hope you enjoy them. If you have any improvements, please let me know so I can update the source.
Installation Instructions
- You can download them here [link removed, see the Tools page].
- Extract the zip contents to the custom content directory described here.
- Edit the html files to update the URL.
- Look for the <form> tag and update the action string to point to your NPC or NV server (depending on the html file).
- Put three browser views on a page that only NPC administrators can access.
- Edit the three browser views to point to the following URLs (you should probably update the view names as well and I like to hide the view border)
- NPCGroupExport.html
- NPCGroupImport.html
- NVDeviceMgmt.html [this widget has been moved here]
NPCGroupExport.html
This gadget exports XML for any group in NPC. This XML describes the group structure and defines any rules for the groups. This can be used in conjunction with NPCGroupImport.html to modify or populate NPC groups programmatically.NPCGroupImport.html
This gadget imports XML into NPC to redefine groups. This can be used to redefine groups, rules, or membership.NVDeviceMgmt.html [this widget has been moved here]
This gadget facilitates adding and removing devices from NetVoyant.I hope you enjoy them. If you have any improvements, please let me know so I can update the source.
Wednesday, April 11, 2012
Using the browser view to add custom content to NPC
A while ago I started making flash videos using Camstudio as a way of teaching people how to use NPC. Camstudio outputs a swf with accompanying html to make it easy to post the video to a website. I wanted this to be added to NPC so i started using the browser view. I needed a place to post the html and swf files so that the browser view could access the files through a url. So, i went into IIS on the npc system and added a virtual directory pointing to a folder on the D: drive. I put the swf and html files into that folder and pointed the browser view to the url. It worked pretty well. Given a little skill with html, anyone could insert anything into NPC pages.
One handy way to use this would be to insert small snippets that help people understand what specific views mean, or how to use/interpret specific pages.
One handy way to use this would be to insert small snippets that help people understand what specific views mean, or how to use/interpret specific pages.
Subscribe to:
Posts (Atom)