eiDashboard v.20R1
eiDashboard – General Configuration Information
This document is meant to be a technical document for those who wish to understand more about the eiDashboard ecosystem and setup. Installation guides can be found here eiDashboard Windows Installation and here eiDashboard Linux Installation
The eiDashboard (EID) is backed by an eiPlatform (EIP). They work in tandem to retrieve information from other EIP’s and databases to display information on a web page. Some prerequisites of the EID are an accompanying EIP of the same release meaning a 20r1 EID should have a 20r1 EIP as well as a database with the schema from the same release. A monitored EIP does not need to be the same as the EID. However, features of the EID may be limited depending on the capabilities of a monitored EIP. Any upgrades to the database will be available as separate files to allow older DB’s to be upgraded and will be included as separate files. The base schema provided with a version will always be the latest version of the schema. A PostgreSQL schema is the reference database implementation of the EID but PilotFish also maintains the MS SQL Server implementation. Other databases should be able to be used with the EID, however, the implementation of the Routes and Interfaces supporting would need to be modified to reflect any nuances in the chosen databases SQL.
The EID database contains the location/URL of all the EID’s monitored EIP’s. These connections should be stored relative to the EID’s server as requests are relayed from the EID to each EIP. EIP’s are uniquely identified in the EID by their EIP Id, which is based on the system name by default or can be configured in an eipServer.conf file. If EIP’s share the same EIP Id, data stored in the EID’s database will not be able to distinguish the difference between the two. For information on where the EIP Id is set click this link eipServer Configuration Information.
The connection flow of an EID is as follows:
User -> Dashboard Web Site -> User Actions on Dashboard -> Dashboard Servlet -> Dashboard EIP Back-end Interfaces OR Monitored EIP REST API
Describing the above flow in words: An EID should be set up with the idea that it is the centralized hub for all of your individual EIP instances. That is, the EID is the one that does the communicating to the EIP’s and acts as a relay for all of the commands and requests coming from the user in the front end. It manages all of the authentication and views into what a user can see on the front end. Access to EIPs through the EID should be relative to the EID server as the server acts as the relay to the user on the front end, even to the monitored EIP’s RESTful API.
One gotcha when setting up each EIP is that each has its own layer of user authentication and security. These are set up on a per-instance basis (see EIP REST API documentation on how to set up a superuser). Initial logins to an individual EIP will be via a superuser which can then set up additional users in the security tab of the Dashboard.
The EID has the ability to organize and display Transactions logged from individual EIP’s. Transaction logging is enabled on an EIP by toggling logging configuration inside a Listeners Transaction Logging tab (eiConsole configuration). These settings are disabled by default as an attempt to minimize the amount of data being logged. This is because transaction logging has a large impact on performance. Logging can increase the workload and resource requirements of an individual EIP instance by several orders of magnitude depending on the transaction logging settings. It is recommended to only log the information needed for the best performance. EIP’s need to also have the transaction logging Interface installed in it’s running interfaces so that it can insert transactions into the EID’s database. Because the method of insertion to the database is an EIP route, modifications can be made to meet any additional requirements or infrastructure differences.