HTTP Probe

Monitor web services and APIs with HTTP-based health checks

HTTP probe allows you to specify a URL that the experiment uses to determine the health or service availability (or other custom conditions) that is a part of the entry or exit criteria. The status code received is mapped against an expected status. It supports HTTP GET and POST methods.

The HTTP GET method sends a GET request to the specified URL. The response received is matched for the response code or response body based on the provided criteria.

HTTP POST method sends a POST request to the provided URL.

YAML ONLY FEATURE

In the case of a complex POST request in which the body spans multiple lines, the bodyPath attribute is used to specify the path to a file consisting of the same. This file is available to the experiment pod through a ConfigMap resource, wherein the ConfigMap name is defined in the chaos engine or the chaos experiment CR. The body and bodyPath attributes are mutually exclusive. Go to probe schema to learn more.

Probe definition

You can define the probes at .spec.experiments[].spec.probe path inside the chaos engine.

kind: Workflow
apiVersion: argoproj.io/v1alpha1
spec:
  templates:
    - inputs:
        artifacts:
          - raw:
              data: |
                apiVersion: litmuschaos.io/v1alpha1
                kind: ChaosEngine
                spec:
                  experiments:
                    - spec:
                        probe:
                          ####################################
                          Probes are defined here
                          ####################################

Schema

Listed below is the probe schema for HTTP Probe with common properties shared across all probes and properties unique to HTTP probe.

Field	Description	Type	Range	Notes
name	Flag to hold the name of the probe	Mandatory	N/A type: string	The name holds the name of the probe. It can be set based on the use case
type	Flag to hold the type of the probe	Mandatory	httpProbe, k8sProbe, cmdProbe, promProbe, and datadogProbe	The type supports five types of probes: httpProbe, k8sProbe, cmdProbe, promProbe, and datadogProbe.
mode	Flag to hold the mode of the probe	Mandatory	SOT, EOT, Edge, Continuous, OnChaos	The mode supports five modes of probes: SOT, EOT, Edge, Continuous, and OnChaos. Datadog probe supports EOT mode only.
url	Flag to hold the URL for the httpProbe	Mandatory	N/A type: string	The url contains the URL which the experiment uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria.
insecureSkipVerify	Flag to hold the flag to skip certificate checks for the httpProbe	Optional	true, false	The insecureSkipVerify contains flag to skip certificate checks.
headers	Flag to hold the http request headers for the httpProbe	Optional	N/A type: map[string]string	The headers contains flag to hold the HTTP request headers.

Method

GET method properties

Field	Description	Type	Range	Notes
criteria	Flag to hold the criteria for the http get request	Mandatory	>=, <=, ==, !=, <, >, oneOf, between	The criteria contains criteria to match the HTTP GET request's response code or body with the expected responseCode or responseBody, as a part of httpProbe run.
responseCode	Flag to hold the expected response code for the GET request	Mandatory	HTTP_RESPONSE_CODE	The responseCode contains the expected response code for the HTTP GET request as part of httpProbe run. It is mutually exclusive with the responseBody field.
responseBody	Flag to hold the expected response body for the GET request	Mandatory	string	The responseBody contains the expected response body for the HTTP GET request as part of httpProbe run. It is mutually exclusive with the responseCode field.

The fields criteria and responseBody is mutually exclusive with criteria and responseCode. This means criteria field is accompanied by either responseBody or responseCode.

POST method properties

