receiver/httpcheck: add structured validation result metrics

[VenuEmmadi]

Description

Adds structured response validation metrics to the HTTP Check Receiver.

Problem: Previously, httpcheck.validation.passed and httpcheck.validation.failed only exposed aggregated counts per validation type, making it difficult to identify which specific validation rule passed or failed when multiple validations were configured for the same endpoint.

Solution: This change introduces a new metric, httpcheck.validation.result, which emits one datapoint per validation rule.

The new metric emits one datapoint per validation rule with the following structured attributes:

Attribute	Description	Example
validation.type	Type of validation performed	json_path, contains, regex, size
validation.path	The expression being evaluated	system_3, healthy, ^ok$
validation.expected	Expected value (when equals specified)	true, ok, 200
validation.result	Pass/fail result of the validation	passed, failed

Example Output:

httpcheck.validation.result{
  validation.type="json_path",
  validation.path="system_3",
  validation.expected="true",
  validation.result="failed"
} = 1

This enables users to:

• Identify exactly which validation failed
• Query validations by JSON path or validation expression
• Monitor multiple validations from a single HTTP request
• Avoid configuring multiple duplicate receivers for the same endpoint

Why this matters: Without this change, a user with the following API response:

{"system_1": true, "system_2": true, "system_3": false}

and multiple validations would only see aggregated validation counts, without visibility into which specific validation failed. The new structured metric makes each validation independently observable.

Backward compatibility: The following legacy metrics continue to work unchanged as aggregate metrics that expose counts grouped by validation type:

• httpcheck.validation.passed
• httpcheck.validation.failed

Link to tracking issue

Fixes #44662

Testing

Added unit tests covering:

• Structured validation result metrics
• JSON path validation attributes
• Passed and failed validation scenarios
• Backward compatibility for legacy metrics
• Multiple validation types:
  • json_path
  • contains
  • regex
  • size

Verified:

• One datapoint is emitted per validation rule
• validation.path correctly identifies the evaluated validation
• validation.result correctly reports passed/failed state
• Legacy metrics continue emitting aggregated counts by validation type

Documentation

Updated receiver/httpcheckreceiver/README.md with:

• Documentation for the new httpcheck.validation.result metric
• Structured attribute descriptions
• Example metric outputs
• Multiple JSON path validation examples
• Backward compatibility notes for legacy metrics
• Updated validation configuration examples
• Clarification for gjson path syntax usage

[thompson-tomo]

Suggested change

	httpcheck.validation.result:
	httpcheck.validation.outcome:

[thompson-tomo]

Suggested change

	attributes: [http.url, validation.type, validation.path, validation.expected, validation.result]
	attributes: [http.url, httpcheck.validation.type, httpcheck.validation.path, httpcheck. validation.expected, httpcheck.validation.result]

[VenuEmmadi]

Lets Keep current names. OTel conventions typically use short, scoped names. validation.type is clear within httpcheck context.

[thompson-tomo]

Suggested change

	validation.result:
	httpcheck.validation.result:

[VenuEmmadi]

Lets Keep current names.

[thompson-tomo]

Suggested change

	validation.path:
	httpcheck.validation.path:

Or

Suggested change

	validation.path:
	httpcheck.validation.expression:

[VenuEmmadi]

Lets use validation.expression - it's more generic and accurate.

[thompson-tomo]

Suggested change

	validation.type:
	httpcheck.validation.type:
	description: Type of validation performed (contains, json_path, size, regex)
	type: string
	requirement_level: recommended
	validation.type:

[VenuEmmadi]

Lets Keep current names.

[thompson-tomo]

Suggested change

	validation.expected:
	httpcheck.validation.expected:

Or maybe

Suggested change

	validation.expected:
	httpcheck.response.expected:

[VenuEmmadi]

Lets Keep current names.

[thompson-tomo]

I am wondering if we should remove validation.path & validation.expected from a metric due to cardinality & instead complement the metric with an event httpcheck.validation.failure. This event would emit that lower level detail and can add things like error.message.

[VenuEmmadi]

Lets Keep as is. Cardinality is safe (static config values). Events would make debugging harder for users.