You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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

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.
  • A new global parameter is introduced named "router.monitor.notification.interval" which defines Interval (in seconds) to report router services monitoring alerts.
  • 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. 
  • Apart from the routerServiceMonitor.log a diff file named routerServiceMonitorDiff.log is maintained for the new alerts.
  • Following is functional flow for getting alerts from Virtual Router
  • Always when the alerts are generated from MoniterService Daemon, logs are written into both the files routerServiceMonitor.log and routerServiceMonitorDiff.log
  • Upon request for alerts from ManagementServer alerts in routerServiceMonitorDiff.log are sent to MS. The request from MS also includes the "timestamp" of the previous alert received.
  • After that routerServiceMonitorDiff.log will be emptied so that afterwards only new alerts will be sent for the next time.
  • When the time request comes from MS and if routerServiceMonitorDiff.log file is empty we check the routerServiceMonitor.log for new alerts using timestamp. This is to handle in case the Alerts failed to reach Management Server in the previous request.

     

 

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: 

        id: id (PK)

        router_id : id 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



  • No labels