feat(outputs.opentelemetry): Support http protocol #17997

minuk-dev · 2025-11-13T19:06:53Z

Summary

OTLP (opentelemetry) provides gRPC and HTTP but opentelemetry output plugin only supports gRPC.
- ref. https://opentelemetry.io/docs/specs/otlp/#otlphttp
So, add some logic to support http protocol with protobuf & json from outputs.opentelemetry

~~### Question~~
~~- I checked other plugins' directories, but is it a coding convention to keep everything within a single file? There's too much logic, so I want to split the file.~~
Solved: #17997 (comment)

Local Test

You can test this feature using below config.

otel.yaml

# otel.yaml
receivers:
  otlp:
    protocols:
        # OTLP/HTTP standard port is 4318
        endpoint: "http://0.0.0.0:4318"

exporters:
  debug:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [debug]

    metrics:
      receivers: [otlp]
      processors: []
      exporters: [debug]

    logs:
      receivers: [otlp]
      processors: []
      exporters: [debug]

docker run --rm -it -v "$(pwd)/otel.yaml":/etc/otel/config.yaml -p 4318:4318 --name otel-collector otel/opentelemetry-collector:latest --config /etc/otel/config.yaml

# telegraf.conf
# skip
[[outputs.opentelemetry]]
protocol = "http"
service_address = "http://localhost:4318/v1/metrics"

Checklist

No AI generated code was used in this PR
AI generated code used in this PR follows the InfluxData Policy on AI-Generated Code Contributions

Related issues

telegraf-tiger · 2025-11-13T19:07:00Z

Thanks so much for the pull request!
🤝 ✒️ Just a reminder that the CLA has not yet been signed, and we'll need it before merging. Please sign the CLA when you get a chance, then post a comment here saying !signed-cla

srebhan

Thanks @minuk-dev for your contribution! I do have some initial comments below. Let's first get the code structure right and then work on the details...

plugins/outputs/opentelemetry/opentelemetry.go

plugins/outputs/opentelemetry/opentelemetry_test.go

srebhan

Thanks @minuk-dev for the update! Here is round two of my comments... ;-)

plugins/outputs/opentelemetry/client.go

srebhan · 2025-12-04T18:48:04Z

plugins/outputs/opentelemetry/client.go

+const (
+	maxHTTPResponseReadBytes = 64 * 1024 // 64 KB
+)


Don't declare this const but just use the value!

I fixed it. But, why?

feaa9c4

Because it is used only in one spot and you can interpret the value from the assignment there. Having this indirection makes reviews harder e.g. if someone changes the value here the consequences in the code are not clear. Use constants if they add value e.g. if you check a numeric return code it's better to write

const errnoUnauthorized = 5 ... if errno == errnoUnauthorized {...}

instead of

if errno == 5 {...}

or if the value might be changed later and is used in multiple places.

plugins/outputs/opentelemetry/opentelemetry_test.go

plugins/outputs/opentelemetry/sample.conf

plugins/outputs/opentelemetry/opentelemetry.go

… for clarity

srebhan

Thanks for the update @minuk-dev! Some more updates...

plugins/outputs/opentelemetry/client_http.go

srebhan · 2025-12-18T12:09:18Z

plugins/outputs/opentelemetry/client_http.go

