Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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.logA new global parameter is introduced named "router.monitor.notification.interval" which defines Interval (in seconds) to report router services monitoring alerts.
  • Each time when requests goes from management server and get the alerts from specific router, we maitain maintain the time stamp in our DB in the table "op_router_monitermonitor_service" and using this time stamp we get only the new alerts in the subsequent request.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 routerServiceMoniter.log 
  • 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.

...

        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

...

3. Advanced zone shared network


TO DOs:

CLOUDSTACK-6253