Reducing Time to Know with F5 Beacon
In most fictional stories, whether told through text or on the screen, there is a point at which plotline resolution is achieved. The heroine defeats her nemesis. The kingdom is saved. The planet is safe. The meteor is destroyed. The entire story, which is usually the bulk of the tale, has been building toward this single seminal moment in time after which we enjoy a breath of relief and celebrate.
Joseph Campbell describes this in his book, 'The Hero with a Thousand Faces.' He posits, through extensive research, that nearly every fable, tale, and story across every human culture shares a common set of elements.
One of those elements is often a false resolution. This confrontation tends to end with apparent success, only to be followed by the discovery that the nemesis has survived, or the approaching meteor is back on a path to destroy the world.
These same plotlines can be followed in IT organizations every day. The same time limitations exist when it comes to troubleshooting a performance or availability incident with a customer-facing application. The clock is ticking, and too often just when IT thinks the issue is resolved, they find out it's not and have to redouble their efforts while the customer grows more and more frustrated.
There is a plethora of "mean time to X" points on the troubleshooting plotline. From detection to fix to validation. The most important of these is probably the mean time to know (MTTK); that is, the point at which you know for certain what the root cause is to then fix and validate in order to repair the issue. MTTK is the metric we need to be working to reduce. All the others are intermediate resolution points, in the sense that we feel a tiny relief at having conquered a problem but then are thrown back into the conflict as we discover the application nemesis has managed to evade our efforts.
To reduce the mean time to know, it's important not just to have telemetry, but to have data that moves the troubleshooting process along. Knowing that the application is slow is not very helpful. Knowing that the degradation is caused by excessive latency is more helpful, but not enough. Being aware that the excessive latency originates from the app server itself is the information you need to move more quickly toward achieving a real resolution—reaching “mean time to know” that you have saved the day.
To do that, you need metrics. But more than just metrics, you need to be able to understand the data in the context of the entire ecosystem of application services, infrastructure, and systems that make it possible to deliver, scale, and secure an application. That means more than a dashboard with charts. It means a visualization of the entire ecosystem—the architectural app topology map—that rapidly identifies exactly which component in the app delivery path is causing the problem.
This is the kind of context F5 Beacon offers. It is not just another data visualization dashboard. F5 Beacon provides a baseline for understanding performance and availability telemetry data in the context of an entire application experience, from end-to-end. That kind of contextual visualization with the right set of analytics makes the difference between the disappointment of realizing you've reached a intermediate resolution and fast forwarding you to the real resolution.
You can experience F5 Beacon yourself, using our interactive scenario simulations (wide screen recommended). In addition, try our 45-day free trial completely free with no functional limitations, and see how F5 Beacon provides you with the app visibility you are lacking and the difference contextual visualizations can make. You’ll not only detect issues as early as possible but also reduce your mean time to know by pinpointing where the real issues are located.