Introduction

Purpose

We already have monitoring services in Virtual Router in 4.3 and ensure the services running through the lifetime of VR. Upon failure alerts are getting generated in Virtual router.

There is a need to send these alerts to management server to notify admin so that further actions can be taken if required.

Scope

Scope of this document is to provide a functional specification for the Virtual Router failure alerting implementation planned for the 4.4 release of CloudStack.

References

• Monitoring VR services
• https://issues.apache.org/jira/browse/CLOUDSTACK-6090

Feature Specifications

• Currently services like ssh, webserver, dhcp, loadbalancer are being monitored on the virtual router using the monitoring script. . This script writes log about service fail and restart of the services. If restart fails, writes alerts in log. These alerts should be send to management server.
• Virtual router does not have NIC for the management network so VR cannot send alerts directly to management server and so it should be polling process from management server to VR.
• We use the existing CheckRouterTask() thread which already has been used for s2s vpn connection status update and redundant router checking and  and "router.check.interval" would be used as interval for checking.
• Improve the log messages in VR upon service failures and restart services by including time stamps and keeping the logs in separate log file named routerServiceMonitor.log
• Each time when requests goes from management server and get the alerts from specific router, we maintain the time stamp in our DB in the table "op_router_monitor_service" and using this time stamp we get only the new alerts in the subsequent request. 
• The rollover strategy of routerServiceMonitor.log is to maintain logs with maxsize of 10MB and backup count to 5. 
• Following is functional flow for getting alerts from Virtual Router
• Always when the alerts are generated from MoniterService Daemon, logs are written into routerServiceMonitor.log.
• Upon request for alerts from ManagementServer alerts in routerServiceMonitor.log are parsed to get the new alerts based on the timestamp. The request from MS also includes the "timestamp" of the previous alert received.
• If "timestamp" is not sent from MS, all the alerts in routerServiceMonitor.log are sent to MS.
  
   
  

UI Changes:

 No UI chagnes.

API Changes:

  No API chagnes.

DB Changes:

•  A new operational table is introduced named "op_router_moniter_service" which includes router_id and last alert generated timestamp.

 New DB table:

        table name: op_router_moniter_service

 Columns: 

        vm_id: id (PK)

        router_id : id of the Virtual router

        router_name: name of the Virtual router

        last_alert_received  : Timestamp when the last alert is received

Supported VR networks:

1. Advanced zone Isolated networks

2. Basic zone shared network

3. Advanced zone shared network