eG Administration
 

Configuring the eG Manager Settings

Expanding the Manager Settings node in the SETTINGS tree will provide you with sub-nodes that enable the configuration of the following manager settings:

  1. Clicking on the General node will open a GENERAL page in the right panel.

  2. Using the GENERAL page, you can configure the following settings:

    • The trend graph option in the eG monitoring console allows users to view and analyze the computed trend values over time. By default, during trending, the eG manager computes the upper and lower bounds of every metric using statistical quality control techniques. In addition, the manager also computes the average and sum of every metric while trending, and stores these values too in the database. Accordingly, the Compute average/sum of metrics while trending flag is set to Yes by default. This ensures that users have the option to plot min-max, average, or sum values of a chosen metric in a trend graph, and are able to better assess and plan the current and future performance of the target components. However, if, for some reason, you do not want the eG manager to perform average and sum computations while trending, you can indicate that by setting the Compute average/sum of metrics while trending flag to No.

    • The default value 1 in the Number of threads for trend computation text box indicates that by default, the eG manager uses a single thread for computing trend values. To speed up the day-end trending activity, you can configure the eG manager to spawn more threads, by increasing the Number of threads for trend computation.

    • The default value 1 in the Number of threads for threshold computation text box indicates that by default, the eG manager uses a single thread for computing thresholds. To speed up the threshold computation process, you can configure the eG manager to spawn more threads, by increasing the Number of threads for threshold computation.

    • Typically, the eG manager computes thresholds on an hourly basis. Accordingly, the default value in the How frequently thresholds are computed text box is 60 (minutes). However, in case of highly dynamic environments (eg., trading environments), where significant data changes occur at regular intervals, you might want to compute thresholds more frequently, say every half an hour, so as to capture the smallest of performance variations. On the contrary, in fairly static environments, where performance data is not likely to change frequently or dramatically, just a few threshold computation points would suffice - in other words, thresholds can be computed less frequently. To alter the frequency of threshold computation to suit your environment, simply modify the How frequently thresholds are computed setting.

    • Since the default threshold frequency is 1 hour (i.e., 60 minutes), by default, thresholds are computed for distinct one-hour data periods - eg., between 7 and 8 PM, between 1 and 2 PM, etc. However, in some environments, data transition might not always occur at such definite time windows. For instance, dramatic data changes could occur in an environment between 6.45 and 7.45 PM, and not during the precise 7 - 8 PM slot. To address the unique thresholding needs of such environments, you can off-set the data period for threshold computation by a fixed duration (in minutes) specified in the Data period that is used for sliding-window thresholds text box. For example, to ensure that the data collected during 6.45 PM and 7.45 PM is considered for threshold computation, specify 15 (minutes) in the Data period that is used for sliding-window thresholds text box.

    • By default, relative thresholds are computed for the whole day. This is why the From and To specifications in the Hours for which relative thresholds are computed configuration indicate 24 hours by default. Sometimes, administrators might decide to compute thresholds for the working hours only - say between 9 AM and 6 PM - so as to avoid computing thresholds for periods of inactivity in the environment, and thus reducing the unnecessary stress on the eG backend. In such a case, you can modify the From time and the To time accordingly.

    • When an agent attempts to download from the manager the details of managed components and tests to be executed, by default, the manager first determines the IP of the agent that is requesting for the information. Then, the manager verifies the IP to nickname mapping, identifies all the nick names that map to that IP address, and allows the agent to download those sections of the eg_agents.ini file that have either the agent's IP address or the nicknames that correspond to it. Accordingly, the Automatically map IP address of agents to nick names flag is set to Yes by default. In a managed service provider environment however, the same IP address could exist in two different customer networks. Similarly, if you have DHCP enabled environments, the IP address could change frequently. In such cases therefore, you can set this flag to No.

    • By default, the manager checks the nickname to IP mapping of every agent that talks to it. Accordingly, the Verify if agent is reporting from configured IP parameter is set to Yes by default. However, in case of DHCP enabled environments, where the IP constantly changes, this has to be set to No, as the agent will otherwise fail.

    • Finally, click the Update button.

  3. Clicking on the Discovered Components node in the tree will invoke a DISCOVERED COMPONENTS POP-UP page in the right panel.

  4. Using the DISCOVERED COMPONENTS POP-UP page, you can configure the following:

    • Whenever the eG manager discovers/re-discovers new components/devices, you can optionally configure the manager to display a Dicovery pop-up listing the recently discovered components/devices. To enable this pop-up, set the Show pop-up flag in this section to Yes. By default, this flag will be set to No, indicating that the Discovery pop-up will not be available by default. Once enabled, this pop-up will appear:

      • As soon as you login to the Admin HomePage;
      • While attempting to add a new component of a recently discovered type;

    • Also, once you set Show pop-up to Yes, you will also be required to configure a Pop-up timeout period, in minutes. By default, this is set to 1 minute - this means that the discovery pop-up will automatically disappear at the end of 1 minute by default. You can override this default setting by providing a timeout period of your choice.

    • Finally, click the Update button.

  5. While signing out of the eG administrative interface.

  6. If you click on the Test Configuration node in the tree, a TEST CONFIGURATION page will appear in the right panel.

  7. Using the TEST CONFIGURATION page, you can define the following:

    • By default, in the AGENTS - TESTS - SPECIFIC CONFIGURATION page, every time you select a Component type, Test type, or Component, a list of unconfigured tests that corresponds to your selection will pop up. This list will enable you to quickly identify those tests that require manual configuration. If you find this pop-up list distracting, then, you can disable the pop-up, by setting the Pop up list of unconfigured tests flag to No (default: Yes).

    • By default, the HOST and PORT parameters of a test cannot be modified during test configuration. Accordingly, the Is host editable? and Is port editable? flags are set to No by default. If you want to change the values of these parameters for one/more components, set the Is host editable? and Is port editable? flags to Yes.

    • Finally, click the Update button.

  8. Clicking on the Threshold Configuration node will invoke a THRESHOLD CONFIGURATION page in the right panel.

  9. eG Enterprise is capable of automatically computing the thresholds of performance using historical data. This auto-thresholding capability eliminates the need for determining the norms of performance manually in dynamic environments where measure values vary with time. eG Enterprise uses tried and tested statistical quality control techniques to analyze past values of the metrics, and automatically sets the upper and lower bounds for each of the metrics based on this analysis. With the help of the THRESHOLD CONFIGURATION section, you can configure the 'past values' to be considered for automatic threshold computations.

    • By default, to perform the threshold computation, the values reported by a measure during each day of the last 14 days is used. This is why, the Automatic threshold computation policy is set to Daily, and the Lookback period to compute automatic thresholds is set to 14, by default. According to these default settings, the threshold for a measure for 8 AM to 9 AM on August 18, will be automatically computed using the actual values reported by that measure during 8 AM to 9 AM on each of the 14 days prior to August 18.

      • In some environments, mandatory operations - for example, data backup operations or virus scanning operations - may occur on one/more servers once a week. This in turn may increase the activity levels on those servers during that time window. In some other environments, such routine operations may be scheduled to take place at a specific time every month. If threshold computations in such environments are based on Daily data collections, then the resulting thresholds may not reflect the weekly/monthly deviations in usage, thus causing false alerts. In such a case, you can set the Automatic threshold computation policy to Weekly or Monthly (as the case may be), and specify the number of past weeks/months to be considered for computing thresholds in the Lookback period to compute automatic thresholds. For instance, say that the Automatic threshold computation policy is set to Weekly and the Lookback period is configured as 2. In such a case, to compute thresholds for 8 AM to 9 AM on August 18, the actual measure values reported on the same day and time in the last 2 weeks will be considered - this will be 8 AM - 9 AM on August 11 and 8 AM - 9 AM on August 4. Similarly, assume that the computation policy is set to Monthly and the Lookback period is set to 2. In such a case, to compute thresholds for 8 AM to 9 AM on August 18, the actual measure values reported on the same date and time but in the last 2 months will be considered - this will be 8 AM - 9 AM on July 18 and 8 AM - 9 AM on June 18.

      Note:

      If the Monthly computation policy is chosen and the date for which thresholds are to be computed is not available in the previous month - say, thresholds are to be computed for July 31, but the previous month of June has only 30 days - then, the data collected during the last day of the previous month will be used for threshold computation. In the case of our example therefore, the data collected on June 30 will be used.

    • Finally, click the Update button.

  10. Click on the Command Execution node in the tree structure to view the COMMAND EXECUTION section in the right panel.

  11. Like email IDs / mobile numbers, you can associate one/more custom scripts with users to the eG Enterprise system. Whenever alarms are raised/modified/closed for a specific user, the associated custom script will automatically execute, so that the details of the alarms are routed to third-party customer relationship management systems or TT systems, and trouble tickets automatically created (or closed, as the case may be) for the corresponding user. The custom scripts thus provide a mechanism by means of which eG alerts are integrated into CRM/TT systems. These custom scripts can be configured in addition to or instead of email / SMS alerts.

    12. Using the COMMAND EXECUTION page, you can configure the details of these scripts as follows:

    • First, to enable the command execution capability, set the Enable Command Execution flag to Yes. By default, this is set to No.

    • To track the status of the script execution and to troubleshoot issues with the same, use the mailexec.log file that is automatically created in the < EG_INSTALL_DIR>\manager\logs directory when the custom scripts execute. You can specify the maximum size up to which this log file can grow, in the Log file maximum size text box. When the file reaches the specified size limit, the details originally logged in the mailexec.log file will be moved to another log file named mailexec.log.1, and the newer information will be logged in the mailexec.log file instead. This log rotation mechanism helps ensure that the log file does not grow beyond control. The default maximum size is 1 MB.

    • You can even indicate the type of information you want to be logged in the mailexec.log file. By default, the log files capture both the errors and the standard output of the specified Command; accordingly, the Log entries for stdout also flag is set to Yes by default. If you want to capture only the errors, set the Log entries for stdout also flag to No.

    • To execute the script for every alert that is generated, set the Separate execution flag to Yes. This means that when the script executes, the details of only a single alert will be included in the script output. Given below is an extract from the mailexec.log file, when the Separate execution flag is set to Yes.

      31/08/2011 11:06:51 USER admin COMMAND echo PARAMS -ComponentType "Host system" -ComponentName "esx150" -LayerName "Operating System" -Desc "-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67" -StartTime "Aug 31, 2011 11:05:18" -Priority "Critical"

      31/08/2011 11:06:51 INFO -ComponentType "Host system" -ComponentName "esx150" -LayerName "Operating System" -Desc "-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67" -StartTime "Aug 31, 2011 11:05:18" -Priority "Critical"

      As you can see, for a single alert, two lines have been logged in the mailexec.log file.

      The first line displays the USER who will be receiving the alarm intimation, the syntax of the COMMAND that is being executed by the script, and the PARAMS - i.e., the input parameters/arguments - that the command takes while executing. In the sample provided, echo is the COMMAND executed by the script. Therefore, the PARAMS tag in our extract is followed by the input parameters required by the echo command. As you can see, every parameter of the echo command consists of two components: the parameter name and its value at runtime. While the param name begins with a - (hyphen), its runtime value is enclosed within "double quotes". Take for instance the parameter, -ComponentType "Host system". Here, -ComponentType is the parameter, and the "Host system" is its value.

      The second line logs the output of the COMMAND - in the case of our example, this will be the output of the echo command. The command output typically begins with the tag INFO, and will be followed by the details of the alert being sent. Like its input, the output of the echo command too is a combination of the parameter name and its value at runtime. While the parameter name indicates what type of information is being sent, the actual information itself is contained within "double quotes" and forms the parameter value. The parameters included in the output of the echo command have been discussed in the table below:

      PARAMETER Description
      ComponentType The problem component type
      ComponentName The name of the problem component
      LayerName The name of the problem layer
      Desc A brief description of the problem; typically, for the echo command, a problem description includes the following:

      • the site affected; if the alarm does not pertain to any site, only a '-' will appear in the output, as is the case in our sample output;
      • the problem test - this is Processors - Esx in our example;
      • the problem measure - this is Usage in our example;
      • the alarm description - in the case of our sample, this is: Physical CPU usage of ESX server's processor is high;
      • the problem descriptor (if any); in the case of our example, this is Processor 3. For non-descriptor-based tests, a '-' will appear here.
      • the measurement host - this is 192.168.8.67 in the case of our example
      • the last measurement value - this is not available in the case of our sample. This value will appear in the description only if the Show last measure value in alerts flag in the MAIL SERVER - ADVANCED OPTONS page (Configure -> Mail Settings -> Advanced Settings) is set to Yes.
      StartTime The problem date/time
      Priority The problem severity

      If the Separate execution flag is set to No on the other hand, the script will be executed only once for all alerts raised simultaneously. Given below is an extract from the mailexec.log file, when the Separate execution flag is set to No.

      30/08/2011 12:13:27 USER admin COMMAND echo PARAMS -ComponentType "Microsoft SQL" -ComponentName "sql100:1433" -LayerName "MS SQL Service" -Desc "-|MsSqlNet|Availability|SQL Server unavailable|master|192.168.8.77" -StartTime "Aug 30, 2011 12:10:26" -Priority "Critical" # -ComponentType "Windows" -ComponentName "win77" -LayerName "Windows Service" -Desc "-|WindowsServices|Availability|Service not up|eGAgentMon|win77" -StartTime "Aug 30, 2011 12:10:41" -Priority "Critical" # -ComponentType "Host system" -ComponentName "esx150" -LayerName "Operating System" -Desc "-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67" -StartTime "Aug 30, 2011 12:11:18" -Priority "Critical" # -ComponentType "Host system" -ComponentName "vdi136" -LayerName "Network" -Desc "-|Network - Esx|Availability|Network interface of the ESX server is down|vmnic1|192.168.8.67" -StartTime "Aug 30, 2011 12:11:23" -Priority "Critical" 30/08/2011 12:13:27 INFO -ComponentType "Microsoft SQL" -ComponentName "sql100:1433" -LayerName "MS SQL Service" -Desc "-|MsSqlNet|Availability|SQL Server unavailable|master|192.168.8.77" -StartTime "Aug 30, 2011 12:10:26" -Priority "Critical" # -ComponentType "Windows" -ComponentName "win77" -LayerName "Windows Service" -Desc "-|WindowsServices|Availability|Service not up|eGAgentMon|win77" -StartTime "Aug 30, 2011 12:10:41" -Priority "Critical" # -ComponentType "Host system" -ComponentName "esx150" -LayerName "Operating System" -Desc "-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67" -StartTime "Aug 30, 2011 12:11:18" -Priority "Critical" # -ComponentType "Host system" -ComponentName "vdi136" -LayerName "Network" -Desc "-|Network - Esx|Availability|Network interface of the ESX server is down|vmnic1|192.168.8.67" -StartTime "Aug 30, 2011 12:11:23" -Priority "Critical"

      In this case again, only two lines will be logged in the mailexec.log. The first line will display the USER name, COMMAND syntax, and the command PARAMS (with their corresponding values). Since multiple alerts will be clubbed in the command output, the first line will include the PARAMS for all alerts. '#' (hash) will be used to separate the parameter-value pairs of one alert from the other.

      The second line, which begins with the tag INFO, will display the combined output of all email alerts generated simultaneously - each alert in the output will also be separated by the hash (#) symbol.

      • Note:

      The Separate execution flag setting will take effect only if a user is configured to receive New alarm intimations alone - i.e., if the Type of notification is set to New for a user in the ADD USER page. For users who are configured to receive the Complete List of alarms, details of multiple alarms will always be clubbed in a single script execution, regardless of this flag setting.

    • Specify the maximum permissible length of the command in the Command length text box. The command line here includes the command syntax, its input arguments (if any), and the value of each argument. By default, the command line can have a maximum of 4000 characters. You can alter this default setting by specifying a length of your choice in the Command length text box. If the Separate execution flag is set to Yes, then, if the Command length is violated, the command will be truncated at the end of the parameter value that is closest to the configured Command length. If the Separate execution flag is set to No, then, upon a Command length violation, the command will be truncated at the end of the complete alert specification that is closest to the configured length.

    • Specify a comma-sepatrated list of scripts that will be executed by the eG manager whenever an alert is generated to the user, in the Allowed script types text box. By default, the script types supported by eG are: .exe, .com, .bat, .wav, .wsf, .vbs, .prn, .sh, .perl

      • Note:

      This capability is supported in a redundant eG manager configuration. In case of the redundant manager configuration, if the primary manager is up and running, it will perform script execution. If the primary manager is down for any reason, the secondary manager will perform script execution.

    • Finally, click the Update button.

  12. The eG Manager supports a command line interface, called the TT MANAGER CLI, that can be configured to automatically execute TT (Trouble Ticketing) system-specific commands as and when alarms are added, modified, or deleted in eG Enterprise. This interface offers a way of communication between the eG Manager and a TT system. Use the options provided by the TT MANAGER CLI page to control the behavior of this command line interface. To access this page, click on the TT Manager CLI node in the tree.

    13. Note:

    This section will appear only if the Trouble Ticket Integration capability is enabled by the eG license.

  13. Using the TT MANAGER CLI page, you can configure the following:

    • Set the Enable CLI parameter to Yes to enable this capability.

    • In the Command text box, echo is displayed by default, indicating that the eG manager will execute an echo command by default to communicate with the TT system.

    • The Command Arguments text box displays the default input parameters that the echo command takes during execution. These default parameters are as follows:

      • AlarmId $AlarmId -DATE $DATE -TIME $TIME -Priority $Priority -ComponentType $ComponentType -ComponentName $ComponentName -Layer $Layer -Desc $Desc -Service $Service

      As you can see, each parameter is represented by a qualifier and a variable name. While the qualifier is typically prefixed by a hyphen (-), the variable name is prefixed by a $ symbol. These variables will be substituted by actual values during runtime. Using the qualifiers, you will be able to tell what value follows. For instance, at runtime, the parameter -Priority $Priority could appear as -Priority Critical. This implies that the Priority of the problem is Critical.

      For more details about the TT Manager CLI, refer to the eG Customization Manual.

      • By selecting the required check boxes against Allowed alarms, you can indicate the alarm priorities for which the eG manager needs to execute the specified command.

      • To track the status of the command execution and to troubleshoot issues with the same, use the ttexec.log file that is automatically created in the <EG_INSTALL_DIR>\manager\logs directory. You can specify the maximum size up to which this log file can grow, in the Log file maximum size text box. When the file reaches the specified size limit, the details originally logged in the ttexec.log file will be moved to another log file named ttexec.log.1, and the newer information will be logged in the ttexec.log file instead. This log rotation mechanism helps ensure that the log file does not grow beyond control.

      • You can even indicate the type of information you want logged in the ttexec.log file. By default, the log files capture both the errors and the standard output of the specified Command; accordingly, the Log entries for stdout also flag is set to Yes by default. If you want to capture only the errors, set the Log entries for stdout also flag to No.

      • From the Date format to be used list box, select the format in which the date/time of the problem should be reported in the command output.

      • Specify the maximum permissible length of the command in the Command length text box. By default, the command line can have a maximum of 8191 characters. You can alter this default setting by specifying a length of your choice in the Command length text box. If the actual command length exceeds the specified limit, then the output will not return the list of affected services and the detailed diagnosis information; instead, an empty string will appear next to the -Services qualifier and the -DD qualifier. If the command length continues to exceed the specified limit even after truncating the services list and the DD, the command execution will return an error.

      • Specify the length of the problem description in the Problem description length text box. If the actual problem description exceeds the specified length, the characters that fall beyond the specified limit will be truncated.

      • Finally, click the Update button.

  14. Clicking on the Log Settings node will open the LOG SETTINGS page in the right panel

  15. In the LOG SETTINGS section of this page, the following settings can be defined:

    • The eG manager runs database cleanup operations at pre-configured frequencies. By default, the eG manager logs the details of a cleanup in the cleanup_log file in the <EG_INSTALL_DIR>\manager\logs directory. The details such as when the cleanup started, when it ended, the duration of the cleanup, what was cleaned up, errors during cleanup, etc., are logged, so that administrators are enabled to efficiently troubleshoot issues (if any) during cleanup. If, for some reason, you want to disable this logging activity, set the Log eG database cleanup operations to Yes.

    • Once key reports are scheduled to be emailed to specific recipients, the eG manager, by default, creates a schedule_log file in the <EG_INSTALL_DIR>\manager\logs directory, to which the success/failure of the report scheduling activity is logged. If you do not want to maintain this log file, then you can disable logging of report scheduling activities, by setting the Log the scheduling of reports flag to No.

    • The eG manager, by default, logs the details of the day-end trend activity, so that administrators know when, how, and for how long trending occurred; this information enables administrators to troubleshoot issues with trending. A trend_log file is created in the <EG_INSTALL_DIR>\manager\logs directory for this purpose. However, if need be, trend logging can be disabled, by setting the Log data trending activity flag to No.

    • By default, the eG Enterprise system performs threshold logging - i.e., the ability to record threshold activities in a log file. A thresh_log file is created in the <EG_INSTALL_DIR>\manager\logs directory, to which all threshold-related processes are logged. However, if need be, threshold logging can be disabled, by setting the Log threshold computation activity flag to No.

    • Finally, click the Update button.

  16. To enable the Audit log capability of eG Enterprise, click on the Auditing node in the tree. An audit log can be best described as a simple log of changes, typically used for tracking temporal information. The eG manager can now be configured to create and maintain audit logs in the eG database, so that all key configuration changes to the eG Enterprise system, which have been effected via the eG user interface, are tracked. The eG audit logs reveal critical change details such as what has changed, who did the change, and when the change occurred, so that administrators are able to quickly and accurately identify unauthorized accesses/modifications to the eG Enterprise system.

  17. Clicking on the Auditing node in the tree reveals an AUDITING page in the right panel

  18. Define the following in the AUDITING page:

    • By default, the eG manager does not have audit logging capabilities. To enable the eG manager to perform audit logging, set the Enable auditlog flag to Yes. By default, this flag is set to No.

    • Setting the Enable auditlog flag to Yes will allow you to include/exclude admin CLI (command lineinterface) activities in the eG manager's audit logging purview. The eG Enterprise Suite provides a command-line interface (CLI) which allows any automation tool that pre-exists in the target environment or a script to communicate with the eG manager and execute simple commands on the manager to perform critical configuration tasks. This integration minimizes user intervention in the configuration of the monitoring system. By default, the eG manager also performs audit logging for configuration activities executed via the command line. Accordingly, the Include activities from the admin command line interface flag is set to Yes by default. To ensure that audit logging is not performed for admin CLI activitie, set this flag to No.

    • Finally, click the Update button.

  19. For configuring advanced manager settings, click on the Advanced Settings node in tree. This will result in the display of the ADVANCED SETTINGS page.

  20. You can configure the following in the ADVANCED MANAGER SETTINGS section:

    • You can now restart the eG manager from the eG administrative console itself. To restart the eG manager immediately, set the Restart the manager now? flag to Yes. By default, it is set to No.

    • To enable logging of the errors and output related to the eG manager's activities, set the Manager Output and Error flag to Yes. This automatically creates the managererr.log and the managerout.log files in the <EG_INSTALL_DIR>\manager\logs directory. While the errors are logged in the managererr.log , the output of manager operations is logged in the managerout.log. Using these log files, you can quickly and easily track the status of the eG manager's activities, capture the errors that occur, and analyze the reasons for these errors/failures.

    • Sometimes, after logging manager-related errors and output for a while, you may switch off logging for a brief period, and then switch it back on. Likewise, for some reason, you may decide to restart an eG manager, which is actively logging manager errors and output. In both these cases, new error and output messages will emerge, waiting to be written to the log files that pre-exist. By setting the Output and Error mode flag to Overwrite, you can ensure that the new messages completely replace the existing contents of the log files. Setting this flag to Append on the other hand, ensures that the new messages are only appended to the old contents.

    • Finally, click the Update button.

  21. To enable administrators to easily and effectively study the historical trends in performance and accurately assess future capacity requirements, the eG Reporter offers a dedicated Capacity Planning Reports category. By default, eG Reporter does not allow users to generate Capacity Planning reports. Clicking on the Capacity Planning node will invoke the CAPACITY PLANNING page in the right panel.

  22. To enable the generation of this category of reports, do the following in the CAPACITY PLANNING page:

    • Reports generated using trend data can accurately reveal the past load and performance trends, using which future trends in load and usage can be determined, potential sizing inadequacies predicted, and the future capacity prudently planned. This trend data is typically computed by applying the Avg, Sum, Max, Min, and Percentile functions on the measure data. To enable the eG manager to compute the trend data by applying the aforesaid functions, set the Enable capacity computation by the eG manager flag to Yes. By default, this is set to No.

    • To enable capacity report generation, set the Enable capacity reports flag to Yes. If you do not want to generate any capacity planning reports, then, set this flag to No. If this flag is set to Yes and the Enable capacity computation by the eG manager flag to No, then the eG manager will not compute the Avg, Sum, Max, Min, and Percentile values of the measures, but you can still attempt to generate capacity planning reports. In this case, the Custom and System capacity planning reports, which rely solely on trend data, will not display any results. Also, the Cumulation, Correlation, and Prediction reports can be generated using raw measure data only and not the computed trend data. On the other hand, if both the flags are set to to Yes, then all reports can be generated.

    • Finally, click the Update button.