UPDATE 6/9/2015: Version 1.7 now released. This update adds standalone support. Since CA is including newer versions of MySQL in their products, DBToolv3 is no longer going to work. This change allows you to specify to use MySQLDump instead of DBToolv3. Essentially, you unremark line 15 and remove/remark line 14. If I get enthusiastic about it, I may update the script to allow a switch from the command line to specify which method to use. I'm just not there yet.
UPDATE 2/10/15: Version 1.6 now released. This update changes the way harvesters and DSAs are backed up, by only backing up the ReaperArchive, ReaperArchive15, and HarvesterArchive directories to a single directory (no redundant rolling backups). It only backs up files that have the archive bit set, so before running it the first time, set the archive bit for all the files in those directories. I also fixed the date naming method so it's YYYYMMDD instead of YYYYDDMM. I also added timestamping to the log so you know how long it takes to perform the file backups vs. the database backups.
UPDATE 2/27/14: Version 1.5 now released. This version doesn't have too many changes. I just added the lines below that allow the NFA mess of data files to be backed up along with everything else. This one script can still be used on any product. However, when running on a Harvester or DSA, extra commands backup the data files.
The syntax for running the tool hasn't changed since 1.4 (but 1.4 introduces some major changes), so you should be able to drop the script in place without changing any scheduled tasks.
nqbackup.bat <dbname> <num_backups_to_keep>
Remember, if you need a reminder how to run the tool, just run it without any arguments (or just double click it from Windows Explorer).
Showing posts with label SuperAgent ADA. Show all posts
Showing posts with label SuperAgent ADA. Show all posts
Tuesday, June 9, 2015
Monday, November 11, 2013
Preparing Windows 2008 for NetQoS Installations
UPDATE: I've added the ability to disable IPv6 and configure SNMP with default settings (public community string and access from any host). I've also corrected the spelling in two places.
UPDATE: There have been several changes lately that I haven't published out here on the blog. Suffice it to say that you can now re-run the script and choose which parts to run and which parts not to run. You are prompted with a yes/no dialog before each section of the script runs. Also, the .Net 4.0 uninstaller now runs as a part of the script. It runs right before Windows Updates and will reboot if .Net 4.0 is uninstalled. You'll need to rerun the script if you want it to run Windows Updates for you.
I've got some ambitious plans for the next version. I want the script to allow you to run it once manually and it will create a response file. That response file can then be used to repeat the script on any number of servers. So, if you want to only run certain parts, the first time you manually run it will create an output file with that info. Then you can use that output file as an input for future runs. This should make preparing a bunch of w2k8 servers easier.
There are a bunch of things that have to be done to a Windows 2008 server before the NetQoS software can be installed. Being the efficient (aka lazy) engineer that I am, I decided to script the whole thing. Here are each of the pieces of my script. Download the whole thing here. If you want to run the script without copying and pasting each piece, you must run 'set-executionpolicy remotesigned -forced' first. Otherwise powershell doesn't allow the script to run. I usually copy and paste each part so I see each part as it happens.
UPDATE: There have been several changes lately that I haven't published out here on the blog. Suffice it to say that you can now re-run the script and choose which parts to run and which parts not to run. You are prompted with a yes/no dialog before each section of the script runs. Also, the .Net 4.0 uninstaller now runs as a part of the script. It runs right before Windows Updates and will reboot if .Net 4.0 is uninstalled. You'll need to rerun the script if you want it to run Windows Updates for you.
I've got some ambitious plans for the next version. I want the script to allow you to run it once manually and it will create a response file. That response file can then be used to repeat the script on any number of servers. So, if you want to only run certain parts, the first time you manually run it will create an output file with that info. Then you can use that output file as an input for future runs. This should make preparing a bunch of w2k8 servers easier.
There are a bunch of things that have to be done to a Windows 2008 server before the NetQoS software can be installed. Being the efficient (aka lazy) engineer that I am, I decided to script the whole thing. Here are each of the pieces of my script. Download the whole thing here. If you want to run the script without copying and pasting each piece, you must run 'set-executionpolicy remotesigned -forced' first. Otherwise powershell doesn't allow the script to run. I usually copy and paste each part so I see each part as it happens.
Tuesday, May 7, 2013
Default SuperAgent Tweaks
Whenever I'm setting up a new SuperAgent system, there are always a few things I go through and do before I start data collection. So, here's my list so I don't have to remember it:
- Add collectors by DNS - I like to add by NetBIOS name then click the IP button. This helps me make sure I get the right IP address. Then, after SA has done its check of the collector, I click the DNS button, which finds the DNS name from the IP address it previously resolved from the NetBIOS name. This double check makes sure I have the right server since the FQDN name should be fairly similar to the NetBIOS name.
- Add a port exclusion - Given the troubles I've had with large deployments and auto-discovery, I've decided to start adding a huge port exclusion from the get go. I add 1025-65535 for the whole domain. When/if I need to monitor an application in that range, I can always add an exception. This can be done via the GUI or through a query:
insert into application_rules
(application_id,exclude_port_begin,exclude_port_end,rule_type)
values (0,1025,65535,0);
New in ADA 9.3! - This option can be enabled on each collector. For standard collector or virtual collector, create a new text file: drive:\CA\bin\saConfigInterfaceRuntimeOptions.ini with the following line:
/force positive config
Then restart the CA ADA Monitor service. - Add actions to the default incident responses - add all the possible actions to the incident responses. If I have the email address of the person/group that will be monitoring the SA for problems, I put an email action in the collection device default incident response.
- Create a 'No Response' network incident response - create this incident response with no actions.
- Adjust network types - I like to have only 4 network types: Internet - VPN, LAN, Not Rated, WAN. I delete all the other network types. Assign the Internet - VPN and Not Rated network types to the 'No Response' incident response created earlier.
- Edit the 'Weekends' maintenance schedule - Change the name to 'Full Time Maintenance' and change the period to all day, every day. If there is a standing maintenance window that affects every server everywhere, add that period to the default.
- Change the data retention settings - Bump everything up to their max. If it becomes a problem later on, I can always tune it down.
- Change the free space alarm - Change this from 5GB to 20GB and put somebody's email address in there.
- Import a networks list - I prefer to use the GXMLG, but at least understand regions if doing it by hand. You can also use the standard private networks list if you have nothing to start with.
- Bump up the default observation numbers
New in ADA 9.3! - You don't have to do this via direct database manipulation any more. Just go to Administration >> Policies >> Performance Thresholds. The middle table allows manipulation of the default threshold settings. You can also setup the default threshold settings for the 'Not Rated' and 'Internet - VPN' network types; set them up for no thresholds on the network and combined thresholds. - Import servers as subnets instead of individual servers - This just makes sense. If possible, try to group servers together into subnets by application. This makes it easier to assign groups of servers to an application. If this isn't possible, enter the entire subnet.
Those are all the tweaks I can think of at the moment. If I think of any others, I'll add them to this list.
SuperAgent Application Thresholds
SuperAgent thresholds are comprised of several different components. The most critical part of the thresholds is the baseline sensitivity. Out of the box, SA thresholds are applied to every application and are set with the sensitivity values dictated by NetQoS. There are actually two types of thresholds that can be applied: sensitivity and milliseconds.
Doing anything in the database directly isn't supported by CA and you may break your stuff. If you do, i'm not responsible and CA will probably have you revert to a db backup before even considering talking to you. So either don't tell them that you did this or make sure you can backup and restore your database as needed. There, you have been warned.
The second type of threshold is a more traditional threshold that looks at the value and determines if it is over a specified value. This threshold is much harder to set since you'd have to track data and understand what values you should set. This type of threshold does have one advantage: baseline creep protection.
Baseline creep is when the baseline increases over time because of a slowly degrading performance. Thresholds tied to that baseline would also slowly increase. This is like boiling a frog. You start out with a live frog in cool water and heat it up gradually. By the time the water is hot enough to kill and boil the frog, it's too late for the frog to jump out.
SuperAgent also takes into consideration the fact that a single observation of a transaction that exceeds a threshold (either sensitivity or millisecond) is nothing to pay attention to. The problems really come into play when many observations are seen exceeding the threshold. The minimum observation count is the number of observations that must exceed the threshold within a 5 minute period before the whole 5 minute period is marked as degraded or excessively degraded. These numbers are quite low out of the box. It is common practice to bump these numbers up (usually by a power of 10) in order to reduce the amount of noise that is reported by SA. More on this later.
When an application is configured, either by a user or by the system, a default set of thresholds is applied. The same settings are used for all applications. This can be a problem with newer SA systems since auto-discovery tends to create many applications. If they are all using the default thresholds, it can result in much noise. This is not because the thresholds are too low. Remember, the default thresholds are tied to the baseline. The real problem is that the default minimum observation numbers are too low. Luckily, these numbers can be changed.
The thresholds and minimum observations can be changed in the GUI through two different places. In the applications list or under policies. The applications list is the better place to be if you want to change more than one application/network type set at a time. In the applications list, multiple applications can be selected (maximum of 100 applications selected at a time) and the thresholds edited for all those applications. This may be handy at least for editing the thresholds of the user created applications.
New in ADA 9.3! - A new option has been added to the GUI that allows the modification of the default threshold for new applications (new system discovered applications and new user defined applications). Go to Administration >> Policies >> Performance Thresholds. The middle table allows modification of the default threshold set. You should also go back to applications that have already been defined and update those thresholds. Once an application is discovered by the system or created by the user, the thresholds are independent of the default set.
When changing the thresholds for the system applications, there are several tactics. The first involves increasing the minimum observation count. This can be done with a fairly simple query that both increases the minimum observation count for all defined applications but also modifies the default application thresholds so that all future applications use the same settings.
--run this query to increase the minimum observation count by a power of 10.
update performance_incident set observations = observations * 10;
You shouldn't have to reload the collectors to get this change to take effect, however if you do experience problems seeing the updated threshold values, reloading the collectors should fix it.
A best practice when configuring SuperAgent is to configure a special network type for all the network definitions in SA whose network performance is not entirely within your control. Alarming on networks like this is ineffective since the resulting alarms are inactionable. I usually create a network type called 'Internet - VPN' to indicate any networks that are entirely or partially out of my domain of control. In other words, I set the network type to 'Internet - VPN' for any client IP address ranges across the internet or on another organization's network. If I were to detect a problem with the network metrics to a user within one of these networks, I wouldn't know if the problem were within my portion of the network or out on the internet. If it were out on the internet, I wouldn't be able to do much about it.
So, first of all, create the 'Internet - VPN' network type and assign all your non-internal IP address ranges to it. This would include VPN IP addresses since a portion of their conversation occurs over the internet.
The next step is optional, since the third step negates its necessity. However, if you don't want to go ahead with the third step, implementing this step will at least prevent you from getting alerts on the network metrics for those networks. All that you need to do is create a new network incident response for the 'Internet - VPN' network type and don't assign any actions to it. This should weed out email notifications from issues detected for networks where you can't help the network performance.
New in ADA 9.3! - A new option has been added to the GUI that negates having to perform step three using direct database manipulation. Instead, go to Administration >> Policies >> Performance Thresholds. Click 'Add Custom by Network Type' in the second table. Pick the 'Internet - VPN' network type. Change the Network and Combined thresholds from 'Use Default' to 'Customize' then change the now enabled drop downs from 'Sensitivity' to 'None'. You'll want to do this for NRTT, RTD, NCST, ERTT, DTT, and TTT.
Step three involves a little database manipulation. Essentially, you will need to add a record to the performance_incident table for every metric/app combo you want to ignore. Since you'll need to ignore NRTT, RTD, NCST, ERTT, DTT, and TTT, you'll need to add 6 rows for every application. Luckily, this isn't too hard. The only downside is that this doesn't set things up for any future applications. You'll have to repeat the process. If you do, the query will fail unless you do a complete undo of everything else first. This first query undoes all the threshold sets for the network type containing the string 'VPN'. Make sure your network type has this string or modify the query below.
-- run this query to remove any thresholds currently tied to that network type
Delete from performance_incident where agg_id = (select max(agg_id) from aggregates where agg_type=1 and agg_name like '%VPN%');
Once you've done that, or if this is the first time you're running this, run the following query. Again, make sure your network type has the string 'VPN' in the name. Essentially, this inserts a row ignoring thresholding for the VPN network type (hence the 0's in the query below right after m.metric_type) for every application and for each of the metrics we want to ignore (hence the last set of numbers).
-- run this query to disable network and combined metrics for the network type whose name contains the string: VPN
INSERT INTO performance_incident (app_id, agg_id, metric_type, thres1, thres1_type, thres2, thres2_type, observations)
SELECT a.app_id, (select max(agg_id) from aggregates where agg_type=1 and agg_name like '%VPN%'), m.metric_type, 100, 0, 90, 0, 50 as observations
FROM applications as a, metric_types as m where m.metric_type in ( 0 , 1 , 2 , 3 , 4 , 9 );
Doing anything in the database directly isn't supported by CA and you may break your stuff. If you do, i'm not responsible and CA will probably have you revert to a db backup before even considering talking to you. So either don't tell them that you did this or make sure you can backup and restore your database as needed. There, you have been warned.
Sensitivity
Sensitivity is a unit-less scalar number between 0 and 200. This type of threshold looks for deviations from baseline. A higher number (think 'more sensitive') will alert on a slight deviation. A lower number will not alert until the deviation is more extreme. Think of it as that sensitive co-worker who goes to HR for everything. If that person is very sensitive, any little thing will cause them to go to HR. If they were less sensitive, it would take something more extreme for them to march over and report you. Sensitivity baselines are really handy since the actual numbers involved in the threshold change as the baseline changes. This means that if one day of the week is typically different than the other days, the baseline would reflect that. Since the baseline reflects that, so do the thresholds for that day. SuperAgent baselines take into consideration hour of the day and other factors to get very good baselines. The other thing that SuperAgent does with regards to baselines is that it baselines every combination individually. Since every combination has its own baseline, a single set of thresholds that refer only to the baseline can be set across the board. This is how things come out of the box.
Milliseconds
The second type of threshold is a more traditional threshold that looks at the value and determines if it is over a specified value. This threshold is much harder to set since you'd have to track data and understand what values you should set. This type of threshold does have one advantage: baseline creep protection. Baseline creep is when the baseline increases over time because of a slowly degrading performance. Thresholds tied to that baseline would also slowly increase. This is like boiling a frog. You start out with a live frog in cool water and heat it up gradually. By the time the water is hot enough to kill and boil the frog, it's too late for the frog to jump out.
Minimum Observation Count
SuperAgent also takes into consideration the fact that a single observation of a transaction that exceeds a threshold (either sensitivity or millisecond) is nothing to pay attention to. The problems really come into play when many observations are seen exceeding the threshold. The minimum observation count is the number of observations that must exceed the threshold within a 5 minute period before the whole 5 minute period is marked as degraded or excessively degraded. These numbers are quite low out of the box. It is common practice to bump these numbers up (usually by a power of 10) in order to reduce the amount of noise that is reported by SA. More on this later.
Default Application Thresholds
When an application is configured, either by a user or by the system, a default set of thresholds is applied. The same settings are used for all applications. This can be a problem with newer SA systems since auto-discovery tends to create many applications. If they are all using the default thresholds, it can result in much noise. This is not because the thresholds are too low. Remember, the default thresholds are tied to the baseline. The real problem is that the default minimum observation numbers are too low. Luckily, these numbers can be changed.
Changing Thresholds Through the Web GUI
The thresholds and minimum observations can be changed in the GUI through two different places. In the applications list or under policies. The applications list is the better place to be if you want to change more than one application/network type set at a time. In the applications list, multiple applications can be selected (maximum of 100 applications selected at a time) and the thresholds edited for all those applications. This may be handy at least for editing the thresholds of the user created applications.New in ADA 9.3! - A new option has been added to the GUI that allows the modification of the default threshold for new applications (new system discovered applications and new user defined applications). Go to Administration >> Policies >> Performance Thresholds. The middle table allows modification of the default threshold set. You should also go back to applications that have already been defined and update those thresholds. Once an application is discovered by the system or created by the user, the thresholds are independent of the default set.
Changing Thresholds Through a MySQL Query
Setting Thresholds for Internet/VPN Network Type
A best practice when configuring SuperAgent is to configure a special network type for all the network definitions in SA whose network performance is not entirely within your control. Alarming on networks like this is ineffective since the resulting alarms are inactionable. I usually create a network type called 'Internet - VPN' to indicate any networks that are entirely or partially out of my domain of control. In other words, I set the network type to 'Internet - VPN' for any client IP address ranges across the internet or on another organization's network. If I were to detect a problem with the network metrics to a user within one of these networks, I wouldn't know if the problem were within my portion of the network or out on the internet. If it were out on the internet, I wouldn't be able to do much about it.So, first of all, create the 'Internet - VPN' network type and assign all your non-internal IP address ranges to it. This would include VPN IP addresses since a portion of their conversation occurs over the internet.
The next step is optional, since the third step negates its necessity. However, if you don't want to go ahead with the third step, implementing this step will at least prevent you from getting alerts on the network metrics for those networks. All that you need to do is create a new network incident response for the 'Internet - VPN' network type and don't assign any actions to it. This should weed out email notifications from issues detected for networks where you can't help the network performance.
New in ADA 9.3! - A new option has been added to the GUI that negates having to perform step three using direct database manipulation. Instead, go to Administration >> Policies >> Performance Thresholds. Click 'Add Custom by Network Type' in the second table. Pick the 'Internet - VPN' network type. Change the Network and Combined thresholds from 'Use Default' to 'Customize' then change the now enabled drop downs from 'Sensitivity' to 'None'. You'll want to do this for NRTT, RTD, NCST, ERTT, DTT, and TTT.
Wednesday, December 12, 2012
SA Collector Feed List through ODBC
Continuing my effort to document the various ways I've used the ODBC connector for the NetQoS products, I'm going to post a couple of the queries and controls I've built and that I use in production. Today's query comes from a need to review all the collector feeds for all the collectors on two different master consoles. Collector feeds are configured for each collection NIC on standard collectors. I haven't run this query on a MC with a MTP connected, but it should result in the same thing.
The query comes from three different tables and results in a list of feeds and options to edit each collector. Unfortunately, the functionality to directly modify the feed properties within the GUI isn't present yet, but something like it should be coming soon. 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:
The query comes from three different tables and results in a list of feeds and options to edit each collector. Unfortunately, the functionality to directly modify the feed properties within the GUI isn't present yet, but something like it should be coming soon. 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:
Thursday, July 12, 2012
GXMLG 2.0
I finally broke down and rebuilt my GXMLG tool. Given the complexity of the task, I originally wrote the applet using MS Access. However, to make things easier to distribute and easier to troubleshoot and use, version 2.0 uses perl and is run from the command line. To illustrate the difference, the old utility was 6.5MB. The new script is 11KB. That's what a graphical interface gives you.
You'll have to install perl (I use strawberry perl on windows boxes) and run the script like this:
The script itself is pretty simple. Specify an input file. This input file is the same sites/networks file referenced in my previous blog post. Here's a sample sites list to get you started. Then just decide which output files you want. If you specify the npc output file, you'll also need to specify the insertion point (more information about the insertion point).
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:
Do Text::CSV first, then Text::CSV_XS.
You'll have to install perl (I use strawberry perl on windows boxes) and run the script like this:
>perl gxmlg.plRunning it without any arguments shows you the help file:
This script outputs any combination of configuration files for the NetQoS
suite of products. You must install strawberry perl and Text::CSV,
Text::CSV_XS, and Getopt::Long. To install CPAN modules, run cpan [module name]
from the command prompt.
Example: cpan Text::CSV
This script was created by Stuart Weenig (C)2012. For more information visit
http://stuart.weenig.com. This script may be redistributed as long as all the
files are kept in their original state.
Current Version: 2.0
Usage: PERL gxmlg.pl [-outnpcxml] [-outsacsv] [-outnvcsvnv] [-outucmcsv]
[-infile NAMEOFINFILE] [-npcinspath INSERTPATH]
[-npcxmlname NPCXMLFILE] [-sacsvname SACSVFILE]
[-nvcsvname NVCSVFILE] [-ucmcsvname UCMCSVFILE]
-infile NAMEOFINFILE Specifies the name of the Sites file to be
imported. (If omitted: sites.csv)
-outnpcxml Output an NPC XML groups definition file.
-npcxmlname NPCXMLFILE Name of the NPC file to be output. (If
omitted: NPCGroups.xml)
-npcinspath INSERTPATH The path to the group that will serve as
the insertion point. Required if using
-outnpcxml option.
-outsacsv Output a SA networks CSV file.
-sacsvname SACSVFILE Name of the SA file to be output. (If omitted:
SANetworks.csv)
-outnvcsv Output a NV discovery scopes file.
-nvcsvname NVCSVFILE Name of the NV file to be output. (If omitted:
NVScopes.csv)
-outucmcsv Output a UCMonitor locations file.
-ucmcsvname UCMCSVFILE Name of the UCMonitor locations file to be output.
(If omitted: UCMLocations.csv)
You must install strawberry perl and Text::CSV, Text::CSV_XS, and Getopt::Long.
To install CPAN modules, run cpan [module name] from the command prompt
Example: cpan Text::CSV
If the server you will be running this on doesn't have access to the internet, you
won't be able to install the modules automatically (since they have to be downloaded
from the internet). The solution is to download the tarballs from www.cpan.org 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 your server.
Open a command prompt and cd to the directory containing Makefile.pl (you'll have to
do this for each module). Then execute the following:
perl Makefile.pl && dmake && dmake test && dmake install
For the text modules, do Text::CSV first, then Text::CSV_XS.
The script itself is pretty simple. Specify an input file. This input file is the same sites/networks file referenced in my previous blog post. Here's a sample sites list to get you started. Then just decide which output files you want. If you specify the npc output file, you'll also need to specify the insertion point (more information about the insertion point).
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 install
Do Text::CSV first, then Text::CSV_XS.
0
comments
More posts like this:
GXMLG,
My Tools,
NetQoS,
NetVoyant,
NPC,
ReporterAnalyzer NFA,
SuperAgent ADA
More posts like this:
GXMLG,
My Tools,
NetQoS,
NetVoyant,
NPC,
ReporterAnalyzer NFA,
SuperAgent ADA
Sunday, July 1, 2012
Manually Configuring Applications in SuperAgent
Over the years, I've configured thousands of SuperAgent applications. I've refined the process, which includes a YouTube video (shown below) and an application flow diagram (detailed below) that I give to application owners to fill out. Usually they give me back their own version of the application infrastructure, which has more and less than what is needed for SuperAgent. That usually results in a meeting where I've taken their data and plugged it into my AFD and I solicit the missing information. So, what I've decided to put in this blog post should be everything needed to get started configuring applications in SuperAgent. Obviously, the SuperAgent administrator will need to know how to properly administer SuperAgent, but this primer is meant more for the application owners than the SuperAgent administrator.
First, the video. This video is based on a bounce diagram presentation that I've given countless times and explains how SuperAgent works on a fundamental level. This is important information to present to the application owners so they know why we're asking for the application flow information.
Beside the video, I also present the Application Flow Diagram (AFD). This is a Visio diagram that shows the information needed in order to configure an application in SuperAgent. I've also written a document to explain the application detailed in the example and how to fill it all out. Here it is:
First, the video. This video is based on a bounce diagram presentation that I've given countless times and explains how SuperAgent works on a fundamental level. This is important information to present to the application owners so they know why we're asking for the application flow information.
Beside the video, I also present the Application Flow Diagram (AFD). This is a Visio diagram that shows the information needed in order to configure an application in SuperAgent. I've also written a document to explain the application detailed in the example and how to fill it all out. Here it is:
Introduction
The purpose of this document is to describe a low complexity application and detail the parameters that must be obtained about that application in order to correctly configure the application for monitoring within CA Application Delivery Analysis (SuperAgent). This document also attempts to identify the types of people responsible for obtaining/providing that information about the application and infrastructure to the NetQoS administrator. Given the diversity of modern organizations, the recommended roles may not have the information required.Monday, May 21, 2012
Analyzing TCP Application Performance
Well, I've been talking about doing it for a long time and I finally got an excuse. One of my customers wanted me to prepare my SuperAgent bounce diagram presentation for recording. In stead, I opted to make a YouTube video. I've given this presentation countless times and now that I've got a video, I can spend more time answering advanced questions than going over fundamentals. Without further ado, here it is.
I've got plans for more videos covering the things I cover most often. My next project is the video of the presentation I did for the CAIM Community's monthly webcast.
I've got plans for more videos covering the things I cover most often. My next project is the video of the presentation I did for the CAIM Community's monthly webcast.
Friday, March 30, 2012
Understanding SuperAgent Network Regions
I've found that many people don't understand the concept of regions in a network definition in SuperAgent. Given the power of a region to make defining networks easier and give more granular reports, I'm actually quite surprised that it hasn't been evangelized a bit more. So, here's my explanation:
SuperAgent organizes data according into buckets. SA could store the analysis data for every single client IP address in its own bucket in the database, but that's kind of the point of MTP. Also, having reports that are that granular are only helpful if you already know where the problem is. In addition, if you think about it, storing the analysis of two client IP addresses in two individual buckets in the database doesn't make sense if those two client IP addresses are connected to the same switch, which is using the same router to get to the WAN which is coming into the same network hardware in the datacenter. If the two clients are using all the same network hardware, measuring two different network round trip times for those two clients is virtually impossible. Think about it, the only thing that is different is the client's NIC, which doesn't really affect SA metrics, due to modern technologies like TCP offload engine (TOE) which bring the ACK turn around time on the NIC down to sub-millisecond.
Ok, so there's the reason to summarize networks according to the network path. If a bunch of IP addresses use the same network path to get back to the servers monitored by SA, there's not much value in storing the analysis on a per-IP basis.
However, for groups of IP addresses that do use different network infrastructure, it is imperative to separate them so that the differentiating network hardware can be isolated and therefore identified and troubleshot (troubleshooted?).
Therefore SA provides the ability to define client networks. Each client network instructs SA how to group IP address blocks together and treat them as one unit for analysis and storage. Each network definition should only contain the IP addresses that share all of their network infrastructure.
This is nice because it cuts down on the amount of configuration required in SA. To illustrate, let me give an example. A US company has decided that its IP address scheme is to allocate an entire /10 block of IP addresses to each time zone (e.g. 10.0.0.0/10 for Eastern, 10.64.0.0/10 for Central, 10.128.0.0/10 for Mountain, and 10.192.0.0/10 for Pacific). It then decides to allocate an entire /19 block of IP addresses to each site within that time zone (e.g. 10.30.0.0/19 for NYC, 10.74.32.0/19 for Chicago, & 10.200.128.0/19 for LAX, among others). This is actually really easy to configure in SA. The networks would be defined in SA as such:
Each of the time zone IP address blocks should be configured so that any clients in the time zone that don't match a site definition get categorized somewhere. Any traffic showing up in those networks is an indicator that a site is missing. On a side note, the time zone networks could be given their own network type and special, tighter thresholds could be applied so that incidents trip immediately for any amount of NRTT. A special network incident response could be setup to send an email to the SA admin to notify him/her that traffic has been seen on a time zone network (indicating a site network definition that is either missing or incomplete).
While this is great, the network administrators at the US based company decided that a standard of 32 VLANs should be implemented at every site. Each VLAN should be a /24 subnet and each VLAN has a standard use (floor 1, floor 2, floor 3, printers, servers, wireless, etc.). With the networks above defined in SA, the network administrator won't be able to differentiate between bad performance on a wireless VLAN and bad performance on a wired VLAN. At this point the administrator has two options: 1) either he can rebuild all the network definitions defining every single /24 subnet or 2) he can define 32 regions in each of the site network definitions. The better option is #2. Here's why:
Defining 32 regions on a /19 network definition in SA is equivalent to defining all 32 /24 sub-subnets within that /19 network. It's shorthand. Once defined, the /19 network definition will have a plus sign (+) next to it. When clicked, the admin can see that SA actually has 32 networks defined within that /19. The nice thing is that they are all grouped together according to site (/19 network).
One disadvantage is that the name originally assigned to the /19 network is the same one originally assigned to all the sub-subnets (regions). This however can be overcome by expanding a /19 (hitting the plus sign) and renaming the VLANs as necessary. Each region can be named individually. The way to get around this is to use option 1 and create a CSV containing all the /24 networks each with a site name prefix and a VLAN designator (name and/or VLAN number).
SuperAgent organizes data according into buckets. SA could store the analysis data for every single client IP address in its own bucket in the database, but that's kind of the point of MTP. Also, having reports that are that granular are only helpful if you already know where the problem is. In addition, if you think about it, storing the analysis of two client IP addresses in two individual buckets in the database doesn't make sense if those two client IP addresses are connected to the same switch, which is using the same router to get to the WAN which is coming into the same network hardware in the datacenter. If the two clients are using all the same network hardware, measuring two different network round trip times for those two clients is virtually impossible. Think about it, the only thing that is different is the client's NIC, which doesn't really affect SA metrics, due to modern technologies like TCP offload engine (TOE) which bring the ACK turn around time on the NIC down to sub-millisecond.
Ok, so there's the reason to summarize networks according to the network path. If a bunch of IP addresses use the same network path to get back to the servers monitored by SA, there's not much value in storing the analysis on a per-IP basis.
However, for groups of IP addresses that do use different network infrastructure, it is imperative to separate them so that the differentiating network hardware can be isolated and therefore identified and troubleshot (troubleshooted?).
Therefore SA provides the ability to define client networks. Each client network instructs SA how to group IP address blocks together and treat them as one unit for analysis and storage. Each network definition should only contain the IP addresses that share all of their network infrastructure.
This is nice because it cuts down on the amount of configuration required in SA. To illustrate, let me give an example. A US company has decided that its IP address scheme is to allocate an entire /10 block of IP addresses to each time zone (e.g. 10.0.0.0/10 for Eastern, 10.64.0.0/10 for Central, 10.128.0.0/10 for Mountain, and 10.192.0.0/10 for Pacific). It then decides to allocate an entire /19 block of IP addresses to each site within that time zone (e.g. 10.30.0.0/19 for NYC, 10.74.32.0/19 for Chicago, & 10.200.128.0/19 for LAX, among others). This is actually really easy to configure in SA. The networks would be defined in SA as such:
| Network Name | Network | Mask |
| EST | 10.0.0.0 | 10 |
| CST | 10.64.0.0 | 10 |
| MST | 10.128.0.0 | 10 |
| PST | 10.192.0.0 | 10 |
| NYC | 10.30.0.0 | 19 |
| ... | ... | 19 |
| CHI | 10.74.32.0 | 19 |
| ... | ... | 19 |
| LAX | 10.200.128.0 | 19 |
| ... | ... | 19 |
While this is great, the network administrators at the US based company decided that a standard of 32 VLANs should be implemented at every site. Each VLAN should be a /24 subnet and each VLAN has a standard use (floor 1, floor 2, floor 3, printers, servers, wireless, etc.). With the networks above defined in SA, the network administrator won't be able to differentiate between bad performance on a wireless VLAN and bad performance on a wired VLAN. At this point the administrator has two options: 1) either he can rebuild all the network definitions defining every single /24 subnet or 2) he can define 32 regions in each of the site network definitions. The better option is #2. Here's why:
Defining 32 regions on a /19 network definition in SA is equivalent to defining all 32 /24 sub-subnets within that /19 network. It's shorthand. Once defined, the /19 network definition will have a plus sign (+) next to it. When clicked, the admin can see that SA actually has 32 networks defined within that /19. The nice thing is that they are all grouped together according to site (/19 network).
One disadvantage is that the name originally assigned to the /19 network is the same one originally assigned to all the sub-subnets (regions). This however can be overcome by expanding a /19 (hitting the plus sign) and renaming the VLANs as necessary. Each region can be named individually. The way to get around this is to use option 1 and create a CSV containing all the /24 networks each with a site name prefix and a VLAN designator (name and/or VLAN number).
Thursday, March 29, 2012
Understanding SA Discovery and Pruning/Grooming
First of all, a little conceptual history around SuperAgent:
SuperAgent was meant to automate the task of analyzing packet captures for essential metrics indicating server or network latency. An engineer wanted a better way to do it than manually and SA was born. Since its inception, it has grown by leaps and bounds increasing its capabilities. Despite the growth, one major concept has remained: SA is meant to automate a manual process for your top applications. This is not a scalability issue. It's something fundamental to the through process behind every revision of the product. SA is meant to analyze the transactions of applications of interest to determine where latency lies.
With the most recent version, SA added a feature that automatically discovers and configures applications. This opened up a whole new area of SA since admins didn't have to automatically configure the applications they were interested in. All they had to do was identify the servers that might be involved and SA did the rest. Expectations began to rise since admins could now easily increase the bounds of what was considered an 'application of interest'.
In order to prevent performance problems that might arise in very complex environments, the developers imposed a limit on the discovery process. When the discovery process has discovered and configured 1000 servers or 1000 applications (whichever comes first) a pruning process will begin. This algorithm reevaluates the active combinations every 5 minutes to determine which 1000 servers and which 1000 applications will remain in the configuration. This doesn't affect any applications configured by the administrator and shouldn't affect the largest, most active applications. Administrators have to understand that this is by design and that the applications configured in SA don't necessarily represent all the applications hosted by a server.
Luckily, the server and application limits can be raised with a simple query in the database. To view the current limits execute the following query:
select * from parameter_descriptions where parameter like 'maxNumAuto%';
Updating those values will change the limits. Remember, those limits were put into place to prevent performance problems. Also SA hasn't been tested by CA's QA department with any limit other than 1000, so if you run into any problems after changing those limits, you'll get push back from support because of it. This is one of the things included in the CIG, which is basically required for every case, so support will know that you did it.
I have increased the limits by 500 in some cases, just to push the envelope a little. I didn't experience severe, immediate problems. If you need much more than that, consider more infrastructure (read more SA master consoles).
Wednesday, March 21, 2012
Disabling SuperAgent Relationship Groups
When an application is configured in SuperAgent, the application actually consists of two parts: the application configuration item itself and the servers assigned to the application. In order to grant permissions to specific applications, administrators would need to create a group in NPC containing both the application configuration item and the servers. The problem with this is that the group that would be created would be static; any time the application configuration changed in SuperAgent, the group would have to be updated.
The answer to this problem is a pair of group sets created by SuperAgent that contain these items. One set contains a group for every application in SuperAgent containing the application CI and the servers assigned to it. The other set contains a group for every server containing the server and any application CIs the server belongs to.
This worked well in the past when applications were manually configured. This only resulted in twice as many groups as the number of applications/servers that the admin was willing to configure. However, with the advent of automatic application discovery and configuration in SuperAgent, it is possible that the number of these groups could skyrocket. This high number of groups can degrade the performance of NPC sync. As a result, there is a need to disable them. The only bad part about disabling them is that you no longer can take advantage of the dynamic groups for permissions purposes.
In order to disable these groups, you have to go to SuperAgent and execute a couple of queries. Before executing any queries you find on the internet, you should backup your database. There. You have been warned.
After running these queries, kick off a full resync of NPC. It may take some time for all those groups to get deleted from NPC. I don't suggest doing this on multiple SA MCs at once. Do them one at a time and let NPC sync with one before moving on to the next.REPLACE INTO parameter_descriptions(Parameter, Level, Type, DefaultValue, Description) VALUES ('SyncRelationshipGroups', 'ProductSync', 'boolean', 'false', 'Sends App/Svr relationship groups to the performance center'), ('SyncRelationshipsEnabled', 'ProductSync', 'boolean', 'true', 'Sends App/Svr relationship combinations to the performance center');UPDATE parameter_descriptions SET DefaultValue = '0' WHERE Parameter IN ('pullLastFullSyncTime', 'pushLastFullSyncTime', 'pullLastIncrSyncTime', 'pushLastIncrSyncTime');UPDATE parameter_descriptions SET DefaultValue = 'true' WHERE Parameter = 'pullForceFullSync';
Friday, March 16, 2012
How to Build or Modify Groups in NPC by using XML
In a previous post, I discussed how to build application reporting groups using dynamic system groups. While this strategy is the recommended way of building application reporting groups, it can become tedious to actually copy and paste all the system groups into your application group. Especially if you have the most recent version of SuperAgent and it has discovered a ton of applications and networks. Luckily, there is an unpublished easier way: XML. NPC has the ability to use XML to modify the group structure. This includes the ability to put referential copies of system groups into custom application reporting groups.
The following is an excerpt from some documentation I wrote about how to use the web service to modify various portions of the NetQoS systems:
The following is an excerpt from some documentation I wrote about how to use the web service to modify various portions of the NetQoS systems:
Group management in NPC is performed through the AdminCommand web service (found at PortalWebService/AdminCommandWS.asmx?WSDL ). Adding or removing groups and adding or removing members from groups is accomplished by invoking the UpdateGroups operation (found at PortalWebService/AdminCommandWS.asmx?op=UpdateGroups). Three main parameters are required: (1)useIDs, (2)allowDeletes, and (3) XML defining the groups (the groups to be added/removed/updated). Groups themselves are defined explicitly in the XML while membership of groups is managed by a set of rules applied to each group. Managed objects that match the rules are included as members of the group, objects that don’t match are excluded.
The first two parameters are global and don’t change often. The parameter useIDs instructs the operation whether or not to use the group ID values from the XML definition when identifying the group to be updated. The useIDs parameter will need to be set to ‘true’ to ensure the correct groups are updated. The only time a value of false would be used is when a single XML file is being used to import a group structure from one NPC system to another.
Wednesday, November 23, 2011
NPC Application Groups
As mentioned in a previous series of posts, when building groups in NPC, there needs to be a 'Reporting Groups' group. Expanding on the need for reporting groups, I figured I'd detail exactly what should go into that group and how to work with it.
The most important group that should exist in the reporting groups is an application group. This application group doesn't contain any objects of itself and really isn't used for any reporting. It's just there to assist in managing the groups that it will contain, namely application groups. While the strategies outlined in my previous posts build the groups needed to organize the geographical layout of your infrastructure, the Applications group is where the logical layout of your applications is built to facilitate reporting on individual applications.
Thursday, October 6, 2011
NPC Sites and Groups 7 of 7: GXMLG - Exporting the Configuration Files
Part of a series of posts. To see all posts, click here.
Once the sites and networks are completely configured in the tool, configuration files can be generated for NPC, NetVoyant, SuperAgent, and UCMonitor.
Before an NPC configuration XML file can be generated, the tool need s to know the path to the ‘All Sites’ group. If an XML file was imported that was exported from an existing ‘All Sites’ group, the tool extracted this information from the XML. If a CSV was imported or the Sites/Networks list was built manually within the tool, this setting must be input manually on the ‘Import’ tab of the tool.
Three other settings of importance exist on the ‘Import’ tab: NVDatasource, SADatasource, and UCMDatasource. If the values of these fields are set to ‘true’ the tool will include rules in the NPC XML for that type of datasource. The tool will also include CSV outputs for those data source types. Setting the value to anything other than ‘true’ will exclude that type of data source output.
There are two options for exporting the configuration files. On the ‘Export Config Files’ tab, the ‘Export All Config Files…’ button will prompt for a location to output the files. The tool will save the XML and CSV files in that target folder. Those files can then be imported into their corresponding products.
The other option for export is to click the individual generation buttons. These will generate the output and place it into a text box in the tool. The text could then be copied and pasted into a text editor to save the files.
Once the sites and networks are completely configured in the tool, configuration files can be generated for NPC, NetVoyant, SuperAgent, and UCMonitor.
Before an NPC configuration XML file can be generated, the tool need s to know the path to the ‘All Sites’ group. If an XML file was imported that was exported from an existing ‘All Sites’ group, the tool extracted this information from the XML. If a CSV was imported or the Sites/Networks list was built manually within the tool, this setting must be input manually on the ‘Import’ tab of the tool.
Three other settings of importance exist on the ‘Import’ tab: NVDatasource, SADatasource, and UCMDatasource. If the values of these fields are set to ‘true’ the tool will include rules in the NPC XML for that type of datasource. The tool will also include CSV outputs for those data source types. Setting the value to anything other than ‘true’ will exclude that type of data source output.
There are two options for exporting the configuration files. On the ‘Export Config Files’ tab, the ‘Export All Config Files…’ button will prompt for a location to output the files. The tool will save the XML and CSV files in that target folder. Those files can then be imported into their corresponding products.
The other option for export is to click the individual generation buttons. These will generate the output and place it into a text box in the tool. The text could then be copied and pasted into a text editor to save the files.
Wednesday, October 5, 2011
NPC Sites and Groups 6 of 7: GXMLG - Automatic Config File Generation
Part of a series of posts. To see all posts, click here.
At this point, this is all the information strictly needed to start with a Sites/Networks list and end up with a fully populated Sites group in NPC, a NetVoyant that should be discovering all devices at all sites, a SuperAgent that only needs an active monitor port, and a UCMonitor that only needs an active monitor port (if monitoring only Cisco telephony).
The obvious next step is to implement this into the product in such a way that this configuration is done in NPC and synchronized to the sub-products. However, since CA is currently sans an NPC Product manager, we’ll have to suffice ourselves with a third party tool.
At this point, this is all the information strictly needed to start with a Sites/Networks list and end up with a fully populated Sites group in NPC, a NetVoyant that should be discovering all devices at all sites, a SuperAgent that only needs an active monitor port, and a UCMonitor that only needs an active monitor port (if monitoring only Cisco telephony).
The obvious next step is to implement this into the product in such a way that this configuration is done in NPC and synchronized to the sub-products. However, since CA is currently sans an NPC Product manager, we’ll have to suffice ourselves with a third party tool.
Tuesday, October 4, 2011
NPC Sites and Groups 5 of 7: UCMonitor Locations and SuperAgent Networks
Part of a series of posts. To see all posts, click here.
UCMonitor Locations
As mentioned before, the relationship between NPC Sites and UCMonitor Locations should be a 1-to-1 relationship. Locations should be named the same way the locations are named in NPC. All that remains is to ensure that the networks that correspond to each site are added to each corresponding location.
UCMonitor Locations
As mentioned before, the relationship between NPC Sites and UCMonitor Locations should be a 1-to-1 relationship. Locations should be named the same way the locations are named in NPC. All that remains is to ensure that the networks that correspond to each site are added to each corresponding location.
UCMonitor locations can be imported via a CSV file. The syntax is described in the Installation Steps documentation and is shown below:
Saturday, October 1, 2011
NPC Sites and Groups 4 of 7: NetVoyant Discovery Scopes
While I agree that there’s not much value in discovering or polling people’s desktops or laptops nor network attached printers, there are mechanisms built into NetVoyant that allow partial discovery of those devices without using licenses. In fact, NetVoyant is setup by default to ignore workstations and printers. During discovery, NetVoyant will attempt to get the sysObject OID. Based on this sysObject OID, NetVoyant knows what type of device is being discovered. If it is a workstation or printer, it will be classified as such and placed into the workstations or printers group and discovery will halt for those devices.
The best scenario will depend on each individual situation. I’ll detail a middle-of-the-road solution that should work in indecisive situations.
Friday, September 30, 2011
NPC Sites and Groups 3 of 7: Building the Groups
Part of a series of posts. To see all posts, click here.
Back when NPC underwent a dramatic set of upgrades, one of the new features was the group tree. Administrators could now create groups of monitored objects that could be applied to pages as filters. Recently, the NPC developers added a context page so that users could actually drill into a site. Instead of applying a filter, NPC would take the user to a set of pages specifically designed to show a set of site overview reports for the objects in the group. These site groups are crucial to implementing the best group structure.
Calling back to a Best Practice document written by NetQoS several years ago, NPC administrators should create five groups under the root, /All Groups: All Sites, Regional, Line of Business, Reporting Groups, and zExcluded Items. Optionally, a sixth group could be added, zRetired Groups, where groups that should no longer be used can be retired without actually deleting them.
Back when NPC underwent a dramatic set of upgrades, one of the new features was the group tree. Administrators could now create groups of monitored objects that could be applied to pages as filters. Recently, the NPC developers added a context page so that users could actually drill into a site. Instead of applying a filter, NPC would take the user to a set of pages specifically designed to show a set of site overview reports for the objects in the group. These site groups are crucial to implementing the best group structure.
Calling back to a Best Practice document written by NetQoS several years ago, NPC administrators should create five groups under the root, /All Groups: All Sites, Regional, Line of Business, Reporting Groups, and zExcluded Items. Optionally, a sixth group could be added, zRetired Groups, where groups that should no longer be used can be retired without actually deleting them.
Thursday, September 29, 2011
NPC Sites and Groups 2 of 7: Building the Sites/Networks List
Part of a series of posts. To see all posts, click here.
Before any thought can be dedicated to configuring the products, a good Sites/Networks list should be compiled. The Sites/Networks list should represent the smallest building blocks for reporting groups. Ideally, if you wanted to report on anything smaller than one of these sites, you’d report on an individual device or poll instance.
This list may already exist in some form or another. You’ll probably need to clean it up a bit. Whether you start over fresh or take an existing list and clean it up, you should have a list similar to the one shown below. Columns could be added to the right to include metadata about the site like Line of Business or Regional membership. This information is not required to implement this best practice, but can help when filling out other groups. The information I’ve provided below will be used as an example throughout this document and should hopefully exemplify most of the complex situations possible in corporate networks.
You’ll notice that I’ve added to the names of Bldg 2 to make them unique. Also notice that I’ve simplified the network definition for Bldg 1 since the two subnets were consecutive and could be summarized using a smaller subnet mask.
To be continued...
This list may already exist in some form or another. You’ll probably need to clean it up a bit. Whether you start over fresh or take an existing list and clean it up, you should have a list similar to the one shown below. Columns could be added to the right to include metadata about the site like Line of Business or Regional membership. This information is not required to implement this best practice, but can help when filling out other groups. The information I’ve provided below will be used as an example throughout this document and should hopefully exemplify most of the complex situations possible in corporate networks.
| Site Name | Network | Line of Business | Region |
| New York | 10.1.0.0/16 | Sales Office | NA |
| Los Angeles (Bldg 1) | 10.2.0.0/16, 10.3.0.0/16 | Corporate | NA |
| Los Angeles (Bldg 2) | 10.4.0.0/16, 10.5.0.0/16, 172.16.1.0/24 | Corporate, Sales Office, Data Center | NA |
| London | 10.100.0.0/16 | Sales Office | EMEA |
| Singapore | 10.150.0.0/16, 192.168.150.0/24 | Sales Office | APAC |
Table 1:
Raw Sites List
Now that the sites list is compiled, it needs to be cleaned up a bit. The Los Angeles site is actually two sites. Also, Bldg 2 of the Los Angeles site is comprised of three different network segments, each serving a different line of business (LOB). I recommend treating each of these network segments as separate locations. Most reporting will want to segregate data center operations from the corporate network infrastructure monitoring. Also, since Corporate and Sales are two different LOB’s, splitting them into different sites will allow easier reporting by LOB later on. After cleaning up the raw Sites/Networks list, we end up with the list shown below:
| Site Name | Network | Line of Business | Region |
| New York | 10.1.0.0/16 | Sales Office | NA |
| Los Angeles (Bldg 1) | 10.2.0.0/15 | Corporate | NA |
| Los Angeles (Bldg 2 - Corp) | 10.4.0.0/16 | Corporate | NA |
| Los Angeles (Bldg 2 - Sales) | 10.5.0.0/16 | Sales Office | NA |
| Los Angeles (Bldg 2 - DC) | 172.16.1.0/24 | Data Center | NA |
| London | 10.100.0.0/16 | Sales Office | EMEA |
| Singapore | 10.150.0.0/16, 192.168.150.0/24 | Sales Office | APAC |
Table 2:
Final Sites/Networks List
You’ll notice that I’ve added to the names of Bldg 2 to make them unique. Also notice that I’ve simplified the network definition for Bldg 1 since the two subnets were consecutive and could be summarized using a smaller subnet mask.
To be continued...
Wednesday, September 28, 2011
NPC Sites and Groups 1 of 7: The Philosophy
Part of a series of posts. To see all posts, click here.
A while ago, I started building a document that detailed the best practices I had developed around groups and sites in NPC. I applied to present this at CA World this November, but the new direction of CA World wasn't compatible with this type of presentation. As a result, I'm going to post my findings here. I'll post the sections individually then maybe post the whole thing later as a single document. I've also built a little applet (using my limited programming skills, so be nice) that takes a majority of the manual work out of following these best practices.
The Philosophy
A while ago, I started building a document that detailed the best practices I had developed around groups and sites in NPC. I applied to present this at CA World this November, but the new direction of CA World wasn't compatible with this type of presentation. As a result, I'm going to post my findings here. I'll post the sections individually then maybe post the whole thing later as a single document. I've also built a little applet (using my limited programming skills, so be nice) that takes a majority of the manual work out of following these best practices.
The Philosophy
After having setup countless instances of the NetQoS suite
of products and after the most recent release of SuperAgent, I’ve stumbled upon
a discovery that I think is significant.
Frankly, I’m surprised no one at NetQoS has realized or built on this
relationship. Perhaps they have, but due
to the recent evacuation of NetQoS talent from CA, no one has stepped in to
fill the gap. This is why I’m writing
these posts.
This discovery came after being tasked to revamp the group
structure in a NetQoS Performance Center (NPC) installation. At the same time, a request came in to clean
up the locations in Unified Communications Monitor (UCM). It was then, that I noticed that the
information required for both was essentially the same. I needed to know what locations we had and
what subnets were in use at those locations.
Not long after that, I realized that the same information is needed,
although in a slightly different form, for SuperAgent and NetVoyant
configurations.
Therefore, in order to configure four of the NetQoS
products, one set of core data is required.
There are obviously other pieces of the configuration that are required
to get the best monitoring. In these posts, I’ll detail how the Sites/Networks list can be used to best configure
the core NetQoS products.
To be continued...
Subscribe to:
Posts (Atom)