Use Cases | Sumo Logic

Blog › Use Cases

Sending CloudPassage Halo Event Logs to Sumo Logic

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.

Show Me the VPN Logs!!!

03.07.2013 | Posted by Praveen Rangnath, 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.

Busted.

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.

The Marriage of Machine Data and Customer Service

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.

Using the transpose operator

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 219.142.249.227 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:

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!

A Few Good Logs

02.15.2013 | Posted by Praveen Rangnath, Product Marketing

“I Want The Logs!”

In the midst of this week’s back and forth between Tesla, the New York Times, and various other media outlets and bloggers, Greylock Data Scientist in Residence (and Sumo Logic Advisory Board Member) DJ Patil posted a tweet that caught my eye: “Love that everyone is using data to have a conversation. It’s about getting to the right answer.”

DJ is 100% correct, and throughout this Tesla/NY Times debate, we at Sumo Logic are thrilled to see the public recognition of the importance of log data — as a source of the truth.

Yes, log data needs to be properly analyzed and understood (as the debate makes evident), but what clearly emerged from the debate is the truism that that log data holds the absolute and authoritative record of all the events that occurred. It’s evident; just see how the discussion revolves entirely around understanding the logs.

The Bigger Picture

There is a bigger picture to this debate, which is that log data is generated everywhere, whether it be from the car you drive, the energy meter beside your home, the device you’re using to read this blog, the server delivering this content, the network delivering this content, the device I’m using to write this post… I could go on and on. And in the same way log files generated by a car hold the answer to whether it ran out of power or met range estimates, log files generated by applications, servers, network and virtualization infrastructure hold the answer to whether revenue generating applications are up and adequately performing, if customers are utilizing a newly developed feature, or if any part of an IT infrastructure is slow or experiencing downtime.

It is important to remember — these are all business critical questions. And just like Tesla needed to analyze their logs to defend their business, every enterprise, large or small, needs to be able to easily analyze and visualize their log data to ensure the health of their business.

Cars, Enterprises, and Terabytes

Before moving on, let’s not forget, enterprises are not cars, and data generated from enterprises is different from data generated by cars, particularly along three dimensions: volume, variety, and velocity. You got it… the 3 Vs of Big Data. Cars do not (or at least do not yet!) generate up to terabytes of unstructured data per day. Enterprises with large distributed IT environments do.

This is where Sumo Logic comes in. Sumo Logic is based on the recognition that enterprises need to be able to easily analyze and visualize the massive amounts of amounts of data generated by their infrastructure and business, and that current on-premise tools just can’t scale. Today, enterprises generate as much data in 10 minutes as they did in the entire year in 2003. It is therefore not surprising that legacy on-premise solutions just can’t keep up.

Sumo Logic makes it possible for enterprises of all sizes to find the truth from their data. And we do so without adding any operational overhead for our customers; Sumo Logic is a 100% cloud-based service. Large enterprises like Netflix and Land O’Lakes use Sumo Logic. Fast growing enterprises like PagerDuty and Okta do as well.

You want some answers? You have some logs? We can handle the logs.

Pardon me, have you got data about machine data?

01.31.2013 | Posted by Bruno Kurtic, Founding Vice President of Product and Strategy

I’m glad you ask, I just might. In fact, we started collecting data about machine data some 9 months ago when we participated at the AWS Big Data conference in Boston. Since then we continued collecting the same data at a variety of industry show and conferences such as VMworld, AWS re: Invent, Velocity, Gluecon, Cloud Slam, Defrag, DataWeek, and others.

The original survey was printed on my home printer, 4 surveys per page, then inexpertly cut with the kitchen scissors the night before the conference – startup style, oh yeah! The new versions made it onto a shiny new iPad as an IOS App. The improved method, Apple caché, and a wider reach gave us more than 300 data points and, incidentally, cost us more than 300 Sumo Logic T-Shirts which we were more than happy to give up in exchange for data. (btw, if you want one come to one of our events, next one coming up will be the Strata Conference).

As a data junkie, I’ve been slicing and dicing the responses and thought that end of our fiscal year could be the right moment to revisit it and reflect on my first blog post on this data set.

Here is what we asked:

Which business problems do you solve by using machine data?
Which tools do you use to analyze machine data in order to solve those business problems?
What issues do you experience solving those problems with the chosen tools?

The survey was partially designed to help us to better understand the Sumo Logic’s segment of IT Operations Management or IT Management markets as defined by Gartner, Forrester, and other analysts. I think that the sample set is relatively representative. Responders come from shows with varied audiences such as developers at Velocity and GlueCon, data center operators at VMworld, and folks investigating a move to the cloud at AWS re: Invent and Cloud Slam. Answers were actually pretty consistent across the different “cohorts”. We have a statistically significant number of responses, and finally, they were not our customers or direct prospects. So let’s dive in and see what we’ve got and let’s start at the top:

Which business problems do you solve by using logs and other machine data?

Applications management, monitoring, and troubleshooting (46%)
IT operations management, monitoring, and troubleshooting (33%)
Security management, monitoring, and alerting (21%)

Does anything in there surprise? I guess it depends on what your point of reference is. Let me compare it to the overall “IT Management” or “IT Operations Management” market. The consensus(if such a thing exists) is that size by segment is:

IT Infrastructure (servers, networks, etc) is up to 50-60% of the total market
Application (internal, external, etc.) is just north of 30-40%
Security is around 10%

Source: Sumo Logic analysis of aggregated data from various industry analysts who cover IT Management space.

There are a few things that could explain the big difference between how much our subsegment leans more toward Applications vs. IT infrastructure.