+	} else {
+		h.httpClient.Transport = &http.Transport{
+			TLSClientConfig: &ntls.Config{
+				InsecureSkipVerify: true,


Hmm we can't enforce this insecure setting! If at all, this should be a user setting.

I need to find other output plugins how to handle it.
Please wait for a while.

Sorry. I fixed it. I made a mistake.

plugins/outputs/opentelemetry/client_http.go

plugins/outputs/opentelemetry/opentelemetry.go

plugins/outputs/opentelemetry/client_http.go

srebhan · 2025-12-18T12:19:56Z

plugins/outputs/opentelemetry/client_http.go

+	defer func() {
+		//nolint:errcheck // cannot fail with io.Discard
+		// 64KB is a not specific limit. But, opentelemetry-collector also uses 64KB for safety.
+		io.CopyN(io.Discard, httpResponse.Body, 64*1024)
+		_ = httpResponse.Body.Close()
+	}()


Why do you need this complexity? Wouldn't

Suggested change

defer func() {

//nolint:errcheck // cannot fail with io.Discard

// 64KB is a not specific limit. But, opentelemetry-collector also uses 64KB for safety.

io.CopyN(io.Discard, httpResponse.Body, 64*1024)

_ = httpResponse.Body.Close()

}()

if _, err := io.Copy(io.Discard, httpResponse.Body) {

return pmetricotlp.ExportResponse{}, err

}

be good enough?

If the server sends very big response unexpectedly, two codes work differently.
So, I think we should use io.CopyN() instead of io.Copy().

Do you think this defensive code is not needed?

Citing the documentation for http.Response:

// The http Client and Transport guarantee that Body is always
// non-nil, even on responses without a body or responses with
// a zero-length body. It is the caller's responsibility to
// close Body. The default HTTP client's Transport may not
// reuse HTTP/1.x "keep-alive" TCP connections if the Body is
// not read to completion and closed.

So either you have to read the whole body if you care for reusing persistent TCP connections or you don't care and then you can just close the body.

Remember that the body is streamed from the connection so if the server sends a "very big response" it will be read and discarded i.e. you read the response from a chunk of memory or a network buffer in the worst case (also memory) and do nothing with it... Which negative effect to you expect from this?

I'm not sure your suggestion is really better. But, I'll change it.
Below is the detailed reason.

Sample code: https://go.dev/play/p/T3vZ1MH-eeK

I use io.CopyN here deliberately as a defensive choice.

This client does not consume the response body, so the goal is to avoid unbounded reads
rather than to maximize connection reuse.

With io.Copy, the client will read until EOF. If the server returns a very large body
or a chunked response that does not terminate properly (e.g. a misbehaving server or
proxy issue), the client would keep reading and consume CPU and network resources.

By limiting the read with io.CopyN, we cap how much data we are willing to consume and
stop early in those cases, even though it means the connection will not be reused.

In this context, protecting client resources is preferred over keep-alive reuse.

You can find many usecases in github.
https://github.com/search?q=io.CopyN%28io.Discard%2C+res.Body&type=code

plugins/outputs/opentelemetry/client_http.go

srebhan · 2025-12-18T12:22:14Z

plugins/outputs/opentelemetry/client_http.go

+func readResponseBody(resp *http.Response) ([]byte, error) {
+	if resp.ContentLength == 0 {
+		return nil, nil
+	}
+
+	maxRead := resp.ContentLength
+
+	// if maxRead == -1, the ContentLength header has not been sent, so read up to
+	// the maximum permitted body size. If it is larger than the permitted body
+	// size, still try to read from the body in case the value is an error. If the
+	// body is larger than the maximum size, proto unmarshaling will likely fail.
+	// 64KB is a not specific limit. But, opentelemetry-collector also uses 64KB for safety.
+	if maxRead == -1 || maxRead > 64*1024 {
+		maxRead = 64 * 1024
+	}
+	protoBytes := make([]byte, maxRead)
+	n, err := io.ReadFull(resp.Body, protoBytes)
+
+	// No bytes read and an EOF error indicates there is no body to read.
+	if n == 0 && (err == nil || errors.Is(err, io.EOF)) {
+		return nil, nil
+	}
+
+	// io.ReadFull will return io.ErrorUnexpectedEOF if the Content-Length header
+	// wasn't set, since we will try to read past the length of the body. If this
+	// is the case, the body will still have the full message in it, so we want to
+	// ignore the error and parse the message.
+	if err != nil && !errors.Is(err, io.ErrUnexpectedEOF) {
+		return nil, err
+	}
+
+	return protoBytes[:n], nil
+}


I really think you should use io.LimitedReader instead.

I think they are different. But, I understand you and I'm not sure about it.
I check it.

I'm not sure I can follow... The body is a ReadCloser so I would do (in the caller side of the code)

// Make sure we close the body defer httpResponse.Body.Close() // Read the body up to the maximum length r := io.LimitReader(httpResponse.Body, maxBodyLength) body, err := io.ReadAll(r) if err != nil { return pmetricotlp.ExportResponse{}, fmt.Errorf("reading response body failed: '%w'", err) } // Discard the rest of the body n, err := io.Copy(io.Discard, httpResponse.Body) if err != nil { return pmetricotlp.ExportResponse{}, fmt.Errorf("discarding remaining response body failed: '%w'", err) } if n > 0 { return pmetricotlp.ExportResponse{}, fmt.Errorf("response body %d byte larger than supported maximum", n) }

I think we don't need to use resp.ContentLength in your version.
We don't have to discard the rest of the body.

So, I changed it like this: 17a6922.

…ethod

srebhan

Thanks @minuk-dev! Please see my comment and also my responses above.

srebhan · 2025-12-19T13:27:27Z

plugins/outputs/opentelemetry/client_http.go

+	exportResponse := pmetricotlp.NewExportResponse()
+	switch httpResponse.Header.Get("Content-Type") {
+	case "application/x-protobuf":
+		err = exportResponse.UnmarshalProto(responseBytes)
+		if err != nil {
+			return pmetricotlp.ExportResponse{}, err
+		}
+	case "application/json":
+		err = exportResponse.UnmarshalJSON(responseBytes)
+		if err != nil {
+			return pmetricotlp.ExportResponse{}, err
+		}
+	}


I think this must be

Suggested change

exportResponse := pmetricotlp.NewExportResponse()

switch httpResponse.Header.Get("Content-Type") {

case "application/x-protobuf":

err = exportResponse.UnmarshalProto(responseBytes)

if err != nil {

return pmetricotlp.ExportResponse{}, err

}

case "application/json":

err = exportResponse.UnmarshalJSON(responseBytes)

if err != nil {

return pmetricotlp.ExportResponse{}, err

}

}

exportResponse := pmetricotlp.NewExportResponse()

switch httpResponse.Header.Get("Content-Type") {

case "protobuf":

if err := exportResponse.UnmarshalProto(responseBytes); err != nil {

return pmetricotlp.ExportResponse{}, err

}

case "json":

if err := exportResponse.UnmarshalJSON(responseBytes); err != nil {

return pmetricotlp.ExportResponse{}, err

}

}

The contentType is from the http response's header.
So, we cannot use it like that.

…andling

telegraf-tiger · 2026-01-01T18:57:01Z

Download PR build artifacts for linux_amd64.tar.gz, darwin_arm64.tar.gz, and windows_amd64.zip.
Downloads for additional architectures and packages are available below.

☺️ This pull request doesn't significantly change the Telegraf binary size (less than 1%)

📦 Click here to get additional PR build artifacts

Artifact URLs

. DEB	. RPM	. TAR . GZ	. ZIP
amd64.deb	aarch64.rpm	darwin_amd64.tar.gz	windows_amd64.zip
arm64.deb	armel.rpm	darwin_arm64.tar.gz	windows_arm64.zip
armel.deb	armv6hl.rpm	freebsd_amd64.tar.gz	windows_i386.zip
armhf.deb	i386.rpm	freebsd_armv7.tar.gz
i386.deb	ppc64le.rpm	freebsd_i386.tar.gz
mips.deb	riscv64.rpm	linux_amd64.tar.gz
mipsel.deb	s390x.rpm	linux_arm64.tar.gz
ppc64el.deb	x86_64.rpm	linux_armel.tar.gz
riscv64.deb		linux_armhf.tar.gz
s390x.deb		linux_i386.tar.gz
		linux_mips.tar.gz
		linux_mipsel.tar.gz
		linux_ppc64le.tar.gz
		linux_riscv64.tar.gz
		linux_s390x.tar.gz

telegraf-tiger bot added feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin plugin/output 1. Request for new output plugins 2. Issues/PRs that are related to out plugins labels Nov 13, 2025

minuk-dev force-pushed the iss17713 branch from c2363d0 to 2e409df Compare November 13, 2025 19:25

minuk-dev marked this pull request as ready for review November 13, 2025 19:42

srebhan reviewed Nov 17, 2025

View reviewed changes

srebhan self-assigned this Nov 17, 2025

srebhan changed the title ~~feat(outputs.opentelemetry): support http protocol with protobuf & json encoding~~ feat(outputs.opentelemetry): Support http protocol Nov 17, 2025

minuk-dev marked this pull request as draft November 17, 2025 14:18

minuk-dev marked this pull request as ready for review November 26, 2025 15:56

srebhan reviewed Dec 4, 2025

View reviewed changes

srebhan added the waiting for response waiting for response from contributor label Dec 10, 2025

minuk-dev force-pushed the iss17713 branch from c981b15 to baf1fd2 Compare December 14, 2025 12:28

minuk-dev requested a review from srebhan December 14, 2025 12:42

minuk-dev added 16 commits December 15, 2025 08:47

refactor(output;opentelemetry): split grpcClient

169a3e3

feat(outputs.opentelemetry): add protocol to support http

36416ea

feat(outputs.opentelemetry): implement otlphttp

512a4c5

docs(outputs.opentelemetry): update README.md

93ade38

feat(output;opentelemetry): set default value

c04e042

fix(outputs.opentelemetry): fix nil error

c6fe3a2

test(outputs.opentelemetry): add test

078d3bb

feat(output;opentelemetry): set default value

cfcf2d1

docs: add comment about readResponseBody's original code

356894c

docs: add sample.conf

5512d7c

chore: fix lint

c114a84

refactor: optimize switch as interface

aee4404

fix: add gzip content-encoding header

dbee0a3

remove dummy interface assertion

9104bd0

remove comment

9d69e5b

refactor close func

c41f567

minuk-dev added 14 commits December 15, 2025 08:47

split client file

c98eb68

refactor client init as connect

62aea5a

remove protocol

7e988eb

refactor: cleanup client config

1aa3d21

remove declaring constant

f1ec453

refactor: split client file for http, grpc

328baff

fix: close http idle connection

00d3314

refactor: replace maxHTTPResponseReadBytes constant with inline value…

4a13ac2

… for clarity

test: simplify assertion & fix missing test http response

456d1e5

docs: remove outdated protocol field

c1b643f

fix: use literal instead of const

7e69065

chore: fix lint

f7a0180

refactor: simplify encoding_type's value

79737d6

chore: re-align for readability

b8fecf6

srebhan removed the waiting for response waiting for response from contributor label Dec 18, 2025

srebhan reviewed Dec 18, 2025

View reviewed changes

minuk-dev added 3 commits December 18, 2025 23:25

refactor: rename ntls to tls

8d30432

refactor: update encoding type handling in Export and Connect methods

0b8550d

refactor: streamline TLS configuration handling in Connect method

2ea252d

minuk-dev force-pushed the iss17713 branch from ab60d9a to 2ea252d Compare December 18, 2025 14:53

refactor: improve error message for non-2xx HTTP response in Export m…

390d2ca

…ethod

srebhan reviewed Dec 19, 2025

View reviewed changes

minuk-dev added 2 commits January 2, 2026 03:33

fix: reuse connection always

f9b6008

refactor: replace readResponseBody with io.LimitReader for response h…

17a6922

…andling

feat(outputs.opentelemetry): Support http protocol #17997

Are you sure you want to change the base?

feat(outputs.opentelemetry): Support http protocol #17997

Conversation

minuk-dev commented Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Local Test

Checklist

Related issues

Uh oh!

telegraf-tiger bot commented Nov 13, 2025

Uh oh!

srebhan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

srebhan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

srebhan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

srebhan Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

srebhan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

minuk-dev commented Nov 13, 2025 •

edited

Loading

srebhan Dec 19, 2025 •

edited

Loading