Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[receiver/prometheusremotewrite] Add HTTP server to handler PRW requests #35535

Merged
merged 1 commit into from
Oct 7, 2024

Conversation

ArthurSens
Copy link
Member

@ArthurSens ArthurSens commented Oct 1, 2024

Part of #33782

Description:

This PR adds an HTTP server to the prometheusremotewritereceiver component. To keep PRs small for easier reviews, the handler doesn't do anything at the moment.

@ArthurSens
Copy link
Member Author

Questions:

  1. I'm still uncertain if changelog entries are needed for a component under development 🤔. Should I add one?
  2. I've tried building the collector for a manual test, but it looks like this component isn't added to the collector by default. Here are the steps I've done:
  • Built a binary with make otelcontribcol
  • Built a new config file
 receivers:
  prometheusremotewrite:

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    metrics:
      receivers: [prometheusremotewrite]
      exporters: [debug]

After running it I'm getting this error:

error decoding 'receivers': unknown type: "prometheusremotewrite" for id: "prometheusremotewrite" (valid values:...

I had the impression that after merging the new component I could build the collector with it already. Do I need to do something else to be able to test this receiver?

@dashpole
Copy link
Contributor

dashpole commented Oct 2, 2024

You can temporarily add it to here while you are testing: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/cmd/otelcontribcol/components.go. But just don't push

That is part of the "Last PR" in the process of adding new components (https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CONTRIBUTING.md#adding-new-components)

@dashpole
Copy link
Contributor

dashpole commented Oct 2, 2024

And Yes, please add changelogs for each PR.

@ArthurSens ArthurSens changed the title receiver/prometheusremotewrite: Add HTTP server to handler PRW requests chore: receiver/prometheusremotewrite - Add HTTP server to handler PRW requests Oct 2, 2024
@ArthurSens ArthurSens force-pushed the prw-receiver-httpserver branch from fff855a to 5a8d1f2 Compare October 2, 2024 13:50
@ArthurSens
Copy link
Member Author

Alrighty, I'm happy with the results so far

image

Content negotiation and very basic functionality will be done in follow up PRs :)

@ArthurSens ArthurSens force-pushed the prw-receiver-httpserver branch from 5a8d1f2 to 5b0f81e Compare October 2, 2024 13:59
@ArthurSens ArthurSens force-pushed the prw-receiver-httpserver branch from 6c1cfd4 to 7b5d4d9 Compare October 4, 2024 17:36
@jpkrohling jpkrohling changed the title chore: receiver/prometheusremotewrite - Add HTTP server to handler PRW requests [receiver/prometheusremotewrite] Add HTTP server to handler PRW requests Oct 7, 2024
@jpkrohling jpkrohling merged commit 6ce4397 into open-telemetry:main Oct 7, 2024
155 checks passed
@ArthurSens ArthurSens deleted the prw-receiver-httpserver branch October 7, 2024 13:43
@github-actions github-actions bot added this to the next release milestone Oct 7, 2024
ghost pushed a commit to sematext/opentelemetry-collector-contrib that referenced this pull request Oct 9, 2024
…sts (open-telemetry#35535)

Part of
open-telemetry#33782

**Description:** 

This PR adds an HTTP server to the `prometheusremotewritereceiver`
component. To keep PRs small for easier reviews, the handler doesn't do
anything at the moment.

Signed-off-by: Arthur Silva Sens <[email protected]>
andrzej-stencel pushed a commit that referenced this pull request Oct 30, 2024
**Description:** 
This PR builds on top of #35535, adding Content-Type negotiation for
Remote-Write requests (still doesn't handle the data).

Signed-off-by: Arthur Silva Sens <[email protected]>
bogdandrutu pushed a commit that referenced this pull request Nov 2, 2024
…35624)

#### Description
This PR builds on top of #35535 and #35565. We're now making sure we're
able to unmarshal a remote write request, while also exercising the
decompression that is made by OTel's confighttp.

Signed-off-by: Arthur Silva Sens <[email protected]>
ArthurSens added a commit to ArthurSens/opentelemetry-collector-contrib that referenced this pull request Nov 4, 2024
…pen-telemetry#35624)

This PR builds on top of open-telemetry#35535 and open-telemetry#35565. We're now making sure we're
able to unmarshal a remote write request, while also exercising the
decompression that is made by OTel's confighttp.

Signed-off-by: Arthur Silva Sens <[email protected]>
zzhlogin pushed a commit to zzhlogin/opentelemetry-collector-contrib-aws that referenced this pull request Nov 12, 2024
…emetry#35565)

**Description:** 
This PR builds on top of open-telemetry#35535, adding Content-Type negotiation for
Remote-Write requests (still doesn't handle the data).

Signed-off-by: Arthur Silva Sens <[email protected]>
MovieStoreGuy pushed a commit that referenced this pull request Dec 15, 2024
#### Description
This PR builds on top of
#35535,
#35565
and
#35624.

Here we're parsing labels into resource/metric attributes. It's still
not great because resource attributes (with exception to
`service.namespace`, `service.name` and `service.name.id`) are encoded
into a special metric called `target_info`. Metrics related to specific
target infos may arrive in separate write requests, so it may be
impossible to build the full OTLP metric in a stateless way.

In this PR I'm ignoring this problem 😛, and transforming `job` and
`instance` labels into resource attributes, while all other labels
become scope attributes.

Please focus on the latest commit when reviewing this PR :) 
1c9ff80

---------

Signed-off-by: Arthur Silva Sens <[email protected]>
sbylica-splunk pushed a commit to sbylica-splunk/opentelemetry-collector-contrib that referenced this pull request Dec 17, 2024
…emetry#35565)

**Description:** 
This PR builds on top of open-telemetry#35535, adding Content-Type negotiation for
Remote-Write requests (still doesn't handle the data).

Signed-off-by: Arthur Silva Sens <[email protected]>
sbylica-splunk pushed a commit to sbylica-splunk/opentelemetry-collector-contrib that referenced this pull request Dec 17, 2024
…pen-telemetry#35624)

#### Description
This PR builds on top of open-telemetry#35535 and open-telemetry#35565. We're now making sure we're
able to unmarshal a remote write request, while also exercising the
decompression that is made by OTel's confighttp.

Signed-off-by: Arthur Silva Sens <[email protected]>
sbylica-splunk pushed a commit to sbylica-splunk/opentelemetry-collector-contrib that referenced this pull request Dec 17, 2024
#### Description
This PR builds on top of
open-telemetry#35535,
open-telemetry#35565
and
open-telemetry#35624.

Here we're parsing labels into resource/metric attributes. It's still
not great because resource attributes (with exception to
`service.namespace`, `service.name` and `service.name.id`) are encoded
into a special metric called `target_info`. Metrics related to specific
target infos may arrive in separate write requests, so it may be
impossible to build the full OTLP metric in a stateless way.

In this PR I'm ignoring this problem 😛, and transforming `job` and
`instance` labels into resource attributes, while all other labels
become scope attributes.

Please focus on the latest commit when reviewing this PR :) 
1c9ff80

---------

Signed-off-by: Arthur Silva Sens <[email protected]>
mterhar pushed a commit to mterhar/opentelemetry-collector-contrib that referenced this pull request Dec 19, 2024
#### Description
This PR builds on top of
open-telemetry#35535,
open-telemetry#35565
and
open-telemetry#35624.

Here we're parsing labels into resource/metric attributes. It's still
not great because resource attributes (with exception to
`service.namespace`, `service.name` and `service.name.id`) are encoded
into a special metric called `target_info`. Metrics related to specific
target infos may arrive in separate write requests, so it may be
impossible to build the full OTLP metric in a stateless way.

In this PR I'm ignoring this problem 😛, and transforming `job` and
`instance` labels into resource attributes, while all other labels
become scope attributes.

Please focus on the latest commit when reviewing this PR :) 
1c9ff80

---------

Signed-off-by: Arthur Silva Sens <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready to merge Code review completed; ready to merge by maintainers receiver/prometheusremotewrite
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants