Conditions

You can set conditions for when an instrument should be mutated or an event should be triggered.

Condition configuration

Here is an example of a condition on a custom instrument:

1telemetry:
2  instrumentation:
3    instruments:
4      router:
5        my.instrument:
6          value: duration
7          type: counter
8          unit: s
9          description: "my description"
10          # ...
11          # This instrument will only be mutated if the condition evaluates to true
12          condition:
13            all:
14              - any:
15                  - eq:
16                      - "val"
17                      - request_header: x-req-header
18              - eq:
19                  - "foo"
20                  - response_header: x-resp-header

exists

The exists condition is testing if selectors is present.

For example, the following condition checks the value of x-req-header exists:

1exists:
2  request_header: x-req-header

eq

The eq condition is an equality test between selectors or values.

For example, the following condition checks the value of x-req-header is equal to val:

1eq:
2  - "val"
3  - request_header: x-req-header

You can use selectors on both sides of the equality test:

1eq:
2  - request_header: x-req-header1
3  - request_header: x-req-header2

Values may be of types string, number or boolean.

gt

The gt condition checks that one value is greater than another.

For example, the following condition checks the response status code is greater than 299:

1gt:
2  - response_status: code
3  - 299

Values may be of types string, number or boolean.

lt

The lt condition checks that one value is less than another.

For example, the following condition checks the response status code is less than 500:

1lt:
2  - response_status: code
3  - 500

Values may be of types string, number or boolean.

not

The not condition is a negation of the nested condition.

For example, the following condition checks the value of x-req-header is not equal to val1:

1not:
2  eq:
3    - "val1"
4    - request_header: x-req-header2

all

The all condition is a list of conditions that all must be true in order for the condition to be true.

For example, the following all condition has a list of eq conditions that check the values of x-req-header1 and x-req-header2, and both eq conditions must be true in order for the all condition to be true:

1all:
2  - eq:
3      - "val1"
4      - request_header: x-req-header1
5  - eq:
6      - "val2"
7      - request_header: x-req-header2

any

The any condition is a list of conditions of which at least one must be true for the condition to be true.

For example, the following any condition has a list of eq conditions that check the values of x-req-header1 and x-req-header2, and at least one of the eq conditions must be true in order for the all condition to be true:

1any:
2  - eq:
3      - "val2"
4      - request_header: x-req-header1
5  - eq:
6      - "val2"
7      - request_header: x-req-header2

Condition configuration reference

The available basic conditions:

You can create complex conditions by using these basic conditions as building blocks.

Example condition configurations

Some example configuration of common use cases for conditions.

Event for a specific subgraph

You can trigger an event for a specific subgraph by configuring a condition with the subgraph's name.

The example below uses the subgraph_name selector to log subgraph responses for the subgraph named "products":

1telemetry:
2  instrumentation:
3    events:
4      subgraph:
5        response:
6          level: info
7          condition:
8            eq:
9            - subgraph_name: true
10            - "products"

On GraphQL error

You can use the on_graphql_error selector to create a condition based on whether or not a GraphQL error is present.

The example configuration below uses on_graphql_error to log only supergraph responses that contain GraphQL errors:

1telemetry:
2  instrumentation:
3    events:
4      router:
5        request:
6          level: info
7          condition: # Only log the router request if you sent `x-log-request` with the value `enabled`
8            eq:
9            - request_header: x-log-request
10            - "enabled"
11        response: off
12        error: error
13      supergraph:
14        response:
15          level: info
16          condition: # Only log supergraph response containing GraphQL errors
17            eq:
18            - on_graphql_error: true
19            - true
20        error: error

On large payloads

For observability of large payloads, you can set attributes using conditions that indicate whether the length of a request or response exceeds a threshold.

The example below sets a custom attribute to true if the length of a request is greater than 100:

1telemetry:
2  instrumentation:
3    spans:
4      mode: spec_compliant
5      router:
6        attributes:
7          trace_id: true
8          payload_is_to_big: # Set this attribute to true if the value of content-length header is > than 100
9            static: true
10            condition:
11              gt:
12              - request_header: "content-length"
13              - 100