In terms of primary use case, LogDNA is our root cause analysis for on-call channels and we're now also using it for load testing. We have a silverized service in production. When an issue hits the on-call channel, meaning a customer receives some type of service issue, we receive an alert and use LogDNA to RCA why that particular alert fired. We use it to trace customer requests and customer interaction, as well as studying our own service to make sure that we don't trip up in the transactions or on the services we depend on.
The product is our only SIEM. We've become more skilled at using it - it's a different way of finding events and collecting the evidence to explain a certain behavior. Over the past six months we've certainly learned to use it as a team. Some types of flows you can automate and we use that particularly for on-call tasks. I've seen a lot of progress but it's mostly an increase in team skills. All our team members use a LogDNA, not just the support team or SRE team. Everyone has something to contribute.
We deal with large companies that have the resources and also complexities. The product we service is actually a key management product. If something doesn't work, you have very big customers who become anxious. We collaborate closely with LogDNA.
Our team is about 100 people. We have site reliability engineers that use the tool for deep RCAs. We have four levels of support and the SREs do capacity testing, latency, performance testing, any type of really confusing or complicated RCAs that may pertain to account compatibility or networking hiccups. We also have an on-call group of about a dozen people who deal with customer issues, checking nothing is seriously wrong with the service. Finally, we have the developers who deal with a secondary transaction debug tooling. If a new feature is rolled out, they can use the tool to track the transaction going through in the system.