It seems that with advent of technologies for capturing errors with breadcrumbs there is a diminished need for ever reading error logs.<p>I am talking about sifting through large log files looking for clues as to what happened.<p>If you do, I would be curious to know what's your use case?
Logging isn't only error catching (though I do use it for that). Logging also gets you metrics, access info, timing info, etc. You can get a lot of insights out of the http access logs of a server, even without having errors.
Good structured logs help you understand what happens, even if you don’t necessarily get an error per say.<p>My use case is distributed backend traffic written in many different languages, none of them supported by Sentry breadcrumbs (I think that’s what you meant).<p>In another context, I’ve seen logs for some internet providers log where they branch off according to their spec: you could read the logs as an actual tree of decisions taken by the program and compare it with the spec.<p>Sometimes, if someone asks me what a program does, I’d say "it logs, mainly, and produces a http response too".
Every day. I spent most of my time since April sifting through production logs to track down a bug between FSEvents and Watchman that produced incorrect query results. Despite much effort, I was never able to reproduce locally. Logs, ring buffers, and remote event recording are invaluable.
>> "capturing errors with breadcrumbs"<p>Forgive my ignorance, but what is this?<p>How would I set up my server that handles API requests to use it?