Mizu Traffic Validation

Mizu has a Traffic Validation feature that can be used in conjunction with tapping pods. While the pod is tapped, requests are checked against the rules listed in the enforce-policy.yaml file and errors are listed in the "Rules" tab of the Mizu UI.

Traffic-Validation

To use traffic-validation in your tap:

mizu tap <pod name> --traffic-validation enforce-policy.yaml

Enforce-Policy

The enforce-policy.yaml file establishes a set of rules for Mizu to validate. For example, this holy-in-name-property rule checks that if there is a JSON with a name, its value should be "Holy".

rules:
- name: holy-in-name-property
  type: json
  key: "$.name"
  value: "Holy"

Rules can also check latency on specific services. This rule checks that responses from the catalogue service are 10 milliseconds or less.

rules:
- name: Catalogue-Latency-SLO
  type: latency
  path: /catalogue
  latency: 10
  service: "catalogue.*"

Rules can use regular expressions to check content length or characters.

- name: content-length-header
  type: header
  key: "Content-Le.*"
  value: "(\\d+(?:\\.\\d+)?)"

Testing Rules

If we tap pods in the WeaveSocks Microservices Demo with enforce-policy.yaml, we will see some of the test-rules features in action.

First, let's deliberately misspell the value in our holy-in-name-property rule in the enforce-policy.yaml file:

rules:
- name: holy-in-name-property
  type: json
  key: "$.name"
  value: "Holy1234"

Then, tap the front-end pods of the sock shop with traffic validation:

mizu tap "(catalo*|front-end*)" -n sock-shop --traffic-validation enforce-policy.yaml

In the Mizu UI at https://localhost:8899, we will see that the requests and responses worked with a 200 OK, but if we check the Rules tab, we will see errors in the holy-in-name-property rule, because the JSON name in the request didn't match the value Holy1234.

Testing Latency

We can do a similar test with latency. If we change the latency value to 2 in enforce-policy.yaml, test-rules will display an error if responses from the catalogue service are not 2 ms or less.

rules:
- name: Catalogue-Latency-SLO
  type: latency
  path: /catalogue
  latency: 2
  service: "catalogue.*"

In the Rules tab in the Mizu UI, we will see errors in the Catalogue-Latency-SLO rule, because the catalogue service latency was 2 ms, and the value must be less than 2.

Conclusion

When a pod is tapped with --traffic-validation, all requests and responses are checked against the rules listed in the enforce-policy.yaml file, and errors are listed in the "Rules" tab of the Mizu UI. Engineers can customize their enforce-policy.yaml file, enabling faster troubleshooting in tumultuous microservices environments.

YAML

The corresponding YAML is attached for your convenience. Try it out!

rules:
- name: Catalogue-Latency-SLO           #catalogue's service "/catalogue" response time < 300
  type: latency
  path: /catalogue
  latency: 300
  service: "catalogue.*"

- name: FECatalogue-Latency-SLO         #front-end's service "/catalogue" response time < 600m
  type: latency
  path: /catalogue
  latency: 600
  service: "front-end.*"

- name: General-SLO                     #all APIs should respond within 1000ms
  type: latency
  path: /*
  service: ".*"
  latency: 1000

- name: holy-in-name-property           #JSON scheme validation: If there is a Name it should be Holy
  type: json
  key: "$.name"
  value: "Holy"

- name: price-is-numeric                #JSON scheme validation: Price type is a Float
  type: json
  key: "$.price"
  value: "(\\d+(?:\\.\\d+)?)"

- name: content-length-header           #Header Validation: Content-length is valid
  type: header
  key: "Content-Le.*"
  value: "(\\d+(?:\\.\\d+)?)"

Support

For support, feel free to use any one of the three: