President and Founder at STILLWATER SUPERCOMPUTING INC
Real User
Sep 17, 2020
It is our sole cross-correlation logging backend for some IBM services. We have a combination of LogDNA and Sysdig for root cause analysis and customer events. LogDNA is related to the operations of the service. Sysdig is somewhat nice in the sense that it also gives us some backdrop when there are any issues with respect to resources and other types of metrics-based constraints.
President and Founder at STILLWATER SUPERCOMPUTING INC
Real User
Mar 9, 2020
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.
Find out what your peers are saying about Mezmo, Datadog, Google and others in Application Performance Monitoring (APM) and Observability. Updated: May 2026.
Application Performance Monitoring and Observability are critical solutions enabling businesses to monitor and optimize application performance. They provide actionable insights to ensure robust, seamless user experiences and drive operational efficiency. As digital landscapes grow complex, Application Performance Monitoring and Observability tools become essential for understanding system behaviors and preempting disruptions. They offer a comprehensive view by correlating metrics, traces,...
It is our sole cross-correlation logging backend for some IBM services. We have a combination of LogDNA and Sysdig for root cause analysis and customer events. LogDNA is related to the operations of the service. Sysdig is somewhat nice in the sense that it also gives us some backdrop when there are any issues with respect to resources and other types of metrics-based constraints.
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.