Track Errors First(bugsink.com) |
Track Errors First(bugsink.com) |
You can try to avoid it by architecture or abstractions, but it only works to some extent.
No! The other way around! All the other events should have context as well. I want to cry every time when I get a random warning-severity log that may or may not indicated something I need to look into.. without collecting the context which is collected on error-severity logging.
So the text was truncated? What? Where? Why? (don't truncate passwords before comparison, please!?) So the kernel logged some WARN dump? In response to what operation? Does only the 6.12 do that, or am I receiving this one from 6.14 machines as well? So the library says the "update()" method is deprecated? Which one of 10 update() methods in that library? Called from where?
[0] https://www.bugsink.com/blog/capture-stacktrace-no-exception...
Glad to see one more on the market. I only knew about GlitchTip prior to today.
Bugsink looks nice and straight forward, and if anything other than email - the absolute worst medium for notifications - lands in there I'll probably make the switch.
it's done: https://github.com/bugsink/bugsink/issues/3
Dicussed on r/programming this morning[0] (on my side of the world) where someone probably picked it up
I'll be in the thread for a while I guess
[0] https://www.reddit.com/r/programming/comments/1l3sj8g/track_...
Maybe one reason is that in many organisations I've seen a lot of "noise" in the error logs, logging things as errors that really aren't errors, which hugely reduces the usefulness. It requires a bit of discipline to keep the error logs clean, but honestly, it's not that hard.
I've found logs of successes, rather than errors, to be useful for understanding attacks or gnarly performance issues. Seeing that you have a lot of long-running requests for a particular user or tenancy when you're running out of database connections is an example that springs to mind.
* For vendors logging is _awesome_. There's basically no upper limit, you can log all kinds of things, and you can bill them by usage. And because of the scale it's hard to do locally, which is also good news for vendors.
* On the developer-side, there's always the "let's not think about it too much right now, let's just collect a bunch of info" argument for logging. Which is great if you don't want to think (more kindly: if you're facing deadlines)
I'm sure there's good cases for logging (I read logs occasionally too) but it wouldn't be my _first_ thing to heavily invest in (hence the article)
Well, they've going that way for ages. But officially entering the stage where it's better to always ignore whatever they have to say is an important landmark anyway.
Right now, I'm playing with the idea to log json in those files and send this also to Signoz, Sentry, graylog, or whatever. This way, my logfiles are still tail-able and grep-able. Very important for development and "the customer is furious, WTF is going on in production" situations.
And also some other software can email me, according to some rules. This helps to have less furious customers. And maybe it can draw some cute graphs, so I can tell management that prod runs great!
Logs should be readable. What that means you should get the relevant information by reading the file after maybe searching for something a few times. That requires that the information there should be about a single topic. If that's too much, it should be tagged so that your tooling can make it readable, but this is for huge services.
In practice most companies are always sending some PII (or even PHI....) to Sentry because filtering is always one step behind. Having it self-hosted would be my strong preference, but self hosting that is a PITA.
No hate on Sentry by the way, but we (and some of our clients in the Netherlands) also like to have a European alternative, and it's a big bonus that this has a very low switching cost.
Good logs do
it's my experience that a full stacktrace is needed (or at least super-helpful) when debugging, since the innermost (triggering) level is not always the level where the problem was introduced. Getting full context (including the values of local variables) all the way up the stack makes that puzzle a whole lot easier.
> Bugsense is a crash reporter [..] In September 2013, Bugsense was acquired by Splunk
You say you’re compatible with the Sentry SDKs, but it’s not at all clear to me which of these platforms will do useful things with Bugsink and which will not.
Mind you this example is the one of the most trivial data structures in existence. Real software has insanely more complicated valid/invalid state, the size of the state space growing exponentially with the number of components.
And these are still single components, so the exponential growth of state combinations point is left unaddressed. In fact, it directly supersedes your point in this comment, as the exponentiality eats your "random data" idea before you even wrote it.
The way I look at testing is less about the current point in time. It is about changes over time. If someone else comes along and changes the underlying implementation to a list where sort order is not guaranteed (maybe thinking their version is faster or something), then the tests will fail and that's exactly what you want. You're testing the expected behavior over time and right now, the expected behavior is a sorted list.
Regardless, I don't understand what you're trying to argue or prove here. Yes, testing is hard and not easily won, I already said that.
I am arguing against your claim that this particular suggestion is feasible for anything but toy projects.
https://erikras.com/blog/final-form-to-typescript
"Of course, it helped that long ago I had put in all of the legwork to have near 100% test coverage, so I could be certain that the migration did not introduce any bugs."