Overview
The following subsections contain the list of parameters that should be monitored in order to properly specify conditions of the application environment. Most of these parameters can be monitored through tools provided by JLupin Platform out-of-the-box. The current state of all components running on the node are collected and provided by Main Server, in omnichannel mode, through the following interfaces:
- JLupin CLI Console - all basic paramters can be found in JLupin CLI Console, it's capable of monitoring Main Server as well as microservices, to get more please refer to CLI Console documentation.
- HTTP Information Api - the same set of data as in case of CLI Console can be also collected using
/getAllEnvironmentState
URI on HTTP Information Api, to get more please refer to HTTP Information Api documentation.
- JLupin JMX Extractor - a smart JMX monitoring tool that is capable of collecting data from Main Server and all microservices in one step, using JMX interfaces. This tool gives the full scope of monitoring data, including custom MBeans defined by a user, to get more please refer to documentation.
NOTICE that we assume that application code is optimized in terms of using resources. If this assumption is not applicable to your case, be advised that code optimization should be performed before adding more resources to your infrastructure.
System parameters
Description
Parameter name |
Description |
CPU Usage |
The basic parameters that reflect amount of available resource in scope of computing. When the value is more than 80% the increase of resources should be taken into consideration (more powerful jBricks or more jBricks). |
Load |
The average number of processes waiting for CPU. When the value exceed the normalized limit (1) the increase of resources should be taken into consideration (ex. more CPU/cores per jBrick or more jBricks) |
Memory usage |
The basic parameters that reflect amount of available resource in scope of memory |
Number of TCP connections / sockets |
The total number of TCP connections in operating system, with particular attention to TIME_WAIT status. If the value exceeds the maximum value the number of microservices per jBrick should be decreased. |
The way of measurement (on the example of JLupin CLI Console)
Parameter name |
Command |
CPU Usage |
node runtime os |
Load |
not available yet, try uptime or vmstat to get it using OS tools directly |
Memory usage |
node runtime os |
Number of TCP connections / sockets |
not available yet, try netstat to get it using OS tools directly |
Platform parameters (Main Server)
Parameter name |
Description |
Cpu Usage |
Percentage usage of CPU by Main Server. |
Mem Usage |
Percentage usage of JVM Heap space of Main Server. |
Threads Usage |
Percentage usage of thread pool associated with specific logical server. |
The way of measurement (on the example of JLupin CLI Console)
Parameter name |
Command |
Cpu Usage |
node runtime cpu |
Mem Usage |
node runtime memory |
Threads Usage |
node runtime threads |
Microservice parameters
Parameter name |
Description |
Status |
Status of a microserice from process manager perspective |
Availability |
Availability of a microservice from Main Server's microservice perspective |
Cpu Usage |
Percentage usage of CPU by a microservice |
Mem Usage |
Percentage usage of JVM Heap space of a microservice |
Threads Usage |
Percentage usage of thread pool associated with a microservice |
The way of measurement (on the example of JLupin CLI Console)
Parameter name |
Command |
Status |
microservice status |
Availability |
microservice status |
Cpu Usage |
microservice runtime cpu |
Mem Usage |
microservice runtime memory |
Threads Usage |
microservice runtime threads |