Agent configuration files · WorkFusion Documentation

The out-of-the-box (OOTB) configuration of Platform Monitor is available after the installation of the WorkFusion platform (on-premise-flat).

Directory structure of OOTB files

OOTB files are located on all the Linux servers (APM, APP, DB, OCR, AutoML) under <INSTALL_DIR>/wfagent/settings/ folder.

The following configuration files are available on the listed servers:

Component name	Service name	Approach to configure the log level
Control Tower	control-tower	Profile
WorkSpace	workspace	Profile
WorkSpace API	workspace-api	Profile
Manual Task Renderer	manual-task-renderer	Explicit
Worker Management Service	worker-management-service	Explicit
Task Dispatcher Service	task-dispatcher-service	Explicit
Bot Manager	bot-manager	Explicit
Bot Agent	bot-agent	Explicit
OCR REST	ocr-rest	Explicit
OCR Worker	ocr-worker	Explicit
AutoML Gateway Service	automl-gateway-service	Explicit
AutoML Model Service	automl-model-service	Explicit
AutoML Model Management Service	automl-model-management-service	Explicit
AutoQC (sqc)	sqc	Explicit

APM server configuration

common.yml

This configuration file describes general configuration of master Platform Monitor.

See common.yml file description

The file consists of five main parts:

The first part contains server port where our platform monitor is deployed.
```
server.port: 10101
```
The second part contains link to datasource (MongoDB) where Platform Monitor reads metrics.
```
metrics.history.source: MongoDb
```
The third part contains information about datasource where Platform Monitor saves metrics.
```
reporter:
  mongo:
    enabled: true
    source: MongoDb
```

The fourth part contains checks which need for deleting older information from agent Platform Monitors.

checks:

  - id: agent.cleanup
    type: custom
    schedule: 20
    evaluate:
      - id: agent.alive

  - id: agent.check
    type: custom
    schedule: 20
    evaluate:
      - { id: agent.validate, parameters: { ns: app }, metric_name: app }
      - { id: agent.validate, parameters: { ns: db }, metric_name: db }
      - { id: agent.validate, parameters: { ns: ocr }, metric_name: ocr }
      - { id: agent.validate, parameters: { ns: ml }, metric_name: ml }

The fifth part contains checks of Linux Platform Monitor.

checks:

  - id: server.disk
    type: java
    evaluate:
      - { id: disk.space, arg: "/", metric_name: root }
      - { id: disk.space, arg: "{{ install_dir }}", metric_name: install }

  - id: server.memory
    type: command
    expression: "cat /proc/meminfo"
    evaluate:
      - { id: table.value.index, arg: "0,MemTotal,1", metric_name: memtotal }
      - { id: table.value.index, arg: "0,MemFree,1", metric_name: memfree }
      - { id: table.value.index, arg: "0,Cached,1", metric_name: cached }
      - { id: table.value.index, arg: "0,Buffers,1", metric_name: buffers }
      - { id: table.value.index, arg: "0,SwapTotal,1", metric_name: swaptotal }
      - { id: table.value.index, arg: "0,SwapFree,1", metric_name: swapfree }
      - { id: expression, arg: "%memfree% + %cached% + %buffers%", metric_name: available }

  - id: server.cpu.amount
    type: command
    expression: "lscpu"
    evaluate:
      - { id: table.value.index, arg: "0,CPU[(]s,1", metric_name: cpuamount }

  - id: server.cpu.util
    type: command
    expression: "cat /proc/loadavg"
    evaluate:
      - { id: command.cpu.util, metric_name: load, type: double }

  - id: server.cpu.util
    type: command
    expression: "sar -u 1 -t 1"
    evaluate:
      - { id: table.value.index, arg: "0,Average,7", metric_name: idle, type: double }
      - { id: expression, arg: "100.0 - %idle%", metric_name: load, type: double }

group.yml

The configuration file defines groups of components

  groups:
   - { id: app, name: APP Components }
   - { id: db, name: DB Components }
   - { id: ml, name: ML Components }
   - { id: pm, name: Platform Monitor }
   - { id: ocr, name: OCR Components }

vault_secret.yml

The configuration file describes Vault client configuration.

mongodb-apm.yml

The configuration file describes configuration of mongo datasource and checks for it.

See mongodb-apm.yml file desctiption

The file consists of three main parts:

The first part contains environment variables which need to create connection to MongoDB.

Values of variables are not real and are used just as an example.

environment:
  mongodb_apm_hostname: localhost
  mongodb_apm_database: wfagent
  mongodb_apm_port: 13017
  mongodb_apm_user: wfagent
  mongodb_apm_password: password
  mongodb_apm_read_only_user: wfagent
  mongodb_apm_read_only_password: password

The second part contains command for restarting MongoDb:

commands:
  - id: restart_mongo_apm
    type: command
    proxy: true
    expression: "%install_dir%/apps/mongodb/mongod.init restart"

