To use an instance of CentraSite with webMethods Mediator, you must define a target that identifies the specific webMethods Mediator that you want to use. A target is a registry object that represents a particular instance of a policy enforcement point (in this case, an instance of webMethods Mediator). The target object specifies the address of the Mediator's deployment endpoint, which is the endpoint that CentraSite uses to interact with Mediator to deploy virtual service.
If you use multiple Mediators with an instance of CentraSite, you must create a target for each Mediator. To make the Mediators easier to distinguish when they are viewed in CentraSite, consider adopting a naming convention for targets that clearly identifies to which environment the target belongs (e.g., development, test, production).
Targets are defined by an administrator with "Manage Runtime Targets" permission. Targets are system-wide objects that are shared by all the organizations within an instance of CentraSite.
To communicate with CentraSite, a Mediator must have a user account on CentraSite. You have to establish this user account before you can configure Mediator's connection to CentraSite. Because Mediator reads and writes to certain objects in the registry (such as virtual services), its user account requires a specific set of permissions. These permissions are identified in the Mediator user documentation.
Note:
If you expect a high volume of traffic through a particular Mediator,
consider clustering that Mediator. When you cluster Mediators, the cluster is
represented by a single target within
CentraSite.
webMethods Mediator collects performance data (e.g., average response time, total request count, fault count) for the virtual services that it hosts. It publishes this data to CentraSite at regular intervals. When you install and configure the Mediator, you must specify whether you want it to collect performance data and, if so, how often you want it to publish the data to CentraSite.
We recommend that you always enable the collection of performance data on your Mediator. A publication interval of 15 minutes is appropriate for most environments. However, if the Mediator will handle a very high volume of traffic, consider increasing this interval to 30 or 60 minutes. CentraSite stores the performance data that it receives from the Mediator in the performance log. You can look at the performance information for a particular virtual service by viewing the virtual service's Performance profile.
The performance data that CentraSite collects from Mediator can cause the log to grow quite rapidly. When the log grows very large, queries to the log can significantly affect CentraSite's performance. To prevent this from happening, we suggest that you routinely purge old entries from the log.
CentraSite provides a log-purging utility that you can use to automatically purge the log on a scheduled basis. We suggest that you use this utility to keep no more than one month of performance data in the log (adjust this recommendation as necessary to accommodate your particular needs). When you configure the log-purging utility, you can specify whether you want to delete the purged log entries or export them to an archive file (in case you want to retain them for future reference).
Note:
The performance metrics that Mediator collects enable service
consumers (and potential service consumers) to determine whether a virtual
service is performing at a required level. Mediator does not collect data at
the granularity that a network administrator would need in order to analyze
performance problems (e.g., to determine why the response time for a particular
virtual service drops at a particular time of day). If you need data to support
this level of analysis, consider adding an Insight agent to your Mediator.
In addition to performance metrics, webMethods Mediator can also log event data. Event data supplies information about activities or conditions that occur on Mediator.
Mediator logs two basic kinds of events: 1) data relating to the operation of Mediator itself and 2) data relating to the execution of virtual services.
The event data that Mediator collects about itself are referred to as lifecycle events. These events represent activities or conditions that occur during the general operation of Mediator. Lifecycle events are reported for the completion of significant processes (e.g., Mediator start-up) and the detection of operational exceptions and policy violations. Mediator logs lifecycle events if you configure it to do so.
Mediator collects the following types of event data relating to the execution of virtual services. Be aware that Mediator does not collect this type of information automatically. If you want to capture these types of events, you must deploy run-time policies to do so.
Transaction Events report information about the requests that the Mediator processes. This type of event is produced by the execution of a logging action in a run-time policy. For example, you might configure a run-time policy to log all of the request and/or response messages submitted to a particular virtual service.
Monitoring Events report transgressions relating to performance metrics. This type of event is produced by the execution of a monitoring action in a run-time policy. For example, you might configure a run-time policy to report occasions when the response time for a virtual service exceeds a specified threshold.
Mediator publishes event data as Simple Network Management Protocol (SNMP) traps. When you install Mediator, you can configure it to publish this data to CentraSite, to another third-party SNMP server or to both. If you choose to log event data to CentraSite, you can view the events using the CentraSite Control user interface.
Note:
If you will be logging event data to CentraSite, you must first
configure CentraSite's event listener as described in the section
Run-Time Governance Reference > Run-Time Events and Key Performance
Indicator (KPI) Metrics .
Like the performance log, the event log will grow larger over time. If it becomes very large, queries to the log will cause performance issues with CentraSite. To manage the size of the event log, we suggest that you occasionally purge old entries from it. As a general guideline, consider maintaining only three months of event data in the log. (Adjust this recommendation as necessary to accommodate your particular needs. If you routinely log request and response messages, for example, you might need to purge more often.)
You can configure CentraSite's log-purging utility to purge the event log on a scheduled basis. When you configure the purging facility, you can specify whether you want to delete the purged entries or export them to an archive file (in case you want to retain them for future reference).
Instead of (or in addition to) using webMethods Mediator for mediation and/or policy enforcement, you can use other third-party products with CentraSite. Support for third-party policy-enforcement and run-time governance tools is available through integrations that are provided by members of the CentraSite Community. These tools are made available through the CentraSite Community Web site at http://www.centrasite.org.
Insight is an additional monitoring tool from Software AG that you can use with CentraSite. Insight provides deep visibility and monitoring of services in a heterogenous SOA environment. CentraSite provides support for Insight as a target type out-of-the-box. For additional information about Insight's uses and capabilities, see the Insight user documentation.
