Skip to main content

HTTP probe

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.

FieldDescriptionTypeRangeNotes
nameFlag to hold the name of the probeMandatoryN/A type: stringThe name holds the name of the probe. It can be set based on the use case
typeFlag to hold the type of the probeMandatoryhttpProbe, k8sProbe, cmdProbe, promProbe, and datadogProbeThe type supports five types of probes: httpProbe, k8sProbe, cmdProbe, promProbe, and datadogProbe.
modeFlag to hold the mode of the probeMandatorySOT, EOT, Edge, Continuous, OnChaosThe mode supports five modes of probes: SOT, EOT, Edge, Continuous, and OnChaos. Datadog probe supports EOT mode only.
urlFlag to hold the URL for the httpProbeMandatoryN/A type: stringThe url contains the URL which the experiment uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria.
insecureSkipVerifyFlag to hold the flag to skip certificate checks for the httpProbeOptionaltrue, falseThe insecureSkipVerify contains flag to skip certificate checks.
headersFlag to hold the http request headers for the httpProbeOptionalN/A type: map[string]stringThe headers contains flag to hold the HTTP request headers.

Method

GET method properties

FieldDescriptionTypeRangeNotes
criteriaFlag to hold the criteria for the http get requestMandatory >=, <=, ==, !=, <, >, oneOf, betweenThe 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.
responseCodeFlag to hold the expected response code for the GET requestMandatory 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.
responseBodyFlag to hold the expected response body for the GET requestMandatorystringThe responseBody contains the expected response body for the HTTP GET request as part of httpProbe run. It is mutually exclusive with the responseCode field.
tip

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

FieldDescriptionTypeRangeNotes
criteriaFlag to hold the criteria for the http post requestMandatory >=, <=, ==, !=, <, >, oneOf, betweenThe criteria contains criteria to match the HTTP POST request's response code with the expected responseCode, as a part of httpProbe run.
responseCodeFlag to hold the expected response code for the POST requestMandatoryHTTP_RESPONSE_CODEThe 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

In the case of Dedicated Chaos Infrastructure, the following apply:

  • The mode and type are mandatory fields in the probe schema when you define the entire configuration of the probe in the manifest (for Kubernetes (Legacy), Linux, and Windows infrastructure).
  • The name, mode, type and other input properties (depending on the probe) is required to rightly configure the resilience probe. If all the necessary details are not provided, the probe will not execute.

In the case of Harness Delegate, the following apply:

  • For Kubernetes (Harness Infrastructure) (also known as DDCR), the mandatory fields are mode and probeID, and the type field is derived. These fields are generated and patched in the backend to the same manifest. However, in the UI, you will only see the mode and probeID fields when configuring your experiment. This is because the manifest is minified in the UI.
  • If you define the entire probe in task.definition.chaos.probes, the entire configuration is required. If you use the task.probeRef, you only need to specify probeID and mode fields.
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
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
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
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
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
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.

tip

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.

tip

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