wrapcheck
json-log-explorer
wrapcheck | json-log-explorer | |
---|---|---|
3 | 1 | |
279 | 3 | |
- | - | |
3.9 | 1.8 | |
3 months ago | 10 months ago | |
Go | TypeScript | |
MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
wrapcheck
-
Structured Logging with Slog
This is such an infuriating problem. I'm convinced I'm using Go wrong, because I simply can't understand how this doesn't make it a toy language. Why the $expletive am I wasting 20-30 and more minutes per week of my life looking for the source of an error!?
Have you seen https://github.com/tomarrell/wrapcheck? It's a linter than does a fairly good job of warning when an error originates from an external package but hasn't been wrapped in your codebase to make it unique or stacktraced. It comes with https://github.com/golangci/golangci-lint and can even be made part of your in-editor LSP diagnostics.
But still, it's not perfect. And so I remain convinced that I'm misunderstanding something fundamental about the language because not being able to consistently find the source of an error is such an egregious failing for a programming language.
-
Wrapcheck v2.3.0 released: Ignore package signatures
If you're curious to read more, you can have a read here: https://blog.tomarrell.com/post/introducing_wrapcheck_linter_for_go
json-log-explorer
-
Structured Logging with Slog
I hadn't even considered collecting traces/spans in this way yet, and have taken the approach of "stuff outputting logs in JSON format to stderr/local file". I usually end up writing a (temporary, structured) log message with the relevant span tags, but wouldn't it would be much better to run the actual trace/span code and be able to verify it locally without the ad-hoc log message?
The prototype I built is a web application that creates websocket connections, and if those connections receive messages that are JSON, log lines are added. Columns are built dynamically as log messages arrive, and then you can pick which columns to render in the table. If you're curious here's the code, including a screenshot: https://github.com/corytheboyd-smartsheet/json-log-explorer
With websockets, it's very easy to use websocketd (http://websocketd.com), which will watch input files for new lines, and write them verbatim as websocket messages to listeners (the web app).
To make the idea real, would want to figure out how to not require the user to run websocketd out of band, but watching good ol' files is dead simple, and very easy to add to most code (add a new log sink, use existing log file, etc.)
What are some alternatives?
revive - 🔥 ~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for golint
chock - Golang Result handling package
emperror - The Emperor takes care of all errors personally
Bunyan - a simple and fast JSON logging module for node.js services
dockle - Container Image Linter for Security, Helping build the Best-Practice Docker Image, Easy to start
websocketd - Turn any program that uses STDIN/STDOUT into a WebSocket server. Like inetd, but for WebSockets.
go-critic - The most opinionated Go source code linter for code audit.
lnav - Log file navigator
errcheck - errcheck checks that you checked errors.
zap - Blazing fast, structured, leveled logging in Go.
Benthos - Fancy stream processing made operationally mundane