The third part contains checks that get current status of database and the Mongo server:

checks:
  - id: mongodb.db.apm
    type: mongo
    expression: "{ dbStats: 1 }"
    source: mongodb_apm_datasource
    evaluate:
     - { id: mongo.object, arg: dataSize, type: double, metric_name: size }
     - { id: mongo.object, arg: ok, type: double, metric_name: ok }

  - id: mongodb.server.apm
    type: mongo
    expression: "{ serverStatus: 1 }"
    source: mongodb_apm_datasource
    evaluate:
     - { id: mongo.object, arg: ok, type: double, metric_name: ok }
     - { id: mongo.object, arg: version, type: string, metric_name: version }

rpa.yml

The configuration file describes recovery mode for RPA Bot Relay.

What does recovery mode means? Recovery mode is mechanism of bootstrapping of RPA part.
How it works? We check our remote RPA Platform Monitor to know if it is running or not. If our remote Platform Monitor installed on a Windows machine doesn't work, Platform Monitor installed on a Linux machine creates an RDP session. This session will be closed in 60 seconds. When the user logs in remotely, Platform Monitor will start. This command is impossible to run from UI.

See rpa.yml file description

server.port: 10101

modules.pmrpa:

  credentials:
    - id: rpahostname1
      user: user
      password: password
      
  alerts:
    - id: agent.rpa.%host%
      triggers:
        - { metric: agent.check.rpa.%host%.size, eq: 0 }
      items: rpa.hubs
  
  checks:
    - id: agent.check.rpa.%host%
      type: custom
      schedule: 20
      evaluate:
        - { id: agent.validate, parameters: { ns: "%host%:10000" }, metric_name: "size" }
      items: rpa.hubs
      
  processes:
    - id: xvfb
      expression: "Xvfb :0 -ac"
      
  commands:
    - id: agent.%host%.start
      type: command
      expression: timeout 10 rdesktop -0 -u %user% %host%  -p '%password%'
      credentials: "%host%"
      schedule: 120
      alerts: [ agent.rpa.%host% ]
      items: rpa.hubs

notifications.yml

The configuration file describes email notifications.

notifications.enabled: False
notifications.sender: no-reply@example.com
notifications.to:  admin@localhost
notifications.topics:
  - template: incident-created
  - template: incident-updated
  - template: component-updated

spring.mail.host: localhost
spring.mail.port: 25
spring.mail.username: wfadmin
spring.mail.password: wfadmin
spring.mail.protocol: smtp

See more details in Notification configuration.

nginx.yml

The configuration file describes nginx configuration of Application Platform Monitor.

See nginx.yml file description

The file consists of three main parts:

The first part contains information about component and alert which are connected with Nginx.

components:
  - { id: nginx, name: Nginx, group: app, description: "Nginx component", alerts: [ nginx ] }
alerts:
  - id: nginx
    triggers:
      - { metric: nginx.monitoring.status, neq: 0, message: "Problem with nginx connection" }

The second part contains command for restarting Nginx.

commands:
  - id: restart.nginx
    type: command
    proxy: true
    expression: "%install_dir%/apps/nginx/nginx.init restart"

The third part contains a check:

checks:
  - id: nginx.monitoring
    type: tcp
    source: Nginx

filebeat.yml

The configuration file describes filebeat configuration of Application Platform Monitor.

See filebeat.yml file description

The file consists of three main parts:

The first part contains information about component and alert which are connected with Filebeat.

components:
  - { id: service.filebeat, name: "Filebeat", group: "{{  wfa_group[server_role].id }}", alerts: [ service.filebeat ] }
alerts:
  - id: service.filebeat
    triggers:
      - { metric: service.filebeat.state, neqs: "RUNNING", message: "Filebeat is not running" }

The second part contains command for restarting Filebeat.

commands:
  - id: restart.service.filebeat
    type: command
    proxy: true
    expression: "/opt/workfusion/python-site/bin/wfmanager restart filebeat"

The third part contains a check.

checks:
  - id: service.filebeat
    type: command
    expression: "/opt/workfusion/python-site/bin/wfmanager status filebeat"
    evaluate:
     - { id: table.value.index, arg: "0,filebeat,1", type: string, metric_name: state }

logstash.yml

The configuration file describes logstash configuration of Application Platform Monitor.

See logstash.yml file description

The file consists of three main parts:

The first part contains information about component and alert which are connected with logstash.

components:
  - { id: service.logstash, name: "Logstash", group: "%agent.ns%", alerts: [ service.logstash ] }
alerts:
  - id: service.logstash
    triggers:
      - { metric: service.logstash.filebeat.status, neq: 0, message: "Problem with Logstash filebeat pipeline tcp check" }
      - { metric: service.logstash.filebeat.listening, neq: 1, message: "No Logstash filebeat pipeline TCP port is listening" }
      - { metric: service.logstash.automl.status, neq: 0, message: "Problem with Logstash automl pipeline tcp check" }
      - { metric: service.logstash.automl.listening, neq: 1, message: "No Logstash automl pipeline TCP port is listening" }

