IANN Monitor Installation Guide

Introduction to the 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.

What is IANN?

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:

  1. FileGPS – Tracks and monitors file transactions across systems for visibility and SLA compliance.
  2. Monitor – Provides real-time monitoring of processes, system health, and metrics with alerts.
  3. AI – Adds intelligence through predictive analytics, anomaly detection, and GenAI insights.

 

 

Who should use this Installation Guide?

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.

What this Installation Guide Covers?

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.

1. Introduction to IANN Monitor Lite

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:

  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.

A screenshot of a computer  AI-generated content may be incorrect.

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.

 

  1. UI Functional Components & Notification Channels


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

 

  1. 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.

  1. 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

  1. SI Application Integration & Log Monitoring

 

The SI Application writes logs into the underlying Linux File System.

  1. A log monitoring agent continuously scans and parses new log entries
  2. Structured log data is pushed to Elasticsearch
  3. Alerts are triggered based on log-based thresholds or anomaly detection rules defined in the

 

 

2. IANN Monitor Lite– Linux Installation Guide

1. Prerequisites and System Requirements

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. CentOS 7, 8, or 9
  2. Ubuntu 20.04 LTS (or equivalent enterprise-supported 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:

  1. The installation must be performed by a user with sudo privileges or equivalent root access for deploying and managing IANN Monitor Server services.

 

  1. The user account running IANN Monitor Client services must have appropriate read, write, and execute permissions for all application directories and log files.

2. Linux Installation Steps

 

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

3. Client Deployment for Linux

 

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/

  • IANN_Monitor_API.jar
  • application.yml
  • config.ini
  • monitor-agent-vm.zip
  • encryptInput.zip

 

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:
  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:

  1. Port:


This is the HTTP port on which your Spring Boot application will run.
 Example:

     server.port = 8180

  1. 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 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;

  1. Username:
    This is the database username that your application will use to connect to the database.
     Example:

     username = my_db_user

  1. Password:

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.

  1. Elasticsearch Configuration [elasticsearch]
  2. Logfile configuration [log_file]
  3. Enable Monitoring configuration [enable_monitoring]
  4. Heartbeat Configuration [heartbeat]
  5. appdata Configuration [appdata]
  6. Database Health Check Configuration ([db_healthcheck])
  7. Sterling Reports Configuration ([sterling_reports])
  8. PCM Stats Configuration ([pcm_stats])
  9. Queue Watcher Configuration
  10. Systemstats configuration([systemstats])
  11. Silogparser Configuration([silogparser])

 

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]
index = <index_prefix>
url = <elasticsearch_url>:<elasticseach_port>
port = <elasticsearch_port>
username = <elasticsearch_username>
password =  <encrypted_elasticsearch_password>

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

 

  1. application_monitoring includes SI application checks, DB health check, Sterling reports, queue watcher, heartbeat, and PCM stats.
  2. vm_metrics_monitoring includes server metrics monitoring.
  3. log_monitoring checks for error logs.

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

  1. ip = [“<IP>;Server Name”]
     Specify the server IP address and its name.

Example:
 ip = [“127.0.0.1:1;WebServer1”, “127.0.0.2.11;DatabaseServer”]

 

  1. urls = [“url;Application Name”]
    Provide the application URL along with a descriptive name.

Example:

urls = [“https://webapp.company.com;WebApp“, “http://api.company.com;APIService“, “http://auth.company.com;AuthService”]

  1. 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.

Example:

Schedule_heatbeat_seconds=300

 

  1. timeout_seconds=10

  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:

  1. set db2 for DB2,
  2. oracle for Oracle,
  3. and sql_server for SQL Server

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]
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>

  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.

  1. username = user1
     Username used for authenticating requests to the queue_url endpoint.
  2. password = aBc123XyZ456+==sDfGhJkLmN0
     Password used for authenticating requests. (Should ideally be stored securely or encrypted.)
  3. Queue_names = q1,q2

 specify the names of queues separated by commas to track their queue depths.
 Note: Monitoring is restricted to a maximum of two queues.

  1.  pool_names=CM_FRAMEWORK,db2Pool

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.

  1. schedule_threads_seconds = 60
     Interval (in seconds) at which the agent schedules general thread-related tasks.
  2. 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 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:

  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”}
   ]

