The FIS Information Hub (InfoHub) is a general-purpose application to gather, store, access, and monitor information. It is a "Hub" because it provides a central location for storing current and historical information from multiple environments and from multiple sources in each environment. InfoHub is "general-purpose" because it can be configured for use by tools via SNMP or any connector API for analytics, trending, and reporting. InfoHub is an application written in GT.M, which drives its monitoring framework and provides an n-tuple key-value datastore to hold information. InfoHub includes a ready-to-run Reference Implementation for monitoring GT.M instances that run V6.0-002 or above.
An InfoHub installation contains one or more of:
InfoHub DB: A database that stores gathered information and manages interaction with Reporting Adaptors.
InfoHub Process: A process that manages the monitoring framework.
Publisher Process: A process that manages a set of related xLine (PipeLine or FileLine) processes, which gather, process, and file data from the Publisher's domain.
FileLine Process: A process that monitors a file continuing to read data as it is appended. The FileLine also tracks the file path in way that handles file renaming, removal and creation. A FileLine is associated with a Publisher.
PipeLine Process: A process that monitors a process using a UNIX pipe (by means of a GT.M PIPE device). A PipeLine is associated with a Publisher.
Subscriber: A specified condition that receives subsciption notifications from the InfoHub; a Subscriber may also provide general query functionality of a Reporting Adaptor.
Subscription: A specified condition that generates a notification to a Subscriber when it is met.
Reporting Adaptor: A process that retrieves information from the InfoHub database; a reporting adaptor, may, or may not, also be a Subscriber.
Gleaner: A plug-in routine invoked by an xLine (PipeLine or FileLine) process. It pairs monitored information with the relevant InfoDict Item ID(s) and returns those pairs to the xLine process for filing in the InfoHub database.
Plug-in: Code that interfaces to the InfoHub logic.
InfoHubs are general-purpose — one InfoHub can monitor multiple data sources, and a single data source can be monitored by multiple InfoHubs. The operations of an InfoHub are data-driven and defined in a text file called InfoHub Configuration File. The InfoHub Configuration File contains a series of descriptors. Descriptors define Publishers that provide information to gather and store in the InfoHub, and Subscriptions for Subscribers to alert based on the information stored in InfoHub. Descriptors also contain information about the environment, sources of data, and the frequency of monitoring (periodic, continuous, or on-demand).
Because it uses character functions for processing external data and only uses byte functions in cases where its internal operation makes them appropriate, an InfoHub can monitor data from sources that rely on ASCII or on various UTF encoding modes. As an application, it can run either in M mode or UTF-8 mode. It does restrict names in its configuration to ASCII, but it can monitor, process and store UTF-8 or UTF16 data.
InfoHub is a GT.M application. Like any other GT.M application, its database can be journaled, recovered, and replicated. An appropriately configured InfoHub using a reference implementation can monitor its own database. InfoHub includes ready-to-run reference implementations: GT.M Monitoring Reference Implementation and Uptime and Log File Monitoring (ULFM) Reference Implementation. For more information on the Reference Implementations available with the InfoHub Distribution, refer to Appendix B: Reference Implementations.
The following illustration is a Reference Implementation of InfoHub for monitoring operator log and WebServer log, and the process output from df and free shell commands. This illustration is only an example to explain a possible InfoHub framework in action. The InfoHub framework setup varies depending on the monitored components and requirements.
In this illustration, the white lines represent process controlled connections used for monitoring and the black lines represent the flow of data. The Instance A Publisher uses gleaners to gather data from the system log, WebServer log, and process output from df and free, to store in the InfoHub database.
The relationship between an InfoHub and an Adaptor is of two types–Subscriber and Query. The red line represents a Subscriber relationship where the Reporting Adaptor registers itself as a Subscriber with the InfoHub. When data arriving at the InfoHub matches a specified Subscription condition, InfoHub places the data in a queue and sends an interrupt (via a configured GT.M trigger) to the Subscriber. The Subscriber then fetches the data from a queue in the InfoHub database where InfoHub placed it before sending the interrupt. If the Subscriber is the last interested Subscriber, it removes the data from the queue.
The black line represents a Query relationship where the Reporting Adaptor retrieves the requested data from the InfoHub repository . The data flows from the InfoHub to the Subscriber, and the entire flow is managed by the Reporting Adaptor - InfoHub is not aware that the Reporting Adaptor exists.
A single Adaptor can have either one or both relationships with InfoHub. The following illustration demonstrates the relationships between InfoHub and Adaptor(s).
![[Note]](../common/images/note.jpg) | Note |
|---|---|
InfoHub runs on GT.M V6.0-002 or above. To monitor log files, InfoHub requires the the FOLLOW deviceparameter which was first introduced in V6.0-002. The FOLLOW deviceparameter enables monitoring of sequential disk files that are concurrently being updated by other processes. The GT.M Monitoring Reference Implementation monitors GT.M V6.0-002 using the $ZPEEK() function, which extracts state information from database/journal files. However, using GT.M programming and shell scripting, it is possible to modify that reference implementation to monitor any GT.M version prior to V6.0-002. Required modifications deal with the format and content of file header listings, messages, and gleaning techniques that vary from release to release. For example, to monitor an earlier release which lacks the $ZPEEK() function, you have to use other techniques, such as parsing DSE output, for example, with a program such as the %DSEWRAP utility. However, you do not need to create an alternative functionality for the FOLLOW deviceparameter because it is available within InfoHub as part of the V6.0-002 and can be used for sequential disk files created by any prior GT.M version. |
InfoHub is not limited to monitoring GT.M applications. Its ability to gather information and interface with other Reporting Adaptors makes it a useful tool for a broad range of monitoring and alerting needs including (but not limited to):
Monitoring of STDERR, STDOUT, STDIN, application and system log files, configuration files, and so on.
Monitoring of processes and system resources.
Alerting Subscribers based on pre-configured conditions.
General-purpose storage and retrieval of time-series data.