The second part contains a command for restarting logstash.

commands:
  - id: restart.service.logstash
    type: command
    proxy: true
    expression: "/opt/workfusion/python-site/bin/wfmanager restart logstash"

The third part contains a check:

checks:
  - id: service.logstash.filebeat
    type: tcp
    source: LogstashFilebeatTcp
  - id: service.logstash.automl
    type: tcp
    source: LogstashAutomlTcp

Application server configuration

common.yml

The configuration file describes general configuration of Agent Platform Monitor on the application server.

See common.yml file description

This file consists of three main parts:

The first part contains server port where our Platform Monitor is deployed.
```
server.port: 10101
```

The second part contains a heck for sync with master Platform Monitor.

checks:
    - id: pm.sync
      type: sync
      schedule: 20
      expression: "{{ http_scheme }}://{{ wfagent_master_host }}:{{ nginx_apm_ext_port }}/{{ wfa_path_context }}/api/proxy"
      credentials: ${environment.agent.credentials}

The third part contains checks of Linux Platform Monitor.

checks:

  - id: server.disk
    type: java
    evaluate:
      - { id: disk.space, arg: "/", metric_name: root }
      - { id: disk.space, arg: "{{ install_dir }}", metric_name: install }

  - id: server.memory
    type: command
    expression: "cat /proc/meminfo"
    evaluate:
      - { id: table.value.index, arg: "0,MemTotal,1", metric_name: memtotal }
      - { id: table.value.index, arg: "0,MemFree,1", metric_name: memfree }
      - { id: table.value.index, arg: "0,Cached,1", metric_name: cached }
      - { id: table.value.index, arg: "0,Buffers,1", metric_name: buffers }
      - { id: table.value.index, arg: "0,SwapTotal,1", metric_name: swaptotal }
      - { id: table.value.index, arg: "0,SwapFree,1", metric_name: swapfree }
      - { id: expression, arg: "%memfree% + %cached% + %buffers%", metric_name: available }

  - id: server.cpu.amount
    type: command
    expression: "lscpu"
    evaluate:
      - { id: table.value.index, arg: "0,CPU[(]s,1", metric_name: cpuamount }

  - id: server.cpu.util
    type: command
    expression: "cat /proc/loadavg"
    evaluate:
      - { id: command.cpu.util, metric_name: load, type: double }

  - id: server.cpu.util
    type: command
    expression: "sar -u 1 -t 1"
    evaluate:
      - { id: table.value.index, arg: "0,Average,7", metric_name: idle, type: double }
      - { id: expression, arg: "100.0 - %idle%", metric_name: load, type: double }

rpa-manager.yml

The configuration file describes Bot Manager configuration of Application Platform Monitor.

See rpa-manager.yml file description

The file consists of four main parts:

The first part contains information about component and alert connected with Bot Manager.

components:
  - { id: rpa.gr, name: "Bot Manager", group: app, alerts: [ rpa.gr ] }

alerts:
  - id: rpa.gr
    triggers:
      - { metric: rpa.gr.hubs.status, neq: 0, message: "Bot Manager web check failed" }
      - { metric: rpa.gr.hubs.http.code, neq: 200, message: "Bot Manager has non-200 response code" }
      - { metric: rpa.gr.hc.status, neq: 0, message: "Bot Manager Healthcheck failed" }
      - { metric: rpa.gr.hc.http.code, neq: 200, message: "Bot Manager Healthcheck API has non-200 response code" }
      - { metric: rpa.gr.hc.health.check.errors, neq: 0, message: "Healthcheck API response contains errors", type: partial_outage }
      - { metric: rpa.gr.hc.health.check.warnings, neq: 0, message: "Healthcheck API response contains warnings", type: partial_outage }

The second part contains command for restarting Bot Manager.

commands:
  - id: restart.bot.manager
    type: command
    proxy: true
    expression: "%install_dir%/apps/rpa_manager/rpa_manager restart"

The third part contains checks.

checks:
  - id: rpa.gr.hubs
    description: "Generate all hubs from SG"
    type: http
    expression: "/api/selenograph/hubs"
    source: RpaGridRouter
    evaluate:
      - { id: rpa.manager.hubs, arg: rpa.hubs }

  - id: rpa.gr.host.%host%
    type: http
    expression: /api/metrics/hub/%host%
    description: "Get hub's metrics from SG"
    source: RpaGridRouter
    ns: "%host%:%port%"
    evaluate:
       - { id: http.json, arg: "register_all" }
    items: rpa.hubs

  - id: rpa.gr.node.%origin%.%port%
    type: http
    expression: /api/metrics/node/%origin%:%port%
    description: "Get nodes's metrics from SG"
    source: RpaGridRouter
    ns: "%origin%:%port%"
    evaluate:
       - { id: http.json, arg: "register_all" }
    items: nodes

The fourth part contains health checks.

checks:
  - id: rpa.gr.hc
    description: "Get Bot Manager health check info"
    type: http-json
    source: RpaGridRouter
    expression: "/api/healthcheck"
    evaluate:
      - { id: health.check, arg: rpa.gr }

workfusion.yml

The configuration file describes Сontrol Tower configuration of Application Platform Monitor.

See workfusion.yml file description

The file consists of four main parts:

The first part contains information about component and alert connected with Control Tower:

components:
  - { id: ct, name: Control Tower, group: app, alerts: [ ct ] }

alerts:
  - id: ct
    triggers:
      - { metric: ct.login.status, neq: 0, message: "Web check failed" }
      - { metric: ct.login.http.code, neq: 200, message: "Bad response code" }
      - { metric: ct.hc.status, neq: 0, message: "Healthcheck API call failed" }
      - { metric: ct.hc.http.code, neq: 200, message: "Healthcheck API has bad response code" }
      - { metric: ct.hc.health.check.errors, neq: 0, message: "Healthcheck API response contains errors", type: partial_outage }
      - { metric: ct.hc.health.check.warnings, neq: 0, message: "Healthcheck API response contains warnings", type: partial_outage }

The second part contains command for restarting Control Tower:

commands:
  - id: restart.control.tower
    type: command
    proxy: true
    expression: "{{ python_site_dir }}/bin/wfmanager restart workfusion"

The third part contains a check:

- id: ct.login
  type: http
  expression: "/%wf_art_name%/login"
  source: Nginx

The fourth part contains health checks:

checks:

  - id: ct.hc
    description: "Get ControlTower health check info"
    type: http-json
    source: Nginx
    expression: "/workfusion/api/v1/health-check?checkExternalComponents=true"
    evaluate:
      - { id: health.check, arg: ct }

wfbi.yml

The configuration file describes service WFBI configuration of Application Platform Monitor.

See wfbi.yml file description

The file consists of three main parts:

The first part contains information about component and alert connected with service WFBI.

components:
  - { id: service.wfbi, name: "Service WFBI", group: app, description: "Version %service.wfbi.version%", alerts: [ service.wfbi ] }


alerts:
  - id: service.wfbi
    triggers:
      - { metric: service.wfbi.status, neq: 0, message: "Web check failed" }
      - { metric: service.wfbi.http.code, neq: 200, message: "Bad response code" }

The second part contains command for restarting service WFBI.

commands:
  - id: restart.service.wfbi
    type: command
    proxy: true
    expression: "%install_dir%/apps/webapps/tomcat.init restart"

The third part contains a check.

checks:
  - id: service.wfbi
    type: http
    expression: "/service-wfbi/tableau/project-info"
    source: Nginx
    credentials: ServiceWfbi
    evaluate:
     - { id: http.json, arg: version, type: string, metric_name: version }

workspace-production.yml

The configuration file describes Workspace production configuration of Application Platform Monitor.

See workspace-production.yml file description

The file consists of three main parts:

The first part contains information about component and alert which are connected with WorkSpace.

components:
  - { id: ws_prod, name: WorkSpace, group: app, alerts: [ ws_prod ] }

alerts:
  - id: ws_prod
    triggers:
      - { metric: ws_prod.dashboard.status, neq: 0, message: "Web check failed" }
      - { metric: ws_prod.dashboard.http.code, neq: 200, message: "Bad response code" }
      - { metric: ws_prod.hc.status, neq: 0, message: "Healthcheck API call failed" }
      - { metric: ws_prod.hc.http.code, neq: 200, message: "Healthcheck API has bad response code" }
      - { metric: ws_prod.hc.health.check.errors, neq: 0, message: "Healthcheck API response contains errors", type: partial_outage }
      - { metric: ws_prod.hc.health.check.warnings, neq: 0, message: "Healthcheck API response contains warnings", type: partial_outage }

The second part contains command for restarting WorkSpace.

commands:
  - id: restart.workspace_production
    type: command
    proxy: true
    expression: "{{ python_site_dir }}/bin/wfmanager restart workspace_production"

The third part contains a check.

checks:
  - id: ws_prod.dashboard
    type: http
    expression: "/workspace/index.htm"
    source: ws_prod.datasource

  - id: ws_prod.hc
    description: "Get Workspace health check info"
    type: http-json
    source: ws_prod.datasource
    expression: "/workspace/api/monitor/health-check"
    evaluate:
      - { id: health.check, arg: ws_prod }

workspace-sandbox.yml

The configuration file describes WorkSpace Sandbox configuration of Application Platform Monitor.

See workspace-sandbox.yml file description

The file consists of four main parts:

The first part contains information about components and alerts connected with WorkSpace.

components:
  - { id: ws_sandbox, name: WorkSpace Sandbox, group: app, alerts: [ ws_sandbox ] }

