Application Monitoring Overview
You can run the monitoring component of TIBCO BusinessWorks™ Container Edition on the same container platform where TIBCO BusinessWorks Container Edition applications are running. TIBCO BusinessWorks Container Edition applications can be registered with the monitoring application to view application metrics.
When TIBCO BusinessWorks Container Edition application registration fails at container startup because of an unhealthy monitoring container, the monitoring register mechanism is implemented. To configure the monitoring register mechanism, the following properties are used as environment variables:
BW_APP_MON_REGISTER_ATTEMPTS(#) (Default : 5)
BW_APP_MON_REGISTER_DELAY(ms) (Default: 5000)
Once the retry count exhausts, the monitoring application does not register and the user needs to restart the container.
To change log levels in application monitoring, the following log levels is used:
Property name: LOG_LEVEL
For example,
- LOG_LEVEL="debug"
- LOG_LEVEL="error"
- LOG_LEVEL="warning"
- LOG_LEVEL="info"
Health check for monitoring application is verified using the following API:
http://host:port/api/v1/monitor/health
.
If the monitoring container is healthy it returns
200K
, else the returned response is
500 Internal Server Error.
At container startup, when the monitoring services fail to connect to the database due to database unavailability, the connection retry mechanism is implemented. To configure the database retry mechanism, the following properties are used as environment variables:
DB_RETRY_COUNT : default set to 10
DB_RETRY_INTERVAL : default set to 10000 ms.
Once the retry count exhausts, the monitoring application crashes automatically.
When a TIBCO BusinessWorks Container Edition application on Cloud Foundry takes time to generate an accessible routing URL, which causes registration failure at container startup, the retry mechanism is implemented for retrying the routing URL accessibility. To configure this retry mechanism, the following properties are used as environment variables:
ROUTING_ACCESSIBILITY_ATTEMPTS(#)(default : 20)
ROUTING_ACCESSIBILITY_DELAY(ms)(default : 6000)
Once the retry mechanism exhausts, the TIBCO BusinessWorks Container Edition container application does not register with the monitoring application, and the user needs to restart the container with higher values.
The DB_URL environment variable is used to provide database-specific information to run the application monitoring containers. The default format of the URL is:
docker run -it --rm -p 48080:8080 -e PERSISTENCE_TYPE="postgres" -e DB_URL="postgres://<username:password>@<machine:port/database>" --name <containerName><monitoringImageName:tag>
The DB_URL can also be segregated into the following environment variables:
-
DB_NAME
-
DB_USER
-
DB_PWD
-
DB_HOST
-
DB_PORT
To use the above environment variables, refer to the below docker command:
docker run -it --rm -p 6151:8080 -e PERSISTENCE_TYPE="<DBTYPE>" -e DB_NAME="<DB_Name>" -e DB_USER="<Username>" -e DB_PWD="<DB_Password>" -e DB_HOST="<HOST_Address>" -e DB_PORT="<DB_Port>" --name <containerName><monitoringImageName:tag>
To avoid exposure of passwords in the free text form, we can obfuscate the password in the DB_PWD environment variable using the npm run obfuscate plainpassword
on command line.
The VALIDATE_DB_URL boolean environment variable is added to skip DB_URL validation. The default value for the environment variable is
True. If you want to use the DB_URL in any format other than its default format
[DBTYPE]://[UserName]:[Password]@[machineName]:[PORT]/[DBNAME]
, set the
VALIDATE_DB_URL environment variable to
False. When set to
false, the DB_URL validation is skipped entirely.