Lightrun Alerts with Slack¶
The following are suggested use cases for Lightrun alerts.
These use cases are not exahustive by any means. Instead, they should serve as a great start when investigating whether Lightrun alerts are right for you. If you have more ideas that we missed here feel free open a PR!
Edge cases and rarely-occuring bugs¶
In many reasonably-large applications there are specific, hidden corners where things can fail in extraordinary ways. There are calls to external APIs that are unreliable, underlying infrastructure problems that your tests do not account for and various delays and timeouts resulting from running your application in the wild and not on your local machine or stagning environments.
By placing conditional Lightrun Logs and Snapshots in strategic locations in the code, then connecting the Lightrun Slack integration to a dedicated channel, you can "catch" these nasty bugs in real-time and observe the situation with full contextual information - including the structure and contents of all the objects across all the relevant frames.
Traditionally, when one sets an alert on some sort of metric, it's common to define a threshold - an upper limit above which the alert is triggered. In most cases this is enough - you want to know when something bad happens and fix it there and then.
However, the next question is line is usually not that easy to answer. In most cases there isn't a way to code business logic into the alerts, which means the only way to get a clear picture of what's happening inside the application is to look at the application logs. If the logs are not telling the full story when the alert is triggered, developers will be forced to deploy hotfixes with more logs in order to better understand what's going on inside the system.
With Lightun, you can define very granular and informative alerts that contain information about the global state of the application, the value of different variables and while using a real-life programming language (the one you wrote your code in!) to define the exact pieces of data you want to extract from the application. This is a familiar and comfortable way for developers to conduct investigations, resulting in a more "streamlined" approach to incident resolution.
Following long-running jobs¶
Some code paths take a really long time to complete - batch jobs, data workers and any type of intensive computation that starves the machine of resources while you wait for its completion might be nerve-racking to watch from the side (especially when you're banking on it to finish successfully to go to lunch).
In some cases it could be useful to "track" the code path as the application chugs along. With Lightrun, you can place logs in various places in the code and get alerted when those places are reached - allowing you to "follow" the code path without adding new logs or configuring alerts inside your APM.