Let’s say you are shopping online. Then you proceed to checkout your cart. What you see next is something like HTTP 500 error.
No specific error or stack trace related to the application source code is displayed to the visitor. It is a secure solution as it hides the ugly source code of some buggy application.
I will describe how to handle errors and exceptions raised by your application.
Errors come from various places but every single error must be pushed to a single place to ease and centralise debug sessions for developers.
Logs of Pikacloud web applications, asynchronous workers, cron jobs, and system logs are pushed to Elasticsearch. Kibana is perfect for data digging and log visualisation. We also query Elasticsearch with Grafana to have a better graphing solution for advanced system analysis enriched with logs metrics.
But who watches logs on a regular basis ? Or even read cron errors send to a mail box ? Pikacloud errors strategy is to push code exceptions to a specific application called Sentry dedicated to errors management. You can tag exceptions sent to Sentry with an application release tag. It help us for tracking, alerting and bug fixing.
With errors and stack traces stored in Sentry when generated by applications, you can also create a user feedback form on your 500 error page. Users will be able to directly contact support describing their issue in “customer words”. Frontiers between developers, ops and support become thin!
This article is the first of a series of how Pikacloud works with various tools and technologies. Next article may talk about deployment strategies used at Pikacloud.