Monitoring Device Administration › How the Management Console Manages Database Growth › Monitoring Device Recommendations

Monitoring Device Recommendations

To optimize the management console database resources, follow the guidelines below:

• If possible, monitor from a physical switch using a physical monitor rather than from a virtual switch using a CA Virtual Systems Monitor. For example, monitor client-server traffic from the physical Distribution layer switch instead of the CA Virtual Systems Monitor on the ESX host that has the web server tier.

  Physical switches have the best SPAN/VACL functionality and they do not suffer performance loss when you exercise that functionality. The CA Virtual Systems Monitor is a guest on the ESX host and as such, it consumes system resources. Also, the web tier is the most challenging tier to monitor since it deals with the client networks. Do not complicate ESX performance when you have a better choice from the physical realm.

• When monitoring from a physical switch using a physical monitor, monitor as close to the server as possible. When the monitoring device is close to the server, the improved accuracy of server metrics enables the management console to clearly distinguish between a network or server incident.
• If you have a CA Multi-Port Monitor, take advantage of SPAN aggregation on the monitor with hardware-based filtering to greatly improve efficiency.

  Or, you can put a matrix switch between the mirrored switch ports and the monitor. This is an investment that can deliver big returns in a large environment. Use the matrix switch or network tool optimizer to filter unwanted traffic at line rate and send well-crafted packet streams to each port of a CA Multi-Port Monitor or CA Standard Monitor. This approach has several advantages:

  • You can often adjust the data from the matrix switch rather than coordinate with the switch administrator to configure the physical switch during a change window.
  • Hardware-based filtering at line rate does not impact system CPU or memory.
  • Software-based filtering, which is available on the CA Standard Monitor or CA Virtual Systems Monitor, takes a lot of CPU and reduces monitor throughput.
  • Up-front cost and total cost of ownership are both lower.
  • The efficiency often makes it feasible to collect at the Access layer (closer to the servers) rather than just the Distribution layer.
• Sizing guidance is generic. Every environment is different. Rules of thumb are helpful, but actual capacity depends upon the nature of the application traffic as well as the configuration.

  The management console does not place restrictions on the numbers of applications, servers, CPUs, or client networks monitored. The management console administrator is free to use the management console and monitoring devices to their maximum capacity, as dictated by the unique characteristics of each particular environment.

• Limit what the management console attempts to monitor by carefully defining:
  • Application port exclusions.
  • Server subnets.
  • Client networks.
• Delete applications that are less interesting, like backup applications.
• Aggregate 24-bit client networks into broader subnets, like /22 networks. This approach limits the management console’s ability to determine which TCP clients are affected by a performance degradation, but does reduce the number of rows that are created in the database.

More information:

How Client Networks Work

Delete a System-Defined Application

Delete a User-Defined Application

How Port Exclusions Work

How Servers Work