IANN Monitor Installation Guide
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:
1. System Administrators / DevOps Engineers
· Primary audience.
· Responsible for deploying, configuring, and maintaining the software in different environments (development, staging, production).
· Use the guide to ensure all prerequisites, system settings, and deployment steps are correctly followed.
2. IT Support Teams / Technical Support Engineers
· Use the guide to troubleshoot installation-related issues reported by end users or internal teams.
· May use it to replicate the installation process for issue diagnosis.
3. Software Developers
· Particularly when working in teams or setting up the project locally.
· Use the guide to set up their development environments and test deployments.
4. Customers / End Users (for On-Premises Software)
· If the product is delivered for self-hosting, customers’ technical teams use the installation guide.
· Often non-developers with technical backgrounds follow these instructions.
5. Consultants / System Integrators
· Third-party professionals who assist organizations in setting up and customizing the product.
6. QA Engineers / Testers
Use the guide to install and configure the software in test environments to validate features or bug fixes.
This guide serves as a comprehensive manual for deploying and configuring the IANN Monitor platform in various environments (Linux, Windows, OpenShift). It covers the following:
1. Purpose and Overview of IANN Monitor Lite
· Clarifies the objective of the document and introduces the IANN Monitor platform.
2. System Architecture and Deployment Models
· Details the architecture of IANN Monitor and how it integrates with the broader ecosystem.
3. Step-by-Step Installation Instructions
· Linux Installations: Covers UI, Server, Rest Consumer, and Client Server deployments.
· Windows Installations: Includes setup with NSSM, password encryption, component deployments, and validation.
· OpenShift Installations: Provides detailed guidance on Helm charts, UI/backend configurations, and deployment steps.
This document provides a detailed, step-by-step guide for installing and configuring IANN Monitor Lite. 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:
Before proceeding, please review the Prerequisites section to verify that your environment satisfies all requirements for a successful installation.
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:
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.
The UI is structured into two major functional components:
1. Alerts Processing: Responsible for detecting critical events and initiating alert notifications as soon as data breaches configured thresholds.
2. Weekly Reports Module Automatically generates weekly summaries from stored monitoring data for review and audit purposes.
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
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.
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
The SI Application writes logs into the underlying Linux File System.
Before installing IANN Monitor 6.4 Lite, 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 |
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.3 IANN Monitor Client Specifications
Instance Type | Components | Cores | RAM | Disk Space |
IANN Monitor Client | API, Appdata, DB healthcheck, Sterlingreports, PCMstats ,queuewatcher,systemstats | 4 Core | 8 GB | Application- 100 GB |
1.4 Prerequisites
Software / Certificate | Specific Version | Required | Installation Instructions / Notes |
Java | IBM Semeru OpenJDK 17.0.8+7 (LTS) | Yes | Installation Setup Guide / Must be installed before setup |
1.5 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 |
9090 | IANN Monitor API (default, configurable) | Client |
9200 | Elasticsearch HTTP/HTTPS | Server |
8080 | IANN Monitor UI | Server |
1.6 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. |
Note: Ensure these files are present in the target environment with proper ownership and permissions before beginning installation.
1.7 User Permissions:
To install and run IANN Monitor, ensure the following user privileges are in place:
This section outlines the step-by-step procedure for installing and configuring IANN Monitor 6.4 Lite. 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_Client.zip
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 3.2).
IANN Monitor Client Directory Structure
After extraction, the IANN_Monitor_Client directory will contain the following files and folders:
IANN_Monitor_Client/
Client Components & What They Collect:
File Name | Description |
IANN_Monitor_API.jar | Contains the client-side backend jar that connects to the Sterling Integrator 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 for the application. It contains all the necessary parameters required for the application to run, such as Elasticsearch settings, API credentials, logging setup, and more. |
monitor-agent-vm.zip | It is the packaged monitoring agent that collects application-level, server-level, and log-level metrics. It is responsible for gathering key information such as application health, system resource usage (CPU, RAM, etc.), and error logs to provide a complete view of system performance and issues. |
encryptInput.zip
| Tool for encrypting passwords. |
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 Encrypting Password
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_client/
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
3.3 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:
This is the HTTP port on which your Spring Boot application will run.
Example:
server.port = 8180
You will need to update:
1. Host: the Sterling Integrator database server hostname or IP
2. Port: the port number on which your SI 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; |
username = my_db_user
For security reasons, the encrypted database password should not be stored directly in the YAML configuration file. Instead, it must be passed securely through environment variables.
Note: To encrypt the password, refer to section 3.2 – Encrypting Password in the documentation.
Before running the IANN_Monitor_API.jar, make sure to export the encrypted SI database password as an environment variable.
For now, proceed with encrypting the SI database password and store it securely so it can be exported in Step 3.
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:
Before starting the application, export the encrypted SI database password as an environment variable using the below command.
export PASSWORD=<SI_DB_encrypted_password>
Then 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 ensure that the log timestamps align with the current system time.
The log file is generated in the same directory where the IANN_Monitor_API.jar is executed.
tail -f jarvis-api.log |
3.4 Configure monitor-agent-vm using Config.ini.
The config.ini file is required for monitor-agent—vm agent. It provides essential configurations such as Elasticsearch connection details, IANN_Monitor_API API Details, and scheduling intervals for collecting various data points. This ensures that the agents know where to send the collected data, how to the IANN_Monitor_API jar, 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.
Step 1: Navigate to IANN_Monitor_Client using the command below.
cd < Client_Install_dir >/ IANN_Monitor_Client |
Step 2: Open the config.ini file to update the required settings.
Step 3: Configure Elasticsearch settings.
[elasticsearch] use_ssl = false |
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.2 Encrypting Password
Step 4: Configure Logfile Configuration [log_file].
log_file]
log_file_path =
This setting defines the directory where log files will be stored.
By default, it is left empty, meaning all log files will be created in the directory where the agent is executed.
If a specific path is provided, the logs will be generated at the specified location instead.
Example:
Log_file_path = /opt/IANN_Monitor/logs/
Step 5: Configure Enable Monitoring Configuration [enable_monitoring].
[enable_monitoring]
application_monitoring=true
vm_metrics_monitoring=true
log_monitoring=true
To disable any of these, set the value to false.
Example:
log_monitoring=false
Step 6: Configure Heartbeat configuration.
By configuring url and server ip here one can monitor the status of application and server.
[heartbeat]
ip = [“0.0.0.0;server1”]
schedule_heatbeat_seconds = 60
urls = [“https://host_ip:port;test_application”]
timeout_seconds = 3
In the [heartbeat] section of your config.ini, you need to update
ip,urls,schedule_heatbeat_seconds and timeout_seconds
Example:
ip = [“127.0.0.1:1;WebServer1”, “127.0.0.2.11;DatabaseServer”]
Example:
urls = [“https://webapp.company.com;WebApp“, “http://api.company.com;APIService“, “http://auth.company.com;AuthService”]
Example:
Schedule_heatbeat_seconds=300
This sets how long (in seconds) the agent waits for a response from the server.
If no response is received within this time, the URL is marked as down (status = 0).
Example:
timeout_seconds=5
Step 7: Configure appdata settings.
[appdata]
si_version = <si_version>
username = iann_monitor
password = Ae9gUiEB/y1N5vs1zOkimYu9RDpwBdBBvqhUcFMwntUQFX3B2cocH9SzmJE=
api_host = http://<api_host>:<port>
db_type =<db_type>
halted_count_seconds=60
adapter_status_seconds=60
purge_seconds=60
schedulers_status_seconds=60
adapter_list =(‘adapter1′,’adapter2’)
schedulers_list = (‘scheduler1′,’scheduler2’)
In the [appdata] section of your config.ini, you only need to update
si_version,api_host,username,password,db_type,adapter_list,schedulers_list
1. si_version:
Set the Sterling Integrator Version.
Example:
si_version = 6.1.0.0
2.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.username & password :
Credentials to authenticate with the IANN_Monitor_API.
Set default username – iann_monitor
Set the default password to ‘password’ and ensure it is encrypted.
Note : To encrypt password refer to – 3.1 Encrypting Password
Example:
username = iann_monitor
password = 8o3DjuRtTlvaqzbehivjk75p
3.db_type:
Specify the database type used by Sterling Integrator:
Example:
db_type = DB2
4. adapter_list, schedulers_list:
adapter_list – provide any 2 adapters which need to be monitored.
Example:
adapter_list = (‘FileAdapter’,’FTPAdapter’)
schedulers_list – provide any 2 scheduler which need to be monitored.
Example:
schedulers_list = (‘NightlyCleanupScheduler’,’DataSyncScheduler’)
5. Scheduling:
Configure the schedule for the following data points so that the agent collects data at the specified intervals.
halted_count_seconds, adapter_status_seconds, purge_seconds, schedulers_status_seconds
Example:
halted_count_seconds=60
adapter_status_seconds=60
purge_seconds=60
schedulers_status_seconds=60
Step 8: Configure Database Health Check Configuration [db_healthcheck]
[db_healthcheck]
cpu_util_seconds=60
database_check_seconds=60
ram_util_seconds=60
db_response_time_seconds=60
active_sessions_seconds=60
inactive_sessions_seconds=60
total_sessions_seconds=60
mailboxes_with_unextracted_messages_seconds=60
Configure the schedule for the following data points so that the agent collects data at the specified intervals.
cpu_util_seconds, database_check_seconds, ram_util_seconds, db_response_time_seconds, active_sessions_seconds, inactive_sessions_seconds, total_sessions_seconds, mailboxes_with_unextracted_messages_seconds
Example:
cpu_util_seconds=60
database_check_seconds=60
ram_util_seconds=60
db_response_time_seconds=60
active_sessions_seconds=60
inactive_sessions_seconds=60
total_sessions_seconds=60
mailboxes_with_unextracted_messages_seconds=60
Step 9: Configure sterling_reports settings.
[sterling_reports]
long_running_bp_seconds=60
ca_certs_seconds=60
system_certs_seconds=60
long_bp_time_seconds=60
Configure how often (in seconds) the agent collects each of these data points.long_running_bp_seconds, ca_certs_seconds, system_certs_seconds
Example:
long_running_bp_seconds=60
ca_certs_seconds=60
system_certs_seconds=60
2. long_bp_time_seconds – Retrieves business processes that have been running longer than the specified number of seconds.
Step 10: Configure pcm_stats settings.
[pcm_stats] |
Configure how often (in seconds) the agent collects each PCM stats data point.
application_ref_query_seconds, tp_ref_query_seconds
Example:
application_ref_query_seconds=60
tp_ref_query_seconds=60
Step 11: Configure queuewatcher_node settings.
Configuration Parameters to be updated:
[queuewatcher_node1] queue_names=q1,q2 pool_names=CM_FRAMEWORK,db2Pool schedule_threads_seconds = 60 |
The endpoint URL that the agent polls to fetch queue data.
specify the names of queues separated by commas to track their queue depths.
Note: Monitoring is restricted to a maximum of two queues.
specify the names of pools separated by commas to track their used connections and total connections.
Note: Monitoring is restricted to a maximum of two pools.
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 systemstats configuration [systemstats].
[systemstats]
metrics_seconds = 60
server_name=node1
environment=general
os=linux
metrics_seconds – Defines how often (in seconds) the agent collects metrics data.
server_name – Specifies the name of the Sterling Integrator server node (e.g., node1 or node2).
environment – Indicates the environment name; default is general.
os – Specifies the operating system of the server (either linux or windows).
Step 10: Configure silogparser settings.
[silogparser] |
Configuration Parameters to be updated:
logs = [
{‘path’: “/path/to/logs1/*.log*”, ‘application’: “si”}
]
Note : here the list of log path monitored is restricted to only one.
3.5 Unzip and Start monitor-agent-vm Agent.
Step 1: Navigate to IANN_Monitor_Client using the command below.
cd <Client_Install_dir>/ IANN_Monitor_Client
Step 2: unzip monitor-agent-vm.zip using the command below.
unzip monitor-agent-vm.zip
Step 3: Start the monitor-agent-vm using the commands below.
nohup ./monitor-agent-vm/monitor-agent-vm> /dev/null 2>&1 &
Step 4: Review the log file and compare its timestamps with the most recent time.
Check the logs with the command below.
tail -f monitor-agent.log
The log file should display entries in the following format.
2025-08-05 19:14:52 INFO Reading configurations completed
2025-08-05 19:14:52 INFO DB Configured is Oracle
2025-08-05 19:14:52 INFO sending the api request of database_response
2025-08-05 19:14:53 INFO Response of db_response_time api 200
2025-08-05 19:14:53 INFO Db_response_time Data Sent to the elasticssearch
2025-08-05 19:14:53 INFO sending the api request of active_sessions
2025-08-05 19:14:54 INFO Response of active_sessions api 200
2025-08-05 19:14:54 INFO Active_sessions Data Sent to the elasticssearch
2025-08-05 19:14:54 INFO sending the api request of inactive_sessions
2025-08-05 19:14:55 INFO Response of inactive_sessions api 200
2025-08-05 19:14:56 INFO Inactive_sessions Data Sent to the elasticssearch
2025-08-05 19:14:56 INFO sending the api request of total_sessions
2025-08-05 19:14:57 INFO Response of total_sessions api 200
2025-08-05 19:14:57 INFO Total_sessionsData Sent to the elasticssearch
2025-08-05 19:14:57 INFO Inside long_running_bp method
2025-08-05 19:14:58 INFO Response of long_running_bp api 200
2025-08-05 19:14:58 INFO Long running bp has no data
2025-08-05 19:14:58 INFO sending the api request of mailbox_with_unextracted_messages
2025-08-05 19:14:59 INFO Response of mailboxes_with_unextracted_messages api 200
2025-08-05 19:14:59 INFO Mailboxes_with_unextracted_messages has no data
2025-08-05 19:14:59 INFO sending the api request of HaltedCount
2025-08-05 19:15:00 INFO Response of halted count api 200
2025-08-05 19:15:00 INFO Halted countData Sent to the elasticssearch
2025-08-05 19:15:00 INFO sending the api request of adapterstatus
2025-08-05 19:15:01 INFO Response of adapter_status api 200
2025-08-05 19:15:01 INFO Adapter statusData Sent to the elasticssearch
2025-08-05 19:15:01 INFO sending the api request of schedulers_status
2025-08-05 19:15:02 INFO Response of schedulers_status api 200
2025-08-05 19:15:02 INFO Schedulers_statusData Sent to the elasticssearch
2025-08-05 19:15:02 INFO Inside ca_cert method
2025-08-05 19:15:03 INFO Response of ca_cert api 200
2025-08-05 19:15:04 INFO ca certs Data Sent to the elasticssearch
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:
Before proceeding, please review the Prerequisites section to verify that your environment satisfies all requirements for a successful installation.
Before installing IANN Monitor 6.4 lite, 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 |
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)
1.3 IANN Monitor Server and Client Specifications
Instance Type | Components | Cores | RAM | Disk Space |
IANN Monitor Client | API, Appdata, DB healthcheck, Sterlingreports, PCMstats ,queuewatcher,systemstats | 4 Core | 8 GB | D Drive- 100 GB / Application- 100 GB |
1.4 Pre-requisites
Software / Certificate | Specific Version | Required | Installation Instructions / Notes |
Java | IBM Semeru OpenJDK 17.0.8+7 (LTS) | Yes | |
NSSM | NSSM v.2.24 | Yes | Refer to Section – (2.7 Prerequisite – NSSM Installation) in this document |
1.5 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 |
9090 | IANN Monitor API (default, configurable) | Client |
8444, 10000 | SSP Adapter / DB ports (as defined in config.ini) | Client / As needed |
1.6 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.7 Prerequisite – NSSM Installation:
NSSM (Non-Sucking Service Manager) is a free and open-source utility for Windows that lets you run any non-service application (like a .jar, .exe, .bat, or a script) as a Windows Service.
Here are the steps to install NSSM (Non-Sucking Service Manager) on Windows:
Step 1: Download NSSM
Step 2: Extract the ZIP File
Step 3: Verify NSSM Installation
To check if NSSM is installed and working:
nssm version |
2. You should see output like below along with usage details.
NSSM: The non-sucking service manager
Version 2.24 64-bit, 2014-08-31
This confirms that NSSM is installed correctly.
This section outlines the step-by-step procedure for installing and configuring IANN Monitor 6.4 lite. Please follow the instructions carefully to ensure a successful deployment.
Extract Installation Package
Step 1: Right-click on the IANN_Monitor.zip file and select “Extract All…”. Choose a destination folder and click “Extract” to unzip and extract its contents.
Once extracted, you will find two primary archives under the IANN_Monitor directory:
IANN_Monitor/
└── IANN_Monitor_Client.zip
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 3.2).
IANN Monitor Client Directory Structure
After extraction, the IANN_Monitor_Client directory will contain the following files and folders:
IANN_Monitor_Client/
Client Components & What They Collect:
File Name | Description |
IANN_Monitor_API.jar | Contains the client-side backend jar that connects to the Sterling Integrator 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 for the application. It contains all the necessary parameters required for the application to run, such as Elasticsearch settings, API credentials, logging setup, and more. |
monitor-agent-vm.zip | It is the packaged monitoring agent that collects application-level, server-level, and log-level metrics. It is responsible for gathering key information such as application health, system resource usage (CPU, RAM, etc.), and error logs to provide a complete view of system performance and issues. |
encryptInput.zip | Tool for encrypting passwords. |
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>, extract the package.
3.2 Encrypting Password
The IANN Monitor application does not store sensitive values like passwords 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. This is where your encryptInput.zip file is located.
Step 2: Unzip the Encryption Tool
Right-click on the encryptInput.zip file.
Select “Extract All…” from the context menu.
Step 3: Run the encryption tool
Navigate to the IANN Monitor Server folder from command prompt and run the following command.
encryptInput/encryptInput.exe
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
3.3 Configure application.yml and Deploy IANN_Monitor_API.jar
Step 1: Go to IANN_Monitor_Client and locate application.yml for updating the configurations.
Step 2: update the application.yml to define API port and database connectivity details
server:
port: 8180 # Port on which jar needs to be run
spring:
servlet:
multipart:
max-file-size: 1GB
max-request-size: 1GB
datasource:
type: com.zaxxer.hikari.HikariDataSource
url: <SI_database_url>
username: <SI_db_user>
password: ${PASSWORD}
driver-class-name: <driver_class>
hikari:
connection-timeout: 120000
minimum-idle: 5
maximum-pool-size: 15
auto-commit: false
jpa:
show_sql: false
open-in-view: false
database-platform: org.hibernate.dialect.OracleDialect
properties:
id:
new_generator_mappings: true
Details to update in your application.yml:
Example:
server.port = 8180
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 shows 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; |
Example:
username = my_db_user
For security reasons, the encrypted database password should not be stored directly in the YAML configuration file. Instead, it must be passed securely through environment variables.
Note: To encrypt the password, refer to section 3.2 – Encrypting Password in the documentation.
Before running the IANN_Monitor_API.jar, make sure to export the encrypted SI database password as an environment variable.
For now, proceed with encrypting the SI database password and store it securely so it can be exported in Step 3.
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: To install the jar, Open Command Prompt from NSSM Folder
Step 4: In the Command Prompt window, to export the encrypted SI database password run the command below.
set PASSWORD=Encrypted_SI_DB_Password
enter the following command to begin installing the IANN_Monitor_API service:
nssm install IANN_Monitor_API
Step 5: To start IANN_Monitor_API, Go to services in task manager and search for IANN_Monitor_API. Right click on the IANN_Monitor_API and then start it, it will come to running state.
3.4 Client Agents Config Setup
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.
Step 1: Go to IANN_Monitor_Client installation directory.
Step 2: Open the config.ini file to update the required settings.
Step 3: Configure Elasticsearch settings.
[elasticsearch] use_ssl = false |
In the [elasticsearch] section of your config.ini, you only need to
update the following fields:
index, url, port,username, and password.
Example: index = iann_test_qa
Example: url = https://0.0.0.120:9200/
Example: port = 9200
authenticate.
Example: username = elastic_user
Example: password = DTwZ0UoOt056TyX4hxQAb5h4=
Note: To encrypt password refer to – 3.2 Encrypting Password
Step 4: Configure Logfile Configuration [log_file].
[log_file]
log_file_path =
This setting defines the directory where log files will be stored.
By default, it is left empty, meaning all log files will be created in the directory where the agent is executed.
If a specific path is provided, the logs will be generated at the specified location instead.
Example:
Log_file_path = /opt/IANN_Monitor/logs/
Step 5: Configure Enable Monitoring Configuration [enable_monitoring].
[enable_monitoring]
application_monitoring=true
vm_metrics_monitoring=true
log_monitoring=true
To disable any of these, set the value to false.
Example:
log_monitoring=false
Step 6: Configure Heartbeat configuration .
By configuring url and server ip here one can monitor the status of application and server.
[heartbeat]
ip = [“0.0.0.0;server1”]
schedule_heatbeat_seconds = 60
urls = [“https://host_ip:port;test_application”]
timeout_seconds = 3
In the [heartbeat] section of your config.ini, you need to update
ip,urls,schedule_heatbeat_seconds and timeout_seconds
Example:
ip = [“127.0.0.1:1;WebServer1”, “127.0.0.2.11;DatabaseServer”, “127.0.0.1.12;CacheServer”]
Example:
urls = [“https://webapp.company.com;WebApp“, “http://api.company.com;APIService“, http://auth.company.com;AuthService]
Example:
Schedule_heatbeat_seconds=300
4. timeout_seconds=3
This sets how long (in seconds) the agent waits for a response from the server.
If no response is received within this time, the URL is marked as down (status = 0).
Example:
timeout_seconds=5
Step 7: Configure appdata settings.
[appdata]
si_version = <si_version>
username = iann_monitor
password = Ae9gUiEB/y1N5vs1zOkimYu9RDpwBdBBvqhUcFMwntUQFX3B2cocH9SzmJE=
api_host = http://<api_host>:<port>
db_type =<db_type>
halted_count_seconds=60
adapter_status_seconds=60
purge_seconds=60
schedulers_status_seconds=60
adapter_list =(‘adapter1′,’adapter2’)
schedulers_list = (‘scheduler1′,’scheduler2’)In the [appdata] section of your config.ini, you only need to update
si_version,api_host,username,password,db_type,adapter_list,schedulers_list
1. si_version:
Set the Sterling Integrator Version.
Example:
si_version = 6.1.0.0
2.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.username & password :
Credentials to authenticate with the IANN_Monitor_API.
Set default username – iann_monitor
Set the default password to ‘password’ and ensure it is encrypted.
Note : To encrypt password refer to – 3.1 Encrypting Password
Example:
username = iann_monitor
password = 8o3DjuRtTlvaqzbehivjk75p
3.db_type:
Specify the database type used by Sterling Integrator:
Example:
db_type = DB2
4. adapter_list, schedulers_list:
adapter_list – provide any 2 adapters which need to be monitored.
Example:
adapter_list = (‘FileAdapter’,’FTPAdapter’)
schedulers_list – provide any 2 scheduler which need to be monitored.
Example:
schedulers_list = (‘NightlyCleanupScheduler’,’DataSyncScheduler’)
5. Scheduling:
Configure the schedule for the following data points so that the agent collects data at the specified intervals.
halted_count_seconds, adapter_status_seconds, purge_seconds, schedulers_status_seconds
Example:
halted_count_seconds=60
adapter_status_seconds=60
purge_seconds=60
schedulers_status_seconds=60
Step 8: Configure Database Health Check Configuration [db_healthcheck]
[db_healthcheck]
cpu_util_seconds=60
database_check_seconds=60
ram_util_seconds=60
db_response_time_seconds=60
active_sessions_seconds=60
inactive_sessions_seconds=60
total_sessions_seconds=60
mailboxes_with_unextracted_messages_seconds=60
Configure the schedule for the following data points so that the agent collects data at the specified intervals.
cpu_util_seconds, database_check_seconds, ram_util_seconds, db_response_time_seconds, active_sessions_seconds, inactive_sessions_seconds, total_sessions_seconds, mailboxes_with_unextracted_messages_seconds
Example:
cpu_util_seconds=60
database_check_seconds=60
ram_util_seconds=60
db_response_time_seconds=60
active_sessions_seconds=60
inactive_sessions_seconds=60
total_sessions_seconds=60
mailboxes_with_unextracted_messages_seconds=60
Step 9: Configure sterling_reports settings.
[sterling_reports]
long_running_bp_seconds=60
ca_certs_seconds=60
system_certs_seconds=60
long_bp_time_seconds=60
long_running_bp_seconds, ca_certs_seconds, system_certs_seconds
Example:
long_running_bp_seconds=60
ca_certs_seconds=60
system_certs_seconds=60
Step 10: Configure pcm_stats settings.
[pcm_stats]
application_ref_query_seconds=60
tp_ref_query_seconds=60
Configure how often (in seconds) the agent collects each PCM stats data point.
application_ref_query_seconds, tp_ref_query_seconds
Example:
application_ref_query_seconds=60
tp_ref_query_seconds=60
Step 11: Configure queuewatcher_node settings.
Configuration Parameters to be updated:
[queuewatcher_node1]
index = node1
queue_url = http://<queuewatcher-host>:<queuewatcher-port>/queueWatch/
username = <queuewatcher_username>
password = <queuewatcher_encrypted_password>
queue_names=q1,q2
pool_names=CM_FRAMEWORK,db2Pool
schedule_threads_seconds = 60
schedule_queuewatcher_seconds = 60
[queuewatcher_node2]
index = node2
queue_url = http://<queuewatcher-host>:<queuewatcher-port>/queueWatch/
username = <queuewatcher_username1>
password = <queuewatcher_encrypted_password>
The endpoint URL that the agent polls to fetch queue data.
specify the names of queues separated by commas to track their queue depths.
Note: Monitoring is restricted to a maximum of two queues.
specify the names of pools separated by commas to track their used connections and total connections.
Note: Monitoring is restricted to a maximum of two pools.
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 systemstats configuration [systemstats].
[systemstats]
metrics_seconds = 60
server_name=node1
environment=general
os=linux
metrics_seconds – Defines how often (in seconds) the agent collects metrics data.
server_name – Specifies the name of the Sterling Integrator server node (e.g., node1 or node2).
environment – Indicates the environment name; default is general.
os – Specifies the operating system of the server (either linux or windows).
Step 10: Configure silogparser settings.
[silogparser]
logs = [{‘path’: “/opt/IBM/SterlingIntegrator/logs/.log”, ‘application’: “si”}]
log_modified_milliseconds = 31536000000
schedule_logparser_seconds = 1800
error_list = [“ERROR”, “Error”, “error”, “ERRORDTL”, “OutOfMemory”, “outofmemory”, “Outofmemory”, “OUTOFMEMORY”, “errors”]
Configuration Parameters to be updated:
logs = [
{‘path’: “/path/to/logs1/*.log*”, ‘application’: “si”}
]
Note : here the list of log path monitored is restricted to only one.
3.5 Installation of monitor-agent-vm Agent:
Step 1: Extract monitor-agent-vm.zip and Open Command Prompt from the NSSM Folder
Step 2: Install the monitor-agent-vm Package
In the Command Prompt window, enter the following command to begin installing the monitor-agent-vm service:
nssm install monitor-agent-vm
Step 3: To start monitor-agent-vm, Go to services in task manager and search for monitor-agent-vm. Right click on the monitor-agent-vm and then start it, it will come to running state.
Step 4:
Go to the monitor-agent-vm package location and open the “monitor-agent.log” text document and verify the logs for any errors or exceptions and then validate the time of the logs with the current time.
2025-08-05 19:14:52 INFO Reading configurations completed
2025-08-05 19:14:52 INFO DB Configured is Oracle
2025-08-05 19:14:52 INFO sending the api request of database_response
2025-08-05 19:14:53 INFO Response of db_response_time api 200
2025-08-05 19:14:53 INFO Db_response_time Data Sent to the elasticssearch
2025-08-05 19:14:53 INFO sending the api request of active_sessions
2025-08-05 19:14:54 INFO Response of active_sessions api 200
2025-08-05 19:14:54 INFO Active_sessions Data Sent to the elasticssearch
2025-08-05 19:14:54 INFO sending the api request of inactive_sessions
2025-08-05 19:14:55 INFO Response of inactive_sessions api 200
2025-08-05 19:14:56 INFO Inactive_sessions Data Sent to the elasticssearch
2025-08-05 19:14:56 INFO sending the api request of total_sessions
2025-08-05 19:14:57 INFO Response of total_sessions api 200
2025-08-05 19:14:57 INFO Total_sessionsData Sent to the elasticssearch
2025-08-05 19:14:57 INFO Inside long_running_bp method
2025-08-05 19:14:58 INFO Response of long_running_bp api 200
2025-08-05 19:14:58 INFO Long running bp has no data
2025-08-05 19:14:58 INFO sending the api request of mailbox_with_unextracted_messages
2025-08-05 19:14:59 INFO Response of mailboxes_with_unextracted_messages api 200
2025-08-05 19:14:59 INFO Mailboxes_with_unextracted_messages has no data
2025-08-05 19:14:59 INFO sending the api request of HaltedCount
2025-08-05 19:15:00 INFO Response of halted count api 200
2025-08-05 19:15:00 INFO Halted countData Sent to the elasticssearch
2025-08-05 19:15:00 INFO sending the api request of adapterstatus
2025-08-05 19:15:01 INFO Response of adapter_status api 200
2025-08-05 19:15:01 INFO Adapter statusData Sent to the elasticssearch
2025-08-05 19:15:01 INFO sending the api request of schedulers_status
2025-08-05 19:15:02 INFO Response of schedulers_status api 200
2025-08-05 19:15:02 INFO Schedulers_statusData Sent to the elasticssearch
2025-08-05 19:15:02 INFO Inside ca_cert method
2025-08-05 19:15:03 INFO Response of ca_cert api 200
2025-08-05 19:15:04 INFO ca certs Data Sent to the elasticssearch
This document provides a comprehensive installation and configuration guide for IANN Monitor version 6.4 on OpenShift environments. It outlines the end-to-end process for deploying both server and client components, ensuring full observability across infrastructure, including Sterling Integrator, and connected systems.
The IANN Monitor platform comprises:
By following this guide, you will be able to:
Before proceeding, please review the Prerequisites section to verify that your environment satisfies all requirements for a successful installation.
Before proceeding with the installation of the IANN application in an OpenShift cluster, ensure the following prerequisites are in place:
2.1 Platform Supported Model and Delivery
The IANN application can be deployed on the following platforms:
2.2 Versions
2.3 Download and Transfer the Helm Package
Start by downloading the IANN Helm package. Transfer the package to a Linux backend that has access to the OpenShift cluster where the deployment will take place. After transferring the package, extract it using the following command:
tar -xvf <helm_package_name>
2.4 Create a Namespace in OpenShift
Before making any modifications to the Helm charts, it is essential to create a dedicated namespace in the OpenShift cluster for the IANN application. Execute the following command to create the namespace:
Openshift:
oc create namespace <namespace-name>
Example:
oc create namespace iann-clientname
Kubernetes:
kubectl create namespace <namespace-name>
Example:
kubectl create namespace iann-clientname
2.5 Create an Image Pull Secret
Once the namespace has been created, the next step is to set up an image pull secret. This secret contains the necessary credentials to authenticate with the container registry and pull the required IANN images. Use the following command to create the secret:
Openshift:
oc create secret docker-registry <secret_name> \
–docker-server=<your-registry-server> \
–docker-username=<your-username> \
–docker-password=<your-password> \
-n <namespace>
Example:
oc create secret docker-registry test-secret \
–docker-server=my-private-registry.com \
–docker-username=my-username \
–docker-password=my-password \
–docker-email=my-email@example.com
Kubernetes:
kubectl create secret docker-registry <secret_name> \
–docker-server=<your-registry-server> \
–docker-username=<your-username> \
–docker-password=<your-password> \
-n <namespace>
Example:
kubectl create secret docker-registry test-secret \
–docker-server=my-private-registry.com \
–docker-username=my-username \
–docker-password=my-password \
–docker-email=my-email@example.com
By completing these steps, you ensure that the OpenShift cluster is properly configured to authenticate with the container registry during the deployment process.
2.6 Exposing Services in OpenShift
After deploying the IANN Monitor components using Helm, the following services must be exposed for external access (UI, Kibana, and API endpoints).
OpenShift Route Exposure
Use oc expose to create routes for services:
Expose API Jar (optional)
oc expose svc/iann-api-service -n <namespace>
To get the generated URLs:
oc get routes -n <namespace>
This will list all exposed endpoints. These routes can be shared with users to access dashboards and APIs.
Note:
2.7 Troubleshooting and Recovery Scenarios
Common scenarios and recovery steps are listed below:
Check Pod Status: Run this command to see the status of all pods in your namespace:
oc get pods -n <namespace>
Describe Problematic Pod:
If any pod shows an errouy6r, run this command to view its details:
oc describe pod <pod-name>
Use this Command followed by a reinstall. Check helm history for rollback options.
Use this Command to check cluster status. Restart pod if needed.
curl -X GET <es-url>:9200/_cluster/health
To further customize the deployment, additional changes can be made to the Helm charts. Begin by opening the values.yaml file in a text editor of your choice on the Linux backend.
3.1 Secret File Configuration
Steps to Encrypt Passwords:
Step 1: Download the Encryption Tool
Obtain the encryptInput.zip file from your designated S3 bucket or Nexus repository.
Step 2: Unzip the Encryption Tool
Extract the contents using the following command:
unzip encryptInput.zip
Step 3: Run the Encryption Tool
Start the encryption program using:
./encryptInput/encryptInput
Step 4: Encrypt Your Password
When prompted with:
Enter password:
Example:
Enter password: mysecretpassword
The tool will output an encrypted string like: EQHGuVfEHaxJQLfiXSgunZfYfjJqErrPBrmQTdTSuhNUpxG6to8YQOwp8yGqFIg2
Use this encrypted string as the value in the values.yaml file.
apiVersion: v1
kind: Secret
metadata:
name: agent-secret
type: Opaque
stringData:
DB_PASS:
encrypt-elastic-password:
encrypt-queueWatcher-password:
OpenShift:
oc apply –f app-secret.yaml
Output: secret/app-secret created
Kubernetes:
kubectl apply –f app-secret.yaml
Output: secret/app-secret created
3.2 Service Account Configuration Section
Give the service account name and keep RBAC as true for the permissions that will be applied to the service account.
runAsUser: Sets a custom user ID (UID) for the container.
fsGroup: Sets a custom group ID (GID) for file system access.
serviceAccount:
create: true
name: testing # This will create a new ServiceAccount named “testing”
rbac:
create: true # This enables Role-Based Access Control(RBAC) for ServiceAccount
security:
runAsUser: 1001 # The container will run as user ID 1001
supplementalGroup: 2002 # Additional group ID the container will belong to
fsGroup: 2001 # Group ID used for file system access
3.3 Image Pull Secret
imagePullSecrets: Refers to the secret used for pulling images from the container registry. Replace the “test-secret” with your actual secret name.
imagePullSecrets:
name: test-secret
3.4 Log Configuration Section
For storing logs give the storage class name and required storage size
logs:
persistence:
useDynamicProvision: true # Set to false to use an existing PVC
pvcName: “” # Specify the existing PVC name when use Dynamic Provision is false
storageClassName: “fast-storage” Example storage class (e.g., “standard”, “gp2”, “fast-storage”)
storageSize: 10Gi #Specify the required storage size for logs
3.5 Database Details
DB:
db_type: #Specify the database type which you are using either DB2 or Oracle or mssql
ssl_connection: false #Set the value to true if your using SSL connection between the application servers and database
db_port: #specify the port
db_host: #specify the host
db_name: #Specify the DATABASE Name
db_user: #Specify the DB username
db_password: #Specify the DB secret name
3.6 Elastic Search Configuration
elasticsearch: index: test url: https://<IP>:<PORT>/ #Elasticsearch URL port: #Elasticsearch PORT username: elastic #Username of Elasticsearch password: #Please add the secret name which contains the encrypted password use_ssl: false os: linux |
|
|
3.7 Appdata Configuration
appdata: enabled: true image: name: # Container image repository resources: limits:
configurations: Si_version:
jarvis_username:
adapter_status_seconds: 300
purge_seconds: 1800
adapter_list:
schedulers_list:
schedulers_status_seconds: 1800
|
|
3.8 PCM Stats Service Configuration
Specifies that application reference queries should be tracked every 300 seconds (5 minutes).
Specifies that transaction point reference queries should be tracked every 300 seconds (5 minutes).
#set enabled to true to enable the PCM stats service
pcm_stats:
application_ref_query_seconds: 1800
tp_ref_query_seconds: 1800
3.9 Sterling Reports Configuration
This section configures the deployment of the Sterling Reports pod, which provides detailed reporting and monitoring for the Sterling application. These reports cover various aspects such as certificate status, long-running business processes, and more.
#set enabled to true to deploy sterling_reports pod and provide sterling_reports beat configuration details below.
sterling_reports:
ca_certs_seconds: 1800
system_certs_seconds: 1800
long_running_bp_seconds: 1800
long_bp_time_seconds: 900
3.10 Database Healthcheck Configuration
This section configures the deployment of the Database Healthcheck.
db_healthcheck:
cpu_util_seconds: 1800
database_check_seconds: 1800
ram_util_seconds: 1800
db_response_time_seconds: 1800
active_sessions_seconds: 1800
inactive_sessions_seconds: 1800
total_sessions_seconds: 1800
long_running_bp_seconds: 1800
mailboxes_with_unextracted_messages_seconds: 1800
3.11 Queuewatcher Multi-node Configuration
Configuration Parameters to be updated:
[queuewatcher_node1]
index = node1
queue_url = http://<queuewatcher-host>:<queuewatcher-port>/queueWatch/
username = <queuewatcher_username>
password = <queuewatcher_encrypted_password>
queue_names=q1,q2
pool_names=CM_FRAMEWORK,db2Pool
schedule_threads_seconds = 60
schedule_queuewatcher_seconds = 60
[queuewatcher_node2]
index = node2
queue_url = http://<queuewatcher-host>:<queuewatcher-port>/queueWatch/
username = <queuewatcher_username1>
password = <queuewatcher_encrypted_password>
The endpoint URL that the agent polls to fetch queue data.
specify the names of queues separated by commas to track their queue depths.
Note: Monitoring is restricted to a maximum of two queues.
specify the names of pools separated by commas to track their used connections and total connections.
Note: Monitoring is restricted to a maximum of two pools.
You will configure a separate block for each node.
If you have 1 node, add only this section:
queueWatcher_node1:
index: node1
queue_url: http://0.0.0.0:0000/queueWatch/
username: #Please provide the username of the B2BI
password: #Please add the secret name which contains the encrypted pass
queue_names:
pool_names:
schedule_queuewatcher_seconds: 60
schedule_threads_seconds: 300
queueWatcher_node2:
index: node1
queue_url: http://0.0.0.0:0000/queueWatch/
username: #Please provide the username of the B2BI
password: #Please add the secret name which contains the encrypted password
3.12 Heartbeat Configuration
This section configures the deployment of the Heartbeat pod, which monitors the availability and responsiveness of specified IPs and URLs. It helps ensure that key services and endpoints are operational and responding within defined time limits.
General Settings
Image Configuration
Resource Configuration
Heartbeat Parameters
heartbeat:
ip:
urls: ‘[“”,]’
schedule_heatbeat_seconds: 60
timeout_seconds: 10
3.13 Systemstats Configuration
This section monitors all the pods,nodes health status in the OpenShift Cluster and sends that to elasticsearch.
systemstats:
configuration: host_url: #Please provide the Openshift Console URL
namespace: #Please provide the namespaces you need to track
nodes:
schedule_system_stats_seconds: 60
schedule_ssl_seconds: 60
3.14 Iann lite App Configuration:
iannliteapp: enabled: true rbac: create: true #SystemStats require read permission for all the api groups in the cluster image: name: tag: pullPolicy: Always resources: limits: cpu: 1 core memory: 1 GB requests: cpu: 1 core memory: 1 GB |
|
|
3.15 Enable_Monitoring
enable_monitoring: application_monitoring: true openshift_metrics_monitoring: true log_monitoring: true |
|
Configure Enable Monitoring Configuration [enable_monitoring].
To disable any of these, set the value to false.
Example:
log_monitoring=false
Step 6: Configure Heartbeat configuration.
By configuring url and server ip here one can monitor the status of application and server.
3.16 Silog Parser
silogparser: log_path: #specify the log path Log_modified_milliseconds: 31536000000 Schedule_logparser_seconds: 1800 |
delay: false error_list: [“ERROR”, “Error”, “error”,”ERRORDTL”,”OutOfMemory”,”outofmemory”,”Outofmemory”,”OUTOFMEMORY”,”errors”]
|
Configuration Parameters to be updated:
logs = [
{‘path’: “/path/to/logs1/*.log*”, ‘application’: “si”}
]
Note: here the list of log path monitored is restricted to only one.
3.17 Log_File
log_file: log_file_path: #specify the log path |
|
This setting defines the directory where log files will be stored.
By default, it is left empty, meaning all log files will be created in the directory where the agent is executed.
If a specific path is provided, the logs will be generated at the specified location instead.
Example:
Log_file_path = /opt/IANN_Monitor/logs/
3.18 Save file and Install IANN Application
helm install <release_name> -f <path of values.yaml> <path/to/helmchart>
helm upgrade <release_name> -f <path of values.yaml> <path/to/helmchart>
helm rollback <release_name> <revision_number>
This section outlines the step-by-step validation checks to be performed after deploying the IANN Monitor stack. These checks help ensure that all services, components, and configurations are functioning as expected across OpenShift and Kubernetes environments.
4.1 Check Helm Installation
Run this Command to Confirm status is deployed.
helm list -n <namespace>
4.2 Check All Pods
After deployment, it’s important to verify that all application components are running correctly. Use the following commands to check the status of all pods in the target namespace:
Openshift:
oc get pods -n <namespace>
Kubernetes:
kubectl get po –n <namespace>
Review the output and ensure that all pods are in either the Running or Completed state.
Agents:
4.3 Check Services and Endpoints
Ensure that all essential services are up and properly exposed within the cluster. Use the following commands to list services in the specified namespace:
Openshift:
oc get svc -n <namespace>
Kubernetes:
kubectl get svc –n <namespace-name>
Verify that critical services such as API, QueueWatcher, and Elasticsearch are present in the output. Their absence may indicate deployment or configuration issues.
To list all secrets in a specific namespace
Openshift:
oc get secrets -n <namespace>
Kubernetes:
kubectl get secret –n <namespace> |
|
Make sure that both the agent secrets and image pull secrets are listed and available.
To list the Agent routes use below Command:
oc get routes
4.4 Check PVCs (Storage)
Persistent Volume Claims (PVCs) ensure that pods have the necessary storage attached. To verify the status of PVCs in the specified namespace.
Openshift:
oc get pvc -n <namespace>
Kubernetes:
kubectl get pvc –n <namespace>
Check that all PVCs show a Bound status, indicating successful allocation of storage. Any other status may require storage configuration review.
4.5 Check Pod Logs
Pod logs help diagnose issues related to application startup, configuration, or runtime errors. Use the following commands to view logs for a specific pod:
Openshift:
oc logs <pod-name> -n <namespace>
Kubernetes:
kubectl logs <pod-name> –n <namespace>
Review the logs for any errors, warnings, or crash-related messages that could indicate problems with the application or service.
To check the pod logs use the below command:
oc exec -it <pod-id> — /bin/bash
Backend API Jar:
4.6 Check DB Health Metrics
Confirm database stats (latency, locks, sessions) are visible in the UI or logs.
4.7 Check Heartbeat and QueueWatcher
Make sure your heartbeat monitors IPs/URLs.
Confirm QueueWatcher is pulling queue info.
4.8 Check Systemstats
Verify pod and node data is being collected.
4.9 Check Helm Rollback Option
Run the following command to review the deployment history and identify rollback options for a Helm release
helm history <release-name> -n <namespace>
Note: the revision number in case rollback is needed.