Field	Description	Type	Range	Notes
criteria	Flag to hold the criteria for the http post request	Mandatory	>=, <=, ==, !=, <, >, oneOf, between	The criteria contains criteria to match the HTTP POST request's response code with the expected responseCode, as a part of httpProbe run.
responseCode	Flag to hold the expected response code for the POST request	Mandatory	HTTP_RESPONSE_CODE	The responseCode contains the expected response code for the HTTP POST request as part of httpProbe run. It is mutually exclusive with the responseBody field.
responseBody	Flag to hold the expected response body for the post request	Mandatory	string	The responseBody contains the expected response body for the HTTP POST request as part of httpProbe run. It is mutually exclusive with the responseCode field.
contentType	Flag to hold the content type of the POST request	Mandatory	N/A type: string	The contentType contains the content type of the HTTP body data, which need to be passed for the HTTP POST request
body	Flag to hold the body of the HTTP POST request	Mandatory	N/A type: string	The body contains the HTTP body, which is required for the HTTP post request. It is used for the simple HTTP body. If the HTTP body is complex then use bodyPath field.
bodyPath	Flag to hold the path of the HTTP body, required for the HTTP POST request	Optional	N/A type: string	The bodyPath field is used in case of complex POST request in which the body spans multiple lines, the bodyPath attribute can be used to provide the path to a file consisting of the same. This file can be made available to the experiment pod via a ConfigMap resource, with the ConfigMap name being defined in the ChaosEngine OR the ChaosExperiment CR.

Run properties

Field	Description	Type	Range	Notes
probeTimeout	Flag to hold the timeout of the probe	Mandatory	N/A type: string	The probeTimeout represents the time limit for the probe to execute the specified check and return the expected data.
attempt	Flag to hold the attempt of the probe	Mandatory	N/A type: integer	The attempt contains the number of times a check is run upon failure in the previous attempts before declaring the probe status as failed.
interval	Flag to hold the interval of the probe	Mandatory	N/A type: string	The interval contains the interval for which probes waits between subsequent retries
probePollingInterval	Flag to hold the polling interval for the probes (applicable for all modes)	Optional	N/A type: string	The probePollingInterval contains the time interval for which continuous and onchaos probe should be sleep after each iteration
initialDelaySeconds	Flag to hold the initial delay interval for the probes	Optional	N/A type: integer	The initialDelaySeconds represents the initial waiting time interval for the probes.
stopOnFailure	Flags to hold the stop or continue the experiment on probe failure	Optional	N/A type: boolean	The stopOnFailure can be set to true/false to stop or continue the experiment execution after probe fails

Authentication

This establishes a fundamental authentication mechanism for the http endpoint. The username:password, encoded in base64 or bearer token should be placed either within the credentials field or as a file path in the credentialsFile field. It's important to note that credentials and credentialsFile are two options that cannot be used simultaneously.

Field	Description	Type	Range	Notes
type	Flag to hold the authentication type	Optional	string	The type encompasses the authentication method, which includes support for both basic and bearer authentication types
credentials	Flag to hold the basic auth credentials or bearer token	Optional	string	The credentials consists of the basic authentication credentials, either as username:password encoded in base64 format or as a bearer token, depending on the authentication type
credentialsFile	Flag to hold the basic auth credentials or bearer token file path	Optional	string	The credentials consists of file path for basic authentication credentials or a bearer token, which are then attached to the experiment pod as volume secrets. These secret resources contain either the username:password encoded in base64 format or a bearer token, depending on the authentication type

TLS

It offers the mechanism to validate TLS certifications for the HTTP endpoint. You can supply the cacert or the client certificate and client key, to perform the validation. Alternatively, you have the option to enable the insecureSkipVerify check to bypass certificate validation.

Field	Description	Type	Range	Notes
caFile	Flag to hold the ca file path	Optional	string	The caFile holds the file path of the CA certificates utilized for server TLS verification
certFile	Flag to hold the client cert file path	Optional	string	The certFile holds the file path of the client certificates utilized for TLS verification
keyFile	Flag to hold the client key file path	Optional	string	The keyFile holds the file path of the client key utilized for TLS verification
insecureSkipVerify	Flag to skip the tls certificates checks	Optional	boolean	The insecureSkipVerify skip the tls certificates checks

Definition

probe:
  - name: "check-frontend-access-url"
    type: "httpProbe"
    httpProbe/inputs:
      url: "https://google.com"
      tlsConfig:
        insecureSkipVerify: true
      method:
        get:
          criteria: == # <, >, <=, >=, ==, !=, oneof, between operations
          responseCode: "200"
    mode: "Continuous"
    runProperties:
      probeTimeout: 5s
      interval: 2s
      attempt: 1
      probePollingInterval: 2s

HTTP GET request (validate response code)

