IANN Monitor Linux Installation
This installation guide provides detailed, step-by-step instructions for setting up the IANN (Intelligent Artificial Neural Network) platform and its associated components. The purpose of this guide is to ensure a smooth and error-free installation process, enabling users to quickly configure the environment and start leveraging the system’s capabilities.
IANN (Intelligent Artificial Neural Network) is Pragma Edge’s AI-powered unified platform designed to bring intelligence, automation, and predictive analytics into business operations. It combines file tracking, monitoring, and AI-driven insights to ensure end-to-end visibility, operational efficiency, and proactive issue resolution
IANN plays a key role in driving digital transformation across industries by turning traditional data exchanges into intelligent, insight-driven processes.
IANN is built as a modular system with three primary components:
This installation guide is designed for a wide range of technical users involved in deploying, maintaining, or supporting IANN solutions. The intended audience includes:
This guide serves as a comprehensive manual for deploying and configuring the IANN platform in various environments (Linux, Windows, OpenShift). It covers the following:
Each section includes detailed prerequisites, component-level configuration, and post-deployment validation steps to ensure successful setup and operation of IANN in production and non-production environments.
This document provides a detailed, step-by-step guide for installing and configuring IANN Monitor 6.4. It ensures the seamless deployment of all core components, including Elasticsearch, Kibana, UI modules, and IANN Monitor agents.
By following this guide, you will be able to:
1. Install and configure the IANN Monitor server components
2. Set up and integrate all necessary client agents
3. Enable essential alerting and monitoring capabilities
Before proceeding, please review the Prerequisites section to verify that your environment satisfies all requirements for a successful installation.
1.1 Context Diagram of IANN Monitor:
The IANN Monitor Context Flow illustrates how the core components within the Monitor module interact with each other and with external systems to deliver real-time monitoring and alerting capabilities. It explains the structure of Monitor and the sequence of operations that enable proactive system health tracking and anomaly detection.
IANN Monitor Context Flow Description:
1. User Interaction & Visualization via IANN Monitor UI:
Users interact with the IANN Monitor UI to visualize real-time alerts and periodic weekly reports. The UI acts as the frontend layer and retrieves data directly from Elasticsearch over port 9200. This enables users to monitor system health, application performance, and recent alert history in an intuitive dashboard.
2. UI Functional Components & Notification Channels
The UI is structured into two major functional components:
Once alerts are processed, they are dispatched via integrated outbound channels:
a. Microsoft Teams via channel email ID
b. Slack via webhook URL
c. Email alerts via SMTP
d. Incident management tools like PagerDuty, X Matters, and ServiceNow using HTTP POST APIs
3. Elasticsearch – Central Data Processing and Storage Layer
Elasticsearch serves as the core data indexing engine. It receives logs and metrics from all connected clients and stores them for analysis and retrieval. It supports both live queries from the UI and backend alert rule evaluation.
All communication with Elasticsearch occurs over port 9200, enabling secure and consistent data ingestion and querying.
4. IANN Monitor Clients – Data Ingestion and Processing Pipeline
The data collection clients are composed of the API Jar and multiple client binaries. These components operate as follows
a. Establish a connection with the SI Oracle Database using port 1521
b. Collect live performance metrics through application endpoints via port 8180
c. Parse and structure the collected data
d. Forward the formatted data into Elasticsearch over port 9200 for storage and monitoring
5. SI Application Integration & Log Monitoring
The SI Application writes logs into the underlying Linux File System.
a. A log monitoring agent continuously scans and parses new log entries
b. Structured log data is pushed to Elasticsearch
Alerts are triggered based on log-based thresholds or anomaly detection rules
Before installing IANN Monitor 6.4, ensure that your environment meets all system requirements and that all required packages, files, and user permissions are in place.
Failure to meet these prerequisites may lead to installation failures or unexpected runtime issues.
The following requirements are mandatory to successfully install and operate the IANN Monitor solution in your environment.
1.1 Deployment Architecture
IANN Monitor requires two Servers, each with specific roles and responsibilities:
Server Role | Description |
Server | Hosts the IANN Monitor UI, Elasticsearch, Kibana, and all supporting UI integrations. |
Client | Deployed on the server where Sterling Integrator is installed. Hosts the IANN Monitor client agents and API JAR module. |
1.2 Operating System Requirements (both servers)
Supported Linux distributions:
1. CentOS 7, 8, or 9
2. Ubuntu 20.04 LTS (or equivalent enterprise-supported distributions)
1.3 IANN Monitor Server and Client Specifications
Instance Type | Components | Cores | RAM | Disk Space |
IANN Monitor Server | Elastic search v.8.X.X or Higher, Kibana v.8.X.X or Higher, UI 6.x | 4 Core | 16 GB | Root-100GB/Application- 300GB |
IANN Monitor Client | API, Appdata, DB healthcheck, Sterlingreports, PCMstats ,queuewatcher,systemstats | 4 Core | 8 GB | Root- 100 GB / Application- 100 GB |
1.4 Product Version Comparison – Prerequisites
Component | 6.3.3 | 6.4.0 |
Supported Databases | Elastic search v.8.X.X | Elastic search v.8.X.X |
OS Requirements | RHEL/CentOS 7, 8, 9; Ubuntu 20.04 LTS |
Same
|
Java Version | IBM Semeru OpenJDK 17.0.8+7 | |
SMTP Config | Required | Required |
SAML Support | Not Available | Optional (Available) |
1.5 Prerequisites
Specific Version | Required | Installation Instructions / Notes | |
Java | IBM Semeru OpenJDK 17.0.8+7 (LTS) | Yes | |
Elasticsearch | Version 8.x.x and above | Yes | Refer to Section 3. Installation Steps in this document |
Kibana | Version 8.x.x and above | Yes | Refer to Section 3. Installation Steps in this document |
1.6 Network & Port Requirements
The following ports must be open and accessible between the IANN Monitor components and any required database or application integrations:
Port | Description | Required On |
9200 | Elasticsearch HTTP/HTTPS | Server |
5601 | Kibana HTTP/HTTPS | Server |
8080 | IANN Monitor UI (default, configurable) | Server |
9090 | IANN Monitor API (default, configurable) | Client |
1.7 Required Packages and Files:
Before proceeding with the installation of IANN Monitor, ensure that the following software packages and security files are available and verified.
File / Package | Description | Source |
IANN_Monitor.zip | Complete IANN Monitor installation bundle | Download from the designated S3 bucket provided by the IANN Monitor Team. |
Security certificates (.crt, .key,.ca-bundle) | TLS/SSL certificates, private keys, and CA bundles are required for secure HTTPS communication. | Supplied by the customer or enterprise security team. |
Note: Ensure these files are present in the target environment with proper ownership and permissions before beginning installation.
1.8 User Permissions:
To install and run IANN Monitor, ensure the following user privileges are in place:
1. The installation must be performed by a user with sudo privileges or equivalent root access for deploying and managing IANN Monitor Server services.
2. The user account running IANN Monitor Client services must have appropriate read, write, and execute permissions for all application directories and log files.
This section outlines the step-by-step procedure for installing and configuring IANN Monitor 6.4. Please follow the instructions carefully to ensure a successful deployment.
Extract Installation Package
Step 1: Once downloaded, unzip the IANN_Monitor.zip file and extract its contents.
unzip IANN_Monitor.zip |
Once extracted, you will find two primary archives under the IANN_Monitor directory:
IANN_Monitor/ ├── IANN _Monitor_ Server.zip └── IANN_Monitor_Client.zip |
2.1 Upload Server Package and Unzip IANN_Monitor_Server.zip
Step 1: Upload IANN_Monitor_Server.zip to the designated Server machine.
The directory path where IANN_Monitor_Server.zip is uploaded will be referred to as <Install_dir> throughout this documentation.
Step 2: From <Install_dir>, run the following command to extract the package:
unzip IANN_Monitor_Server.zip |
Step 3: To set the permissions for the IANN_Monitor_Server directory and all its contents, run:
chmod -R 755 IANN_Monitor_Server |
This ensures:
1. The owner has read, write, and execute permissions.
2. Group and others have read and execute permissions.
Step 4: Navigate into the IANN_Monitor_Server directory by running the below command:
cd IANN_Monitor_Server/ |
IANN Monitor Server Directory Structure
After extraction, the IANN_Monitor_Server directory will contain the following files and folders:
IANN_Monitor_Server/
· IANN_Monitor.jar
· application.yml
· config.ini
· logo.png
· nodata.png
· default_dashboard.zip
· encryptInput.zip
· Heartbeat.zip
· systemstats.zip
· ELK_Start.sh
· server_restart.sh
· teams.zip
· slack.zip
· Weekly_report.zip
· alerts.zip
· send_mails.zip
· shards.zip
Purpose of Each Server Component:
The following table provides an overview of key files and packages included in the IANN Monitor installation bundle. Each component serves a specific role in enabling monitoring, alerting, reporting, and automation functionalities.
Component | Description |
IANN_Monitor.jar | The main IANN Monitor application JAR. |
application.yml | Contains configuration settings for IANN_Monitor.jar. |
config.ini | Configuration file for server agents (database, scheduling, etc.). |
logo.png | Logo image displayed on the IANN Monitor UI. |
nodata.png | Image used in weekly reports to indicate “no data”. |
default_dashboard.zip | Used to create default dashboards in the IANN Monitor application. |
encrypt.zip | Tool for encrypting passwords in your config files. |
Heartbeat.zip | Agent to monitor server and application status (via URL checks). |
systemstats.zip | Agent to collect server metrics like CPU, RAM, disk, and network. |
ELK_Start.sh | Script to restart Elasticsearch and Kibana services. |
server_restart.sh | Script to restart the server agent processes. |
teams.zip | Sends environmental health reports and critical alerts to Microsoft Teams. |
slack.zip | Sends environmental health reports and critical alerts to Slack. |
Weekly_report.zip | Generates and sends automatic weekly reports showing trends. |
alerts.zip | Responsible for managing and processing triggered alerts. |
send_mails.zip | Sends alert notifications by email. |
Shards.zip | Monitors the health and status of Elasticsearch shards. |
2.2 Installing and Setting Up Elasticsearch Without Security Certificates (SSL):
This section guides you through the initial setup and configuration of Elasticsearch.
Step 1: Navigate to the <Install_dir> / IANN_Monitor_Server and Download Elasticsearch
1. Open a terminal and navigate to the Server directory:
cd <Install_dir> / IANN_Monitor_Server |
Download the Elasticsearch 8.12.2 package using the following command:
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.12.2-linux-x86_64.tar.gz |
2. Extract the downloaded archive:
tar -xvzf elasticsearch-8.12.2-linux-x86_64.tar.gz |
3. Navigate into the extracted Elasticsearch directory:
cd <Install_dir> / IANN_Monitor_Server/elasticsearch-8.12.2 |
Step 2: Edit elasticsearch.yml
1. The elasticsearch.yml configuration file is located at:
<Install_dir>/IANN_Monitor_Server/elasticsearch-8.12.2/config/ |
2. Update the following basic configuration settings in elasticsearch.yml file.
cluster.name: “<cluster_name>” network.host: 0.0.0.0 http.port: 9200 discovery.seed_hosts: [“127.0.0.1”] discovery.type: single-node xpack.security.enabled: true |
3. bin folder is located at:
<Install_dir>/IANN_Monitor_Server/elasticsearch-8.12.2/ |
4. Navigate to bin folder using below command:
cd <Install_dir>/IANN_Monitor_Server/elasticsearch-8.12.2/ |
5. Start Elasticsearch in the background using the below command:
nohup ./bin/elasticsearch > /dev/null 2>&1 & |
6. Once started check whether the elasticsearch is running or not using below command:
ps –ef | grep elasticsearch |
7. Verify Elasticsearch is running by checking its default port:
telnet <your public/private ip> 9200 |
Note: <your public/private IP> – This is the host address or DNS of the server running Elasticsearch.
Example: telnet ec2-62-99-71-171.compute-1.amazonaws.com 9200
8. Try accessing Elasticsearch in your browser.
http://<your public or private IP>:9200 |
9. Since we haven’t set up a username and password yet – you can simply ignore authentication.
2.3 Create or Reset the Elasticsearch Username and Password
To Reset the elastic user’s password.
Step 1: Navigate to the bin directory
Use the following command to change to the Elasticsearch installation’s bin directory:
cd <Install_dir>/elasticsearch-8.12.2/bin |
|
Step 2: Run the password reset tool
Execute the password reset script for the elastic user in interactive mode:
./elasticsearch-reset-password -u elastic -i |
Step 3: Follow the prompts
The tool will display:
This tool will reset the password of the [elastic] user. Type y and press Enter to proceed. |
Step 4: Set a new password
You’ll then be prompted to enter a new password twice. Choose a strong, secure password.
Step 5: Verify access via browser
After successfully resetting the password, you can test the login by opening a browser and navigating to:
http://<your-IP>:9200/
When prompted, enter:
Username: elastic
Password: <elasticsearch-password>
Step 6: Expected JSON output
Upon successful login, Elasticsearch will respond with JSON similar to the following:
{
|
2.4 Enable SSL/TLS Encryption (Secure Connection) for Elasticsearch:
Now, to enable SSL/TLS encryption for Elasticsearch Secure access.
Step 1: Edit the elasticsearch.yml file
This file is located at:
<Install_dir>/IANN_Monitor_Server/elasticsearch-8.12.2/config/elasticsearch.yml |
Step 2: Create a certs directory inside the Elasticsearch config folder to store all your security certificates:
mkdir <Install_dir>/IANN_Monitor_Server/elasticsearch-8.12.2/config/certs |
Step 3: Place your certificate files (.crt, .key, .ca-bundle) into this certs directory.
<Install_dir>/IANN_Monitor_Server/elasticsearch-8.12.2/config/certs |
Step 4: Add the following SSL settings to your elasticsearch.yml file:
xpack.security.http.ssl.enabled: true |
Note: Replace <Install_dir>/IANN_Monitor_Server/elasticsearch-8.12.2/config/certs/… with the actual paths to your certificate files.
Step 5: Save the elasticsearch.yml file.
Step 6: Restart Elasticsearch to apply the SSL changes:
Navigate to bin using:
cd <Install_dir>/IANN_Monitor_Server/elasticsearch-8.12.2/ |
And run elasticsearch:
nohup ./bin/elasticsearch > /dev/null 2>&1 & |
Step 7: Finally, verify that secure (HTTPS) access to Elasticsearch is Functional.
1. Open a browser and navigate to:
https://<your-IP>:9200/
2. Log in using:
Username: elastic
Password: <elasticseach_password>
2.5 Install and Configure Kibana
This section guides you through the steps to install, configure, and securely connect Kibana to Elasticsearch, including user creation and SSL configuration.
2.5.1 Extract Kibana
Step 1: Navigate to the Server directory:
cd <Install_dir> / IANN_Monitor_Server
|
Step 2: Download using the below command
wget https://artifacts.elastic.co/downloads/kibana/kibana-8.12.2-linux-x86_64.tar.gz |
Step 3: Extract the kibana.tar.gz archive using the following command:
tar -xvzf kibana-8.12.2-linux-x86_64.tar.gz |
Step 4: Navigate into the extracted Kibana directory:
cd kibana-8.12.2-linux-x86_64 |
2.5.2 Create Kibana User in Elasticsearch
To enable Kibana to communicate with Elasticsearch, create a dedicated user:
Step 1: Find the PID by running:
ps -ef | grep org.elasticsearch.bootstrap.Elasticsearch |
Step 2: Stop Elasticsearch with
kill -9 <pid> |
Step 3: Create the kibanauser with required roles in Elasticsearch
1. To create the Kibana user navigate to the Elasticsearch installation directory using below command
cd <Install_dir>/elasticsearch-8.12.2/ |
2. Run the following command to create the kibanauser with the necessary roles:
./bin/elasticsearch-users useradd kibanauser -p password –r superuser,kibana_admin,kibana_system |
The above command It creates a new user named kibanauser and Sets the password to password.
Step 3: Save this username and password to set them in kibana yaml file for elasticsearch.username and elasticsearch.password in coming section 3.5.4.
Step 4: After creating the user, start Elasticsearch again:
nohup ./bin/elasticsearch > /dev/null 2>&1 & |
2.5.3 Update Kibana Certificates
To enable secure HTTPS communication:
Step 1: Create the certs directory inside the kibana folder using the below command.
1. Navigate to kibana folder using below command:
cd <Install_dir>/ IANN_Monitor_Server/kibana-8.12.2-linux- x86_64/config |
2. Create certs directory inside kibana folder using below command:
mkdir certs |
Step 2: Navigate to the certs folder and upload the security certificate files (.crt, .key, .ca-bundle) into this location
<Install_dir>/ IANN_Monitor_Server/kibana-8.12.2-linux-x86_64/config/certs |
2.5.4 Configure kibana.yml
Edit the kibana.yml file to configure Elasticsearch URL, user credentials, and server host.
Step 1: Navigate to the config folder:
cd <Install_dir>/ IANN_Monitor_Server/kibana-8.12.2-linux-x86_64/config |
Step 2: Update the following configuration:
server.host: “0.0.0.0” server.port: 5601 elasticsearch.hosts: [“https://<elasticsearch-host>:9200“] elasticsearch.username: “kibanauser” elasticsearch.password: “your_kibana_user_password” |
Note: The elasticsearch.username and elasticsearch.password are generated in section 3.5.2
Step 3: Add these lines for server SSL and Elasticsearch SSL verification
server.ssl.enabled: true server.ssl.certificate: /path/to/your/server.crt server.ssl.key: /path/to/your/server.key elasticsearch.ssl.certificateAuthorities: /path/to/your/ca-bundle elasticsearch.ssl.verificationMode: certificate |
Step 4: Update the following settings above lines:
1. server.ssl.certificate with the path to the .crt file located at <Install_dir>/IANN_Monitor_Server/kibana-8.12.2-linux-x86_64/config/certs.
2. server.ssl.key with the path to the .key file in the same directory.
3. elasticsearch.ssl.certificateAuthorities with the path to the .ca-bundle file also found in this directory.
2.5.5 Start Kibana
Step 1: Navigate to bin folder below command.
cd <Install_dir>/ IANN_Monitor_Server/kibana-8.12.2-linux-x86_64/ |
Step 2: Start Kibana using below command.
nohup ./bin/kibana > /dev/null 2>&1 & |
1. Verify Kibana is Running :
Check port 5601:
telnet localhost 5601 OR telnet <your public/private ip> 5601
2. Access Kibana in your web browser
https://<your-IP>:5601/
Log in using:
· Username: elastic
· Password: the password you set during password reset
2.6 IANN Monitor Application Installation
This section covers the configuration steps for the IANN Monitor UI application, including the setup of the application.yml file and the installation of other UI components.
2.6.1 Generating Truststore and Keystore using Security Certificates
The IANN Monitor application uses security certificates to:
1. Enable SSL (so that data sent over the network is encrypted)
2. Securely connect to Elasticsearch (so it can trust the server it is talking to)
To do this, it needs two important files:
1. A keystore, which holds the application’s own certificates used to enable SSL.
2. A truststore, which holds certificates of systems (like Elasticsearch) the application needs to trust.
This section explains how to generate both the keystore and truststore using certificates you have already uploaded to the Elasticsearch folder.
Steps to generate truststore and keystore:
1. Go to the certificates directory
Navigate to the directory where you have placed your SSL certificates using below command.
cd <Install_dir> /IANN_Monitor_Server/elasticsearch-8.12.2/config/certs |
2. Generate the truststore
Run the following command from the certs directory:
keytool -import -file <your_certificate>.crt -keystore truststore.p12 -storepass password -noprompt -storetype pkcs12 |
What does this:
1. keytool is a tool that comes with Java for managing certificates.
2. -import -file <your_certificate>.crt tells it to import your certificate file (replace <your_certificate>.crt with your actual certificate file name).
3. -keystore truststore.p12 creates a new file called truststore.p12.
4. -storepass password sets the password to password (you can change this).
5. -noprompt imports without asking for confirmation.
6. -storetype pkcs12 specifies the format.
3. Generate the keystore
A keystore is used by your application to identify itself (hold its own private key and certificate) so it can enable SSL.
Run this command from the same certs directory:
openssl pkcs12 -export -out keystore-new.p12 -inkey ca.key -in ca.crt -passout pass:password -name “your_alias_name” |
What this does:
1. openssl pkcs12 -export creates a PKCS12 keystore file.
2. -out keystore-new.p12 is the output file name.
3. -inkey ca.key is your private key file.
4. -in ca.crt is your certificate file.
5. -passout pass:password sets the keystore password.
6. -name “your_alias_name” is an alias you give to this entry (replace with something meaningful).
Note:
1. Keep your truststore.p12 and keystore-new.p12 files safe.
2. Remember the passwords you set here — you will use them in your application.yml file.
The IANN Monitor application does not store sensitive values like password in plain text.
Instead, it uses an encryption tool so these values are saved in a secure, encoded format.
For example, instead of writing:
password: mysecretpassword
you’ll store something like:
password: TtjVcSpUPstVC3BYUTbGRrg1+4UKaeZJZd+KUF5mjkA=
This makes it harder for anyone to misuse your passwords even if they get access to your configuration files.
How to encrypt your sensitive values
Step 1: Go to the IANN Monitor installation directory
cd <Install_dir>/ IANN_Monitor_Server/
This is where your encryptInput.zip file is located.
Step 2: Unzip the encryption tool
Run this command to extract the encryptInput.zip file
unzip encryptInput.zip
Step 3: Run the encryption tool
Use this command to start the encryption program:
./encryptInput/encryptInput
Step 4: Follow the prompt to encrypt your value
When you run the tool, it will ask you:
Enter password:
type the value you want to encrypt.
Example :
Enter password: mysecretpassword
It will give you an encrypted string like:
EQHGuVfEHaxJQLfiXSgunZfYfjJqErrPBrmQTdTSuhNUpxG6to8YQOwp8yGqFIg2
The Default Dashboard module in the IANN Monitor application automates the creation of dashboards and alert configurations for a given environment. This significantly reduces the manual effort required during setup and ensures a consistent, ready-to-use monitoring experience from the start — saving time and accelerating customer onboarding.
This default dashboard location needs to be specified in the application.yml file of the IANN Monitor application to enable automatic creation of dashboards and alerts.
Step 1: Before configuring the default_dashboard location in the application.yml file (as shown in later sections), you need to unzip the dashboard files to prepare them for use.
Step 2: To unzip, navigate to default dashboard location
cd <Install_dir> /IANN_Monitor_Server/ |
Step 3: Unzip using below command:
unzip default_dashboard.zip |
2.6.4 Configure application.yml for IANN Monitor Application.
This section explains how to configure the application.yml file for the IANN Monitor application, highlighting the key settings you need to update for proper operation.
Key Sections to Update:
1. SSL: Enable SSL for the IANN Monitor application.
2. Port: Default is 8080. Change this if needed.
3. FileLocation: Path to the default dashboard files, used to auto-create dashboards after installation.
4. timeZone: Defaults to UTC. Change to CST, IST, EST, etc. as needed.
5. defaultUser: Set the default user details like userId, firstName, and lastName.
6. elasticSearch: Configure Elasticsearch credentials — username, password, host, port, and truststore.
7. SMTP: SMTP settings for sending email notifications.
8. Logo: Path to the logo file shown in the application.
9. Saml:SSO and role mappings (if enabled)
Step 1: Navigate to IANN_Monitor_Server Directory:
Navigate to IANN_Monitor_Server Directory using the below command.
cd <Install_dir> /IANN_Monitor_Server/ |
Step 2: SSL and Port Configuration:
To secure data transmission and protect sensitive information, the IANN Monitor application supports SSL.
Below is an example of how to configure SSL and set the server port in your application.yml file.
server:
|
1. Make sure to replace <Install_dir> and <keystore password> with your actual values.
2. Adjust the port if you want the application to listen on a different port.
Note: To encrypt Keystore password refer to – 3.6.2 Encrypting Password
Step 3: FileLocation Configuration:
1. Set the default dashboard path at fileLocation under python.
python: |
Step 4: TimeZone Configuration:
1. By default, the timeZoneFormat under timezone is set to UTC. Change it to CST or your preferred timezone if necessary.
timeZone: |
Step 5: DefaultUser Configuration:
Update the following in defaultUser section:
1. userId: The unique login username for the default admin user (e.g., superadmin).
2. firstName: First name of the user.
3. lastName: Last name of the user.
4. phNo: Contact phone number.
5. emailId: Email address for this user account.
6. status: Keep this as Y to indicate the user is active; otherwise, keep it to N.
7. password: The password the user will use to log in (encrypted in the system after first use).
8. role: The user’s role, typically SUPER_ADMIN for the default administrative user.
defaultUser: |
Step 6: Elasticsearch Configuration:
The Elasticsearch section in your application.yml file is used by the IANN Monitor application to connect securely to your Elasticsearch instance.
It includes all the necessary connection details like credentials, host, port, and truststore for SSL.
Note : To encrypt Elasticsearch and trustore passwords refer to – 3.6.2 Encrypting Password
elasticSearch:
|
What to update:
1. userName: The Elasticsearch username with permissions to read and write data.
2. password: The password for the Elasticsearch user. (Consider encrypting this using the provided encryptInput tool.)
3. hostName: The fully qualified domain name (FQDN) or IP address where your Elasticsearch is hosted.
4. port: The Elasticsearch port. Default is 9200.
5. scheme: Use https for secure connections.
6. trustStore: The full path to your truststore file (.p12), which ensures the application trusts your Elasticsearch server’s SSL certificate.
7. trustStorePassword: The password you set when creating the truststore.(Consider encrypting this using the provided encryptInput tool.)
Step 7: SMTP Configuration:
The spring.mail section in your application.yml file allows the IANN Monitor application to send email notifications.
spring: |
What to update
1. host: Your SMTP server hostname (for example, smtp.gmail.com, smtp.office365.com, or your internal SMTP server).
2. port: The SMTP server port. Usually 587 for TLS/STARTTLS or 465 for SSL.
3. username: The SMTP username used to authenticate (often an email address or SMTP access key).
4. password: The SMTP password or access key. Encrypt this using the encryptInput tool before putting it here.
Step 8: Logo Configuration:
The logoPath setting in your application.yml file specifies the path to the logo image that will be displayed in the IANN Monitor application UI.
logo: |
How to update the logo:
By default, the Pragmaedge logo is used. To replace it with your own brand logo, follow these steps:
1. Delete the existing logo.png file located at:
<Install_dir>/IANN_Monitor_Server/logo.png
2. Upload your desired logo file to the directory:
<Install_dir>/IANN_Monitor_Server/
3. Rename your uploaded file to logo.png.
4. Ensure that logoPath in your configuration points to:
<Install_dir>/IANN_Monitor_Server/logo.png
Step 9: Saml Configuration:
To integrate SAML Single Sign-On (SSO) with the IANN Monitor application.
saml: |
What to update
1. sso-url:
Update this to point to your Identity Provider’s Single Sign-On (SSO) URL.
2. slo-url:
Set this to your Identity Provider’s Single Logout (SLO) URL.
3. idp.metadata:
Upload your IdP metadata XML file to the server (for example, under <Install_dir>/IANN_Monitor_Server/) and update this field with the full path to that file.
4. registration-id:
Change this to the unique registration identifier configured for your SAML integration.
5. idp-groups-role-mapper:
Update this mapping to reflect your IdP groups and their corresponding application roles.
SuperAdmin-SUPER_ADMIN,Admin-ADMIN,BusinessAdmin-BUSINESS_ADMIN,BusinessUser-BUSINESS_USER
The above mapping follows the format:
<SAML IdP Group> – <IANN Monitor Application Role>
Add accordingly based on your setup.
For example:
SuperAdmin-SUPER_ADMIN,Admin-ADMIN,BusinessAdmin-BUSINESS_ADMIN,BusinessUser-BUSINESS_USER
Left side (SuperAdmin, Admin, etc.) are your SAML IdP groups.
Right side (SUPER_ADMIN, ADMIN, etc.) are your IANN Monitor application roles.
Update or add mappings as needed to reflect your organization’s SAML groups and their corresponding application roles
2.6.5 Deploy IANN Monitor Application
Step 1: Navigate to the IANN Monitor JAR directory
go to the folder where your IANN Monitor JAR file is located using the command below.
cd <Install_dir> /IANN_Monitor_Server/ |
Step 2: Start with the default (IANN Monitor) profile using the command below.
nohup java -Dspring.profiles.active=iann_Monitor -jar IANN_Monitor.jar > /dev/null 2>&1 & |
Step 3: If Saml needs to be enabled, Start with the SAML profile (for SSO integration).
1. Find the process id of IANN Monitor application using below command.
ps -ef | grep IANN_Monitor.jar |
2. Kill this pid using below command.
kill –9 <pid> |
3. Start the IANN Monitor Application with saml profile using the command below.
nohup java -Dspring.profiles.active=saml -jar IANN_Monitor.jar > /dev/null 2>&1 &
|
Step 4: If you want to start with performance tuning and custom GC settings:
Follow Step 3 to kill the process and run the below command.
This option runs the IANN Monitor application with optimized memory, garbage collection (GC), and concurrency parameters to improve performance and handle larger workloads efficiently.
nohup java -Xms1536m -Xmx3g -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 \ -XX:ParallelGCThreads=6 -XX:ConcGCThreads=4 -Djava.util.concurrent.ForkJoinPool.common.parallelism=4 \ -Dspring.profiles.active= iann_Monitor \ -jar IANN_Monitor.jar –spring.config=application.yml
|
Step 5: To verify if the jar is running or not:
ps -ef | grep IANN_Monitor.jar |
Step 6: Accessing the Application UI:
1. Once the application has started successfully, open your browser and navigate to:
https://<IP or DNS>:<port>
2. Use the username and password set in application.yml to log in for the first time:
2.7 Send Mails and Alert Configuration:
1. alerts: Monitors for critical and warning conditions, evaluates if any alert thresholds are triggered, and records these alerts in Elasticsearch.
2. send_mail: Retrieves the stored alerts from Elasticsearch and sends alert notification to the configured reporting systems.
2.7.1 Unzip alerts.zip and Send_mail.zip
Step 1: Navigate to the IANN_Monitor_Server directory using the command below.
cd <Install_dir> /IANN_Monitor_Server/ |
Step 2: Unzip the alerts.zip and send_mail.zip packages using the unzip command.
unzip alerts.zip unzip send_mails.zip |
2.7.2 Edit config.ini file for Elasticsearch and SMTP Details
Step 1: Navigate to config.ini using below command:
cd <Install_dir> /IANN_Monitor_Server/ |
Step 2: Update the following sections for Alerts and Send Mail.
[elasticsearch] Section
[elasticsearch] |
Replace <elasticsearch_host> with the hostname or IP address of your Elasticsearch server.
1. Set username to your Elasticsearch username.
2. Update password with your encrypted Elasticsearch password.
3. Confirm port matches your Elasticsearch port (default is 9200).
4. Ensure use_ssl is true if you are using HTTPS.
Note : To encrypt Elasticsearch password refer to – 3.6.2 Encrypting Password
[email] Section
[email] |
1. host: Set this to your SMTP server address (e.g., smtp.office365.com, smtp.gmail.com, or your internal SMTP server).
2. port: Usually 587 for TLS; change if your SMTP provider uses a different port.
3. from: The sender email address that will appear in outgoing emails.
4. username: Your SMTP username (often the email address or an SMTP access key).
5. password: encrypted smtp password.
Note: To encrypt Elasticsearch password refer to – 3.6.2 Encrypting Password
2.7.3 Start Alerts and Send Mail Agents
Step 1: Start the alerts and send mail agents from their respective locations:
nohup ./alerts/alerts > /dev/null 2>&1 & nohup ./send_mails/send_mails> /dev/null 2>&1 & |
Step 1: Verify that the agents are running by checking their process status:
ps -ef | grep alerts ps -ef | grep send_mails |
Step 2: Check the agent logs for any errors or exceptions, and validate the log timestamps against the current time:
tail -f alerts.log tail -f send_mail.log |
Note: You might notice “index not found” errors in the alerts.log and send_mail.log files. This is expected because no dashboards have been created yet in the IANN Monitor. You can safely ignore these errors for now—they will disappear once the dashboards are set up.
2.8 Configure Heartbeat and System Stats
Heartbeat:
Heartbeat monitors the health and availability of servers and applications by regularly checking their status through configured URLs. It ensures that critical services are up and running, and promptly detects any downtime or connectivity issues.
Systemstats:
Systemstats collects key server metrics, including CPU usage, memory (RAM) utilization, disk space consumption, and network activity. This helps in continuously tracking the resource performance and capacity of the server infrastructure.
Step 1: Navigate to config.ini using below command:
cd <Install_dir> /IANN_Monitor_Server/ |
This section outlines the configuration and startup of the Heartbeat and System Stats agents.
Step 2: Update the following sections for elasticsearch,Hearbeat and Systemstats
[elasticsearch] – section:
index = iann_test_qa |
What to Update
1. index = <index_prefix>
Add this line in the [elasticsearch] section of your configuration.
The index_prefix determines the prefix used when creating all indexes in Elasticsearch. This is helpful for separating environments in the IANN Monitor application.
For example:
index = iann_test_qa
This means all indexes created in Elasticsearch will start with iann_test_qa, making it easy to identify and manage them by environment (like iann_test_prod, iann_test_dev, etc.).
[heartbeat] – section:
[heartbeat] |
What to Update
1. ip = [“<IP>:Server Name”]
Specify the server IP address and its name.
For example:
ip = [“127.0.0.1:1:WebServer1”, “127.0.0.2.11:DatabaseServer”, “127.0.0.1.12:CacheServer”]
2. urls = [“url:Application Name”]
Provide the application URL along with a descriptive name.
For example:
urls = [“https://webapp.company.com:WebApp”, “http://api.company.com:APIService”, http://auth.company.com:AuthService]
3. schedule_heatbeat_seconds = 60
This sets how often (in seconds) the heartbeat checks run. The default is 60 seconds, but you can update it if you want health checks to run more or less frequently.
[systemstats] – section:
[systemstats] |
What to Update
1. schedule_system_stats_seconds = 300
This sets how often (in seconds) the system statistics are collected. The default is 300 seconds (i.e., every 5 minutes). You can change this value to run the checks more or less frequently, for example schedule_system_stats_seconds = 120 to collect stats every 2 minutes.
2. os = linux
Specify the operating system of the servers being monitored. For example:
os = linux for Linux servers, or os = windows for Windows servers.
3. environment = general
Label the environment type for easier identification in logs and dashboards. For example:
environment = production, environment = staging, or environment = general.
2.8.1 Start Heartbeat and Systemstats
Step 1: Navigate to config.ini using below command:
cd <Install_dir> /IANN_Monitor_Server/ |
Step 2: Unzip Heatbeat and Systemstats using commands below:
Unzip Heartbeat.zip Unzip systemstats.zip |
Step3 : Start the alerts and send mail agents using the commands below.
nohup ./Heartbeat/Heartbeat > /dev/null 2>&1 & nohup ./systemstats/systemstats > /dev/null 2>&1 & |
Step 4: Verify Status using the commands below.
ps -ef | grep Heartbeat ps -ef | grep systemstats |
Step 5: Check the agent logs for any errors or exceptions, and validate the log timestamps against the current time:
tail -f Heartbeat.log tail -f systemstats.log |
|
2.9 Shards Usage
This section explains how to configure the IANN Monitor component to monitor the shard usage of Elasticsearch. Proper shard monitoring setup helps maintain cluster health, ensures balanced data distribution, and supports optimal search and indexing performance.
Step 1: Navigate to IANN_Monitor_Server using below command:
cd <Install_dir> /IANN_Monitor_Server/ |
Step 2: Update the following section in config.ini
[shards_interval] |
What to Update
1. shards_interval_seconds = 300
This sets how often (in seconds) the IANN Monitor checks Elasticsearch shard usage.
For example:
shards_interval_seconds = 300
means shard usage will be monitored every 5 minutes.
Step 1: Navigate to IANN_Monitor_Sercer using below command:
cd <Install_dir> /IANN_Monitor_Server/ |
Step 2: Unzip the shards_monitor.zip using command
unzip shards.zip |
Step 3: Start the shards agent using the commands below.
nohup ./shards/shards /dev/null 2>&1 & |
Step 4: Verify Status
ps -ef | grep shards |
Step 5: Check the agent logs for any errors or exceptions, and validate the log timestamps against the current time:
tail –f Elasticsearch_shards.log |
2.10 Teams and Slack Configuration
1. Teams: Sends a summary of the overall environmental health along with the top critical alerts triggered in the environment to the designated Teams channel.
2. Slack: Sends a summary of the overall environmental health along with the top critical alerts triggered in the environment to the designated Slack channel.
Note: Make sure to configure these settings and start the teams and slack agents after your client agents have started to avoid index not found errors.
This section describes how to configure notifications for Microsoft Teams and Slack.
Step1: Navigate to config.ini using below command:
cd <Install_dir> /IANN_Monitor_Server/ |
[teams_alerts] – section:
[teams_alerts] |
What to Update:
1. from = <sender_email>
Specify the sender email address used to post notifications to Microsoft Teams.
For example:
from = alerts@company.com
Note: This email user should be part of the Teams channel where you want these notifications to be delivered.
2. queuedepth_threshold = <number>
Sets the threshold for queue depth. An alert will be triggered when this limit is crossed.
For example:
queuedepth_threshold = 200
3. url_heartbeat_index = {“<environment>”:”<index_prefix>_url_heartbeat-“}
4. Map each environment name to its corresponding heartbeat index pattern. For example: url_heartbeat_index = {“uat”:”uat_url_heartbeat-“}`
5. system_heartbeat_index = {“<environment>”:”<index_prefix>_system_heartbeat-“} Map each environment name to the system heartbeat index pattern. For example: system_heartbeat_index = {“uat”:”uat_system_heartbeat-“}`
6. iann_monitor_UI_url = <iann_monitor_application_url>
Provide the URL to access the IANN Monitor application.
For example:
iann_monitor_UI_url = https://monitor.company.com/#/login
7. server_metrics = {“<environment>”:[“<server_name>;<metrics_index_pattern>”]}
Define the mapping of environment to server name and metrics index.
For example:
server_metrics = {“uat”:[“AppServer1;uat_metrics_general-*”, “DBServer1;uat_db_metrics-*”]}
Here, AppServer1 is the server name and uat_metrics_general-* is the index pattern where its metrics are stored.
2.10.1 Start Teams and Slack
Step 1: Navigate to config.ini using below command:
Step 2: Unzip Teams and Slack using commands below:
Unzip slack.zip Unzip teams.zip |
Step 3: Start the Teams and Slack agents using the commands below.
nohup ./ teams/teams > /dev/null 2>&1 & nohup ./ slack/slack > /dev/null 2>&1 & |
Step 4: Verify Status using the commands below.
ps -ef | grep slack ps -ef | grep teams |
Step 5: Check the agent logs for any errors or exceptions, and validate the log timestamps against the current time:
tail -f IANN_MONITOR_SLACK.log tail -f IANN_MONITOR_TEAMS.log |
2.11 Weekly Report Configuration
The weekly report offers a high-level overview of how your systems and applications are performing, highlighting average daily usage metrics. It is automatically generated every week to help you track trends and identify any areas that may need attention.
Note: Make sure to configure these settings and start the weekly report after your client agents have started to avoid index not found errors.
This section describes how to configure Weekly Reports config.ini file.
Step 1: Navigate to config.ini using below command:
cd <Install_dir> /IANN_Monitor_Server/ |
Make sure to update the following sections:
[Environment_Type]- section
[Environment_Type] |
What to Update
1. vm = true
Set this to true if you are monitoring a VM environment.
2. openshift = false
Set this to true if you are monitoring an OpenShift environment; otherwise keep it false.
3. lightwell_metrics = false
Set this to true if you want to include Lightwell metrics in the weekly reports.
For example:
lightwell_metrics = true
4. environment
This must be manually updated after you create the environment in the UI.
For example:
environment = my_environment
5. environment_prefix = iann_monitor_test
This should match the index prefix set in your [elasticsearch] section.
For example:
environment_prefix = iann_monitor_test
6. timezone = Asia/Kolkata,IST
Set to your local timezone for accurate timestamps.
For example:
timezone = Asia/Kolkata,IST
7. pdf_name = <name_for_pdf_reports>
Sets the base name for the generated PDF reports.
For example:
pdf_name = system_health_report
8. pragmaedge_image_path = <logo_file>
Provide the image file (logo) path that will appear in your PDF reports.
For example:
pragmaedge_image_path = company_logo.png
[weekly_report_vm] – section
[weekly_report_vm]
“Database Server Metrics”: “envprefix_dbserver_metrics-*”} |
What to Update
1. Update headings and index name in serverdetails.
2. “App Server Metrics” is the heading that will appear in your PDF report for this server
3. “envprefix_appserver_metrics-*” is the Elasticsearch index pattern where this server’s metrics are stored.
[email] – section
Add the line below under the email section to send the weekly report to the specified email address:
to = receiver@email.com
[weekly_report_openshift] – section
No need to configure [weekly_report_openshift] since this is not an OpenShift environment.
Step 1: Navigate to config.ini using below command:
cd <Install_dir> /IANN_Monitor_Server |
Step 2: Unzip Weekly_report using commands below:
Unzip Weekly_report.zip |
Step 3: Start the Weekly_report agents using the commands below.
nohup ./ Weekly_report/Weekly_report > /dev/null 2>&1 & |
Step 4: Verify Status using the commands below.
ps -ef | grep Weekly_report |
Step 5: Check the agent logs for any errors or exceptions, and validate the log timestamps against the current time:
tail -f weekly_report.log |
2.12 Configure Auto-Restart of IANN Monitor Server Applications
This section describes two supported methods to configure automatic restarts for critical IANN Monitor components such as Elasticsearch, Kibana, and UI services. You can choose between a cron-based approach or systemd-based service management depending on your environment and system preferences.
2.12.1 Auto-Restart Using Crontab
This method uses scheduled cron jobs to monitor and restart applications if they are not running.
Step 1: Navigate to the Server Directory
cd /IANN_Monitor_Server/ |
This directory contains two key scripts:
1. Start_ELK.sh – Manages Elasticsearch and Kibana
2. server_restart.sh – Manages UI and API JAR restarts
Step 2: Schedule Cron Jobs
To create scheduled tasks that check and restart applications every minute:
1. Open the crontab editor:
crontab –e |
2. Add the following entries, adjusting <Install_Dir> as needed:
*/1 * * * * /<Install_Dir>/IANN_Monitor_Server/Start_ELK.sh /<Install_Dir>/IANN_Monitor_Server >> /<Install_Dir>/IANN_Monitor_Server/elk_restart_beat.log 2>&1
*/1 * * * * /<Install_Dir>/IANN_Monitor_Server/server_restart.sh /<Install_Dir>/IANN_Monitor_Server >> /<Install_Dir>/IANN_Monitor_Server/server_restart_beat.log 2>&1
|
Step 3: Verify Cron Configuration
To confirm the cron jobs have been scheduled correctly:
crontab -l |
2.12.2 Verification (Crontab Method)
Once configured, the system will check every minute if Elasticsearch, Kibana, and UI services are active. If any of them are down, the respective script will trigger a restart automatically.
This section outlines the steps for deploying the IANN Monitor client components and configuring their respective beats.
The client server will be the same server where Sterling Integrator is installed. Ensure that all client agents are uploaded to this server before you begin the configuration (section 4.2).
IANN Monitor Client Directory Structure
After extraction, the IANN_Monitor_Client directory will contain the following files and folders:
IANN_Monitor_Client/
· IANN_Monitor_API.jar
· application.yml
· config.ini
· appdata.zip
· Database_Healthcheck.zip
· sireports.zip
· pcm_stats.zip
· queuewatcher.zip
· systemstats.zip
· silogparser.zip
· ssp_heartbeat.zip
· Ian_monitor_beats_start.sh
· run_iann_monitor_beats_start.sh
Client Components & What They Collect:
File Name | Description |
IANN_Monitor_API.jar | Contains the client-side backend jar that connects to the SI database. |
application.yml | This defines the Sterling Integrator (SI) database details, allowing the IANN_Monitor_API to connect to the database. |
config.ini | The main configuration file where all parameters (database connection, environment type, schedules, etc.) are set. |
appdata.zip | Collects multiple Sterling Integrator metrics and statuses, including service times, mailbox depth, adapter health, halted processes, and scheduler info. |
Database_Healthcheck.zip | Collects detailed database health metrics such as IOPS, throughput, latency, sessions, locks, and tablespace usage. |
sireports.zip | Gathers BP (business process) metrics and SI certificate details, including long-running BPs, trusted certs, and execution distribution across nodes. |
pcm_stats.zip | Executes application reference queries for PCM application insights. |
queuewatcher.zip | Collects QueueWatcher data including heap usage, non-heap usage, active threads, and queue depth. |
systemstats.zip | Gathers core server metrics like CPU, RAM, Disk, and Network utilization. |
silogparser.zip | Scans Sterling Integrator logs (silogs) for errors. |
ssp_heartbeat.zip | Checks the status and availability of the SSP (Secure Proxy) application. |
ian_monitor_beats_start.sh | Lists the paths to all agent start scripts and Works like a config file to tell which agents to start. |
run_iann_monitor_beats_start.sh | Reads these paths from ian_monitor_beats_start.sh and Restarts the agents to keep them running continuously. |
3.1 Upload Client Package and Unzip IANN_Monitor_Client.zip
Step 1 : Upload IANN_Monitor_Client.zip to the designated Server machine.
The directory path where IANN_Monitor_Client.zip is uploaded will be referred to as <Client_Install_dir> throughout this Client deployment.
Step 2: From < Client_Install_dir>, run the following command to extract the package:
unzip IANN_Monitor_Client.zip |
Step 3: To set the correct permissions for the IANN_Monitor_Client directory and all its contents, run:
chmod -R 755 IANN_Monitor_Client |
This ensures:
1. The owner has read, write, and execute permissions.
2. Group and others have read and execute permissions.
3.2 Configure application.yml and Deploy IANN_Monitor_API.jar
Step 1: Navigate to IANN_Monitor_Client using the command below.
cd < Client_Install_dir>/IANN_Monitor_Client |
Step 2: update the application.yml to define API port and database connectivity details
server: |
Details to update in your application.yml:
1. Port:
This is the HTTP port on which your Spring Boot application will run.
Example:
server.port = 8180
2. URL:
This is the JDBC connection URL that tells your application how to connect to the database.
You will need to update:
1. Host: the database server hostname or IP
2. Port: the port number on which your database is listening
3. Database Name: the name of your database or service
4. Schema: the schema application will be used.
This table show how the JDBC URL differs for each supported database. Adjust the URL accordingly for the Sterling Integrator database.
DB Type | Example JDBC URL Format |
Oracle | jdbc:oracle:thin:@host:port/service?currentSchema=schema |
DB2 | jdbc:db2://host:port/database:currentSchema=schema; |
SQL | jdbc:sqlserver://host:port;databaseName=database;schema=schema; |
3. Username:
This is the database username that your application will use to connect to the database.
Example:
username = my_db_user
4. Password:
This is the encrypted password for the database user specified above.
Note: To encrypt password refer to – 3.6.2 Encrypting Password
Example:
password = my_db_password
5. driver-class-name:
Update the driver class name as per the table below.
DB Type | Driver Class |
Oracle | oracle.jdbc.OracleDriver |
DB2 | com.ibm.db2.jcc.DB2Driver |
SQL Server | com.microsoft.sqlserver.jdbc.SQLServerDriver |
Step 3: Start IANN_Monitor_API jar by using the below command.
nohup java -Xms1g -Xmx8g –jar IANN_Monitor_API.jar /dev/null 2>&1 & |
-Xms : sets the initial heap size (memory allocated at JVM startup)
-Xmx : sets the maximum heap size (upper limit for JVM heap memory)
Step 4: Check status of the jar by running below command.
ps -ef | grep IANN_Monitor_API.jar |
Step 5: Check the jar logs for any errors or exceptions, and validate the log timestamps against the current time.
tail -f IANNMonitor-api.log |
3.3 Configure Client Agents using Config.ini.
The config.ini file is required for all agents. It provides essential configurations such as Elasticsearch connection details, Client DB Connector settings, and scheduling intervals for collecting various data points. This ensures that the agents know where to send the collected data, how to connect to the database, and how frequently to gather each type of metric.
Make sure to make the following changes in the config file by following the steps below.
1. Elasticsearch Configuration [elasticsearch]
2. appdata Configuration [appdata]
3. Database Health Check Configuration ([db_healthcheck])
4. Sterling Reports Configuration ([sterling_reports])
5. PCM Stats Configuration ([pcm_stats])
6. Queue Watcher Configuration
7. Systemstats configuration([systemstats])
8. Silogparser Configuration([silogparser])
9. SSP Configuration ([ssp])
Step 1: Navigate to IANN_Monitor_Client using the command below.
Step 2: Open the config.ini file to update the required settings.
Step 3: Configure Elasticsearch settings.
[elasticsearch] index = <index_prefix> url = <elasticsearch_url>:<elasticseach_port> port = <elasticsearch_port> username = <elasticsearch_username> password = <encrypted_elasticsearch_password> use_ssl = false os = linux |
In the [elasticsearch] section of your config.ini, you only need to
update the following fields:
index, url, port,username, and password.
1. Index – This is the index prefix used to differentiate Elasticsearch indices across various environments.
Example : index = iann_test_qa
2. Url -This is the complete HTTPS URL (or HTTP if SSL is not used) to reach your Elasticsearch cluster.
Example : url = https://0.0.0.120:9200/
3. Port – This is the network port on which your Elasticsearch instance is listening.
Example: port = 9200
4. username – The Elasticsearch username that the agent will use to authenticate.
Example: username = elastic_user
5. password – The encrypted password for the Elasticsearch user.
Example: password = DTwZ0UoOt056TyX4hxQAb5h4=
Note: To encrypt password, refer to – 3.6.2 Encrypting Password
Step 4: Configure appdata settings.
[appdata] |
In the [appdata] section of your config.ini, you only need to update
apihost,jarvis_username, jarvis_password, db_type,list,adapter_list,service_list,schedulers_list
1.api_host:
The api_host IANN_Monitor_API.jar to which the agents connect to and fetch the data.
Example:
api_host = http://apiurl:9090
2.jarvis_username & jarvis_password :
Credentials to authenticate with the IANN_Monitor_API.
Set default username – jarvis
Set the default password to ‘password’ and ensure it is encrypted.
Note : To encrypt password refer to – 3.6.2 Encrypting Password
Example:
jarvis_username = jarvis
jarvis_password = 8o3DjuRtTlvaqzbehivjk75p
3.db_type:
Specify the database type used by Sterling Integrator:
1. Use db2 for DB2,
2. oracle for Oracle,
3. and sql_server for SQL Server
Example:
db_type = DB2
4. list, adapter_list , service_list, schedulers_list:
List – A list of mailboxes or directory paths that need to be monitored.
Example:
list = (‘/ceuroot/AL875′,’/abc’)
adapter_list – A list of adapters that should be monitored.
Example:
adapter_list = (‘FileAdapter’,’FTPAdapter’)
service_list – A list of BP (Business Process) services to be monitored.
Example:
service_list = (‘OrderProcessingService’,’InvoiceGenerationService’)
schedulers_list -A list of schedulers that need to be monitored.
Example:
schedulers_list = (‘NightlyCleanupScheduler’,’DataSyncScheduler’)
5. mailbox_long_running_morethan_mins:
mails running more than the time configured here are monitored.
Example: mailbox_long_running_morethan_mins = 5
6. Scheduling:
Configure the schedule for the following data points so that the agent collects data at the specified intervals.
scheduled_seconds, external_perimeter_seconds, adapter_status_seconds, halted_count_seconds, halting_count_seconds, interrupted_count_seconds, waiting_count_seconds, waiting_on_io_count_seconds, active_count_seconds, archive_seconds, index_seconds, purge_seconds, app_availability_time_seconds, schedulers_status_seconds, run_time_of_service_seconds, adapter_uptime_status_seconds, bp_status_seconds, non_index_seconds, mailbox_long_running_seconds, document_processed_seconds, db_usage_seconds, get_mailbox_depth_seconds
Example:
scheduled_seconds = 300
external_perimeter_seconds = 60
adapter_status_seconds = 60
halted_count_seconds = 300
halting_count_seconds = 300
interrupted_count_seconds = 300
waiting_count_seconds = 300
waiting_on_io_count_seconds = 300
active_count_seconds = 300
archive_seconds = 300
index_seconds = 300
purge_seconds = 300
app_availability_time_seconds = 300
schedulers_status_seconds = 300
run_time_of_service_seconds = 300
adapter_uptime_status_seconds = 300
bp_status_seconds = 300
non_index_seconds = 300
mailbox_long_running_seconds = 300
document_processed_seconds = 300
db_usage_seconds = 300
get_mailbox_depth_seconds = 300
7. Metrics Toggles:
Enable or disable monitoring of specific data points.
If set to true, the agent will monitor and collect data for that metric.
If set to false, the agent will skip monitoring that data point.
Metrics toggles to configure:
Waiting_count_version, Halted_count_version, archive, index, purge, get_mailbox_depth_query, get_mailbox_ref_query, document_processed, db_usage, mailbox_long_running, run_time_of_service, adapter_status, adapter_uptime_status, halted_count, halting_count, interrupted_count, waiting_count, waiting_on_io_count, Purge_count, app_availability_time, schedulers_status, Non_index, Bp_status, get_mailbox_depth, active_count
Example:
Waiting_count_version = false #(Set waiting count version to true if SI version is 6.2 for waiting counts else false)
Halted_count_version = false #(Set halted count version to true if SI version is 6.2 else false)
archive = true
index = true
purge = true
get_mailbox_depth_query = false
get_mailbox_ref_query = true
document_processed = true
db_usage = true
mailbox_long_running = true
run_time_of_service = true
adapter_status = true
adapter_uptime_status = true
halted_count = true
halting_count = true
interrupted_count = true
waiting_count = true
waiting_on_io_count = true
Purge_count = true
app_availability_time = true
schedulers_status = true
Non_index = false
Bp_status = false
get_mailbox_depth = true
active_count = false
external_perimeter=true
Step 5: Configure sterling_reports settings.
[sterling_reports] large_bp_steps=3000 |
1.Scheduling:
Configure how often (in seconds) the agent collects each of these data points.
trusted_certs_seconds, ca_certs_seconds, system_certs_seconds, no_execution_per_node_seconds, bp_records_per_month_seconds, bp_with_large_bp_steps_seconds, bp_runs_bp_steps_seconds, bp_definition_details_for_si_seconds, long_running_bp_steps_seconds, long_running_bp_seconds, long_bp_steps_time_seconds, long_bp_time_seconds
Example:
trusted_certs_seconds = 60
ca_certs_seconds = 60
system_certs_seconds = 60
no_execution_per_node_seconds = 60
bp_records_per_month_seconds = 60
bp_with_large_bp_steps_seconds = 60
bp_runs_bp_steps_seconds = 60
bp_definition_details_for_si_seconds = 60
long_running_bp_steps_seconds = 60
long_running_bp_seconds = 60
long_bp_steps_time_seconds = 60
long_bp_time_seconds = 1800
2. Metrics Toggles:
Set to true if you want the agent to monitor these data points.
If set to false, the agent will skip collecting them.
ca_certs, system_certs, long_running_bp_steps, long_running_bp, bp_definition_details_for_si, system_cert, ca_cert, trusted_cert, bp_runs_bp_steps, no_execution_per_node, bp_records_per_month, bp_with_large_bp_steps, trusted_certs
Example:
ca_certs = true
system_certs = true
long_running_bp_steps = true
long_running_bp = true
bp_definition_details_for_si = true
system_cert = true
ca_cert = true
trusted_cert = true
bp_runs_bp_steps = true
no_execution_per_node = true
bp_records_per_month = true
bp_with_large_bp_steps = true
trusted_certs = true
3. large_bp_steps:
IANN Monitor will track BPs that have 3000 steps or more, based on the value set in large_bp_steps
Example:
large_bp_steps=3000
Step 6: Configure db_healthcheck settings
[db_healthcheck] |
1.Scheduling:
Configure how often (in seconds) the agent collects each database health metric.
Scheduling keys:
read_iops_seconds, inactive_sessions_seconds, total_sessions_seconds, database_check_seconds, database_locks_seconds, db_response_time_seconds, top_tables_seconds, mailboxes_with_unextracted_messages_seconds, no_of_messages_extracted_older_n_days_seconds, active_sessions_seconds, tablespace_usage_seconds, purge_locks_seconds, cpu_util_seconds, ram_util_seconds, db_conn_seconds, read_latency_seconds, write_latency_seconds, read_throughput_seconds, write_throughput_seconds, cluster_status_seconds, write_iops_seconds, over_all_database_size_seconds, no_of_messages_unextracted_older_n_days_seconds
Example:
read_iops_seconds = 60
inactive_sessions_seconds = 60
total_sessions_seconds = 60
database_check_seconds = 60
database_locks_seconds = 60
db_response_time_seconds = 60
top_tables_seconds = 60
mailboxes_with_unextracted_messages_seconds = 60
no_of_messages_extracted_older_n_days_seconds = 60
active_sessions_seconds = 60
tablespace_usage_seconds = 60
purge_locks_seconds = 60
cpu_util_seconds = 60
ram_util_seconds = 60
db_conn_seconds = 60
read_latency_seconds = 60
write_latency_seconds = 60
read_throughput_seconds = 60
write_throughput_seconds = 60
cluster_status_seconds = 60
write_iops_seconds = 60
over_all_database_size_seconds = 60
no_of_messages_unextracted_older_n_days_seconds = 60
2. Metrics Toggles:
Set to true if you want the agent to monitor that specific database metric.
If set to false, the agent will skip monitoring it.
read_iops, cpu_util, ram_util, db_conn, read_latency, write_latency, read_throughput, write_throughput, over_all_database_size, database_check, tablespace_usage, active_sessions, inactive_sessions, total_sessions, database_locks, db_response_time, mailboxes_with_unextracted_messages, no_of_messages_extracted_older_n_days, purge_locks, cluster_status, write_iops, no_of_messages_unextracted_older_n_days
Example:
read_iops = true
cpu_util = true
ram_util = true
db_conn = true
read_latency = true
write_latency = true
read_throughput = true
write_throughput = true
over_all_database_size = true
database_check = true
tablespace_usage = true
active_sessions = true
inactive_sessions = true
total_sessions = true
database_locks = true
db_response_time = true
mailboxes_with_unextracted_messages = true
no_of_messages_extracted_older_n_days = true
purge_locks = true
cluster_status = true
write_iops = true
no_of_messages_unextracted_older_n_days = true
top_tables=true
3. bp_locks_minutes, days, days_unextracted:
1. bp_locks_minutes: Monitors locks that have been held for this number of minutes or longer.
Example :
bp_locks_minutes=2
2. days: Tracks extracted messages that are older than this number of days.
Example :
days=4
3. days_unextracted: Checks for unextracted messages that are older than the specified number of days.
Example :
days_unextracted=5
Step 7: Configure pcm_stats settings.
[pcm_stats] |
1. Scheduling:
Configure how often (in seconds) the agent collects each PCM stats data point.
Scheduling keys:
application_ref_query_seconds, tp_ref_query_seconds, wf_ref_query_seconds
Example:
application_ref_query_seconds=60
tp_ref_query_seconds=60
wf_ref_query_seconds=60
2. Metrics Toggles:
Set to true if you want the agent to monitor that specific data point.
If set to false, the agent will skip monitoring it.
Toggles:
application_ref_query, tp_ref_query, wf_ref_query
Example:
application_ref_query=true
tp_ref_query=true
wf_ref_query=true
Step 8: Configure queuewatcher_node settings.
Configuration Parameters to be updated:
[queuewatcher_node1] |
1. index = node1
Name of the queuewatcher node – node1 or node2
2. queue_url = http://120.0.0.0:50000/queueWatch/
The endpoint URL that the agent polls to fetch queue data.
3. username = user1
Username used for authenticating requests to the queue_url endpoint.
4. password = aBc123XyZ456+==sDfGhJkLmN0
Password used for authenticating requests. (Should ideally be stored securely or encrypted.)
5. schedule_threads_seconds = 60
Interval (in seconds) at which the agent schedules general thread-related tasks.
6. schedule_queuewatcher_seconds = 60
Interval (in seconds) at which the agent polls the queue_url to collect queue data.
You will configure a separate block for each node.
If you have 1 node, add only this section:
Example:
[queuewatcher_node1]
index = node1
queue_url = http://120.0.0.0:50000/queueWatch/
username = user1
password = aBc123XyZ456+==sDfGhJkLmN0
schedule_threads_seconds = 60
schedule_queuewatcher_seconds = 60
If you have 2 nodes, add both sections:
[queuewatcher_node1]
index = node1
queue_url = http://120.0.0.0:50000/queueWatch/
username = user1
password = aBc123XyZ456+==sDfGhJkLmN0
schedule_threads_seconds = 60
schedule_queuewatcher_seconds = 60
[queuewatcher_node2]
index = node2
queue_url = http://120.0.0.1:50000/queueWatch/
username = user2
password = zYx987WvU654/TuRqPoLmNkJiHg
Step 9: Configure ssp settings.
[ssp] |
Configuration Parameters to be updated:
1. Replace “host” and port with your actual SSP Engine hostnames and ports.
2. You can add as many ssp servers as needed by expanding the data dictionary.
3. delay controls how often (in seconds) the SSP check runs.
Step 10: Configure silogparser settings.
[silogparser] |
Configuration Parameters to be updated:
1. logs: List of log file paths and the application name.
You can add multiple entries to monitor different logs, for example:
logs = [
{‘path’: “/path/to/logs1/*.log*”, ‘application’: “si”},
{‘path’: “/path/to/logs2/*.log*”, ‘application’: “other_app”}
]
2. log_modified_milliseconds: The time window (in milliseconds) to consider a log file as recently modified (here set to 1 year).
3. schedule_logparser_seconds: Frequency in seconds to run the log parser.
4. error_list: List of keywords to look for in logs to catch errors.
Step 11: Configure systemstats settings.
[systemstats] |
Refer to section 3.8 Configure Heartbeat and System Stats for systemstats configuration.
3.4 Configure Auto-Restart for Client Agents.
To ensure continuous operation, configure the client agents to automatically start or restart in case of a failure or system reboot.
Use this Script – run_iann_monitor_beats_start.sh
Make sure to specify the full path to run_iann_monitor_beats_start.sh in the commands used in crontab.
For detailed steps on setting up auto-restart using cron jobs or creating systemd service files for all IANN Monitor client agents, refer to 3.12.1 Auto-Restart Using Crontab
4.1 Agent Startup Failure- Key Errors
Issue: Agent fails to start due to missing or incorrect keys in the configuration file.
Planned Action: Run ./appdata/appdata to identify the exact issue (e.g., key errors), update the config file, and restart the agent.
Add the missing db_type parameter in the config file and re-run the agent
4.2. IANN Monitor UI/API Startup Failure – Java Exception
Issue: IANN Monitor fails to start due to unsupported Java version.
Planned Action: Check the installed Java version using java -version. Ensure Java 17 or above is installed and properly configured before restarting the services.
4.3. SSL Configuration Issues – Elasticsearch
Issue: Elasticsearch fails to start due to incorrect SSL certificate configuration.
Validate certificate paths, correct any mismatches, and ensure proper SSL certificates are configured.
Update the certificate paths in the elasticsearch.yml file and restart Elasticsearch..
4.4. Kibana UI Inaccessible – Certificate Validation Issue
Issue: Kibana is running on the server, but UI access fails due to a certificate validation issue while retrieving data from Elasticsearch.
Planned Action: Validate all SSL/TLS certificates and related configurations, ensuring that Kibana and Elasticsearch use matching certificates and that CA bundle paths are correctly set in kibana.yml.
4.5. Applications Not Accessible via Browser
Issue: Applications are up and running but not reachable in the browser.
Planned Action: Verify that the correct ports are enabled and whitelisted in the firewall/network configuration.
4.6. No Data from DB Monitoring Agents
Issue: Agents show “No Data” because 500 timeout errors occur due to insufficient database access permissions.
Planned Action: Check the logs to identify permission errors, then grant the required privileges to the IANN Monitor database user.
4.7. Elasticsearch Connection Timeout – Max Retry Exceeded
Issue: Applications fail to connect to Elasticsearch due to timeout errors (e.g., “max retries exceeded with URL: https://localhost:9200”)
Planned Action: Ensure Elasticsearch is running and accessible on port 9200, verify the HTTPS endpoint configuration, and correct any incorrect URLs or SSL settings in the application. Once the connection issue is resolved, test connectivity using curl to confirm successful access.