(hypothesis #1) analysts measure total product sold to derive the market size which might not be the same as effort people apply to these use cases.
(hypothesis #2) there is more shelfware in IT Infrastructure which overrepresented effort.
(hypothesis #3) there are more home-grown solutions in Application management which underrepresents effort.
(hypothesis #4) our data is an indicator or a result of a shift in the market (e.g., when enterprises shift toward the IaaS, they spend less time managing IT Infrastructure and shift more toward the core competency, their applications).
(obnoxious hypothesis #5) intuitively, it’s the software stupid – nobody buys hardware because they love it, it exists to run software (applications), and we care more about applications, and that’s why it is so.

OK, ok, let’s check the data to see which hypothesis can our narrow response set help test/validate. I don’t think our data can help us validate hypothesis #1 or hypothesis #2. I’ll try to come up with additional survey questions that will, in the future, help test these two hypotheses.

Hypothesis #3 on the other hand might be partially testable. If we compare responses from users who use commercial vs. who use home-grown, we are left with the following:

Not a significant difference between responders who use commercial vs. responders who use home grown tools. Hypothesis #3 explains only a couple of percentage points of difference.

Hypothesis #4 – I think we can use a proxy to test it. Let’s assume that responders from VMworld are focused on internal data center and the private cloud. In this case they would not be relying as much on IaaS providers for IT Infrastructure Operations. On the other hand, let’s also assume that AWS, and other cloud conference attendees are more likely to rely on IaaS for IT Infrastructure Operations. Data please:

Interesting, seems to explain some shift between security and infrastructure, but not applications. So, we’re left with:

hypothesis #1 – spend vs. reported effort is skewed – perhaps
hypothesis #2 – there is more shelfware in IT infrastructure – unlikely
obnoxious hypothesis #5 – it’s the software stupid – getting warmer

That should do it for one blog post. I’ve barely scratched the surface by stopping with the responses to the first question. I will work to see if I can test the outstanding hypotheses and, if successful, will write about the findings. I will also follow-up with another post looking at the rest of the data. I welcome your comments and thoughts.

While you’re at it, try Sumo Logic for free.

AWS re:Invent – The future is now

12.05.2012 | Posted by Stefan Zier, Cloud Infrastructure Architect

This past week, several of us had the pleasure of attending Amazon Web Service’s inaugural re:Invent conference in Las Vegas. In the weeks leading up to the conference, it wasn’t fully obvious to me just how big this show was going to be (not for lack of information, but mostly because I was focused on other things).

When I picked up my badge in the Venetian and walked through the enormous Expo hall, it struck me: IaaS, the cloud, is no longer a bleeding edge technology used by a few daring early adopters. The economics and flexibilities afforded are too big to be ignored – by anyone.

Attending sessions and talking to customers showed that, more than ever before, application architectures are distributed. The four design principles outlined in Werner Vogels excellent keynote on day 2 of the conference – Werner calls them “The Commandments of 21st Century Architectures” made it obvious that the cloud requires people to build their applications in fundamentally different ways from traditional on-premise applications.

While at the conference, I spent quite some time at the Sumo Logic booth, explaining and demoing our solutions to customers. Most of them run distributed systems in AWS, and it never took more than 2 minutes for them to realize why their lives would be much easier with a log management solution — having a central tool to collect and quickly analyze logs from a large distributed app is essential to troubleshooting, monitoring and optimizing an app.

Once I started to explain how our product is architected, and started relating to the architecture principles Werner outlined, most people understood why Sumo Logic’s product can scale and perform the way it does, unlike some other “cloud washed” solutions on the market.

In addition to having a highly relevant set of attendees for us, the conference also was a great place to find other vendors who exist in the same ecosystem – we’ve begun several good conversations about integrations and partnerships.

The response from people we talked to was overwhelmingly positive. During the conference, we’ve seen a big increase in sign-ups for our Sumo Logic Free product. We will definitely be back next year.

Real-time Enterprise Dashboards, Really

11.14.2012 | Posted by Bruno Kurtic, Founding Vice President of Product and Strategy

Today we shipped a highly anticipated new capability with a novel approach, novel not only to Sumo Logic, but also novel within our space: Real-time Enterprise Dashboards. Dashboard technologies have been around for many years, but not all dashboard technologies are created equal. Most existing technologies leverage either precomputed summary data sets or recompute the entire data set every time a dashboard is viewed. As such, they suffer from long load times, stale information, an inability to handle the data volume.

Our customers faced a specific challenge: how to take terabytes of machine data per day, crunch it, transform it into information, and render that information in a way that supports making business and IT decisions in real time. Now they can.

When machine data is used to troubleshoot and monitor today’s production applications or infrastructure, data volume is the enemy. Large farms of Apache or IIS servers, SaaS and other applications, or data center infrastructure like VMware farms, Cisco networking gear, or Linux or Microsoft Windows server farms generate volumes of data that obey Moore’s Law: the data volume doubles every two years. It only makes sense that the volume of machine data would follow Moore’s Law – if machine computing capacity doubles, those machines do twice the work, as a result they generate twice the amount of machine data that describes that work.

This exponential growth has put existing dashboarding technologies under an insurmountable strain. Some of us here at Sumo Logic built previous-generation dashboards in our past lives. From our experience we realized that an entirely new approach is required to enable real-time monitoring and dashboarding and that realization drove development of a new architecture.

First, we adopted the cloud computing paradigm. That turned a data center into an API with lim(capacity)=∞. This enabled us to spin up and spin down additional capacity truly on demand with a single API call. Then we built our Streaming Query Engine that leverages that capacity in an elastic manner. It continuously takes data off the wire and computes results before the data ever hits its permanent resting place. This “one-time” computing is more efficient and less costly than traditional recompute methods. When you view a Sumo Logic Dashboard, you simply attach to the existing state, which is continuously computed by our Stream Query Engine in the background. What you get is freshest data available instantly enabling real-time visibility into your infrastructure or applications. And they are beautiful to boot.

Try it for yourself.

Connect the dots with the new Trace operator

07.18.2012 | Posted by David Andrzejewski, Data Sciences Engineer

The trace operator is a new “beta” feature in Sumo Logic that allows the user to identify and follow chains of entities across different log messages, which themselves may be distributed across different assemblies, machines, or even datacenters. Its origins lie in our culture of “dogfooding” and a recent hackathon where engineers had the opportunity to work on cool or itch-scratching projects of their own choosing.

Since the Sumo Logic service itself is a cloud-based distributed system, we often found ourselves investigating behaviors across multiple components of the system. Following our own logging advice, we use unique IDs to track these events and to make them easily identifiable within our logs. However, unless the “originating ID” follows activity across every single system component, it was still necessary to perform multiple searches to follow event chains all the way to the end. To show how trace automates this procedure and makes our lives easier, we’ll walk through a simplified session tracking example.

Session Tracking Example

Say that your product uses a variety of session IDs to track requests as they flow throughout your system. For example, different components might use a series of 4-digit hexadecimal IDs to process a customer order as shown below.

Now imagine that an error is encountered within the system while processing the accountID causing an internal error log to be generated containing the webID: “PROCESSING FAILED: webID=7F92“.

Manually connecting the dots

Starting from this information, we could perform a series of searches and manual investigations to uncover the root cause from this set of logs:

User action webID=7F92
Initiating requestID=082A for webID=7F92 …
… orderID=34C8 received for requestID=082A …
Retrieving userID=11D2 for requestID=082A …
… accountID=1234 access, userID=11D2 …
ERROR accountID=1234 not found!
(this error percolates back until the original webID fails)
PROCESSING FAILED: webID=79F92

Note that to arrive at this conclusion we are essentially following a ”chain” of these hex IDs across different components of our system.

Session tracking with trace

The idea of the trace operator is to automate this process, allowing us to jump almost directly from the observed webID (log #1) to the original failure deep within the system (log #6) via the following query:

* | trace “ID=([0-9a-fA-F]{4})” “7F92″ | where _raw matches “*ERROR*”

Let’s deconstruct what’s happening here. First, assume that our * keyword search query runs over the time window of interest, capturing all relevant logs and plenty of irrelevant ones as well. Next we have the trace operator:

The regular expression (with exactly one capturing group) ”ID=([0-9a-fA-F]{4})” tells trace how to identify the individual pieces of the chain we are trying to build, in this case 4-digit hex strings following “ID=“.
The final value gives trace the starting point to build a chain from, which for us is the original webID 7F92.
trace then scans incoming logs to build the underlying chain based on IDs occurring together in the same log, starting from the user supplied initial value (here 7F92).

For example, when trace observes this log

Initiating requestID=082A for webID=7F92 …

it uses the regex to identify two IDs: 082A and 7F92. Since 7F92 is the starting point it is already part of the chain, and since 082A has just co-occurred with 7F92 we add it to the chain as well. As trace works its way through the logs, any log containing any ID which is part of the chain is passed through, and any other log is simply ignored. For example the following log would not be added, because none of these IDs are connected to the chain we build starting from the webID 7F92:

Initiating requestID=8182 for webID=8384 …

This is how the trace operator filters logs by “connecting the dots” across different log messages.

The smoking gun

Finally, once we’ve used trace to filter down to logs containing IDs which we know to be connected to the failing webID 7F92, we do string matching to filter down to logs containing the substring “ERROR” and discover a failure associated with the accountID. Note that if we had simply done an “ERROR” keyword search we might be faced with a deluge of other errors not directly connected to the specific issue we were trying to investigate. Furthermore, without the constructing our chain of IDs, there would be no obvious connection between accountID 1234 and our failure webID 7F92. Hopefully this example has given you a taste for what you can do with trace – there are certainly many other possible applications.

Sumo Logic at AWS Big Data Boston

05.29.2012 | Posted by Bruno Kurtic, Founding Vice President of Product and Strategy

I recently represented Sumo Logic at the AWS Big Data conference in Boston. It was a great show, very well-attended. Sumo Logic was one of the few vendors invited to participate.

During the conference I conducted a survey of the attendees to try to understand how this, emerging early-adopter segment of IT professionals, manages log data for their infrastructure and applications.

Common characteristics of attendees surveyed:

They run their apps and infrastructure in the cloud
They deal with large data sets
They came to learn how to better exploit/leverage big data and cloud technologies

What I asked:

Do you use logs to help you in your daily work, and if so, how?
What types of tools do you use for log analysis and management?
What are the specific pain points associated with your log management solutions?

The findings were interesting. Taking each one in turn:

No major surprises here. Enterprises buy IaaS in order to run applications, either for burst capacity or because they believe it’s the wave of the future. The fact that someone else manages the infrastructure does not change the fact that you have to manage and monitor your applications, operating systems, and virtual machines.

A bit of a surprise here. In my previous analysis, some 45% of enterprises use homegrown solutions, but in this segment it’s 70%. Big difference with the big data and cloud crowd. A possible explanation for this is that existing commercial solutions are not easy to deploy and run in the cloud and don’t scale to handle big data. So, the solution = build it yourself. Hmm.

Yes, yes, I know, it adds up to more than 100%. That’s because the question was stated as “select as many as apply” and many respondents have more than one problem. So, nothing terribly interesting in there. But let me dig a bit deeper into issues associated with homegrown vs. commercial.

This makes a bit more sense. For the home grown, it looks like complexity is the biggest pain – which makes sense. Assembling together huge systems to support big volumes of log data is more difficult than many people anticipate. Hadoop and other similar solutions are not optimized to simply and easily deliver answers. This then leads to the next pain point: if it is not easy to use, then you don’t use it = does not deliver enough value.

The responses on commercial solutions make sense as well. Today’s commercial products are expensive and hard to operate. On top of the sticker price, you have to spend precious employee time to perform frequent software upgrades and implement “duct tape” scaling. If you don’t have expertise internally you buy it from vendors’ professional services at beaucoup $$$$$. You have to get your own compute and storage, which grow as your data volume grows. So, commercial “run yourself” solutions = very high CAPEX (upfront capital expenditures) and OPEX (ongoing operational expenditures). In the end (as the second pain point highlights), commercial solutions are also complex to operate and hard to use, requiring highly skilled and hard to find personnel.

Pretty bleak – what now?
At Sumo Logic, we think we have a solution. The pain points associated with home-grown and commercial solutions that were architected in the last decade are exactly what we set out to solve. We started this company after building, selling and supporting the previous generation of log management and analysis solutions. We’ve incorporated our collective experience and customer feedback into Sumo Logic.

Built for the cloud
The Sumo Solution is fundamentally different from anything else out there. It is built for big data and is “cloud native”. All of the complexities associated with deploying, managing, upgrading, and scaling are gone – we do all that for you. Our customers get a simple-to-use web application, and we do all the rest.

Elastic scalability
Our architecture is true cloud, not a “cloud-washed” adaptation of on-premise single-instance software solutions that are trying to pass themselves off as cloud. Each of our services are separate and can be scaled independently. It takes us minutes to triple the capacity of our system.

Insights beyond your wildest dreams
Because of our architecture, we are able to build analytics at scale. Our LogReduce™ and Push Analytics™ uncover things that you didn’t even know you should be paying attention to. The whole value proposition is turned on its head – instead of having to do all the work yourself, our algorithms do the work for you while you guide them to get better over time.

Come try it out and see for yourself: https://www.sumologic.com/free-trial/

Twitter

Follow @sumologic

Sumo Logic
Mentions

.@SumoLogic co-founder Christian Beedgen presents 3:45 today at #gluecon. Topic: Dissecting AWS Detailed Billing Reports for Fun & Profit
22 May | SumoLogic