Historian Container Architecture
Historian for Linux is developed using the microservices architecture concept. Microservice architecture is a minimalist approach to modular software development. Modularity is defined as the degree to which a system's components may be separated and recombined.
That is the reason each Historian container performs its unique job and the containers communicate with each other for solving different use cases. For example, the Historian database container is responsible for storing time series data to disk, whereas the REST query is responsible for exposing REST APIs for data query from the Historian database. You can choose to install all or any of these applications.
The following diagram shows the core components of Historian for Linux and how they interact with one another.
Historian for Linux provides the following containerized components:
- Docker 1: Historian Database
- Historian Database is a C++ based native time series archiver based on the Historian archiving engine. The TCP/IP server listens on port 14000 and is configurable using Docker's port map technology.
For information, refer to Historian Database.
- Docker 2: REST Query
- The REST query is a Java-based REST service. It offers REST APIs for data query from the Historian database. It uses the OAUTH2 server for authentication and authorization. The REST query provides REST APIs that are similar to the Predix Time Series data query APIs for querying data. This implies that any analytics application developed using Predix Time Series data query APIs can work seamlessly with Historian for Linux.
For information, refer to Historian REST Query Service.
- Docker 3: Web Admin
- Web admin hosts a web-based admin console for the Historian database. You can view and edit properties and list of tags, list of collectors, and the list of data stores. It is a Tomcat-based web service, which listens on port 9443 and uses the OAUTH2 server for authentication and authorization. It also provides the ability to:
- Start and stop collectors
- Configure collectors
- Browse, add, delete, and rename tags, data stores, and archive files
- View status of the connected collectors
- View the most recently collected data
You can also use a UAA service with web admin.
For information, refer to Historian Web Admin Service.
- Docker 4: Tuner
- Tuner helps you to configure the Historian database properties such data archiving style (daily, hourly, or by size), tag properties (such as collection rate, conditional collection filtering). You must provide these configuration changes in the form of JSON payload in a file. It offers a REST API for uploading JSON file from REST clients to Tuner container. It uses OAUTH2 Server for authentication and authorization filtering.
For information, refer to Historian Tuner.
- Docker 5: The Server-to-Server Collector
- The server-to-server collector streams data from one Historian database (source Historian) to another Historian database (destination Historian) or to Predix time series.
- Docker 6: The OPCUA DA Collector
- The OPCUA DA collector connects to the OPCUA Data Access (DA) server and can collect polled and asynchronous data. It then streams data to the Historian database. This collector can securely connect with the OPCUA DA server with certificate exchange.
For information, refer to Historian OPCUA DA Collector.
- Docker 7: The MQTT Collector
- The MQTT collector connects to MQTT broker and subscribes for topics. The data in the JSON payload must be in the Predix time series format. The collector automatically adds tags and streams data to the Historian database. Because of this collector, Historian for Linux is well integrated with Predix Edge’s data bus for consuming data. Predix Edge’s data bus is an MQTT broker.
For information, refer to Overview of the MQTT Collector.
- Docker 8: Public REST APIs
- Public REST APIs query data from the Historian for Linux archives.
For information, refer to Overview of the Public REST APIs.