Access video
In this demo, we're going to discuss LogReduce which finds the meaningful patterns in your data and reduces the noise, which so overwhelms most Log Analytics tools. But it condenses that data without excluding any important details about your machine data. So let's get started.
I've just had an application failure and using Sumo Logic, I'm looking at five minutes on either side of that failure to see if there's any things that pop out at me that might have caused the failure. As you can see, it's a huge number of logs; it's 133 pages. This is just an overwhelming number to look through and this is really where the secret sauce of Sumo Logic comes in. Using LogReduce and the summarize operator, I can look for the meaningful patterns in those logs and be able to get down to the root cause because unlike with keyword searches, I'm not ignoring any of the data.
Logs are extremely repetitious. Starting right off, we can see that we've got a stack trace and that stack trace has gone over 900 times. Now, this is the kind of noise that I want to know about, but ignore because I already know what it means. I'm looking for that needle in the haystack.
Here, we can see some network access through our firewall. Interesting, but probably not part of the problem. Here, we use asterisks. That indicates the part of this log statement that changes. Whereas the rest can be used to group them together.
Below that, we can see a get statement, so it's a different type of log. Now we can adjust those patterns to better group our log statements if you'd like by clicking on the pencil. In that way, we can adjust the pattern to better represent what log statement should be grouped together. I can also adjust the relevance of any grouping by using the thumbs up or thumbs down icon.
We can continue to scroll the events; I see some Windows events here. Now here is something that might be of interest to us. This log line indicates that a user on the PIX firewall executed a pretty draconian statement that denied access over a pretty wide range of IPs. More likely than not, this is what is the root of our problem.
How would I have looked for this with keyword-based searching? I might have looked for anything having to do with a database; perhaps an IP, a host name, a port number. None of those options would have turned up this log line. Why? Because there's nothing to associate it with the database directly. This really lies at the root of the weakness of keyword searches as compared to LogReduce. Typical keyword-based searching would constrain the data and eliminate what didn't fit. LogReduce is able to condense the data and help me find those things that I didn't even know I was looking for and in that way, speed up the root cause analysis.
Let's go over what we showed you today. We showed you how we could find those meaningful patterns in the data by reducing the noise of all of those errors that weren't important. It helped us find that single PIX firewall problem that was at the root of our application issue.
