Handle HTTP/2 GOAWAY messages when writing to outputs
#11,901 opened on 2022年9月28日
Repository metrics
- Stars
- (9,892 stars)
- PR merge metrics
- (平均マージ 2d 12h) (30d で 136 merged PRs)
説明
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.