Edit

Agent configuration files

The out-of-the-box (OOTB) Platform Monitor configuration 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) in the <INSTALL_DIR>/wfagent/settings/ folder.

The following configuration files are available on the listed servers:

APM	APP	DB	OCR	AutoML (Master and Agent)
common.yml group.yml vault_secret.yml mongodb-apm.yml rpa.yml notifications.yml nginx.yml filebeat.yml logstash.yml	common.yml group.yml vault_secret.yml rpa-manager.yml nginx.yml wfbi.yml workspace-production.yml workspace-sendbox.yml workfusion.yml filebeat.yml	common.yml group.yml vault_secret.yml mongodb-ocr.yml mongodb-rpa.yml mysql.yml nexus.yml postgres.yml s3.yml vault.yml nginx.yml filebeat.yml	common.yml group.yml vault_secret.yml ocr.yml rest module worker module nginx.yml filebeat.yml	common.yml group.yml vault_secret.yml vds_node.yml rabbitmq.yml gateway.yml vds_cluster.yml scaling.yml filebeat.yml

APM server configuration

common.yml

The configuration file describes general configuration of master Platform Monitor.

The common.yml 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 the Vault client configuration.

mongodb-apm.yml

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

The mongodb-apm.yml 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 a 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 need to get current status of database also 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.

Recovery mode is mechanism of bootstrapping of RPA part. We check our remote RPA Platform Monitor to know if it is running or not. If our remote Platform Monitor (installed on Windows machine) doesn't work, Platform Monitor (installed on Linux machine) will create 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.

The rpa.yml file is as follows:

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 about notifications configuration in Notifications configuration.

nginx.yml

The configuration file describes nginx configuration of Application Platform Monitor.

The nginx.yml file consists of three main parts.

• The first part contains information about component and alert that 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 a command for restarting Nginx:

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

• The third part contains check:

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

filebeat.yml

The configuration file describes filebeat configuration of Application Platform Monitor.

The filebeat.yml file consists of three main parts:

• The first part contains information about component and alert that 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 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.

The logstash.yml file consists of three main parts:

• The first part contains information about component and alert that 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 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 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.

The common.yml 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 check which need 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.

The rpa-manager.yml file consists of four main parts:

• The first part contains information about component and alert that are 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 a 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.

The workfusion.yml consists of four main parts:

• The first part contains information about component and alert that are 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 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.

The wfbi.yml file consists of three main parts:

• The first part contains information about component and alert that are 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 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.

The workspace-production.yml file consists of three main parts:

• The first part contains information about component and alert that are connected with WorksSpace:

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

The workspace-sandbox.yml file consists of three main parts:

• The first part contains information about components and alerts that are 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.

The mongodb-ocr.yml 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_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 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 which need to get current status of database also 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.

The mongodb-rpa.yml 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 which need to get current status of database also 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.

The mysql.yml file consists of three main parts:

• The first part contains information about component and alert that are 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 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.

The nexus.yml file consists of three main parts:

• The first part contains information about component and alert that are 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.

The postgres.yml file consists of three main parts:

• The first part contains information about component and alert that are 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 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.

The s3.yml file for MinIO consists of two main parts:

• The first part contains information about component and alert that are 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
  

The s3.yml file for Riak consists of two main parts:

• The first part contains information about component and alert that are 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.

The vault.yml file consists of three main parts:

• The first part contains information about component and alert that are 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.

The ocr.yml file (rest module) consists of four main parts:

• The first part contains information about component and alert that are 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.

The ocr.yml file (worker module) consists of two main parts:

• The first part contains information about component and alert that are 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.

The vds_cluster.yml file consists of the following parts:

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

  vds_cluster.yml - env

  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 that are 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.

The vds_node.yml file consists of the following parts:

• The first part contains information about environment of AutoML Node that can be a hostname for the 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 the VDS Gateway configuration.

The gateway.yml file consists of two main parts:

• The first part contains information about component and alert that are 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 AutoML RabbitMQ configuration.

The rabbitmq.yml file consists of two main parts:

• The first part contains information about component and alert that are 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 VDS Scaling Service configuration.

The scaling.yml 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}