Do you catch and log errors of your productions web apps?
If so, which tools/libs/methods are you using?
If not, why did you decide to ignore it?
For further actions, you may consider blocking this person and/or reporting abuse
Read next
ES6 Spread Operator: Unleashing the Power of Modern JavaScript
Ellis -
Artificial Intelligence and Machine Learning in Web Development
Bradley Dirheimer -
The Most Important Thing I learned About Writing Readable Code
Karl Esi -
Animation in SVG
Tom Nijhof -
Top comments (10)
Depends on the application and the stack used to deploy it. That should determine what tools are available. Automated ones are nice and can be used to send you notifications of problems.
I would like to point out that every single service that does error/logging/analytics for you, is crap. There, I said, they're crap. They'll for example give you beautiful graphs of how many 404s you have per hour, but they won't show you why it 404d, or how to address it and fix it. They'll give you lots of numbers that are great for meetings with people who also don't understand what is involved in fixing code, but who probably decide what your budget will be for the next six months. They'll show you pretty charts, but can't show you the exact line in the code that threw the error, so you have no idea how to fix it. Don't bother using them.
The best logs you can have are your own. As you write the code, learn to account for errors and exceptions and capture as many of them as you can in your actual code, send correct api responses, and display proper useful messages to users. And always have an "ELSE" that SHOULD never happen and make sure even that logs to a text file somewhere or into whatever tool/service you use to view logs.
For JS stacks everyone hypes up linters, but...really no one gives a damn if you have an empty space at the end of a line or lines longer than 80 characters or if you use spaces over tabs [Tabs ftw]. In JS 99% of your errors will be "undefined" or unfinished promises. Use async/await and check for undefined/NaN/null always and you'll have nearly zero errors your linters actually help solve.
UI/UX errors are just as important as DNS errors, 301s, 404s, 500s, api endpoints failing, bad database queries, and finally, syntax errors.
When something goes to production there should be ZERO syntax errors. If there are any, it means you as the dev failed to even load the page and perform the interactions available on that page or you'd have spotted the syntax errors [regardless of language]
Make sure you have access to view actual log entries. Eg. Server access logs, and error logs for whatever language or framework or tool you're using.
On Apache/Nginx servers those logs are easy to find and easy to review to find the exact point of error in the code so you can fix it.
On automated deployments it can get harder because more things are obfuscated and you should plan ahead and make sure you know where to find the information you need.
Mainly, work with someone who knows their stuff. That will save you more time than any of the above. Just work with someone who actually knows how to debug things and learn from them. This is how you get better at it.
For every stack there's a different way to approach this. For ever language there are different places to look for errors. Each one is fairly simple and no one knows all of them, however any time you're stuck just google it and you should be able to find where errors are logged for that language or stack no problem.
I know I hit on a lot of subjects here, but there's a lot more I didn't even get to, it all just comes down to what languages and stacks you are using, which should then dictate your deployment processes tied to them and thus how you store error logs and review them.
So many subjects in your answer, I love it!
In the past I always stick to the error logs I could see on servers and tried to think of possible errors upfront and handle them on the code.
Then a lot of react side projects came in and I learned about the Error Boundary.
I have a couple of apps running smoothly. But one in particular had reports of strange behaviors and almost every case could be tracked back to data issues.
But it was hard to get proper feedback from users and I was searching for something to catch unhandled errors, be able to push my handled ones too and get not only a stack trace but also some context which user it was, what his actions roughly were before and so on.
I totally agree with you that it would be best to implement my own logging. But because this is just a side project I wanted to have something with less effort. I am even okay with sacrificing the luxury of custom handling if an existing library or service would enable me to implement it rudimentary.
I am testing bugdnag at the moment.
You can instrument your application to send the data to
Jaeger. You can useOpenTelemetry(it is still in beta) or the SDKJaegerlibrary for the client. That is one of the best ways to start, in my opinion.Jaeger is new to me, looks promising, will look into that one. Thanks for the suggestion!
I always make sure production applications are taking advantage of whatever monitoring/logging/error tools we have available. Our technical stack is on Azure Cloud so I like setting up Application Insights and Azure Monitoring /w custom Alerts to let me know (via email/text) if something critical occurs.
My common scenarios to cover in collecting monitoring data include:
To extend that final point about debugging software, there are a few places I want alerts and logging and that's in my server/architecture layer, application layer, client layer and lastly behaviour (UI "user layer").
For the Server layer, I have something that will scrape server access logs and error logs.
If you're using Cloud hosting then I set up the tools they provide to monitor those things on the infrastructure-side.
For the application layer, I have Azure's Application Insights' Node SDK running to give me application error monitoring and I pair this with Azure Alerts again to let me know about critical issues me or the team need to know about as soon as they happen. Application Insight's flexibility lets me use it both in the back-end for node debugging and error reporting but it also has a client-side JS implementation as well with a similar feel to how Google Analytics' events. There are so many tools here in this space I suggest you try a bunch and pick what you like: Sentry.io, LogRocket and Rollbar are the other favourites I recommend to check out.
For the behaviour layer, I highly recommend HEAP Analytics - their user-centric data approach and UI to setup events/actions on a site is super smooth and is a valuable tool to match user behaviour and UI path and match that with error logging reports and App Insights telemetry on user path/behaviour. I find HEAP much more helpful and insightful than simply relying on Google Analytics for front-end tracking/web metrics.
I really appreciate you took the time to answer do detailed!
You have some good points. I am used to have Azure available in the enterprise environment but for my own clients with relative small apps compared to my dayjob the stuff usually runs on DigitalOcean and I am searching for good ways to make the most out of it.
Besides reliablillity metrics an underestimated point is indeed to watch out for possible bottlenecks in the future with increasing transactions 👍
you can use sentry sentry.io
Do you have experience how sentry plays along with adblockers?
not at all
I tried Bugsnag real quick after a private recommendation and have to say it is really easy to integrate so far.