[httpcheckreceiver] new receiver

[codeboten]

The HTTP Check Receiver can be used for synthethic checks against HTTP endpoints. This receiver will make a request to the specified endpoint using the configured method.

Here's an example configuration:

receivers:
  httpcheck:
    endpoint: http://endpoint:80
    method: GET
    collection_interval: 10s

The metrics being emitted:

ResourceMetrics #0
Resource SchemaURL:
ScopeMetrics #0
ScopeMetrics SchemaURL:
InstrumentationScope otelcol/httpcheckreceiver v0.62.0-6-g847c930f95
Metric #0
Descriptor:
     -> Name: httpcheck.duration
     -> Description: Measures the duration of the HTTP check.
     -> Unit: ms
     -> DataType: Gauge
NumberDataPoints #0
Data point attributes:
     -> http.url: Str(https://lightstep.com)
StartTimestamp: 2022-10-13 18:34:04.43338 +0000 UTC
Timestamp: 2022-10-13 18:34:14.436818 +0000 UTC
Value: 204
Metric #1
Descriptor:
     -> Name: httpcheck.status
     -> Description: 1 if the endpoint resulted in status http.status_code, otherwise 0.
     -> Unit: 1
     -> DataType: Sum
     -> IsMonotonic: false
     -> AggregationTemporality: Cumulative
NumberDataPoints #0
Data point attributes:
     -> http.method: Str(GET)
     -> http.status_class: Str(3xx)
     -> http.status_code: Int(200)
     -> http.url: Str(https://lightstep.com)
StartTimestamp: 2022-10-13 18:34:04.43338 +0000 UTC
Timestamp: 2022-10-13 18:34:14.436818 +0000 UTC
Value: 0
NumberDataPoints #1
Data point attributes:
     -> http.method: Str(GET)
     -> http.status_class: Str(4xx)
     -> http.status_code: Int(200)
     -> http.url: Str(https://lightstep.com)
StartTimestamp: 2022-10-13 18:34:04.43338 +0000 UTC
Timestamp: 2022-10-13 18:34:14.436818 +0000 UTC
Value: 0
NumberDataPoints #2
Data point attributes:
     -> http.method: Str(GET)
     -> http.status_class: Str(5xx)
     -> http.status_code: Int(200)
     -> http.url: Str(https://lightstep.com)
StartTimestamp: 2022-10-13 18:34:04.43338 +0000 UTC
Timestamp: 2022-10-13 18:34:14.436818 +0000 UTC
Value: 0
NumberDataPoints #3
Data point attributes:
     -> http.method: Str(GET)
     -> http.status_class: Str(1xx)
     -> http.status_code: Int(200)
     -> http.url: Str(https://lightstep.com)
StartTimestamp: 2022-10-13 18:34:04.43338 +0000 UTC
Timestamp: 2022-10-13 18:34:14.436818 +0000 UTC
Value: 0
NumberDataPoints #4
Data point attributes:
     -> http.method: Str(GET)
     -> http.status_class: Str(2xx)
     -> http.status_code: Int(200)
     -> http.url: Str(https://lightstep.com)
StartTimestamp: 2022-10-13 18:34:04.43338 +0000 UTC
Timestamp: 2022-10-13 18:34:14.436818 +0000 UTC
Value: 1
	{"kind": "exporter", "data_type": "metrics", "name": "logging"}

Fixes #10607

[mwear]

Is it worth considering any other representations of this metric? One thought is that if this were httpcheck.status where the value is the status code, then you wouldn't have to interpret what success means. Success, failure, etc could be determined on the query side.

[codeboten]

That's correct, the representation could be the status code itself (which is currently an attribute). I don't have a strong preference one way or the other. The success/failure metric is similar to probe_success emitted by https://github.com/prometheus/blackbox_exporter. It does mean that this receiver will need to have a way for users to configure success/failure.

[carlosalberto]

Out of curiosity, do you expect users to check the method attribute? e.g. probe both GET and POST in the same service?

[codeboten]

i wouldn't expect someone to want to hit the same endpoint with different methods. i would expect consumers of the telemetry to want to be able to filter responses by the method though.

[djaglowski]

I think it would make a lot of sense to keep the status code as an attribute, but also to change the meaning of the value from "success" to "a single observation of this status code".

You would expect subsequent observations to look like this:

{ "time": "t0", "url": "/foo", "method": "GET", "code": 200, "value": 1 }
{ "time": "t1", "url": "/foo", "method": "GET", "code": 200, "value": 1 }
{ "time": "t2", "url": "/foo", "method": "GET", "code": 404, "value": 1 } // outage
{ "time": "t3", "url": "/foo", "method": "GET", "code": 200, "value": 1 }

See my other comment for more on why I think this model is useful for summarization.

[jmacd]

See my suggestion to make this a 0-1 metric similar to or perhaps specified to create an OpenMetrics StateSet. @dashpole note the connection to #1712 and #2409.

[dashpole]

I've reviewed your other comment, and I think this would be a great way to represent this sort of information! A unit seems like the best place I can think of for putting that information, and it makes sense in contexts other than Prometheus.

[dashpole]

Seems like we could take a similar approach for info metrics as well.

[jmacd]

Sounds good!

[carlosalberto]

Symbolic approval, this looks good! Also interested to help improve this with a few potential additions ;)

[djaglowski]

I think it would make a lot of sense to keep the status code as an attribute, but also to change the meaning of the value from "success" to "a single observation of this status code".

You would expect subsequent observations to look like this:

{ "time": "t0", "url": "/foo", "method": "GET", "code": 200, "value": 1 }
{ "time": "t1", "url": "/foo", "method": "GET", "code": 200, "value": 1 }
{ "time": "t2", "url": "/foo", "method": "GET", "code": 404, "value": 1 } // outage
{ "time": "t3", "url": "/foo", "method": "GET", "code": 200, "value": 1 }

See my other comment for more on why I think this model is useful for summarization.

[jmacd]

See my suggestion to make this a 0-1 metric similar to or perhaps specified to create an OpenMetrics StateSet. @dashpole note the connection to #1712 and #2409.

[codeboten]

Thanks to everyone for all the input. I've updated httpcheck.status to produce a data point for each http response class (1xx, 2xx, 3xx, 4xx, 5xx). The resulting data looks something like this:

I've also added another metric to allow users to count the number of errors that occurred. Previously, i was using the status code -1 which seemed a bit cryptic.

@mwear @djaglowski @jmacd PTAL