{"id":2125,"date":"2018-08-09T22:51:19","date_gmt":"2018-08-10T03:51:19","guid":{"rendered":"https:\/\/rpchurchill.com\/wordpress\/?p=2125"},"modified":"2019-04-30T18:41:28","modified_gmt":"2019-04-30T23:41:28","slug":"monitoring-system-health-and-availability-and-logging-part-2","status":"publish","type":"post","link":"https:\/\/rpchurchill.com\/wordpress\/posts\/2018\/08\/09\/monitoring-system-health-and-availability-and-logging-part-2\/","title":{"rendered":"Monitoring System Health and Availability, and Logging: Part 2"},"content":{"rendered":"

Continuing yesterday’s<\/a> discussion of monitoring and logging, I wanted to work through a few specific cases and try to illustrate how things can be sensed in an organized way, and especially how errors of various types can be detected. To that end, let’s start with a slightly simplified situation as shown here, where we have a single main process running on each machine, and the monitoring, communication, and logging are all built in to each process.<\/p>\n

<\/p>\n

As always, functionality on the local machine is straightforward. In this simplified case, things are either working or they aren’t, and that should be reflected in whatever log are or are not written. Sensing the state and history of the remote machine is what’s interesting.<\/p>\n

First, let’s imagine a remote system that supports only one type of communication. That channel must be able to support messaging for many functions, including whatever operations it’s carrying out, remote system administration (if appropriate), reporting on current status, and reporting on historical data. The remote system must be able to interpret the incoming messages so it can reply with an appropriate response. Most importantly it has to be able to sense which of the four kinds of messages it’s receiving. Let’s look at each function in turn.<\/p>\n