influxdata/telegraf

Handle HTTP/2 GOAWAY messages when writing to outputs

Open

#11,901 opened on Sep 28, 2022

View on GitHub
 (2 comments) (0 reactions) (0 assignees)Go (4,161 forks)batch import
feature requesthelp wantedsize/m

Repository metrics

Stars
 (9,892 stars)
PR merge metrics
 (Avg merge 2d 12h) (136 merged PRs in 30d)

Description

Use Case

HTTP/2 introduced a means for servers to tell clients to stop sending requests over a specific connection - the GOAWAY signal - (HTTP/1.1 needed to wait until it finished processing a request and then send Connection: Close, HTTP/2 does not).

AWS's Application Load Balancers (ALBs) sometimes send GOAWAY messages, for various reasons, the two main documented ones being

  • if the compressed length of any of the headers exceeds 8 K bytes
  • if the number of requests served through one connection exceeds 10,000

So, if an output connection is sufficiently long-lived that it carries 10,000 writes (which may not be that long a time for a busy instance), the ALB will eventually send a GOAWAY

Expected behavior

Telegraf should receive the GOAWAY, close the connection, and resubmit over a new one.

Actual behavior

Telegraf logs an error

2022-09-12T10:37:00Z E! [outputs.influxdb] When writing to [https://[ALB address]:8086/]: failed doing req: Post "https://[ALB address]:8086/write?db=messaging": http2: Transport: cannot retry err [http2: Transport received Server's graceful shutdown GOAWAY] after Request.Body was written; define Request.GetBody to avoid this error
2022-09-12T10:37:00Z E! [agent] Error writing to outputs.influxdb: could not write any address

Additional info

The data isn't lost - because the write didn't complete successfully, it remains in the buffer and will be written out at the next flush interval.

But, it does lead to a level of log noise where telegraf's being used as an aggregator and performing a lot of writes.

Contributor guide