Monitoring Data: Timing and Interruptions
Monitoring data flows through several segments on the path from client to database. Timing interactions along this path can affect the data. Some segments of this path retain data across interruptions, while others do not retain data.
Best Practice for Intervals
Default values for the monitoring interval and heartbeat interval are a good choice for many applications. If your enterprise needs different values, then for best results set the client monitoring sample interval and the client-server heartbeat interval to identical values.
Client
Most monitoring data begins in a client. Each client gathers data and transfers it to the FTL server in its regular heartbeat messages.
For the most complete results, ensure that the client monitoring sample interval is identical to the client-server heartbeat interval. (You can configure these intervals as global realm properties of the FTL server. However, the monitoring sample interval for persistence servers and TIBCO eFTL servers is fixed.)
If the heartbeat interval is longer than the sample interval, the client accumulates data from several sample intervals, and sends the accumulated samples to the FTL server in the next heartbeat.
If the client cannot communicate with the FTL server, the client retains its monitoring data until it successfully reconnects to the server, then it transfers the accumulated samples. Memory availability could limit the amount of data that a client can accumulate.
When a client stops or restarts, it does not preserve monitoring data it has not yet sent to the FTL server.
FTL Server
The FTL server receives data from clients, and also generates monitoring data that measures its own operations. The FTL server publishes a stream of monitoring data messages on the built-in monitoring endpoint.
As each monitoring sample set arrives from a client, the FTL server immediately publishes it on the monitoring stream. The FTL server also stores the new data samples, overwriting previous data samples for that client.
The FTL server publishes each sample in a separate message.
The monitoring message stream is available only to current subscribers. Subscribers cannot receive any messages that the FTL server sends while a subscribing client is not running, or while the communications link is interrupted. Monitoring data in those messages is no longer available to the subscriber.
You cannot associate a persistence store with the monitoring endpoint.
Gateway
The monitoring gateway service (tibmongateway) subscribes to the monitoring message stream.
As each message arrives, the adapter immediately stores the data in the database and then discards the message.
The gateway cannot receive any messages that the FTL server sends while the gateway is not running, or while the communications link from the FTL server is interrupted. Data in those messages is no longer available to the adapter.
If the gateway service stops, or if communications from the FTL server are interrupted, then the gateway cannot receive any messages that the FTL server sent in the interim. Data in those messages is lost.