Fiorano ESB Server hosts various JMS topics for the ESB Peer Servers to publish information related to application, component and internal state changes. These events are used to keep the ESB Server and the Peer Server synchronized with each other. Events generated within the Enterprise Server are not published to any JMS topic but these can be subscribed to using various other transport protocols. All these events are referred to as control messages within the Fiorano Network.
Custom monitoring applications can be written to subscribe to these control messages so as to monitor the Fiorano Network. In addition, the Fiorano Network can be monitored using the Web Dashboard. This document gives insight of all the necessary details to build one such custom monitoring application in addition to describing the in-built monitoring and reporting capabilities.
Event Types And Subscription
This section describes various kinds of events that are raised in the Fiorano Network. These events are used to perform various tasks such as updating necessary data structures, synchronizing application states, notifying connected clients and so on.
Audit Events
All audit events generated by the Peer Servers are published onto the Enterprise Server topic 'FES_AUDIT_EVENT_TOPIC'. These audit events provide a means of accountability for changes done in the system and also help in detecting a security violation in certain cases.
ApplicationAuditEvent
- ApplicationLifeCycleAuditEvent: This event is raised when there is a change in the Event Process life cycle such as from a stopped to a launched state or vice-versa.
- ApplicationRepositoryAuditEvent: This event is raised when there is a modification in the Event Process Repository such as when changes are made to an Event Process, Deletion of an Event Process, Addition of an Event Process to a repository and so on. This audit event is raised only within the Enterprise Server as the Peer Server does not have an Event Process repository of its own.
ServiceAuditEvent
- ComponentLifeCycleAuditEvent: This event is raised when there is a change in the Component life cycle such as from a stopped to a running state or vice-versa.
- ServiceRepositoryAuditEvent: This event is raised when there is a modification in the component repository of either the Enterprise Server or the Peer Server.
PrincipalStoreSyncAuditEvent
This event is raised when the Peer Server synchronizes its principal store with that of the Enterprise Server.
AuthenticationAuditEvent
This event is raised when the User tries to log on to or create a connection with the Server.
AuthorizationAuditEvent
This event is raised when the User tries to perform an operation that is protected by permissions granted to the User such as looking up a connection factory, creating a JMS connection, launching an event process, changing audit policies, deleting audit events and so on.
SecurityAuditEvent
This event is raised when there is a modification in the security database of the Server such as when there is a new User creation, a User deletion, a group creation, an addition of a member to a group, the granting of specific permissions to a User and so on.
Refer to eMapper section in for detailed description of Audit Events and Audit Functionality as a whole.
Subscribing to Audit Events
To subscribe to audit events generated by any Server, add an Audit Event Listener by performing the following actions:
- Launch the preferred profile in eStudio.
- From he Profile node, navigate to to Fiorano > etc > AuditManager.
- Right-click the AuditManager node and select Add > Add AuditEventListener.
- Provide a fully qualified class name for the audit listener class of this listener and add this class to the Server classpath.
System Events
System Events have an important part to play within the Fiorano System since they determine how the system behaves in a particular situation. All Events are defined in the fiorano.tifosi.dmi.events package present in $FIORANO_HOME/esb/shared/lib/esb-shared-tif-dmi.jar. This section provides a brief explanation of System Events and also describes various ways to subscribe to Events.
Event Description
A brief description of various System Events is as below:
| System Event | Description |
|---|---|
| HAStatusEvent | This Event is launched within the Enterprise Server when there is a change of state of an HA Server such as from the ACTIVE to the STANDALONE state. |
| HARepositorySyncEvent | This Event is launched within Enterprise Server when HA Servers synchronize their databases with each other. |
| UserEvent | This Event is launched within the ESB network by business components whose monitoring configuration has been enabled. |
| ApplicationEvent | This Event is launched by the Enterprise Server when an application is launched, killed, created, saved, or deleted. Application launch and kill events are also handled by the Peer Servers. |
| RouteEvent | The Enterprise Server launches this Event when a debugger is set or removed from a running Event Process. |
| BacklogMonitorEvent | This Event is launched by the Peer Servers when the configured backlog level is reached as defined by the backlog policies active on that Peer Server. |
| LowMemoryEvent | This Event is launched by all Fiorano Servers when they detect that memory usage of a Server has crossed the specified threshold. |
| SBWEvent | This Event is launched by the Peer Servers when a message reaches a port on which document tracking is enabled. On receiving these Events from the Peer Servers, the Enterprise Server stores them into a preconfigured document tracking database. |
| SecurityEvent | The Enterprise Server launches this Event when a User action results in security violations (as determined by the ACL of that particular User in the Enterprise Server such as launching or killing an Event Process or a Service Instance. |
| ServiceEvent | This Event is launched by the Peer Server when a Service Instance is launched or killed. |
| ServiceRepositoryUpdationEvent | The Enterprise Server launches this event when some modification is made to the Service Repository of the Enterprise Server such as registering a new service, addition of a resource to an existing service and so on. |
| SPEvent | The Enterprise Server raises this Event at the time of startup and shutdown. |
| TPSEvent | This Event is launched by both the Enterprise Server and Peer Servers when connecting to/disconnecting from the Enterprise Server. Note: On receiving this Event from a Peer Server, the Enterprise Server synchronizes the states of all Event Processes with the Peer Server. |
Refer to Events Tracking section for detailed description of Audit Events and Audit Functionality as a whole.
Subscribing to System Events
System Events generated within the Peer Servers are published onto various monitoring topics. Users can create subscribers to these topics to listen to the Events generated by the Peer Servers. (See next section for the list of events published onto such topics.)
Note that such a subscriber would not receive events generated within the Enterprise Server, as these Events are not published onto any topic. For listening to Events generated within both the Enterprise Server and the Peer Server using a single application, Users can register an Event listener within the Enterprise Server using the Run Time Library (RTL) APIs. These RTL APIs provide support for subscribing to Events from the Enterprise Server and the Peer Servers such as:
- HAStatusEvent
- HARepositorySyncEvent
- UserEvent
- ApplicationEvent
- RouteEvent
- SBWEvent
- SecurityEvent
- ServiceEvent
- ServiceRepositoryUpdationEvent
- SPEvent
- TPSEvent
An RTL Event Subscriber can listen to all System Events except Backlog and Low Memory Events. To subscribe to these two Events from the Peer Server, create a subscriber for the topic FES_BACKLOG_MONITORING_TOPIC and for the topic FES_SYSTEM_EVENTS_TOPIC along with appropriate message selectors as shown in the next section.
To subscribe to Low Memory Events from within the Enterprise Server, Users need to register a JMX notification listener with the JMX Object identified using the following name:
Fiorano.jmx.notifications:ServiceType=EventManager,Name=ResourceEventManager.
Refer to $FIORANO_HOME/fmq/samples/JMX/JMXNotifications.java for a sample code to register the JMX Notification listener.
Event Topics
System Events from Peer Servers are published onto various monitoring topics present within the Enterprise Server. Each type of Event has a JMS message header property named 'DATA_TYPE' or 'EVENT_TYPE' set to a unique value to distinguish between various Events. This section provides a list of the Event Topics along with the list of Events that are published by the Peer Servers. Please note the different values given for DATA_TYPE/EVENT_TYPE properties of these Events. These values may be used to create message selectors; subscribe to preferred set of Events from an Event Topic.
FES_SYSTEM_EVENT_TOPIC
- Application Event (DATA_TYPE = 302)
- Service Event (DATA_TYPE = 303)
- TPS Event (DATA_TYPE = 305)
- Low Memory Event (DATA_TYPE = 404)
FES_SBW_EVENTS_TOPIC
- SBW Event (DATA_TYPE = 307)
FES_USER_EVENTS_TOPIC
- User Event (DATA_TYPE = 217)
FES_BACKLOG_MONITORING_TOPIC
- Backlog Monitor Event (DATA_TYPE = 403)
FES_AUDIT_EVENT_TOPIC
- Audit Event (EVENT_TYPE = 600)
Sample Subscriber Applications
Please refer to the samples named TopicEventSubscriber.java and RTLEventSubscriber.java located under $FIORANO_HOME/esb/samples/SamplePrograms/EventSubscriber which illustrate the use of APIs to subscribe to various Events. Custom applications can be built around these samples to perform various actions on receiving the Event.
Built-in Event Tracking / Reporting
Using the Fiorano dashboard or the Event Manager tool, you can see various types of System Events raised within the Fiorano Network. As these events are stored into a configurable SQL database, it enables to search for historical events using these tools.
The Event Viewer can be used to view the System Events listed below:
- Application Events
- Service Events
- Security Events
- TPS Events
- SP / Enterprise Server Events
- SBW Events
In addition, FioranoMQ provides built-in support for registering SMTP alerts for various types of System Events. For Backlog and Memory Events, you have a choice to sign up for JMS alerts. Alert registration can be done via dashboard. Refer to sections Server Status and Document Tracking for instructions regarding this.
Alerts can be registered for the System Events listed below:
- Application Events
- Service Events
- Security Events
- TPS Events
- SP / Enterprise Server Events
- Backlog Notification Events
- Low Memory Events
Event Parameters
Various Enterprise Server Level parameters determine whether the Enterprise Server will listen to a particular type of Event and whether these events will be forwarded to RTL clients. These parameters can be configured via Profile Manager in eStudio. The parameters that may be configured, their location and descriptions are as below:
FES > Fiorano > Esb > Events > FESEventsManager
| System Event | Description |
|---|---|
| EnableSystemEventTracking | This parameter determines whether System Events will be inserted into the Events databasefor future reference. By default, this property is enabled. |
| ListenForUserEvents | This parameter determines whether the Enterprise Server will create a subscriber to listen for User Events or not. If RTL clients are to receive User Events, this parameter should be enabled. By default, this property is enabled. |
| RTLToReceiveUserEvents | This parameter determines whether or not User Events captured by the Enterprise Server (given the ListenForUserEvents flag is Enabled) will be forwarded to RTL clients. By default, this property is in disabled state. |
| RTLToReceiveSecurityEvents | This parameter determines whether Security Events raised within the Enterprise Server will be forwarded to RTL clients. By default this property is disabled. |
FES > Fiorano > Esb > Sbw > SBWManager
| System Event | Description |
|---|---|
| EnableDocTracking | This parameter determines whether the SBW Events received by the Enterprise Server will be inserted into the SBW database for future reference. |
| RTLToReceiveSBWEvents | This parameter determines whether the SBW Events captured by the Enterprise Server will be forwarded to RTL clients. This is an expert property specified under the profile node listed above. |
Other Monitoring activities
Measuring Response Time
Each SBW Event captures information of the time the message was tracked. This information can be used to measure the response time of a service by enabling document tracking at both input and output ports of the service. This feature can also be used to measure the time taken for the message to flow from one service to another. In the screenshot below, document tracking has been enabled on the input port of chat1 service and output port of chat2 service. It is possible to view that it took 69 milliseconds for the message to flow from chat1 service to the chat2 service.
Measuring Throughput
Fiorano pre-built components provide functions to enable monitoring via their Custom Property Sheet (CPS) panel. When monitoring is enabled, these components publish information about the messages processed within configured interval in the form of User Events. These events provide information about the number of messages processed within this time. The dashboard can be used to view data both in tabular as well as graphical forms (see screenshot below). Please, refer to Events section for more details.
Service Status Monitoring
Service Events raised by the Peer Server contain information about the current status of the service such as whether the service is running or not. Using the dashboard, you can register to receive SMTP alerts when a particular service within an Event Process is launched or killed. These alerts can be useful in detecting abnormal service termination due to unexpected errors such as a JVM crash or an unintentional shutdown. Please refer to Server Status section for more details.
Messaging Threshold
Using the dashboard, you can create backlog policies and define SMTP/JMS alerts to be sent when a service has more than the specified number of messages in its pending messages queue. You may also create more than one policy for a single service to receive alerts at multiple levels of a pending message queue. For example, registering to receive SMTP/JMS alerts when the size of the pending message queue reaches 5, 10 or 15 either in an upward or a downward direction. Please refer to Monitoring section for more details on Backlog Monitoring feature.
Server Memory Threshold
Using the dashboard, you can create memory usage policies to receive SMTP/JMS alerts when a Server memory reaches the specified threshold. These alerts can be used as a preventive measure to avoid any future issues caused by Out Of Memory problems. Please refer to Document Tracking in for more details.