This section provides miscellaneous information to help you administer Business Transaction Management and includes the following subsections:
The following list describes the ways you can check the status of your system services. The list orders these tasks from high-level to low-level (top to bottom). Each listed task directs you to where you can perform the monitoring and provides a link to more detailed information:
To check:
At-a-glance summary of system services and system alerts
Navigate to Dashboards > Operational Health Summary
Detailed view of all system alerts
Navigate to Alerts in the Last Hour > System Alerts
Current status of a specific system service
Navigate to the specific system service and display the Status tab.
System alerts provide information about the health of the Business Transaction Management infrastructure. Business Transaction Management issues system alerts in situations such as the occurrence a fatal error, a container going down, the rejection of a policy, deletion of an attribute that is in use, and so forth.
Use the Status tab to check the status of the selected Business Transaction Management system service.
The table at the top of the Status tab provides the following information about the service:
Url: The location where Business Transaction Management expects to find the service uuid.
Id: The uuid assigned to the service.
Status: The service status can have one of the following values:
RUNNING - The system service is running and working correctly. For a system service to be RUNNING, all of its associated resources must be accessible and running.
DEGRADED - A resource may be unreachable, but that resource is not mandatory for the system service to operate. It is a good idea to investigate unreachable resources for a degraded service. A re-sync of the system may fix services that are in a degraded state. Degraded services do not trigger alerts to the system log.
FAULTED - A required resource cannot be reached. Typically, a faulted value appears when a database required by the service is down. When a service reaches the faulted state, it is considered unusable. Access is subsequently shut down to the service to prevent errors from cascading throughout the system. A faulted service triggers an alert to the system log. This alert should provide information about how to address the root cause of the problem. A re-sync of the system will not fix services that are in a faulted state. Instead, you need to first address the root cause of the problem, and then restart the Business Transaction Management deployment that contains the faulted service.
SETUP_REQUIRED - A required resource or piece of the system service has not been upgraded. For example, the transaction management component is not connected to a database.
INITIALIZING - A service is in this transient state at the very beginning of its lifetime.
Below the Service Status table is the Resources Status table, which provides status information about other components in the Business Transaction Management environment that are related to the selected service. For example, several system services use databases. The resources section will confirm whether the database is running and working correctly.
The Resources Status table provides the following types of information:
Status: The resource status can have one of the following values:
OK - The resource is running and working correctly.
FAULTED - A required resource cannot be reached.
SETUP_REQUIRED - A required resource has not been upgraded.
Last Access: Time-stamp of when the service last attempted to access the resource.
Last Successful Access: Time-stamp of when the service last accessed the resource. When diagnosing problems using the system log, the time-stamp of the Last Successful Access for a resource is a good starting point.
Another important piece of information included in the Resources Status table is the URL of the sphere service with which the selected system service is associated.
Note:
Resource URLs are displayed either with a dash "-", or with parentheses "()". URLs displayed with a dash represent a resource that can exist only once within an installation, such as the sphere service, whereas URLs displayed with parentheses represent a resource of which there can exist multiple instances, such as a monitor.The sphere is synchronized about every fifteen minutes. You can manually resynchronize the sphere by choosing Admin > Resync System. Resynchronizing ensures that the sphere reflects the current state of your system. Resync System also performs an aliveness check at the same time.
By default, “aliveness” is checked every two minutes to determine whether services are up or down. You can change the time interval for the automatic aliveness check, as described below. (The CLI equivalent for checking aliveness is the configureAlivenessCheck command.
To change the time interval for the automatic aliveness check:
In the Navigator, choose Administration > System Services.
Select AP_Sphere_Service and then choose Admin >Edit Setup Data for AP_Sphere_Service.
Click the Edit XML link.
Find the <AlivenessInterval> element and change its value to the appropriate number of seconds. The default value is 120, or two minutes.
Click Apply.
Business Transaction Management automatically discovers and monitors components, depending on how you have set up the Observer Communication policy. Once a component has been discovered, you can explicitly start and stop the monitoring of its endpoints.
When you start or stop monitoring an endpoint, both the monitor and the observer configurations are updated. Once monitoring stops, no performance measurements are recorded, no messages are logged, and no transactions are traced.
To stop monitoring of an endpoint
Select the endpoint (or the service).
Choose Admin > Stop Monitoring.
The Stop Monitoring tool then opens and lets you select additional endpoints to stop monitoring.
To start monitoring of an endpoint
Select the endpoint (or the service).
Choose Admin > Start Monitoring.
The Start Monitoring tool then opens and lets you select additional endpoints to start monitoring.
Note:
Business Transaction Management can use dependency analysis to discover service endpoints running in unmonitored containers if those endpoints interact with services in monitored containers. You can use theregisterExternalContainer command to define containers for such endpoints.You can explore the registered containers by selecting Explorer > Containers in the Navigator. The summary area then lists all registered containers.
Select a container in the main area to display information about the container on the Profile tab. Open the container's administration console by clicking the URL in the Administration UI Console field. You can edit the container's profile by choosing Modify > Edit Profile for the_selected_container.
To view the services running in a container, select the container and display the Services tab. You can also drill down into the service endpoints running in a container by expanding the container in the main area.
The following list describes the ways you can monitor the health of your containers. The list orders these monitoring tasks from high-level to low-level (top to bottom). Each listed task directs you to where you can perform the monitoring and provides a link to more detailed information:
To check:
Overall current health of all containers
Navigate to Dashboards > Operational Health Summary
Recent history of all container-related problems (in addition to other system-related problems)
Navigate to Alerts in the Last Hour > System Alerts
Current health of a specific container
Navigate to specific container > the Up/Down Status icon in the summary area
There might be times when you want to unregister a container (in other words, remove it from the sphere and the Management Console). For example, if any of the following statements are true, you can, and probably, should unregister the container:
You have registered the container with a different sphere
This situation results if you reconfigure an observer to send observations to a monitor that is registered in a different sphere. In this case, the container in which the observer is running is automatically registered with the other sphere as soon as traffic is observed.
You have uninstalled the observer from the container.
You have uninstalled or physically removed the container from your system.
If none of these statements are true, and you unregister a container, the container will be automatically reregistered as soon as message traffic is observed to or from the container.
Select the container you want to unregister.
Choose Modify > Delete selected_container Registration.
The Delete Registration tool opens.
Click Delete.
System policies are normally used by administrators. Most system policies are not editable. The ones that you can modify allow you do define custom attributes, to configure the connection to the message logging database, to configure discovery, to specify the interval at which measurements are aggregated and collected, and to tell the system what action to take in response to new or changed WSDLs.
This section describes available system policies and explains how you access them, how you view their definition, how you define them, and how you modify them.
You can view system policies by selecting Administration > System Policies in the navigator. The following table lists and describes these policies.
| Name | Description |
|---|---|
| Baseline storage | Supports the derivation and storage of baseline values for endpoints, services, and transactions. |
| Callout Measurement | Supports the measurement and display of average response time, throughput, and fault count for a given link. You cannot edit this policy. |
| Condition measurement | Provides condition alert count and condition alert count rate measurements for a given transaction. You cannot edit this policy. |
| Core Measurement | Supports the calculation of the following counts for a given endpoint and service: average response time, maximum response time, throughput, fault count, traffic, fault percentage, throughput rate, and fault rate. You cannot edit this policy. |
| Data Model Attribute Definitions | Extends custom attributes for services, endpoints, operations, containers, agents, business objects, transactions, and type domains. |
| Default Message Logging Database | Configures the connection to a database used for logging messages. |
| Default Observer Communication Policy | Determines which genres are to be observed and monitored, and specifies the monitor port number. |
| Event Generation Policy | Configures the generation of events based on the occurrence of event notifications. |
| Event Notification Measurement Policy | Used by the notifier service. You can only re-define criteria for this policy. |
| Measurement Interval Policy | Specifies the interval at which measurements are aggregated and collected throughout Business Transaction Management. |
| Service Versioning Policy | Directs the system in what action to take in response to new or changed WSDLs. For more information, see Resolving Discovery Issues. |
| Simple Transaction Measurement Policy | Supports measurement of average response time, maximum response time, completed transaction count, started transaction count, completed transaction rate, started transaction rate for a given transaction.
Business Transaction Management will use either this policy or the Transaction Measurement policy to measure transaction performance, depending on how the transaction is defined and what features are used. You cannot edit this policy. |
| System generated log policy for transaction | Specifies the location for storing transaction messages, the limits on time store, the rotation interval, and defines the scope of logging.
You cannot edit this policy. |
| Transaction measurement | Supports measurement of average response time, maximum response time, completed transaction count, started transaction count, completed transaction rate, started transaction rate for a given transaction.
Business Transaction Management will use either this policy or the Simple Transaction Measurement policy to measure transaction performance, depending on how the transaction is defined and what features are used. You cannot edit this policy. |
| Uptime Measurement | Supports the uptime measurement for a given endpoint and service. You cannot edit this policy. |
| Monitor Group Policy | Creates and configures a monitor agent group. |
To view a system policy definition:
Select Administration > System Policies.
Double click the policy of interest in the main pane.
Click the Profile tab.
To define a system policy:
Select Create System Policy from the Admin menu.
Choose one of the following: Message Log Database, Monitor Agent Group, or Observer Communication.
Specify the information required and click Apply.
When you define a policy, you must supply identifying information: the policy's name and whether it is enabled. You must also supply settings that determine what the policy will accomplish, and criteria that determine to which endpoints (targets) the policy is applied.
Some system policies can only be modified and must be accessed from Administration > System Policies in the navigator.
To modify a system policy
Select Administration > System Policies.
Select the policy of interest in the main area.
Select Modify > Edit definition for policy. If the menu item is not available, the policy cannot be modified.