Note : here the list of log path monitored is restricted to only one.

  1. log_modified_milliseconds: The time window (in milliseconds) to consider a log file as recently modified (here set to 1 year).

 

  1. schedule_logparser_seconds: Frequency in seconds to run the log parser.
  2. error_list: List of keywords to look for in logs to catch errors.

 

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

3. IANN Monitor - Windows Installation Guide

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. Prerequisites and System Requirements

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. Windows 8,10 ,11

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

Installation Setup Guide

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

  1. Go to the official NSSM download page:
    1. https://nssm.cc/download

 

  1. Choose the correct version for your OS:
    1. For most users, download the 64-bit version (e.g., nssm-2.24.zip).

Step 2: Extract the ZIP File

  1. Right-click the downloaded ZIP file.
  2. Select Extract All… and extract it to a location like C:\nssm.

Step 3: Verify NSSM Installation

To check if NSSM is installed and working:

  1. Navigate to win64 in nssm installed folder from command prompt and enter the command below.

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.

2. Windows Installation Steps

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

3. Client Deployment

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/

  • IANN_Monitor_API.jar
  • application.yml
  • config.ini
  • monitor-agent-vm.zip
  • encryptInput.zip

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:

  1. Port:
    This is the HTTP port on which your Spring Boot application will run.

Example:

     server.port = 8180

  1. 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 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;

 

  1. Username:
    This is the database username that your application will use to connect to the database.

Example:

            username = my_db_user

  1. Password:

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.

  1. 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: To install the jar, Open Command Prompt from NSSM Folder

  1. Navigate to the nssm folder.
  2. Open the win64 subfolder.
  3. Click on the address bar, type cmd, and press Enter to open the Command Prompt window in that directory.

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

  1. In the NSSM service installer window that appears, click on the three dots next to the Path field.
  2. In the “Path” field, browse and select the java.exe file (usually located inside the Java/bin directory).
  3. In the “Startup directory” field, select the folder where the IANN Monitor API JAR file is located.
  4. Provide “–jar” in arguments field of NSSM
  5. Click OK to confirm.

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.

A screenshot of a computer  AI-generated content may be incorrect.

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.

  1. Elasticsearch Configuration [elasticsearch]
  2. Logfile configuration [log_file]
  3. Enable Monitoring configuration [enable_monitoring]
  4. Heartbeat Configuration [heartbeat]
  5. appdata Configuration [appdata]
  6. Database Health Check Configuration ([db_healthcheck])
  7. Sterling Reports Configuration ([sterling_reports])
  8. PCM Stats Configuration ([pcm_stats])
  9. Queue Watcher Configuration
  10. Systemstats configuration([systemstats])
  11. Silogparser Configuration([silogparser])

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]
index = <index_prefix>
url = <elasticsearch_url>:<elasticseach_port>
port = <elasticsearch_port>
username = <elasticsearch_username>
password =  <encrypted_elasticsearch_password>

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

  1. 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/

  1. Port – This is the network port on which your Elasticsearch instance is listening.

Example: port = 9200

  1. username – The Elasticsearch username that the agent will use to

              authenticate.

 Example: username = elastic_user

  1. 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

  1. application_monitoring includes SI application checks, DB health check, Sterling reports, queue watcher, heartbeat, and PCM stats.
  2. vm_metrics_monitoring includes server metrics monitoring.
  3. log_monitoring checks for error logs.

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

  1. ip = [“<IP>;Server Name”]
     Specify the server IP address and its name.