The HTTP GET method involves sending an HTTP GET request to the provided URL and then assessing the response code against specified criteria (<, >, <=, >=, ==, !=, oneof, between). This can be accomplished by configuring the httpProbe/inputs.method.get field.

Use the following example to tune this:

# contains the http probes with get method and verify the response code <a href="#contains-the-http-probes-with-get-method-and-verify-the-response-code" id="contains-the-http-probes-with-get-method-and-verify-the-response-code"></a>
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: engine-nginx
spec:
  engineState: "active"
  appinfo:
    appns: "default"
    applabel: "app=nginx"
    appkind: "deployment"
  chaosServiceAccount: litmus-admin
  experiments:
  - name: pod-delete
    spec:
      probe:
      - name: "check-frontend-access-url"
        type: "httpProbe"
        httpProbe/inputs:
          url: "frontend-service.default.svc.cluster.local"
          method:
            # call http get method and verify the response code
            get:
              # criteria which should be matched
              criteria: == # <, >, <=, >=, ==, !=, oneof, between
              # expected response code for the http request, which should follow the specified criteria
              responseCode: "200"
        mode: "Continuous"
        runProperties:
          probeTimeout: 5s
          interval: 2s
          attempt: 1
          probePollingInterval: 2s

HTTP GET request (validate response body)

The HTTP GET method involves sending an HTTP GET request to the provided URL and then assessing the response body against specified criteria (contains, equal, notEqual, matches, notMatches, oneof). This can be accomplished by configuring the httpProbe/inputs.method.get field.

Use the following example to tune this:

# contains the http probes with get method and verify the response body <a href="#contains-the-http-probes-with-get-method-and-verify-the-response-body" id="contains-the-http-probes-with-get-method-and-verify-the-response-body"></a>
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: engine-nginx
spec:
  engineState: "active"
  appinfo:
    appns: "default"
    applabel: "app=nginx"
    appkind: "deployment"
  chaosServiceAccount: litmus-admin
  experiments:
  - name: pod-delete
    spec:
      probe:
      - name: "check-frontend-access-url"
        type: "httpProbe"
        httpProbe/inputs:
          url: "http://frontend-service.default.svc.cluster.local"
          method:
            # call http get method and verify the response code
            get:
              # criteria which should be matched
              criteria: contains
              # expected response body for the http request, which should follow the specified criteria
              responseBody: "hello world"
        mode: "Continuous"
        runProperties:
          probeTimeout: 5s
          interval: 2s
          attempt: 1
          probePollingInterval: 2s

HTTP POST request (validate response code)

This section holds the HTTP body necessary for making an HTTP POST request and then assessing the response code against specified criteria, particularly for simple requests. The HTTP body content can be supplied in the 'body' field, and this can be initiated by configuring the httpProbe/inputs.method.post.body field.

Use the following example to tune this:

# contains the http probes with post method and verify the response code <a href="#contains-the-http-probes-with-post-method-and-verify-the-response-code" id="contains-the-http-probes-with-post-method-and-verify-the-response-code"></a>
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: engine-nginx
spec:
  engineState: "active"
  appinfo:
    appns: "default"
    applabel: "app=nginx"
    appkind: "deployment"
  chaosServiceAccount: litmus-admin
  experiments:
  - name: pod-delete
    spec:
      probe:
      - name: "send-data-to-backend"
        type: "httpProbe"
        httpProbe/inputs:
          url: "backend.default.svc.cluster.local"
          method:
            # call http post method and verify the response code
            post:
              # value of the http body, used for the post request
              body: "{\"name\":\"foo\",\"description\":\"bar\"}"
              # http body content type
              contentType: "application/json; charset=UTF-8"
              # criteria which should be matched
              criteria: "==" # <, >, >=, <=, ==, !=, oneof, between
              # expected response code for the http request, which should follow the specified criteria
              responseCode: "200"
        mode: "Continuous"
        runProperties:
          probeTimeout: 5s
          interval: 2s
          attempt: 1
          probePollingInterval: 2s

HTTP POST request (validate response body)

This section holds the HTTP body necessary for making an HTTP POST request and then assessing the response body against specified criteria, particularly for simple requests. The HTTP body content can be supplied in the 'body' field, and this can be initiated by configuring the httpProbe/inputs.method.post.body field.

Use the following example to tune this:

# contains the http probes with post method and verify the response code <a href="#contains-the-http-probes-with-post-method-and-verify-the-response-code" id="contains-the-http-probes-with-post-method-and-verify-the-response-code"></a>
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: engine-nginx
spec:
  engineState: "active"
  appinfo:
    appns: "default"
    applabel: "app=nginx"
    appkind: "deployment"
  chaosServiceAccount: litmus-admin
  experiments:
  - name: pod-delete
    spec:
      probe:
      - name: "send-data-to-backend"
        type: "httpProbe"
        httpProbe/inputs:
          url: "backend.default.svc.cluster.local"
          method:
            # call http post method and verify the response code
            post:
              # value of the http body, used for the post request
              body: "{\"name\":\"foo\",\"description\":\"bar\"}"
              # http body content type
              contentType: "application/json; charset=UTF-8"
              # criteria which should be matched
              criteria: contains
              # expected response body for the http request, which should follow the specified criteria
              responseBody: "ok"
        mode: "Continuous"
        runProperties:
          probeTimeout: 5s
          interval: 2s
          attempt: 1
          probePollingInterval: 2s

HTTP POST request (complex HTTP body)

For complex POST requests with multi-line bodies, the 'bodyPath' attribute comes into play. It allows you to specify the path to a file containing the required body content. This file can be accessed by the experiment pod through a ConfigMap resource, with the ConfigMap name defined in either the ChaosEngine or the ChaosExperiment CR. To set this up, configure the httpProbe/inputs.method.post.body field.

Please note that it is mutually exclusive with the body field. If body is specified, it will be used for the POST request; otherwise, bodyPath will be used.

Use the following example to tune this:

# contains the http probes with post method and verify the response code <a href="#contains-the-http-probes-with-post-method-and-verify-the-response-code" id="contains-the-http-probes-with-post-method-and-verify-the-response-code"></a>
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: engine-nginx
spec:
  engineState: "active"
  appinfo:
    appns: "default"
    applabel: "app=nginx"
    appkind: "deployment"
  chaosServiceAccount: litmus-admin
  experiments:
  - name: pod-delete
    spec:
      probe:
      - name: "send-data-to-backend"
        type: "httpProbe"
        httpProbe/inputs:
          url: "backend.default.svc.cluster.local"
          method:
            # call http post method and verify the response code
            post:
              # the configMap should be mounted to the experiment which contains http body
              # use the mounted path here
              bodyPath: "/mnt/body.yml"
              # http body content type
              contentType: "application/json; charset=UTF-8"
              # criteria which should be matched
              criteria: "==" # <, >, >=, <=, ==, !=, oneof, between
              # expected response code for the http request, which should follow the specified criteria
              responseCode: "200"
        mode: "Continuous"
        runProperties:
          probeTimeout: 5s
          interval: 2s
          attempt: 1
          probePollingInterval: 2s

Authentication

This establishes a fundamental authentication mechanism for the HTTP endpoint. The username:password encoded in base64 or bearer token should be placed either within the credentials field or as a file path in the credentialsFile field.

The credentials and credentialsFile are two options that cannot be used simultaneously.

Use the following example to tune this:

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: engine-nginx
spec:
  engineState: "active"
  appinfo:
    appns: "default"
    applabel: "app=nginx"
    appkind: "deployment"
  chaosServiceAccount: litmus-admin
  experiments:
  - name: pod-delete
    spec:
      probe:
      - name: "send-data-to-backend"
        type: "httpProbe"
        httpProbe/inputs:
          url: "backend.default.svc.cluster.local"
          auth:
            type: Basic
            credentials: "dXNlcm5hbWU6cGFzc3dvcmQ="
          method:
            # call http post method and verify the response code
            post:
              # the configMap should be mounted to the experiment which contains http body
              # use the mounted path here
              bodyPath: "/mnt/body.yml"
              # http body content type
              contentType: "application/json; charset=UTF-8"
              # criteria which should be matched
              criteria: "==" # ==, !=, >, <, >=, <=, between, oneof
              # expected response code for the http request, which should follow the specified criteria
              responseCode: "200"
        mode: "Continuous"
        runProperties:
          probeTimeout: 5s
          interval: 2s
          attempt: 1
          probePollingInterval: 2s

Headers

Headers for HTTP requests can be specified in a map format within the headers path.

Use the following example to tune this:

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: engine-nginx
spec:
  engineState: "active"
  appinfo:
    appns: "default"
    applabel: "app=nginx"
    appkind: "deployment"
  chaosServiceAccount: litmus-admin
  experiments:
  - name: pod-delete
    spec:
      probe:
      - name: "send-data-to-backend"
        type: "httpProbe"
        httpProbe/inputs:
          url: "backend.default.svc.cluster.local"
          headers:
            Content-Type: application/json
          auth:
            type: Basic
            credentials: "dXNlcm5hbWU6cGFzc3dvcmQ="
          method:
            # call http post method and verify the response code
            post:
              # the configMap should be mounted to the experiment which contains http body
              # use the mounted path here
              bodyPath: "/mnt/body.yml"
              # http body content type
              contentType: "application/json; charset=UTF-8"
              # criteria which should be matched
              criteria: "==" # ==, !=, <, >, <=, >=, between, oneof
              # expected response code for the http request, which should follow the specified criteria
              responseCode: "200"
        mode: "Continuous"
        runProperties:
          probeTimeout: 5s
          interval: 2s
          attempt: 1
          probePollingInterval: 2s

TLS With custom certificates

It offers the mechanism to validate TLS certifications for the http endpoint. You can supply the cacert or the client certificate and client key, to perform the validation.

The CA certificate file must be incorporated into the experiment pod either as a configMap or a secret. The volume name (configMap or secret) and mountPath should be specified within the chaosengine at the spec.components.secrets path.

Use the following example to tune this:

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: engine-nginx
spec:
  engineState: "active"
  appinfo:
    appns: "default"
    applabel: "app=nginx"
    appkind: "deployment"
  chaosServiceAccount: litmus-admin
  experiments:
  - name: pod-delete
    spec:
      components:
        secrets:
          - name: ca-cert
            mountPath: /mnt
      probe:
      - name: "send-data-to-backend"
        type: "httpProbe"
        httpProbe/inputs:
          url: "backend.default.svc.cluster.local"
          tlsConfig:
            caFile: "/mnt/ca.crt"
          method:
            # call http post method and verify the response code
            post:
              # the configMap should be mounted to the experiment which contains http body
              # use the mounted path here
              bodyPath: "/mnt/body.yml"
              # http body content type
              contentType: "application/json; charset=UTF-8"
              # criteria which should be matched
              criteria: "==" # ==, !=, <, >, <=, >=, between, oneof
              # expected response code for the http request, which should follow the specified criteria
              responseCode: "200"
        mode: "Continuous"
        runProperties:
          probeTimeout: 5s
          interval: 2s
          attempt: 1
          probePollingInterval: 2s

TLS skip certificate verification

You can bypass the tls certificate checks by enabling the insecureSkipVerify option.

Use the following example to tune this:

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: engine-nginx
spec:
  engineState: "active"
  appinfo:
    appns: "default"
    applabel: "app=nginx"
    appkind: "deployment"
  chaosServiceAccount: litmus-admin
  experiments:
  - name: pod-delete
    spec:
      probe:
      - name: "send-data-to-backend"
        type: "httpProbe"
        httpProbe/inputs:
          url: "backend.default.svc.cluster.local"
          tlsConfig:
            insecureSkipVerify: true
          method:
            # call http post method and verify the response code
            post: 
              # the configMap should be mounted to the experiment which contains http body
              # use the mounted path here
              bodyPath: "/mnt/body.yml"
              # http body content type
              contentType: "application/json; charset=UTF-8"
              # criteria which should be matched
              criteria: "==" # <, >, <=, >=, ==, !=, oneof, between
              # expected response code for the http request, which should follow the specified criteria
              responseCode: "200"
        mode: "Continuous"
        runProperties:
          probeTimeout: 5s
          interval: 2s
          attempt: 1
          probePollingInterval: 2s