Blog › Use Cases
02.23.2014 | Posted by Bruno Kurtic, Founding Vice President of Product and Strategy
Security is a tricky thing and it means different things to different people. It is truly in the eye of the beholder. There is the checkbox kind, there is the “real” kind, there is the checkbox kind that holds up, and there is the “real” kind that is circumvented, and so on. Don’t kid yourself: the “absolute” kind does not exist.
I want to talk about security solutions based on log data. This is the kind of security that kicks in after the perimeter security (firewalls), intrusion detection (IDS/IPS), vulnerability scanners, and dozens of other security technologies have done their thing. It ties all of these technologies together, correlates their events, reduces false positives and enables forensic investigation. Sometimes this technology is called Log Management and/or Security Information and Event Management (SIEM). I used to build these technologies years ago, but it seems like decades ago.
A typical SIEM product is a hunking appliance, sharp edges, screaming colors – the kind of design that instills confidence and says “Don’t come close, I WILL SHRED YOU! GRRRRRRRRRR”.
Ahhhh, SIEM, makes you feel safe doesn’t it. It should not. I proclaim this at the risk at being yet another one of those guys who wants to rag on SIEM, but I built one, and beat many, so I feel I’ve got some ragging rights. So, what’s wrong with SIEM? Where does it fall apart?
SIEM does not scale
It is hard enough to capture a terabyte of daily logs (40,000 Events Per Second, 3 Billion Events per Day) and store them. It is couple of orders of magnitude harder to run correlation in real time and alert when something bad happens. SIEM tools are extraordinarily difficult to run at scales above 100GB of data per day. This is because they are designed to scale by adding more CPU, memory, and fast spindles to the same box. The exponential growth of data over the two decades when those SIEM tools were designed has outpaced the ability to add CPU, memory, and fast spindles into the box.
Result: Data growth outpaces capacity → Data dropped from collection → Significant data dropped from correlation → Gap in analysis → Serious gap in security
SIEM normalization can’t keep pace
SIEM tools depend on normalization (shoehorning) of all data into one common schema so that you can write queries across all events. That worked fifteen years ago when sources were few. These days sources and infrastructure types are expanding like never before. One enterprise might have multiple vendors and versions of network gear, many versions of operating systems, open source technologies, workloads running in infrastructure as a service (IaaS), and many custom written applications. Writing normalizers to keep pace with changing log formats is not possible.
Result: Too many data types and versions → Falling behind on adding new sources → Reduced source support → Gaps in analysis → Serious gaps in security
SIEM is rule-only based
This is a tough one. Rules are useful, even required, but not sufficient. Rules only catch the thing you express in them, the things you know to look for. To be secure, you must be ahead of new threats. A million monkeys writing rules in real-time: not possible.
Result: Your rules are stale → You hire a million monkeys → Monkeys eat all your bananas → You analyze only a subset of relevant events → Serious gap in security
SIEM is too complex
It is way too hard to run these things. I’ve had too many meetings and discussions with my former customers on how to keep the damned things running and too few meetings on how to get value out of the fancy features we provided. In reality most customers get to use the 20% of features because the rest of the stuff is not reachable. It is like putting your best tools on the shelf just out of reach. You can see them, you could do oh so much with them, but you can’t really use them because they are out of reach.
Result: You spend a lot of money → Your team spends a lot of time running SIEM → They don’t succeed on leveraging the cool capabilities → Value is low → Gaps in analysis → Serious gaps in security
So, what is an honest, forward-looking security professional who does not want to duct tape a solution to do? What you need is what we just started: Sumo Logic Enterprise Security Analytics. No, it is not absolute security, it is not checkbox security, but it is a more real security because it:
Processes terabytes of your data per day in real time. Evaluates rules regardless of data volume and does not restrict what you collect or analyze. Furthermore, no SIEM style normalization, just add data, a pinch of savvy, a tablespoon of massively parallel compute, and voila.
Result: you add all relevant data → you analyze it all → you get better security
It is SaaS, there are no appliances, there are no servers, there is no storage, there is just a browser connected to an elastic cloud.
Result: you don’t have to spend time on running it → you spend time on using it → you get more value → better analysis → better security
Rules, check. What about that other unknown stuff? Answer: machine that learns from data. It detects patterns without human input. It then figures out baselines and normal behavior across sources. In real-time it compares new data to the baseline and notifies you when things are sideways. Even if “things” are things you’ve NEVER even thought about and NOBODY in the universe has EVER written a single rule to detect. Sumo Logic detects those too.
Result: Skynet … nah, benevolent overlord, nah, not yet anyway. New stuff happens → machines go to work → machines notify you → you provide feedback → machines learn and get smarter → bad things are detected → better security
Read more: Sumo Logic Enterprise Security Analytics
11.25.2013 | Posted by Vance Loiselle, CEO
The annual craze of getting up at 4am to either stand in line or shop online for the “best” holiday deals is upon us. I know first-hand, because my daughter and I have participated in this ritual for the last four years (I know – what can I say – I grew up in Maine). While we are at the stores fighting for product, many Americans will be either watching football, or surfing the web from the comfort of their couch looking for that too-good-to-be-true bargain. And with data indicating a 50% jump in Black Friday and Cyber Monday deals this year, it’s incumbent on companies to ensure that user experiences are positive. As a result, the leading companies are realizing the need to obtain visibility end-to-end across their applications and infrastructure, from the origin to the edge. Insights from machine data (click-stream in the form of log data), generated from these environments, helps retailers of all stripes maximize these two critical days and the longer-term holiday shopping season.
What are the critical user and application issues that CIOs should be thinking about in the context of these incredibly important shopping days?
User Behavior Insights. From an e-commerce perspective, companies can use log data to obtain detailed insights into how their customers are interacting with the application, what pages they visit, how long they stay, and the latency of specific transactions. This helps companies, for example, correlate user behavior with the effectiveness of specific promotional strategies (coupons, etc) that allow them to rapidly make adjustments before the Holiday season ends.
The Elasticity of The Cloud. If you’re going to have a problem, better it be one of “too much” rather than “too little”. Too frequently, we hear of retail web sites going down during this critical time. Why? The inability to handle peak demand – because often they don’t know what that demand will be. Companies need to understand how to provision for the surge in customer interest on these prime shopping days that in turn deliver an exponential increase in the volume of log data. The ability to provide the same level of performance at 2, 3 or even 10x usual volumes in a *cost-effective* fashion is a problem few companies have truly solved. The ability of cloud-based architectures to easily load-balance and provision for customer surges at any time is critical to maintaining that ideal shopping experience while still delivering the operational insights needed to support customer SLAs.
Machine Learning for Machine Data. It’s difficult enough for companies to identify the root cause of an issue that they know something about. Far more challenging for companies is getting insights into application issues that they know nothing about. However, modern machine learning techniques provide enterprises with a way to proactively uncover the symptoms, all buried within the logs, that lead to these issues. Moreover, machine learning eliminates the traditional requirement of users writing rules to identify anomalies, which by definition limit the ability to understand *all* the data. We also believe that the best analytics combine machine learning with human knowledge about the data sets – what we call Machine Data Intelligence – and that helps companies quickly and proactively root out operational issues that limit revenue generation opportunities.
Security and Compliance Analytics. With credit cards streaming across the internet in waves on this day, it’s imperative that you’ve already set up the necessary environment to both secure your site from fraudulent behavior and ensure your brand and reputation remain intact. As I mentioned in a previous post, the notion of a perimeter has long since vanished which means companies need to understand that user interactions might occur across a variety of devices on a global basis. The ability to proactively identify what is happening in real-time across your applications and the infrastructure on which they run is critical to your underlying security posture. All this made possible by your logs and the insights they contain.
Have a memorable shopping season and join me on twitter – @vanceloiselle – to continue the conversation.
11.19.2013 | Posted by Vance Loiselle, CEO
There is little debate that the “Obamacare” rollout has been choppy at best. Regardless of which side of the political debate you fall, many of us in technology, CIOs and software executives alike, can learn from this highly publicized initiative as we approach the November 30th deadline. Development of new applications, especially web applications, is no longer just about the myopic focus on Design, Develop, Test, and Rollout. The successful development and deployment of these applications must have a holistic, information-driven approach, which includes the following four key processes:
- Application Quality Analytics – the constant tracking of the errors, exceptions, and problems that are occurring in each new release of the code.
- Application Performance Analytics – the real-time measurement of the performance of the application as the users are experiencing it.
- Security Analytics – the real-time information required to analyze and conduct forensics on the security of the entire application and the infrastructure on which it runs.
- User Analytics – real-time insights on which users are in the application, what pages they are viewing, and the success they’ve had in conducting transactions in the application.
Application Quality Analytics – Is it really necessary that in the year 2013, that development of applications still need to be 4 parts art and 1 part science? I’m sure that the Secretary of Health and Human Services, Kathleen Sibelius, wished it was more science when she testified in front of Congress about why the site was not ready. She had no real-time information or metrics at her disposal about the number of defects that were being fixed each day, the number of errors being encountered by users, the severity of the errors, and the pace at which these errors and defects were being resolved.
These metrics are sitting there in the log files (data exhaust from all applications and software components to track what the software is doing), and are largely untapped by most development organizations. Moreover, this data could be shared between multiple teams to pinpoint the root cause of problems between the application itself and the network and infrastructure on which it is running. It was so frustrating to see CGI (the contractor hired to build the application) and Verizon (the contractor hired to host the application in their “cloud”) passing the buck between each other in front of Congress.
Application Performance Management – Much has been made about the performance of Healthcare.gov. The HHS secretary even had gall to say that the site had not crashed, it was just “performing slowly”, while in the congressional hearing there was a live image on the screen informing users that the site was down. The site was down AND performing slowly because the site’s developers are stuck in a previous generation of thinking – that you can measure the site performance without taking into account user analytics. It’s not good enough to measure application performance by sampling the transaction response times periodically. Testers and managers need access to real-time information about each user, the session they were running, the performance at each step, and the outcomes (e.g. new plan sign-up created or failed, 5 insurance plans compared, pricing returned from 2 out of 3 carriers, etc.) along the way. Most monitoring tools look at just the application or just the network and infrastructure it runs on, and have little to no visibility about the outcomes the user is experiencing. Guess what? Most, if not all, of this information is sitting in the logs waiting to be harnessed.
Security Analytics – I appreciated when Secretary Sibelius was asked about what steps had been taken to ensure the privacy and security of the data that fellow Americans had submitted on Healthcare.gov. The reality is that most IT organizations have very bifurcated organizations to address security and application development. The old school view is that you put a web application firewall in place and you close down the ports, and your perimeter is safe. The reality today is that there is no perimeter. People have mobile phones and tablets and use third-party services to store their documents. Healthcare.gov itself is dependent on 3rd parties (insurance carriers) to provide and receive private information.
The most effective way today to ensure some level of security is to have a real-time security analytics and forensics solution in place. These solutions can scan every element of user and system activity, from – you guessed it – the log data, and determine everything from invalid logins and potential breaches to unauthorized changes to firewall rules and user permissions.
User Analytics – Ok, I get it, the Obama administration did not want to share information about how many people had signed up on Healthcare.gov for weeks. The argument was made that the accuracy of the data could not be trusted. Either it was a political maneuver or incompetence, but either reason is sad in the year 2013. And why do the White House and HHS have the right to keep this information a secret? The American taxpayers are paying the hefty sum of $200M+ to get this application up and running. Shouldn’t we know, in real-time, the traction and success of the Affordable Care Act? It should be posted on the home page of the web site. I guarantee the information about every enrollee, every signup – successful or failed – every county from which they logged in, every plan that was browsed, every price that was displayed, every carrier that’s providing quotes was AVAILABLE IN THE LOG DATA.
There has been a lot of coverage about President Kennedy recently and we are reminded that he challenged our government to put people on the moon in the 1960s, and they did – with a very limited set of computer and software tools at their disposal. I would ask the CIOs and software types out there, let’s learn from the Healthcare.gov rollout, and embrace a modern, information-driven approach to developing and rolling out applications. And President Obama, if you need some help with this, give me a shout – I’m ready to serve.
11.13.2013 | Posted by Bruno Kurtic, Founding Vice President of Product and Strategy
Cloud is opaque
One of the biggest adoption barriers of SaaS, PaaS, and IaaS is the opaqueness and lack of visibility into changes and activities that affect cloud infrastructure. While running an on-premise infrastructure, you have the ability to audit activity ; for example, you can easily tell who is starting and stopping VMs in virtualization clusters, see who is creating and deleting users, and watch who is making firewall configuration changes. This lack of visibility has been one of the main roadblocks to adoption, even though the benefits have been compelling enough for many enterprises to adopt the Cloud.
This information is critical to securing infrastructure, applications, and data. It’s critical to proving and maintaining compliance, critical to understanding utilization and cost, and finally, it’s critical for maintaining excellence in operations.
Not all Clouds are opaque any longer
Today, the world’s biggest cloud provider, Amazon Web Services (AWS), announced a new product that, in combination with Sumo Logic, changes the game for cloud infrastructure audit visibility. AWS CloudTrail is the raw log data feed that will tell you exactly who is doing what, on which sets of infrastructure, at what time, from which IP addresses, and more. Sumo Logic is integrated with AWS CloudTrail and collects this audit data in real-time and enables SOC and NOC style visibility and analytics.
Network acl changes.
Creation and deletion of network interfaces.
Authorized Ingress/Egress across network segments and ports.
Changes to privileges, passwords and user profiles.
Deletion and creation of security groups.
Starting and terminating instances.
And much more.
Sumo Logic Application for AWS CloudTrail
Cloud data comes to life with our Sumo Logic Application for AWS CloudTrail, helping our customers across security and compliance, operational visibility, and cost containment. Sumo Logic Application for AWS CloudTrail delivers:
Seamless integration with AWS CloudTrail data feed.
SOC-style, real-time Dashboards in order to monitor access and activity.
Forensic analysis to understand the “who, what, when, where, and how” of events and logs.
Alerts when important activities and events occur.
Correlation of AWS CloudTrail data with other security data sets, such as intrusion detection system data, operating system events, application data, and more.
This integration delivers improved security posture and better compliance with internal and external regulations that protect your brand. It also improves operational analytics that can improve SLAs and customer satisfaction. Finally, it provides deep visibility into the utilization of AWS resources that can help improve efficiency and reduce cost.
The integration is simple: AWS CloudTrail deposits data in near-real time into your S3 account, and Sumo Logic collects it as soon as it is deposited using an S3 Source. Sumo Logic also provides a set of pre-built Dashboards and searches to analyze the CloudTrail Data.
To learn more, click here for more details: http://www.sumologic.com/applications/aws-cloudtrail/ and read the documentation: https://support.
10.09.2013 | Posted by Bruno Kurtic, Founding Vice President of Product and Strategy
I’m very pleased to announce our strategic alliance with Akamai. Our integrated solution delivers a unified view of application availability, performance, security, and business analytics based on application log data. Customers who rely on Akamai’s globally distributed infrastructure now can get the real-time feed of all logs generated by Akamai’s infrastructure into their Sumo Logic account in order to integrate and cross-analyze them with their internally generated application data sets!
What problems does the integrated solution solve?
To date, there have been two machine data sets generated by applications that leverage Akamai:
1. Application logs at the origin data centers, which application owners can usually access.
2. Logs generated by Akamai as an application is distributed globally. Application owners typically have zero or limited access to these logs.
Both of these data sets provide important metrics and insights for delivering highly-available, secure applications that also provide detailed view of business results. Until today there was no way to get these data sets into a single tool for real-time analysis, causing the following issues:
- No single view of performance. While origin performance could be monitored, but that provides little confidence that the app is performant for end users.
- Difficult to understand user interaction. Without data on how real users interact with an application, it was difficult to gauge how users interacted with the app, what content was served, and ultimately how the app performed for those users (and if performance had any impact on conversions).
- Issues impacting customer experience remained hidden. The root cause of end-user issues caused at the origin remained hidden, impacting customer experience for long periods of time.
- Web App Firewall (WAF) security information not readily available. Security teams were not able to detect and respond to attacks in real-time and take defensive actions to minimize exposure.
Akamai Cloud Monitor and Sumo Logic provide an integrated approach to solving these problems. Sumo Logic has developed an application specifically crafted for customers to extract insights from their Akamai data, which is sent to Sumo Logic in real time. The solution has been deployed by joint customers (at terabyte scale) to address the following use cases:
Real-time analytics about user behavior. Combine Akamai real-user monitoring data and internal data sets to gain granular insights into user behavior. For example, learn how users behave across different device types, geographies, or even how Akamai quality of service impacts user behavior and business results.
Security information management and forensics. Security incidents and attacks on an application can be investigated by deep-diving into sessions, IP addresses, and individual URLs that attackers are attempting to exploit and breach.
Application performance management from edge to origin. Quickly determine if an application’s performance issue is caused by your origin or by Akamai’s infrastructure, and which regions, user agents, or devices are impacted.
Application release and quality management. Receive an alert as soon as Akamai detects that one or more origins have an elevated number of 4xx or 5xx errors that may be caused by new code push, configuration change, or another issue within your origin application infrastructure.
Impact of quality of service and operational excellence. Correlate how quality of service impacts conversions or other business metrics to optimize performance and drive better results
I could go on, but I’m sure you have plenty of ideas of your own.
Join us for a free trial here – as always, there is nothing to install, nothing to manage, nothing to run – we do it all for you. You can also read our announcement here or read more about the Sumo Logic application for Akamai here. Take a look at the Akamai press release here.
09.10.2013 | Posted by Bruno Kurtic, Founding Vice President of Product and Strategy
What is “anomaly detection”?
Here is how the peeps on the interweb and wikipedia define it: Anomaly detection (also known as outlier detection) is the search for events which do not conform to an expected pattern. The detected patterns are called anomalies and often translate to critical and actionable insights that, depending on the application domain, are referred to as outliers, changes, deviations, surprises, intrusions, etc.
The domain: Machine Data
Machine data (most frequently referred to as log data) is generated by applications, servers , infrastructure, mobile devices, web servers, and more. It is the data generated by machines in order to communicate to humans or other machines exactly what they are doing (e.g. activity), what the status of that activity is (e.g. errors, security issues, performance), and results of their activity (e.g. business metrics).
The problem of unknown unknowns
Most problems with analyzing machine data orbit around the fact that existing operational analytics technologies enable users to find only those things they know to look for. I repeat, only things they KNOW they need to look for. Nothing in these technologies helps users proactively discover events they don’t anticipate getting, events that have not occurred before, events that may have occurred before but are not understood, or complex events that are not easy or even possible to encode into queries and searches.
Our infrastructure and applications are desperately, and constantly, trying to tell us what’s going on through the massive real-time stream of data they relentlessly throw our way. And instead of listening, we ask a limited set of questions from some playbook. This is as effective as a patient seeking advice about massive chest pain from a doctor who, instead of listening, runs through a checklist containing skin rash, fever, and runny nose, and then sends the patient home with a clean bill of health.
This is not a good place to be; these previously unknown events hurt us by repeatedly causing downtime, performance degradations, poor user experience, security breaches, compliance violations, and more. Existing monitoring tools would be sufficient if we lived in static, three system environments where we can enumerate all possible failure conditions and attack vectors. But we don’t.
We operate in environments where we have thousands of sources across servers, networks, and applications and the amount of data they generate is growing exponentially. They come from a variety of vendors, run a variety of versions, are geographically distributed, and on top of that, they are constantly updated, upgraded, and replaced. How can we then rely on hard-coded rules and queries and known condition tools to ensure our applications and infrastructure is healthy and secure? We can’t – it is a fairy tale.
We believe that three major things are required in order to solve the problem of unknown unknowns at a multi-terabyte scale:
Cloud: enables an elastic compute at the massive scale needed to analyze this scale of data in real-time across all vectors
Big Data technologies: enable a holistic approach to analyzing all data without being bound to schemas, volumes, or batch analytics
Machine learning engine: advanced algorithms that analyze and learn from data as well as humans in order to get smarter over time
Sumo Logic Real-Time Anomaly Detection
Today we have announced Beta access to our Anomaly Detection engine, an engine that uses thousands of machines in the cloud and continuously and in real-time analyzes ALL of your data to proactively detect important changes and events in your infrastructure. It does this without requiring users to configure or tune the engine, to write queries or rules, to set thresholds, or to write and apply data parsers. As it detects changes and events, it bubbles them up to the users for investigation, to add knowledge, classify events, and to apply relevance and severity. It is in fact this combination of a powerful machine learning algorithm and human expert knowledge that is the real power of our Anomaly Detection engine.
So, in essence, Sumo Logic Anomaly Detection continuously turns unknown events into known events. And that’s what we want: to make events known, because we know how to handle and what to do with known events. We can alert on them, we can create playbooks and remediation steps, we can prevent them, we can anticipate their impact, and, at least in some cases, we can make them someone else’s problem.
Sumo Logic Anomaly Detection has been more than three years in the making. During that time, it has had the energy of the whole company and our backers behind it. Sumo Logic was founded with the belief that this capability is transformational in the face of exponential data growth and infrastructure sprawl. We developed architecture and adopted a business model that enable us to implement an analytics engine that can solve the most complex problems of the Big Data decade.
04.23.2013 | Posted by CloudPassage: Cloud Security
The below is a guest post from CloudPassage.
Automating your server security is about more than just one great tool – it’s also about linking together multiple tools to empower you with the information you need to make decisions. For customers of CloudPassage and Sumo Logic, linking those tools to secure cloud servers is as easy as it is powerful.
The CloudPassage Halo Event Connector enables you to view security event logs from CloudPassage Halo in your Sumo Logic dashboard, including alerts from your configuration, file integrity, and software vulnerability scans. Through this connector, Halo delivers unprecedented visibility of your cloud servers via your log management console. You can track server events such as your server rebooting, shutting down, changing IP addresses, and much more.
The purpose of the Halo Event Connector is to retrieve event data from a CloudPassage Halo account and import it into Sumo Logic for indexing or processing. It is designed to execute repeatedly, keeping the Sumo Collector up-to-date with Halo events as time passes and new events occur.
The Halo Event Connector is free to use, and will work with any Halo subscription. To get started integrating Halo events into Sumo Logic, make sure you have set up accounts for CloudPassage Halo and Sumo Logic.
Then, generate an API key in your CloudPassage Halo portal. Once you have an API key, follow the steps provided in the Halo – Sumo Logic documentation, using the scripts provided on Github. The documentation walks you through the process of testing the Halo Event Connector script.
Once you have tested the script, you will then add the output as a “Source” by selecting “Script” in Sumo Logic (see below).
When you have finished adding the new data source that integrates the Halo Event Connector with Sumo Logic (as detailed in the .pdf documentation), you will be taken back to the “Collectors” tab where the newly added Script source will be listed.
Once the Connector runs successfully and is importing event data into Sumo Logic, you will see Halo events such as the following appear in your Sumo Logic searches:
Try it out today – we are eager to hear your feedback! We hope that integrating these two tools makes your server security automation even more powerful.
03.07.2013 | Posted by Praveen Rangnath, Former Head of Product Marketing
Show Me the Money!!! Show Me the VPN Logs!!!
Move over Tesla automobile logs, it’s time for Yahoo VPN logs to get their moment in the sun!
Just as soon as log data dropped out of the headlines they came right back, as Yahoo CEO Marissa Mayer announced a ban on telecommuting – with the decision reportedly driven by analysis of the company’s VPN log data.
From the VPN data, it’s said that the Yahoo CEO determined too many remote workers were not pulling their weight, as evidenced by their lack of connecting to the VPN and accessing Yahoo’s IT systems. Certainly, VPN logs don’t tell the entire story around telecommuter productivity, but they are an important data point, and the information contained in those logs certainly was compelling for Ms. Mayer.
There is of course a bigger picture to this, and it starts with the fact that this is not the first time VPN logs are in the news. (Not even the first time this year!). See this blog post from the Verizon RISK team, where they helped their client identify a developer who took global wage arbitrage to an extreme; he collected his six-figure paycheck in the USA and then outsourced his own job to a Chinese consulting firm, paying that firm a fraction of his salary to do his job for him!
How did he do this? Simple: He FedEx’d his RSA token to China. How did he get caught? Simple: They found him sitting in his office while the VPN logs showed him in China.
All thanks to the logs.
At the highest level, what do the Tesla, Yahoo, and wage arbitrage stories tell us? Simply put, log data is immensely valuable, it’s increasingly becoming front and center, and it’s not going away anytime soon.
We at Sumo Logic couldn’t be happier, as this is further public recognition of the value hidden in machine data (the biggest component of which is log data). We’ve said it many times, log data holds the absolute and authoritative record of all the events that occurred. That’s true for automobile logs, server logs, application logs, device logs, and yes Mr. Developer who outsourced his job to China… VPN logs.
03.06.2013 | Posted by Sanjay Sarathy, CMO
Last week we announced how Atchik uses Sumo Logic and our ability to easily analyze machine data to reshape its customer service function. In fact, there are a variety of ways in which customer service organizations can become best friends with your log management infrastructure to improve your customers’ perception of your product or service. Specifically, companies can use a log management service to:
- Pinpoint exactly what the customer did during the course of a transaction or interaction with an application or service, as opposed to relying purely on email threads or phone logs. This root cause analysis can help in understanding bottlenecks that the customer complained about and, just as importantly, provide guidance to the development team on how customers are using the product or service. Actually it’s a great reason for the app development teams to use the service as well, but that’s the subject of another post.
- Easily correlate that application activity with the impact on other infrastructure elements that affect the consumer experience. Unfortunately, many companies today only focus on a single application view of the customer experience when, given how integrated applications and services are today, it’s critical to get a full picture of all the different ways in which the customer is affected.
- Proactively address potential customer-facing issues *before* they hit by receiving real-time alerts when application anomalies are diagnosed by the log management solution
- Create customer dashboards and reports that provide real-time insights into the customer activity you care most about tracking
We use Sumo Logic internally to support every function in the organization from application development to QA to customer service and even marketing. Our co-founder and VP of Engineering, Kumar Saurabh, is hosting a webinar on March 26th to talk about “Sumo and Sumo”. We invite you to attend.
02.19.2013 | Posted by Yan Qiao, Software Engineer
Sumo Logic lets you access your logs through a powerful query language. In addition to searching for individual log messages, you may extract, transform, filter and aggregate data from them using a sequence of operators. There are currently about two dozen operators available and we are constantly adding new ones. In this post I want to introduce you to a recent addition to the toolbox, the transpose operator.
Let’s say you work for an online brokerage firm, and your trading server logs lines that look like the following, among other things:
2013-02-14 01:41:36 10.20.11.102 GET /Trade/StockTrade.aspx action=buy&symbol=s:131 80 Cole 18.104.22.168 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_7_3)+AppleWebKit/536.5+(KHTML,+like+Gecko)+Chrome/19.0.1084.54+Safari/536.5 200 0 0 449
There is a wealth of information in this log line, but to keep it simple, let’s focus on the last number, in this case 449, which is the server response time in milliseconds. We are interested in finding out the distribution of this number so as to know how quickly individual trades are processed. One way to do that is to build a histogram of the response time using the following query:
stocktrade | extract “(?<response_time>\d+$)” | toInt(ceil(response_time/100) * 100) as response_time | count by response_time
Here we start with a search for “stocktrade” to get only the lines we are interested in, extract the response time using a regular expression, round it up to the next 100 millisecond, and count the occurrence of each number. The result looks like:
Now, it would also be interesting to see how the distribution changes over time. That is easy with the timeslice operator:
stocktrade | timeslice 1m | extract “(?<response_time>\d+$)” | toInt(ceil(response_time/100) * 100) as response_time | count by _timeslice, response_time
and the result looks like the following:
This gets the data we want, but it is not presented in a format that is easy to digest. For example, in the table above, the first five rows give us the distribution of response time at 8:00, the next five rows at 8:01, etc. Wouldn’t it be nice if we could rearrange the data into the following table?
That is exactly what transpose does:
stocktrade | timeslice 1m | extract “(?<response_time>\d+$)” | toInt(ceil(response_time/100) * 100) as response_time | count by _timeslice, response_time | transpose row _timeslice column response_time
Here we tell the query engine to rearrange the table using time slice values as row labels, and response time as column labels.
This is especially useful when the data is visualized. The “stacking” option allows you to draw bar charts with values from different columns stacked onto each other, as shown below:
The length of bars represents number of trading requests per minute, and the colored segments represent the distribution of response time.
That’s it! To find out other interesting ways to analyze your log data, sign up for Sumo Logic Free and try for yourself!