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.
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 nameholds 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 typesupports 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 modesupports 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 urlcontains 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 insecureSkipVerifycontains flag to skip certificate checks. | 
| headers | Flag to hold the http request headers for the httpProbe | Optional | N/A type: map[string]string | The headerscontains 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 criteriacontains criteria to match the HTTP GET request's response code or body with the expectedresponseCodeorresponseBody, as a part ofhttpProberun. | 
| responseCode | Flag to hold the expected response code for the GET request | Mandatory | HTTP_RESPONSE_CODE | The responseCodecontains the expected response code for the HTTP GET request as part ofhttpProberun. It is mutually exclusive with theresponseBodyfield. | 
| responseBody | Flag to hold the expected response body for the GET request | Mandatory | string | The responseBodycontains the expected response body for the HTTP GET request as part ofhttpProberun. It is mutually exclusive with theresponseCodefield. | 
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 criteriacontains criteria to match the HTTP POST request's response code with the expectedresponseCode, as a part ofhttpProberun. | 
| responseCode | Flag to hold the expected response code for the POST request | Mandatory | HTTP_RESPONSE_CODE | The responseCodecontains 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 responseBodycontains 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 contentTypecontains 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 bodycontains 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 usebodyPathfield. | 
| bodyPath | Flag to hold the path of the HTTP body, required for the HTTP POST request | Optional | N/A type: string | The bodyPathfield 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 probeTimeoutrepresents 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 attemptcontains 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 intervalcontains 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 probePollingIntervalcontains 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 initialDelaySecondsrepresents 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 stopOnFailurecan 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 typeencompasses 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 credentialsconsists of the basic authentication credentials, either as username:password encoded inbase64format or as abearertoken, depending on the authentication type | 
| credentialsFile | Flag to hold the basic auth credentials or bearer token file path | Optional | string | The credentialsconsists 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 inbase64format or abearertoken, 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 caFileholds the file path of the CA certificates utilized for server TLS verification | 
| certFile | Flag to hold the client cert file path | Optional | string | The certFileholds the file path of the client certificates utilized for TLS verification | 
| keyFile | Flag to hold the client key file path | Optional | string | The keyFileholds the file path of the client key utilized for TLS verification | 
| insecureSkipVerify | Flag to skip the tls certificates checks | Optional | boolean | The insecureSkipVerifyskip 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
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.
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