Validating output
Define rules that a test run's output must satisfy.
A test run shows what a pipeline produces. The Validation sub-tab defines rules that the output is checked against, so a run passes or fails automatically instead of being read by hand.
Validation pipelines
Rules are grouped into validation pipelines. A validation pipeline holds the rules for one of the configuration's YAML pipelines: when a test run targets that pipeline, the rules in its group are evaluated against the run's output. Each YAML pipeline can have one validation pipeline.
- Open the Validation sub-tab and select + Pipeline.
- Select the YAML pipeline the group checks. Pipelines that already have a group cannot be selected again.
Each group renders as a card titled with its pipeline's name. A run that targets a pipeline with no group, or an empty group, is evaluated with no rules: success means the collector ran cleanly.
If the group's pipeline is later removed from the YAML, the card shows a warning and its rules stop running, but the group stays editable until you delete it. Deleting a group deletes its rules.
Validation rules
A validation rule checks a run automatically, so a run passes or fails without you reading the output by hand. Each rule evaluates the captured output, or the collector's stderr, of runs that target its group's pipeline.
To add a rule, expand the group's card, select Add Validation Rule, and choose a Rule type.
| Rule type | Checks |
|---|---|
| Match output text | The output or stderr contains, or does not contain, a value, matched as text or regex. |
| Record count | The number of records (datapoints, spans, or log records) is within a threshold. |
| Record attribute | An attribute on the records meets a condition, such as being present or equal to a value. |
| OTTL condition | Records satisfy an OTTL condition you write, with a quantifier over how many must match. |
Record count and Record attribute are guided builders: they save as OTTL rules and reopen in the builder when edited. A rule that goes beyond the builder's shape, such as a composed condition, opens in OTTL mode instead. The builder's helper points there: for nested fields or composed conditions, switch to OTTL mode.
OTTL expressions are syntax-checked against the collector's OTTL grammar when the rule is saved; a syntax error blocks the save. If the syntax check is unavailable, the rule saves and any error is reported when a run evaluates it.
A run with a failing rule is marked Validation Failed.
Attribute checks
The Record attribute rule confirms a pipeline produced the attributes you expect. For example, check that k8s.pod.name is present on every record after a k8sattributes processor runs, or that a sensitive attribute is gone after redaction.
A record attribute rule has the following fields.
| Field | Description |
|---|---|
| Require | Which records must satisfy the condition: All records match, At least one matches, No record matches, Matching count…, or Distinct values…. The count options open a comparison, from Exactly to Between. |
| Scope | Where the attribute is read: Resource, Scope, or Record. |
| Attribute key | The attribute to check, such as k8s.pod.name. |
| Operator | The condition to apply: Exists, Equals, Contains, Matches regex, or a numeric comparison such as Greater than or At most. |
| Value | The value to compare against. Not used with the Exists operator. |
To check that an attribute is present, set Require to All records match and Operator to Exists. To check that an attribute is absent, set Require to No record matches with the Exists operator.
OTTL conditions
The OTTL condition rule evaluates an OTTL condition against the run's records, using the same expression language as the transform and filter processors.
| Field | Description |
|---|---|
| Context | The level the condition reads: for example span, datapoint, or log, plus resource and scope. The options are trimmed to the pipeline's signal type. |
| Require | The quantifier: All records match, At least one matches, No record matches, Matching count…, or Distinct values…. The count options open a comparison, from Exactly to Between. |
| OTTL condition | The condition itself, such as attributes["http.status_code"] >= 500. Conditions compose with and, or, and not. |
Distinct values… counts the distinct values a Value expression resolves to, such as attributes["http.route"], and compares the count to the threshold; the condition field becomes an optional row filter. Use it as a cardinality guardrail against a high-cardinality attribute inflating your metrics ingest. At most 0 asserts that the value never appears in the output.
Output and stderr
A Match output text rule reads from one of two streams, set by Read from:
- Output. The OTLP records the pipeline produced. Use it to assert on what your processors emit.
- Stderr. The collector's own diagnostic log. Use it to catch silent processor drops, OTTL parse errors, and exporter rejections that never reach the output.
Compare a run's input and output
A run with an OTLP input offers a Compare input ↔ output view: a side-by-side diff of the input and output records. Detected changes are offered as candidate rules, as chips such as + attribute added, + attribute removed, or + attribute changed. Selecting one opens the rule editor pre-filled with an OTTL rule asserting the output state, so an observed change becomes a rule directly.
Rules created by the AI assistant
The AI assistant's Build mode can run pipeline tests and saves the assertions it checked to the pipeline's validation collection, with the description Created by the AI assistant. A later assistant run replaces only the rules the assistant created; rules you author are never touched. See AI assistant.
Regex library
When a rule matches with a regular expression, Telflo provides a picker and editor to select or write the expression. Common sensitive-data patterns, such as credit card and CVV numbers, are available from a regex library and can be added to a group in one step with Add from regex library.
Use rules with a run
- Define rules in the validation pipeline for the pipeline you test.
- Run a test that targets that pipeline. See Running tests.
- Telflo evaluates the captured output against the group's rules and reports which passed and which failed.
Combine rules with test suites so a saved test is checked the same way every time.
Static validation
Telflo also validates a configuration structurally and against the collector schema as you build. See Validation. Static validation confirms the configuration is valid. Output validation confirms it behaves as expected on sample data.
Last updated on