Monitor Solution Best Practice v3.2 part of Symantec Server Management Suite

Transcription

1 Summary When implementing Monitoring and Alerting part of Server Management suite. The following items are areas that should be reviewed. It is important to start to monitor what you need and add/build onto this where needed. I would normally start with the Top 5 Service Desk Incidents and drive automated remediation around those alone. Number of managed/monitored nodes or resources This is in respect to the number of resource returning data back to the Altiris Server. The more resources the more data is being collected. Depending on the type of data whether it is fault data (representing data that does not change frequently) versus performance data (representing data that changes frequently and used for trending purposes) this will of course mean more data will be communicated and stored in the CMDB. Both the Agent Installation Summary Report (ensure Agent version is up-to-date) and Agent Count by OS provides a good summary on current plug-in version installed and also the number of resources being monitored: Agent Installation Summary Report:

2 Suggestions: Ensure Agent Versions are all up-to-date by checking the reports. Agent Count by OS Report: Agent Plug-In versus Agentless Monitor Solution supports two types of methods for monitoring servers, this can either be done using a plug-in that extends the Symantec Management Agent to monitoring and/or agentless that can be done without the need to have an agent/plug-in installed on the server using standard protocols like WMI, SNMP and WSMan etc. Now which method to use Agent Plug-in or Agentless? My advice is to use the plug-in where possible as it provides much more monitoring capabilities, auto remediation and it is less intrusive on the network bandwidth. For example it will only send events to the central event console when the threshold has been triggered; the auto remediation occurs even before the event has reached the central event console and it is also not dependent on the network. Using agentless when it is only not possible to install the plug-in onto a server, it provides monitoring capabilities available via the standard protocols though it is limited to the remediation capabilities via those protocols, it is dependent on the network and the metric values need to be sent to the Site Server to be evaluated in order to determine if a threshold has been triggered. Monitor Solution Agentless is integrated into Site Server and is referred to as the Remote Monitoring Server (RMS). Please refer to the section below on Remote Monitoring Server. For more critical servers then you could also combine both Agent Plug-in and Agentless together. Agentless Important Notes: Make sure you run Network Discovery before using Agentless Monitoring. Agentless monitoring is dependent on the credentials used during the Network Discovery phase.

3 Number of enabled monitor packs/policies Each monitor pack/policies will contain a set of predefined rules and metrics used for collecting data either for trending or for alerting. Those metric types for trending are labeled metric collect and those used for alerting are labeled metric and have a severity applied. Each pack/policy will have a different number of existing rules, the more individual rules/metrics applied to each resources the more data will be collected and stored in the CMDB. It would be advised to keep the baseline to exactly what is needed. To find out what you have enabled simply run the detected Monitor Policy report and group by Monitor Policy. You can then expand to see which resources these policies apply to or have been detected on: Detected Monitor Policies Report: Suggestions: Review these monitor policies to ensure the monitor packs are enabled and detected.

4 Metric polling interval Each metric will have a preset polling interval, which is used to check the metric value on each resource. By default this is set to 300 seconds. Depending on the number of resource and packs enabled it would be advised to review this whether it is applicable to be this value for all resources and all metrics. For less severe rules it might be worth reviewing these and increasing where possible. The more frequent the interval the more data bei ng communicated and stored in the CMDB. It is important to review the values in the metric as shown below, the polling interval should be reviewed to what is an acceptable interval, you may want to create cloned versions of this with different interval times to apply to different classes or critically of servers: Suggested Values: Review Polling intervals: 300 > Metric type (performance versus fault) This is in reference to the type of data. Fault data would be referring to data that does not change frequently the value. For e.g. fault data could be a service is running or not running or a process exists or does not exist. Performance data would be for e.g. CPU performance where the value is consistently changing and therefore it is more frequently being communicated back to the server and stored in the CMDB.

5 Configuration settings and data performance This refers to how frequent the metric log is uploaded to the server, whether NT event and process information is being collected and what is the interval for this. In the past both NT Event and process information represented the largest tables in the CMDB so it is advised to review these settings to ensure that you collect only what you really need to collect. You may want different configuration settings for servers, for example classify the configuration settings for the criticality of servers. Class A servers versus Class B servers. Below is a sample configuration view for servers. You may want to clone and create multiple versions of this for different classes of servers. The critical values here are the Data Collection values, the more aggressive the value the more data growth in the CMDB. Also whether this data is always being collected or only when alerts are triggered need to e reviewed. My recommendation is to set the interval value to the longest possible acceptable time and then when alerts get triggered. Some suggested values: <1500 Servers: Default Settings are good. It is not recommended to go above 1500 Servers per Symantec Management Server. Review Record metric values every: seconds Record process values every: Off for all machines (have separate configuration for selected servers). If it is required for all servers then > seconds

6 Purging settings This is how long you want to store the data collected in the CMDB for. We have separated the different types of data into its own category. Below you can see the default values for purging. The important section below that can affect data growth is the nonnumeric data (string, process and NT event data). The longer the value and data stored in the cmdb in relation to those the more the database growth will be so it would be recommended to keep those to the min acceptable level for monitoring purposes. It is important to note for the numeric data the hourly summary occurs after the detailed summary and so forth with the daily summaries. NOTES: Please note that the way the purging works above is cumulatively so the hourly summaries starts only after the 7 days of detailed data and then the daily summaries starts after the combined values of both the detailed data and hourly summaries. Suggestions: Review the Non-numeric data purging and whether you can decrease this where possible. Suggested Values: String metric data: <7 Days (if possible <5 Days) Process data: <7 days (if possible <5 Days) NT event data: <7 Days Detailed data for numeric (do not recommend more than 1 month of detailed data) This will cause significant database growth.