Example:
 ip = [“127.0.0.1:1;WebServer1”, “127.0.0.2.11;DatabaseServer”, “127.0.0.1.12;CacheServer”]

  1. urls = [“url;Application Name”]
    Provide the application URL along with a descriptive name.

Example:
urls = [“https://webapp.company.com;WebApp“, “http://api.company.com;APIService“, http://auth.company.com;AuthService]

  1. 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.

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:

  1. set db2 for DB2,
  2. oracle for Oracle,
  3. and sql_server for SQL Server

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

  1. 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

  1. 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]
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>

  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.

  1. username = user1
     Username used for authenticating requests to the queue_url endpoint.
  2. password = aBc123XyZ456+==sDfGhJkLmN0
     Password used for authenticating requests. (Should ideally be stored securely or encrypted.)
  3. Queue_names = q1,q2

specify the names of queues separated by commas to track their queue depths.
 Note: Monitoring is restricted to a maximum of two queues.

  1.  pool_names=CM_FRAMEWORK,db2Pool

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.

  1. schedule_threads_seconds = 60
     Interval (in seconds) at which the agent schedules general thread-related tasks.
  2. 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 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:

  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”}
   ]

Note : here the list of log path monitored is restricted to only one.

  1. log_modified_milliseconds: The time window (in milliseconds) to consider a log file as recently modified (here set to 1 year).
  2. schedule_logparser_seconds: Frequency in seconds to run the log parser.
  3. error_list: List of keywords to look for in logs to catch errors.

3.5 Installation of monitor-agent-vm Agent:

Step 1: Extract monitor-agent-vm.zip and Open Command Prompt from the NSSM Folder

  1. Go to the IANN_Monitor_Client path where the monitor-agent-vm.zip file is located. Right-click on monitor-agent-vm.zip and select Extract All
  2. Navigate to the nssm folder.
  3. Open the win64 subfolder.
  4. Click on the address bar, type cmd, and press Enter to open the Command Prompt window in that directory.

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

  1. In the NSSM service installer window that appears, click on the three dots next to the Path field.
  2. Browse and select the monitor-agent-vm.exe located in the server folder.
  3. Click OK to confirm.

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

4. IANN Monitor - OpenShift Deployment

1.Introduction

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:

  1. Server Components: Elasticsearch, Kibana, and the IANN Monitor UI
  2. Client Components: Agents responsible for collecting system metrics, Sterling logs, SSP monitoring, and database health information

By following this guide, you will be able to:

  1. Deploy and configure server components on OpenShift
  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.

2. Prerequisites for IANN Monitor Deployment in OpenShift

Before proceeding with the installation of the IANN application in an OpenShift cluster, ensure the following prerequisites are in place:

  1. Access to the OpenShift Cluster: Verify that you have the necessary permissions to access and manage the target OpenShift cluster.
  2. IANN Helm Package: Ensure you have the Helm package required for deploying the IANN application.
  3. Container Registry Access: Obtain the credentials needed to access the container registry that hosts the IANN application images.
  4. Access to the IANN Namespace: Confirm that you have the appropriate permissions to create and manage resources within the designated namespace in the OpenShift cluster.

2.1 Platform Supported Model and Delivery

The IANN application can be deployed on the following platforms:

  1. RedHat OpenShift Container Platform 4.14
  2. IBM Cloud
  3. AWS Cloud
  4. Azure Cloud
  5. On-Premises Infrastructure

2.2 Versions

  1. IANN-Monitor-Lite

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:

  1. Ensure the OpenShift cluster allows external routes.
  2. TLS can be enabled by editing the route type (edge, passthrough, reencrypt) depending on security requirements.

2.7 Troubleshooting and Recovery Scenarios

Common scenarios and recovery steps are listed below:

  1. Pods Not Running:

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>

  1. Helm Install Fails:


Use this Command followed by a reinstall. Check helm history for rollback options.

  1. Elasticsearch Unhealthy:


