|
MANAGER SETTINGS - GENERAL SETTINGS
This page appears when you click the General Settings node under the MANAGER SETTINGS tree structure that appears when you click the Manager option from the Settings tile.
Using the General Settings section that appears, 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 (mins) 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 (mins). 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. Next, indicate how user logins to the eG management console are to be authenticated. By default, the login credentials of each eG Enterprise user are stored in the eG database. Every time a user attempts to login to the eG management console, their credentials are validated by the eG database. This is why, eG Enterprise is set as the default Authentication provider for login. You can override this default setting by choosing one of the other options, which are as follows:
Active Directory: Select this option if eG Enterprise integrates with Active Directory to authenticate domain user logins to the eG management console. If this option is chosen, then the passwords of domain users will not be stored or maintained by the eG database. Instead, the Active Directory server will be the single point of control and management of the passwords. Every time a domain user/group attempts to login to the eG management console, the eG manager connects to the Active Directory server to authenticate the login. SAML Identity Provider: Select this option if you want eG Enterprise to support Single Sign-On (SSO) via SAML. SAML is an open standard that allows identity providers (IdP) to pass authorization credentials to service providers (SP). If this option is chosen, then eG Enterprise will serve as a service provider (SP) that integrates with an Identity Provider (IP) such as OneLogin, Okta, ADFS etc., to grant authorization to any user who attempts to login to the eG management console. For more details on how to enable SSO for eG Enterprise via SAML, refer to Administrating eG Enterprise document.
Finally, click the Update button to save the changes made.
|