In the second post of this series, I have listed the high level use cases of Glassbeam for Glassbeam across our internal teams: Technical Support, Sales, Engineering, and Product Management. In the next 4 posts, I will dive deep into the use cases for each of the above teams and talk about the value Glassbeam for Glassbeam as a data-driven decision making solution, brings to each team. You can read the other posts in this series Part 1 and Part 2.
Support is a high pressure job in any organization. When the application infrastructure one monitors and supports is functioning without issues, it is a pretty place to be in, but when things go wrong, hell breaks loose. The impact is higher on a hosted platform, as instead of one customer, all customers are impacted.
The ideal solution for our, or for that matter any Technical Support team is to proactively identify 100% of the issues upfront. While that is not practical, the next best solution is to:
It is just not about pre-emptively identifying known issues but doing it in real time. There are many use cases our Technical Support team uses Glassbeam Analytics for; here, I will explain some key use case scenarios.
Rules are created for real time event data, frequently collected performance data, or for periodic configuration/state information. Our Technical Support teams know specific patterns of events or changes in the state of our applications that have historically erupted in the past and broken the system.
To proactively monitor those known issues, our support teams automate the detection of such problems using our Rules engine. These known issues could be indicators of an impending problem. Glassbeam Analytics alerts our support teams, to respond to the issue at hand immediately. Here are some examples of the rules our Technical Support team monitors and for which they receive alerts from Glassbeam Analytics.
Our support teams can also look at the summary report for each host. We have created multiple views on the configuration details and performance metrics that our Support team uses to quickly get to the root cause of the problem.
Glassbeam Analytics provides a custom reporting tool that is used to:
Here is one example of such a report:
In a distributed computing environment with multiple services working in parallel, troubleshooting any problem in the platform pipeline is complex as multiple things are happening in parallel. Our Support team uses the Glassbeam Explorer app, the ‘search and interact’ solution to not only search for the issues that they are interested in but to also see how the other platform services are performing when an issue occurs. Our Support team uses the ‘display all surrounding events’ feature in Explorer for a deeper analysis on a specific event. Here’s an example of searching for an event and looking at other events that happened at the same time.
We first search for the string and filter to the source using the facet filters on the left.
Once we find the event of interest, we click the event to see the events surrounding this event from all the other log sources.
Glassbeam supports both streaming data and data sent in batches. We can handle simple structured log formats such as Syslog, JSON, XML, CSV, and so on to complex multi-structured logs such as name-value pairs of any sort, tabular data, and a lot more.
In my next post, I will talk about how our Engineering team in Glassbeam, uses Glassbeam for Glassbeam for their use cases.
Refer to other posts in this Glassbeam for Glassbeam series: