search

Particular / ServiceControl

Backend for ServiceInsight and ServicePulse
https://docs.particular.net/servicecontrol/
Other
52 stars 47 forks source link

Refactor Hearbeat provider implementation #58

Closed indualagarsamy closed 10 years ago

indualagarsamy commented 11 years ago

Currently, the hearbeats server as a vehicle to:

  1. Send heartbeat information in a periodic interval
  2. Send performance counter information
  3. Configuration information

The above three things have different time intervals. While hearbeats could be sent every 5 mins, performance counters may need to be sent every 30 seconds and config information may need to be sent just once when the endpoint is started.

Therefore we need to separate it into different concerns.

andreasohlund commented 11 years ago

+1

On Thu, Sep 19, 2013 at 10:37 AM, Indu Alagarsamy notifications@github.comwrote:

Currently, the hearbeats server as a vehicle to:

  1. Send heartbeat information in a periodic interval
  2. Send performance counter information
  3. Configuration information

The above three things have different time intervals. While hearbeats could be sent every 5 mins, performance counters may need to be sent every 30 seconds and config information may need to be sent just once when the endpoint is started.

Therefore we need to separate it into different concerns.

— Reply to this email directly or view it on GitHubhttps://github.com/Particular/ServiceControl/issues/58 .

http://andreasohlund.net http://twitter.com/andreasohlund

dannycohen commented 11 years ago

Currently, the hearbeats server as a vehicle to:

  1. Send heartbeat information in a periodic interval
  2. Send performance counter information
  3. Configuration information

Regarding item 2: this si a good point that I propose will be handled via the implementation of plugins to 3rd party operations tools. Optionally, and pending additional discussion on 3rd party operations tool plugin planning (ETA: Oct. 3rd) we can remove the performance counters from the heatbeat implementation

Regarding item 3: I think this should remain as is. In the (near) future it will not be used only for monitoring endpoint restarts, but also to monitor endpoint configuration changes (i.e. the scenario where a change in a configuration or an upgrade occurs just before an endpoint starts failing messages; Notifying Opie will allow him to check whether this correlation indicates causation; having this data in the heartbeat will allow us to indicate or even actively detect such correlations).