The Power of Blackfire Alerting
That’s right: power! Blackfire Alerting, bundled with Monitoring, can help you achieve Total Operational Excellence.
In a recent article on Observability Strategy, we discovered what Blackfire could do for applications, from early discoveries of performance issues to ensuring your optimizations last in the long run.
Blackfire also allows you to zoom in with a bird’s-eye view thanks to Blackfire Monitoring. With it, you can pinpoint the root cause of a bottleneck to a single function call or request in a Profile. Plus, it tells you when and where something specific happened. Handy, huh? And Blackfire Profiler lets you understand why the script behaves that way.
However, Blackfire proves its full power when used within a complete Observability Strategy. We can then know what should be prioritized and precisely where to look for places that could use some performance optimization. Yet, you may not want to spend days watching Blackfire Monitoring anxiously, waiting for something to happen.
That’s where Blackfire Alerting comes in.
Blackfire Alerting has your back 24/7
Blackfire Alerting can help teams stay on top of issues and respond to them before they escalate into major incidents. When an alert is triggered, it immediately pushes a notification saying that something is wrong with your application.
Let’s create our first alert by clicking the Alerting tab in the Environment dashboard. But first, make sure that Blackfire Monitoring is enabled in that Environment.
You’ll see some suggestions for sample rules when clicking on “Add Alert”. You could pick one or create an alert from scratch. Let’s start with the “High response time” sample rule.
This alert tracks the average response time for the Web context. You can define both warning and alert levels. An alert will escalate if the response time stays above a certain threshold for a certain period of time. Let’s toggle all options to discover all the options we have. Alert can rely on any Monitoring metrics (including Throughput, Response time, Memory, or Load) and for both the HTTP and CLI context. As a reminder, consumers and CLI commands can also be monitored.
Alert all the things!
Once you select the metric you want to track and define its context, (CLI or HTTP), you’ll have to decide how that metric should be tracked. Should this alert rely on the metric average value? Its minimum or maximum? Its cumulative sum? Its 50th or 96th percentiles? That’s up to you.
And to complete the alert configuration, you’ll need to define the threshold values and the period of time in which an event should occur. Do you want to be warned if the load remains above a certain level for at least five minutes? Or is the throughput below a critical level for half an hour? All the options are on the table!
Define performance and business-related alerts
Blackfire Alerting can—and probably should—be used with both performance and business goals in mind. You can set up alerts for whichever situation you think you’ll come across.
Performance-wise, you’ll likely want to ensure your application’s success and stay optimized in the long run. Anticipate all negative scenarios by providing yourself with a considerable headstart when a bug hits production.
You can also consider business-related objectives. Has your application activity met expectations? Have you entered a troubling low level or finally broke through that glass ceiling? Blackfire Alerting has your back in all situations.
Notification and Escalation
An alert has to be heard loud and clear to make a difference. So, let’s define the notification plan for our alert.
Notifications can be sent whenever the alert state changes, either when the alarm level is reached or when we recover from it.
Further notifications can also be defined after a period of time. Do we want to wait for a certain amount of minutes before reaching out to the team through other channels? Blakcfire Alerting is designed to fit in your larger escalation processes.
The last point to consider is what channel this notification should push to. Two channels are defined by default: emailing you and emailing all the environment members. Many more escalations channels can be defined right from the alert definition form. Notification channels are shared with Blackfire builds to reach you and your teams wherever you are (Slack, Teams, emails, for example…). You could also plug Blackfire Alerting into your existing notifications systems using webhooks.
One more thing on alerting: Blackfire keeps track of past alerts. You can then focus on a specific one and display the data that has led to this alert. If you want to see for yourself, Blackfire demo environment contains a couple of alerts you can explore to discover more about this key feature.
Now, if you haven’t already started, go ahead and create your first alert. Head to one of your environments with Blackfire Monitoring enabled and give yourself the headstart and headspace you deserve.
Then, reach out to us on Twitter or Reddit to share your experience.
And, as always, Happy Performance Optimization!