Use this Command to check cluster status. Restart pod if needed.

curl -X GET <es-url>:9200/_cluster/health

3. Helm Charts Changes

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

  1. In the root path of helm chart there will be a file name  “appsecret.yaml”. Here we would add the passwords and keep it secret.
  2. Here please provide the values which need to be kept in the values.yaml
  3. The encrypt-elastic-password and encrypt-queueWatcher-password fields must be encrypted using the provided encryption utility. Follow the steps below to generate the encrypted values:

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:

  1. To apply the changes to secret in the cluster, run the following command:

oc apply –f app-secret.yaml

 

  Output: secret/app-secret created

         

  1. This means the secret was successfully created or updated in the cluster using the settings defined in the app-secret.yaml file.

Kubernetes:

  1. To apply the changes to secret in the cluster, run the following command

kubectl apply –f app-secret.yaml

 

Output: secret/app-secret created

  1. This means the secret was successfully created or updated in the cluster using the settings defined in the app-secret.yaml file.

 

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

  1. Provide DB details of the Sterling Integrator. 

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

  1. Provide the Elasticsearch details such as URL, port, username, and secret name which contains the password. Additionally, specify the index name, which must be unique.

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

  1. To enable deployment of the appdata pod, set ‘enable’ to ‘true’ and specify the Beat configurations you want the appdata pod to monitor.
  2. Si_version: Specify the version of the sterling integrator.
  3. jarvis_username: Username to authenticate with the API.
  4. jarvis_password: Password for the Jarvis account.
  5. api_host: Base URL of the API endpoint used for integration.
  6. db_type: Specifies the DB type
  7. scheduled_seconds: Defines a default time interval (300 seconds)  for scheduled tasks or operations.
  8. mailbox_long_running_morethan_mins: 30 – Tracks mailbox processes that have been running for more than 30 minutes.
  9. adapter_list: A list of various adapters (e.g., REST Http Server Adapter, SMTP Send Adapter) used for different integrations or communication protocols
  10. schedulers_list: A list of scheduler jobs or tasks.

 

appdata:

enabled: true

image:

name:                                # Container image repository

tag:                                 # Image tag

pullPolicy: Always

resources:

limits:
  cpu:  1 core
  memory: “1GB” 

requests:

  cpu:  1 Core

  memory: “1GB”

 

configurations:

   Si_version:

 

   jarvis_username: 


   jarvis_password: 


   api_host:

 
   db_type: sql_server


   halted_count_seconds: 1800

 

   adapter_status_seconds: 300

 

   purge_seconds: 1800

 

  

   adapter_list:

 

   schedulers_list:

 

   schedulers_status_seconds: 1800

  

 

 

  1. adapter_status_seconds: 300 – Tracks adapter status every 300 seconds (5 minutes).
  2. halted_count_seconds: 1800 – Tracks halted counts every 1800 seconds (30 minutes).
  3. purge_seconds: 1800 – Tracks purge operations every 1800 seconds.
  4. schedulers_status_seconds: 300 –Tracks scheduler status every 300 seconds.

3.8 PCM Stats Service Configuration

  1. application_ref_query_seconds: 300

Specifies that application reference queries should be tracked every 300 seconds (5 minutes).

  1. tp_ref_query_seconds: 300

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.

  1. ca_certs_seconds: Define the interval, in seconds, for checking CA certificates. For example, “1800” means the check will run every 30 minutes.
  2. system_certs_seconds: Define the interval, in seconds, for checking system certificates. Again, “1800” means the check will run every 30 minutes.
  3. long_running_bp_seconds: Define the interval, in seconds, for checking long-running business processes. Setting this to “1800” means the check will run every 30 minutes.
  4. long_bp_time_seconds: Defines the threshold time (in seconds) that marks a complete business process as long-running.

