Whitebox versus blackbox monitoring

There are many ways we could go about monitoring, but they largely fall into two main categories, that is, blackbox and whitebox monitoring.

In blackbox monitoring, the application or host is observed from the outside and, consequently, this approach can be fairly limited. Checks are made to assess whether the system under observation responds to probes in a known way:

  • Does the host respond to Internet Control Message Protocol (ICMP) echo requests (more commonly known as ping)?
  • Is a given TCP port open?
  • Does the application respond with the correct data and status code when it receives a specific HTTP request?
  • Is the process for a specific application running in its host?

On the other hand, in whitebox monitoring, the system under observation surfaces data about its internal state and the performance of critical sections. This type of introspection can be very powerful as it exposes the operating telemetry, and consequently the health, of the different internal components, which otherwise would be difficult or even impossible to ascertain. This telemetry data is usually handled in the following ways:

  • Exported through logging: This is by far the most common case and how applications exposed their inner workings before instrumentation libraries were widespread. For instance, an HTTP server's access log can be processed to monitor request rates, latencies, and error percentages.
  • Emitted as structured events: This approach is similar to logging but instead of being written to disk, the data is sent directly to processing systems for analysis and aggregation.
  • Maintained in memory as aggregates: Data in this format can be hosted in an endpoint or read directly from command-line tools. Examples of this approach are /metrics with Prometheus metrics, HAProxy's stats page, or the varnishstats command-line tool.

Not all software is instrumented and ready to have its internal state exposed for metrics collection. For example, it can be a third-party, closed-source application that has no means of surfacing its inner workings. In these cases, external probing can be a viable option to gather the data that's deemed essential for a proper service state validation.

Regardless, not only third-party applications benefit from blackbox monitoring. It can be useful to validate your applications from their clients' standpoint by going through, for example, load balancers and firewalls. Probing can be your last line of defense—if all else fails, you can rely on blackbox monitoring to assess availability.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.17.150.163