alerts:
  - id: ws_sandbox
    triggers:
      - { metric: ws_sandbox.dashboard.status, neq: 0, message: "Web check failed" }
      - { metric: ws_sandbox.dashboard.http.code, neq: 200, message: "Bad response code" }
      - { metric: ws_sandbox.hc.status, neq: 0, message: "Healthcheck API call failed" }
      - { metric: ws_sandbox.hc.http.code, neq: 200, message: "Healthcheck API has bad response code" }
      - { metric: ws_sandbox.hc.health.check.errors, neq: 0, message: "Healthcheck API response contains errors", type: partial_outage }
      - { metric: ws_sandbox.hc.health.check.warnings, neq: 0, message: "Healthcheck API response contains warnings", type: partial_outage }

The second part contains command for restarting WorkSpace.

commands:
  - id: restart.workspace_sandbox
    type: command
    proxy: true
    expression: "{{ python_site_dir }}/bin/wfmanager restart workspace_sandbox"

The third part contains checks.

checks:
  - id: ws_sandbox.dashboard
    type: http
    expression: "/workspace-sandbox/index.htm"
    source: ws_sandbox.datasource

  - id: ws_sandbox.hc
    description: "Get Workspace Sandbox health check info"
    type: http-json
    source: ws_sandbox.datasource
    expression: "/workspace-sandbox/api/monitor/health-check"
    evaluate:
      - { id: health.check, arg: ws_sandbox }

Database server configuration

mongodb-ocr.yml

The configuration file describes configuration of mongo datasource (of OCR) and check for it.

See mongodb-ocr.yml file description

The file consists of three main parts:

The first part contains enviroment variables needed to create a connection to MongoDB.

Values of variables are not real and are used just as an example.

environment:
  mongodb_ocr_hostname: localhost
  mongodb_ocr_database: wfagent
  mongodb_ocr_admin_database: admin
  mongodb_ocr_port: 13017
  mongodb_ocr_read_only_user: wfagent
  mongodb_ocr_read_only_password: password

The second part contains a command for restarting MongoDb.

commands:
  - id: restart_mongo_ocr
    type: command
    proxy: true
    expression: "%install_dir%/apps/mongodb/mongod.init restart"

The third part contains checks needed to get the current status of database and Mongo server.

checks:
  - id: mongodb.db.ocr
    type: mongo
    expression: "{ dbStats: 1 }"
    source: mongodb.ocr.datasource
    evaluate:
     - { id: mongo.object, arg: dataSize, type: double, metric_name: size }
     - { id: mongo.object, arg: ok, type: double, metric_name: ok }

  - id: mongodb.server.ocr
    type: mongo
    expression: "{ serverStatus: 1 }"
    source: mongodb.ocr.admin.datasource
    evaluate:
     - { id: mongo.object, arg: ok, type: double, metric_name: ok }
     - { id: mongo.object, arg: version, type: string, metric_name: version }

mongodb-rpa.yml

The configuration file describes configuration of mongo datasource (for RPA) and checks for it.

See mongodb-rpa.yml file description

The file consists of three main parts:

The first part contains enviroment variables which need to create connection to MongoDB.

Values of variables are not real and are used just as an example.

environment:
  mongodb_rpa_hostname: localhost
  mongodb_rpa_database: wfagent
  mongodb_rpa_admin_database: admin
  mongodb_rpa_port: 13017
  mongodb_rpa_read_only_user: wfagent
  mongodb_rpa_read_only_password: password

The second part contains a command for restarting MongoDb.

commands:
  - id: restart_mongo_rpa
    type: command
    proxy: true
    expression: "%install_dir%/apps/mongodb/mongod.init restart"

The third part contains checks needed to get the current status of database and Mongo server.

checks:
  - id: mongodb.db.rpa
    type: mongo
    expression: "{ dbStats: 1 }"
    source: mongodb.rpa.datasource
    evaluate:
     - { id: mongo.object, arg: dataSize, type: double, metric_name: size }
     - { id: mongo.object, arg: ok, type: double, metric_name: ok }

  - id: mongodb.server.rpa
    type: mongo
    expression: "{ serverStatus: 1 }"
    source: mongodb.rpa.admin.datasource
    evaluate:
     - { id: mongo.object, arg: ok, type: double, metric_name: ok }
     - { id: mongo.object, arg: version, type: string, metric_name: version }

mysql.yml

The configuration file describes MySql database configuration of Platform Monitor.

See mysql.yml file description

The file consists of three main parts:

The first part contains information about component and alert connected with MySql.

  components:
    - { id: mysql, name: MySQL, group: db, description: "Version %mysql.query2.version%", alerts: [ mysql ] }
  alerts:
    - id: mysql
      triggers:
        - { metric: mysql.query1.status, neq: 0, message: "Problem with mysql query" }

The second part contains a command for restarting MySql.

  commands:
    - id: restart.mysql
      type: command
      proxy: true
      expression: "%install_dir%/apps/mysql/mysql.init restart"

The third part contains checks.

  checks:
    - id: mysql.query1
      type: sql
      expression: "select database() as db"
      source: Mysql
      evaluate:
        - { id: sql.output, arg: db, type: string, metric_name: name }
  
    - id: mysql.query2
      type: sql
      expression: "select version() as version"
      source: Mysql
      evaluate:
        - { id: sql.output, arg: version, type: string, metric_name: version }

nexus.yml

The configuration file describes Nexus database configuration of Platform Monitor.

See nexus.yml file description

The file consists of three main parts:

The first part contains information about component and alert connected with Nexus.

  components:
    - { id: nexus, name: Nexus, group: db, description: "Nexus component", alerts: [ nexus ] }
  alerts:
    - id: nexus
      triggers:
        - { metric: nexus.monitoring.status, neq: 0, message: "Problem with nexus connection" }

The second part contains a command for restarting Nexus.

  commands:
    - id: restart.nexus
      type: command
      proxy: true
      expression: "%install_dir%/apps/nexus/nexus/bin/nexus restart"

The third part contains checks.

  checks:
    - id: nexus.monitoring
      type: http
      expression: "/nexus/service/local/status"
      source: Nexus
      parameters:
        accept_type: "application/json"
      evaluate:
        - { id: http.json, arg: register_all }

postgres.yml

The configuration file describes PostgreSQL database configuration of Platform Monitor.

See postgres.yml file description

The file consists of three main parts:

The first part contains information about component and alert connected with PostgreSQL.

  components:
    - { id: postgres, name: PostgreSQL, group: db, description: "Version %postgres.query2.version%", alerts: [ postgres ] }
  alerts:
    - id: postgres
      triggers:
        - { metric: postgres.query1.status, neq: 0, message: "Problem with postgres query" }

The second part contains a command for restarting PostgreSQL.

  commands:
    - id: restart.postgres
      type: command
      proxy: true
      expression: "%install_dir%/apps/pgsql/%postgres_version%/data/postgresql-%postgres_version%.init restart"

The third part contains checks.

  checks:
    - id: postgres.query1
      type: sql
      expression: "select current_database() as db"
      source: Postgres
      evaluate:
        - { id: sql.output, arg: db, type: string, metric_name: name }
    - id: postgres.query2
      type: sql
      expression: "select version() as version"
      source: Postgres
      evaluate:
        - { id: sql.output, arg: version, type: string, metric_name: version }

s3.yml

The configuration file describes MinIO or Riak configuration of Platform Monitor.

See s3.yml file description for MinIO

The file for MinIO consists of two main parts:

The first part contains information about component and alert connected with MinIO.

components:
  - { id: minio, name: "File Storage (Minio)", group: db, alerts: [ minio ] }

commands:
  - id: restart.minio
    type: command
    proxy: true
    expression: "{{ python_site_dir }}/bin/wfmanager restart minio"

alerts:
  - id: minio
    triggers:
      - { metric: minio.tcp.status, neq: 0, message: "Problem with riak.tcp check" }
      - { metric: minio.tcp.listening, neq: 1, message: "No TCP port is listening" }
      - { metric: minio.stats.status, neq: 0, message: "Web check failed" }
      - { metric: minio.stats.http.code, neq: 200, message: "Bad response code" }

The second part contains checks.

checks:
  - id: minio.stats
    type: http
    expression: "/minio/health/ready"
    source: Minio

  - id: minio.tcp
    type: tcp
    source: MinioTcp

See s3.yml file description for Riak

The file for Riak consists of two main parts:

The first part contains information about component and alert connected with Riak.

commands:
  - id: restart.riak
    type: command
    proxy: true
    expression: "{{ python_site_dir }}/bin/wfmanager restart riak riak-cs riak-stanchion"

alerts:
  - id: riak
    triggers:
      - { metric: riak.stats.status, neq: 0, message: "Web check failed" }
      - { metric: riak.stats.http.code, neq: 200, message: "Bad response code" }
      - { metric: riak.tcp.status, neq: 0, message: "Problem with riak.tcp check" }
      - { metric: riak.tcp.listening, neq: 1, message: "No TCP port is listening" }
      - { metric: stanchion.tcp.status, neq: 0, message: "Problem with stanchion.tcp check" }
      - { metric: stanchion.tcp.listening, neq: 1, message: "No TCP port is listening" }
      - { metric: riakcs.tcp.status, neq: 0, message: "Problem with riakcs.tcp check" } 
      - { metric: riakcs.tcp.listening, neq: 1, message: "No TCP port is listening" }

The second part contains checks.

checks:
  - id: riak.stats
    type: http
    expression: "/stats"
    source: Riak
    evaluate:
      - { id: http.json, arg: "riak_core_version", type: string, metric_name: version }

  - id: riak.tcp
    type: tcp
    source: RiakTcp

  - id: stanchion.tcp
    type: tcp
    source: StanchionTcp

  - id: riakcs.tcp
    type: tcp
    source: RiakCsTcp