#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.

  1. cpu_util_seconds: 1800 – Frequency for monitoring CPU utilization
  2. database_check_seconds: 1800 – Frequency for performing a database health check
  3. ram_util_seconds: 1800 – Frequency for monitoring RAM utilization
  4. db_response_time_seconds: 1800 – Frequency for tracking database response
  5. active_sessions_seconds: 1800 – Frequency for monitoring active sessions
  6. inactive_sessions_seconds: 1800 – Frequency for monitoring inactive sessions
  7. total_sessions_seconds: 1800 – Frequency for tracking total sessions
  8. long_running_bp_seconds: Define the interval, in seconds, for checking long-running business processes. Setting this to “1800” means the check will run every 30 minutes.
  9. mailboxes_with_unextracted_messages_seconds: 1800 – Frequency for tracking mailboxes with unextracted messages

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>

  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.

  1. username = user1
     Username used for authenticating requests to the queue_url endpoint.
  2. password = aBc123XyZ456+==sDfGhJkLmN0
     Password used for authenticating requests. (Should ideally be stored securely or encrypted.)
  3. Queue_names = q1,q2

specify the names of queues separated by commas to track their queue depths.
 Note: Monitoring is restricted to a maximum of two queues.

  1.  pool_names=CM_FRAMEWORK,db2Pool

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.

  1. schedule_threads_seconds = 60
     Interval (in seconds) at which the agent schedules general thread-related tasks.
  2. 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:

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

  1. enabled: Set to true to enable heartbeat monitoring.

Image Configuration

  1. name: Container image repository.
  2. tag: Image version (leave empty for latest).
  3. pullPolicy: Always (or IfNotPresent).

Resource Configuration

  1. limits: Define CPU and memory limits.
  2. requests: Define minimum CPU and memory requests.

Heartbeat Parameters

  1. ip: IP address to monitor.
  2. urls: List of URLs to monitor (e.g., [“http://example.com“]).
  3. schedule_heatbeat_seconds: Interval between checks (default: 60).
  4. timeout_seconds: Timeout for each check (default: 10).

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].

  1. application_monitoring includes SI application checks, DB health check, Sterling reports, queue watcher, heartbeat, and PCM stats.
  2. vm_metrics_monitoring includes server metrics monitoring.
  3. log_monitoring checks for error logs.

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:

  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”}
   ]

Note: here the list of log path monitored is restricted to only one.

  1. log_modified_milliseconds: The time window (in milliseconds) to consider a log file as recently modified (here set to 1 year).
  2. schedule_logparser_seconds: Frequency in seconds to run the log parser.
  3. error_list: List of keywords to look for in logs to catch errors.

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

  1. After updating all the values in values.yml we need to install the helm which deploys all the resources in the templates file.
  2. Save the values.yaml file.
  3. To install the helm chart:

helm install <release_name> -f <path of values.yaml>               <path/to/helmchart>

  1. To upgrade the helm chart:

helm upgrade <release_name> -f <path of values.yaml> <path/to/helmchart>

  1. To roll back the helm chart by giving revision number:

helm rollback <release_name> <revision_number>

4. Post-Deployment Validation

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>

Title: Inserting image...

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:

Title: Inserting image...

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.

Title: Inserting image...

To list all secrets in a specific namespace

Openshift:

oc get secrets -n <namespace>

Kubernetes:

kubectl get secret –n <namespace>

 

Title: Inserting image...

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

Title: Inserting image...

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.

Title: Inserting image...

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:
Title: Inserting image...

4.6 Check DB Health Metrics

Confirm database stats (latency, locks, sessions) are visible in the UI or logs.

Title: Inserting image...

4.7 Check Heartbeat and QueueWatcher

Make sure your heartbeat monitors IPs/URLs.

Confirm QueueWatcher is pulling queue info.

Title: Inserting image...

Title: Inserting image...

4.8 Check Systemstats

Verify pod and node data is being collected.

Title: Inserting image... 

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.

Title: Inserting image...