Filter internet-scanner noise from control-plane HTTP error log - #29
Draft
saltzm wants to merge 1 commit into
Draft
Filter internet-scanner noise from control-plane HTTP error log#29saltzm wants to merge 1 commit into
saltzm wants to merge 1 commit into
Conversation
Co-Authored-By: matthew@modal.com <saltzm@gmail.com>
Contributor
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The control plane listens on public
:443(net.Listen("tcp", ":443")inlib/server.go), so its socket is constantly hit by internet port scanners and bots. Their failed TLS handshakes and malformed HTTP/2 prefaces are logged by Go'snet/httpserver viahttp.Server.ErrorLog, which — because we never set it — falls back tolog.Default()→ stderr. In Datadog (source:vprox) these dominate the "error"-looking volume: ~1.88Mhttp: TLS handshake error from <ip>: ...lines and ~800http2: server: error reading preface from client <ip>: ...lines over 7 days. None are real server faults.This wires
http.Server.ErrorLogto a filteringio.Writerthat drops those two line categories and forwards everything else to stderr (same destination/format as before,LstdFlags):Minimal and scoped: no change to vprox's own
log.Printfcall sites and no behavior change for any non-scanner log line.go build ./...,go vet ./...,go test ./..., andgofmtall pass.Context / analysis
vprox currently has no log levels — everything is stdlib
log.Printfat one undifferentiated severity, which is why Datadog classifies it all asstatus:info. The scanner lines are the highest-volume "errors" yet aren't emitted by vprox's own logger at all; they come from the stdlib http server, so thisErrorLoghook is the correct place to control them.Alternatives (intentionally NOT in this PR)
log/slogmigration: introduce a structured leveled logger (stdlib, no new dep vs zap/zerolog) and reclassify these lines aswarn/debuginstead of string-filtering, plus confirm the Datadog JSON pipeline mapslevel→status. Larger, mechanical, higher review surface — worth doing separately.Draft for review of the approach/substring list before merge.
Link to Devin session: https://modal.devinenterprise.com/sessions/a2093159c7e541998fbd2fd1c877f3f8
Requested by: @saltzm