vault.yml

The configuration file describes Vault configuration of Platform Monitor.

See vault.yml file description

The file consists of three main parts:

The first part contains information about component and alert connected with Vault.

components:
  - { id: vault, name: Vault, group: db, description: "Vault component", alerts: [ vault ] }

alerts:
  - id: vault
    triggers:
      - { metric: vault.monitoring.status, neq: 0, message: "Problem with vault connection" }

The second part contains command for restarting Vault.

commands:
  - id: restart.vault
    type: command
    proxy: true
    expression: "%install_dir%/apps/vault/vault.init restart"

The third part contains checks.

checks:
  - id: vault.monitoring
    type: tcp
    source: Vault

OCR server configuration

ocr.yml

rest module

The configuration file describes OCR Rest configuration of OCR Platform Monitor.

See ocr.yml file description (rest module)

The file consists of four main parts:

The first part contains information about component and alert connected with OCR Rest.

components:
  - { id: ocr.rest, name: OCR Rest, group: ocr, description: "Version %ocr.rest.info.version%", alerts: [ ocr.rest ] }

alerts:
  - id: ocr.rest
    triggers:
      - { metric: ocr.rest.api.status, neq: 0, message: "OCR API check failed" }
      - { metric: ocr.rest.api.time, gte: 20000, type: performance, message: "OCR API has long response time" }
      - { metric: ocr.rest.api.http.code, neq: 200, message: "OCR API has non-200 response code" }  
      - { metric: ocr.hc.status, neq: 0, message: "OCR Healthcheck call failed " }
      - { metric: ocr.hc.http.code, neq: 200, message: "OCR API has non-200 response code" }
      - { metric: ocr.hc.health.check.errors, neq: 0, message: "OCR Healthcheck API response contains errors", type: partial_outage }
      - { metric: ocr.hc.health.check.warnings, neq: 0, message: "OCR Healthcheck API response contains warnings", type: partial_outage }

The second part contains a command for restarting OCR Rest.

commands:
  - id: restart.ocr
    type: command
    proxy: true
    expression: "%install_dir%/apps/ocr/ocr2.init restart"

The third part contains checks.

checks:
  - id: ocr.rest.api
    type: http
    expression: "/"
    source: OcrRest

  - id: ocr.rest.summary
    type: http
    expression: "/api/v1/cloud/summary"
    source: OcrRest

  - id: ocr.rest.info
    type: http
    expression: "/api/project-info"
    source: OcrRest
    evaluate:
     - { id: http.json, arg: version, type: string, metric_name: version }

  - id: ocr.rest.tasks
    type: http
    expression: "/api/v1/metrics/count?status=PROCESSING&period=1440"
    source: OcrRest
    evaluate:
     - { id: http.response, type: int, metric_name: processing }

The fourth part contains health checks.

checks:
  - id: ocr.hc
    description: "Get OCR health check info"
    type: http-json
    source: OcrRest
    expression: "/api/v1/health-check"
    evaluate:
      - { id: health.check, arg: ocr.rest }

worker module

The configuration file describes OCR worker configuration of OCR Platform Monitor.

See ocr.yml file description (worker module)

The file consists of two main parts:

The first part contains information about component and alert connected with OCR worker.

components:
  - { id: ocr.worker, name: OCR Worker, group: ocr, alerts: [ ocr.worker ] }

alerts:
  - id: ocr.worker
    triggers:
      - { metric: ocr.worker.status, neq: 0, message: "Process check command failed" }
      - { metric: ocr.worker.command.exit, neq: 0, message: "OCR worker process not found" }

The second part contains checks.

checks:
  - id: ocr.worker
    type: command
    expression: "pgrep -f ocr-worker-"
    evaluate:
      - { id: command.exit }

AutoML Server

Mesos cluster

The configuration file describes Mesos Cluster configuration of AutoML Platform Monitor.

See vds_cluster.yml file description

The file consists of three main parts:

The first part contains information about the environment that describes the location of Mesos REST API:

vds_cluster.yml environment:

environment:
  mesos_host: localhost
  mesos_port: 5050
  mesos_protocol: https
  mesos_user: admin
  mesos_password: admin

The second part contains information about component and alert connected with Mesos REST API:

vds_cluster.yml component:

credentials:
  - id: mesos
    user: "%mesos_user%"
    password: "%mesos_password%"

components:
  - { id: ml.cluster, name: ML Cluster, group: ml, description: "ML cluster", alerts: [ ml.cluster ]  }

datasources:
  - { id: ml.mesos, protocol: "%mesos_protocol%", host: "%mesos_host%", port: "%mesos_port%", type: http }

