Probes

Overview

A Skopos probe packages a service healthcheck as a container. During application deployment, a probe is instantiated and attached to the service network of a target component. From this position, the probe can verify the operation of the target service on the same network used to consume that service.

Skopos probes are an advance over traditional healthcheck methods because they are:

  • in-application: a probe runs in the same context as the application, and faithfully reproduces the position of a service's client
  • containerized:
    • a probe may be packaged with support for specific client libraries (e.g. mysql, redis, etc.), providing for in-depth assessment of target components
    • a probe enjoys the same distribution mechanisms, run-time configuration, and deployment orchestration as other containers

While probes are typically used to perform healthchecks, the Skopos probe mechanism is general purpose. A probe can be built to provide nearly any kind of functionality for assessing or acting upon target component instance(s) over a network. For example, a probe may be used to load/stress test a component and verify its performance, or to fully verify a service API.

Using Probes

Skopos can use any of the standard library probes described in the next section, as well as any custom probe available from an image repository.

Skopos executes probes according to their specification in an application:

  • Probes are ordinarily specified using quality gates which associate user defined deployment checks to one or more component images.
  • Advanced: probes may also be specified directly in the component lifecycle section of an application model, just as any other injected step may be specified. See the Component Lifecycle reference for details.

In either case, a probe is specified using the probe syntax for injected steps. Each of the probes in the standard libray (below) includes a number of usage examples in its documentation.

There is also a sample Pet Voting Application which uses probes to verify its deployment. This application demonstrates the typical use case for probes.

Probe Library

The Skopos probe library includes general purpose probes for HTTP and TCP connect healthchecks, as well as a number of service specific probes, e.g., for verifying in detail the deployment of database components. Each of the probes below links to its detailed user documentation.

Skopos library probes are based on a minimal Alpine Linux image. These images are ~22MB compressed, ~64MB uncompressed.

General Purpose Probes

  • http - The http probe calls a REST API over http/https on component instances, e.g., to perform an http health check.
  • tcp-connect - The tcp-connect probe performs a simple socket connect health check on component instances.

Service Specific Probes

  • redis - The redis probe connects to and pings redis component instances. This probe can be used to verify a deployed service provides access to the redis API on the component's service network.
  • postgres - The postgres probe connects to postgres component instances and lists their databases. This probe can be used to verify a deployed service provides access to the postgres API on the component's service network.
  • mariadb - The mariadb probe connects to mariadb/mysql component instances and lists their databases. This probe can be used to verify a deployed service provides access to the mariadb/mysql API on the component's service network.
  • mongo - The mongo probe connects to mongo component instances and lists their databases. This probe can be used to verify a deployed service provides access to the mongo API on the component's service network.