-
Notifications
You must be signed in to change notification settings - Fork 6
Master greenyet
You can monitor just based on a HTTP 200 response, if you don't have an elaborate JSON available yet.
If your service exposes child component statuses, greenyet can derive the overall status automatically. A red component will set a red overall color, all green will yield an overall green color, and yellow otherwise. If you have your own logic, you can expose the overall color instead (see color in https://github.com/cburgmer/greenyet/wiki/Howto#optional).
Put in your reverse proxy/load balancer together with your nodes. Most of the times your machines will be green, so only the first entry of the config will be shown per environment (e.g. the reverse proxy, your call). The list unfolds once one machine changes color. This behaviour is known as collapsing. If you want to remove this behaviour add the ?expand=true query parameter to the greenyet URL. Collapsed nodes will be clearly marked with the 'COLLAPSED' indicator.
Get your environments sorted in the order from dev to prod. Make use of the environment names that greenyet knows about to get the right ordering.
The polling interval duration configured in POLLING_INTERVAL matches the status page request timeout. Worst case duration for a failure to be reported on the dashboard is the sum of the request timeout/polling time (default 5 seconds) and the dashboard refresh (5 seconds).
Be aware of the load that greenyet will put on your systems. A combination of polling interval, number of hosts monitored, and number of instances of greenyet running, will certainly leave an impression on your architecture if the status page takes time to load, or worse triggers more HTTP requests downstream.
What worked for us so far was either just passively logging the internal status of application (just serving up those logs), or if more up-to-date information is required debounce costlier operations.