Log Entries created as LOGLEVEL/Severity "ERROR" by default

[x123]

A number of the different log entries seem to be logged at LOGLEVEL "error" by default, for instance:

certstream-server-go/internal/certificatetransparency/ct-watcher.go

Line 420 in bf24abb

if processed%1000 == 0 {

These type of entries, which don't appear to be errors, but rather INFO level logigng:

"2025/08/09 10:32:55 ct-watcher.go:356: Processed 12188000 entries | Queue length: 14"

Show up in the logs as this if you wrap this server up in a container and run it in k8s, for instance:

{
insertId: "REDACTED"
labels: {6}
logName: "REDACTED"
payload: "textPayload"
receiveLocation: "REDACTED"
receiveTimestamp: "2025-08-09T10:32:55.753906272Z"
resource: {2}
severity: "ERROR"
textPayload: "2025/08/09 10:32:55 ct-watcher.go:356: Processed 12187000 entries | Queue length: 15"
timestamp: "2025-08-09T10:32:55.101944803Z"
traceSampled: false
}

there are obviously some that deserve to be ERROR level, and are correctly reflected:

https://mammoth2026h2.ct.sectigo.com: GetRawEntries() failed: got HTTP Status "400 Bad Request"

Any chance that the status updates about Processed numbers and Queue Length could be set at an INFO level? May try my hand at fixing it and submitting a PR in the coming days/weeks.

[d-Rickyy-b]

Thanks for reporting this issue. Currently, I am not using any log levels explicitly as of now. Anything that's logged is done through go's default log.Println and log.Printf method. The Go standard library logs everything to stderr (reference). And k8s interprets everything logged to stderr as severity ERROR (reference).

As stated in the reddit post, "Only the actual output / results of a Unix tool belong to stdout". That's clearly debatable, as we're not dealing with a command line tool here. So we'd need to use setOutput to os.StdOut for most logs and os.StdErr for error logs.

I might also switch to Go's "new" structured logging library "slog" (see this blog post) in the future to have proper log levels in the log output and change the log destination depending on the chosen level.

I appreciate any help and PRs :)

[x123]

Makes total sense. Will circle back to this one if I get a few cycles and see if I could help in any way. Feel free to look at the repo https://github.com/x123/certstream-server-go (it's nothing special), but have a deterministic nix flake and then use that to build the Containerfile (similar to https://mitchellh.com/writing/nix-with-dockerfiles ) and have a little k8s helm chart which I'll likely make a kustomize variant of.