alerts:
  - id: ml.cluster
    triggers:
      - { metric: cluster.api.status, neq: 0, message: "Web check failed" }
      - { metric: cluster.api.http.code, neq: 200, message: "Bad response code" }

The third part contains checks:

vds_cluster.yml checks:

checks:
  - id: cluster.api
    type: http
    expression: "/slaves"
    source: ml.mesos
    credentials: mesos

  - id: cluster.memory
    type: http
    expression: "/slaves"
    source: ml.mesos
    credentials: mesos
    evaluate:
       - { id: http.json, arg: "slaves.resources.mem", type: double, metric_name: memtotal }
       - { id: http.json, arg: "slaves.used_resources.mem", type: double, metric_name: used }
       - { id: expression, arg: "%memtotal% - %used%", type: double, metric_name: available }

  - id: cluster.cpu
    type: http
    expression: "/slaves"
    source: ml.mesos
    credentials: mesos
    evaluate:
       - { id: http.json, arg: "slaves.resources.cpus", type: double, metric_name: amount.cpuamount }
       - { id: http.json, arg: "slaves.used_resources.cpus", type: double, metric_name: util.cpuamount }

  - id: cluster.disk
    type: http
    expression: "/slaves"
    source: ml.mesos
    credentials: mesos
    evaluate:
       - { id: http.json, arg: "slaves.resources.disk", type: double, metric_name: total }
       - { id: http.json, arg: "slaves.used_resources.disk", type: double, metric_name: used }
       - { id: expression, arg: "%total% - %used%", type: double, metric_name: free }

These checks extract capacity info using Mesos API. Capacity of all resources are represented as a sum of values from all nodes.

AutoML Node

The configuration file describes AutoML Node configuration of AutoML Platform Monitor.

See vds_node.yml file description

The first part contains information about environment of AutoML Node that can be a host name for non standalone installation:

vds_node.yml
```
environment:
  agent.ns: {{ hostname }}
```

The second part contains information about component of Mesos REST API.

vds_node.yml component

components:
  - { id: ml.node, name: ML Node, group: ml, description: "ML node", alerts: [ server ]  }

gateway.yml

The configuration file describes VDS Gateway configuration.

See gateway.yml file description

The file consists of two main parts:

The first part contains information about component and alert connected with VDS Gateway.

components:
  - { id: gateway, name: VDS Gateway, group: ml, description: "Version %gateway.info.version%", alerts: [ gateway ] }

alerts:
  - id: gateway
    triggers:
      - { metric: gateway.api.status, neq: 0, message: "Web check failed" }
      - { metric: gateway.api.time, gte: 30000, type: performance, message: "Long response time" }
      - { metric: gateway.api.http.code, neq: 200, message: "Bad response code" }

The second part contains checks.

checks:
  - id: gateway.api
    type: http
    expression: "/vds-gateway-service/listHyperModels"
    source: VdsGateway
  - id: gateway.info
    type: http
    expression: "/vds-gateway-service/manage/info"
    source: VdsGateway
    evaluate:
      - { id: http.json, arg: build.version, type: string, metric_name: version}

rabbitmq.yml

The configuration file describes the AutoML RabbitMQ configuration.

See rabbitmq.yml file description

The file consists of two main parts:

The first part contains information about component and alert connected with RabbitMQ.

components:
  - { id: rabbitmq, name: VDS RabbitMQ, group: ml, alerts: [ rabbitmq ]  }

alerts:
  - id: rabbitmq
    triggers:
      - { metric: rabbitmq.api.status, neq: 0, message: "Web check failed" }
      - { metric: rabbitmq.api.http.code, neq: 200, message: "Bad response code" }

The second part contains checks.

checks:
  - id: rabbitmq.api
    type: http
    expression: "/api/overview"
    source: RabbitMQ
    credentials: rabbitmq
    evaluate:
      - { id: rabbitmq.summary }
  - id: rabbitmq.queues
    type: http
    expression: "/api/queues"
    credentials: rabbitmq
    source: RabbitMQ
    evaluate:
      - { id: extract }

scaling.yml

The configuration file describes the VDS Scaling Service configuration.

See scaling.yml file description

The file consists of two main parts:

The first part contains information about component and alert.

components:
  - { id: scaling, name: VDS Scaling, group: ml, description: "Version %scaling.info.version%", alerts: [ scaling ]  }

alerts:
  - id: scaling
    triggers:
      - { metric: scaling.api.status, neq: 0, message: "Web check failed" }
      - { metric: scaling.api.time, gte: 30000, type: performance, message: "Long response time" }
      - { metric: scaling.api.http.code, neq: 200, message: "Bad response code" }

The second part contains checks.

checks:
  - id: scaling.api
    type: http
    expression: "/vds-scaling-service/listHyperModels"
    source: VdsScaling
  - id: scaling.info
    type: http
    expression: "/vds-scaling-service/manage/info"
    source: VdsScaling
    evaluate:
      - { id: http.json, arg: build.version, type: string, metric_name: version}