7 CMDB Database Growth and Monitor table size: Check the Space Used for Monitor Tables reports to see which data type is using the most space in the CMDB: Most likely it will be the Process Data as shown in the sample below. This allows you to review what possible changes to the configuration and purging might be needed. Monitor Table space used by monitored resources Report: This report is also very useful though it can take sometime to run in some instances to best running it in a schedule or during low times. It allows you to look for what machines have not been reporting data to check that they are working ok, also the data used per resource. Again normally it is Process Data so this should be the one to review.

8 Remote Monitoring Server (RMS) The RMS gets automatically installed onto the Symantec Management Platform Server and can be identified by checking the Symantec Management Agent settings and looking for the Altiris Monitor Agent RMS as shown below. You can also roll out the Remote Monitoring Server to Site Servers by selecting the Monitor Service on the site server. The Monitor Service will also roll out Credential Management and PPA as these are dependencies for the RMS. The Monitor Site Service is located on the Symantec Management Console under Settings>Notification Server>Site Server Settings. You can select the monitor site service and get an overview on what the summary of that Remote Monitoring Server is currently doing as shown below.

9 A Portal Web Part is also available to display the health of the Remote Monitoring Server and can be added to the default Monitor Dashboard. This will display the RMS Site Servers, the number of resources and the health of the Site Server. Some Valuable Monitoring Resources: Symantec Connect (Includes Customer questions and answers): Monitor Solution Community (Includes Connect Packs, How To, Reports, Videos and discussions): New Monitor Report for Server Health Summary:

10 Suggested Configuration and Values for Monitoring and Alerting: Number of Monitored Resources: Agent Based () Agent Less () Number Of metrics () Polling Interval () Data Collection: Record Process Value () Turn Off most machines (Separate into classes ) Server Settings: Purging Detailed Data Numeric ()

11 TIP Server Resource Manager and Real-Time Performance Viewer. I thought I would share a tip that several of you may not be aware of. When you right click on a Server within the Computer View select Resource Manager: You will get the default Resource Manager View as shown below, you will see in the top right corner of the Resource manager a drop down custom view that allows you to change to the Server Resource Manager View. After selecting the Server Resource Manager view you will get the following View below that will show you the health/performance of the Server for the past 24 hours: Now please note that if you have not enabled monitoring then it will provide you with details on what you need to do in place of the web parts below. Also note that all of these web parts the data is now populated by a single Monitor Policy Windows Server Performance Health Monitor Policy

12 Now change the 24 Hour history on any of the Web parts to Real -Time and this will now display the performance of the selected metric in Real-Time.

13 Now that you have the data being collected in Real-Time if you double click on the Processor Web Part it will automatically launch into the Real-Time Performance Viewer for the resource and allow you to select all available counters and metrics as shown in the screenshot below.

14 TIP Real-Time Performance Viewer Connection. Now sometimes when trying to connect to a monitored resource via the Real -Time Performance Viewer you may get the following error below: Failed to connect the Monitor Plug-in. The Monitor Plug-in Service may be initializing or not running. Please retry in a few minutes and verify that the Monitor Service is installed and running on the machine. Now the error message does provide some good ideas to what is causing this but here are a few others that can also be sometimes missed. 1. Check the Monitor Plug-in is installed Altiris Monitor Agent 2. Check that the Service is actually running. 3. Real-Time Performance Viewer does require TCP port 1011 bi -directional to work so make sure you check the firewall settings. 4. A common error is that no Agent Plug-in Configuration is applied to the Resource. As shown below make sure the machine you are trying to connect to is a target of the Configuration Policy. Normally you can tell when looking at the processes on the target resource is the AeXSMLogUpload.exe is not running then likely the Configuration file is missing.

15 Once you have checked all of the above the Real -Time Performance Viewer should now be working and getting the results below: Again I hope someone out there finds these tips useful.

16 TIP Network Discovery and Agentless monitoring: Here is the summary with regards to Network Discovery requirements and Agent-Less monitoring: A Network Discovery task run is required as it will bind the machines specified in the IP Range (IP Range defined in Network Discovery Task) to the Connection Profile used in that Network Discovery task. This is how the association between resource and connection profile to be used is made. This resource to connection profile association is needed for a resource that will be Agentless monitored using any of the follow Agentless Metric sources: a) HTTP b) SNMP c) WMI d) WS-MAN So to summarize; During a Network Discovery Task run, any resource discovered is then associated with the Connection Profile used with the Network Discovery task. (Connection Profile selection is part of the Network Discovery task setup) In order for our RMS Agent to connect to a resource using a specific protocol, we must have the connection profile binding to that resource. However, for ICMP protocol, there is not passing of credentials so a Network Discovery need not be done if you are looking to monitor JUST for availability status (up\down) of a resource. For all other protocols, we would need that resource to connection profile binding.