Sumo Wrestling Your Logs with Sumo Logic
February 05, 2016

Sumo Wrestling Your Logs with Sumo Logic

Derek Ardolf | TrustRadius Reviewer
Score 7 out of 10
Vetted Review
Verified User
Review Source

Overall Satisfaction with Sumo Logic

Sumo Logic was being used by developers, system engineers, management, and InfoSec as a primary log aggregation tool. It was replacing the Splunk deployment in our enterprise because it was cheaper, hosted by Sumo Logic, and helped bring larger visibility to the enterprise (as we were able to ingest larger amounts of logs than we had before). As a result, many developer teams that did not initially have the insight into their applications were able to get instant access to how things were running on their systems.
  • Sumo Logic allowed for our InfoSec team to ingest logs from our CDN directly, in real-time, instead of massive compressed archives that were sent every two-hours (the only alternative at the time). Sumo Logic had an app for these logs, that allowed us to easily get an immediate payoff from the data, with canned dashboard and saved searches.
  • Sumo Logic has a fairly extensive REST API when it comes to log sources, source configurations, dashboard data, searches, etc. Their wiki for the API is usually kept up to date.
  • Sumo Logic, during the period of time I had used their product, had added the ability to configure agents via configuration files. This allowed customers to configure their endpoints, and modify the endpoints, with configuration management tools like Chef / Puppet / Salt. Beforehand, the only option was to always make changes either via the web portal or REST API.
  • The solutions engineers were extremely helpful, and easily reachable when issues would occur.
  • Users at our company found it easy to get started, working on new dashboards, scheduled searches, and alerting. The alerting worked well with our third-party paging tool.
  • Sumo Logic, during the period that I used their product (up until at least November 2015), did not have a User / RBAC API. This made it very difficult to manage users (we had about 100 users). Even though they had SAML integration, allowing us to utilize a single-sign on solution, we would have to do manual reviews of user accounts in Sumo Logic on a regular basis. There was no export feature, so it became a matter of copy/pasting all users from the web portal, and creating a spreadsheet out of the data. This was a big pain, as we were all about automation. I had been told that a User / RBAC REST API would be made available sometime during Q1 - Q1 2016.
  • The user who creates any saved search queries, alerts, reports, or dashboards, is the only user that is able to edit them. In a collaborative environment, or larger enterprise, this brings a level of difficulty. For example, if an alert breaks and is spamming an inbox/pager, it cannot be edited or stopped unless done specifically by the user who created it. The RBAC has not been improved enough to allow groups/teams/organizations to have ownership over them (as of November 2015).
  • If you are to delete a user account in Sumo Logic, as your account is setup to allow a specific amount of user accounts in addition to the storage limits agreed in contract, all of the work they had created for teams -- dashboards, scheduled searches, alerting, reporting, etc. -- all become unpublished and unscheduled. They all become inherited by the user that deletes their account. This may create a mess, as this may now completely stop many useful reports/alerts/dashboards that were being taken care of initially. As a result, deletion of a user who is no longer having access to Sumo Logic (due to leaving the company, or leaving a team the needs access), requires a complete review of everything the user has saved in order to see whether anything needs to be rescheduled for alerting/reporting or republished for dashboard viewing. This is all as of November 2015.
  • Purging log data can be extremely difficult. Sumo Logic stores data in a WORM (Write Once, Read Many) type of database. This is done for security reasons, and the database also stores it's data in an encrypted form. If you wish for any data to be removed for any reason, such as PHI / PII / etc. information, you have to wipe out absolutely all data within a time range that Sumo Logic has ever gathered for you. This does not just include the source of the data you are trying to purge, but would include all log data from all sources that you have (even if separately indexed, or partitioned). I am unsure of whether this is still the fact, or if this has at least narrowed down to partition/index, or source.
  • In the web portal, Sumo Logic has icons for agents that are working -- green/yellow if I remember right. Source hosts would always show a big green checkmark for health, even if certain sources were completely failing. If Sumo Logic agents are logging errors that logs can't be collected (permissions, some agent issue, etc.), there wasn't a way to visibly see there was an issue unless you were looking for it in logs. This resulted in periods of time where we did not receive logs from many sources. This is hard to alert on, as we found we would have to create a scheduled search of Sumo Logic agent logs that looked for as many error/warning messages as we could, that we knew about. This was incredibly difficult, and unmanageable.
  • It was nearly all positive impacts for us. Teams that never had data so easily accessible beforehand (such as developers, and managers being able to see dashboards for infrastructure health) were able to make immediate changes based on what they found. This could be said, likely, of any log aggregation toolset being used at a company. Though, with Sumo Logic, the default apps were very helpful in quickly showing us issues that were proactively resolved (so, unknown amount of time/stability gain there).
  • Being able to integrate log data from our CDN, creating great real-time visibility for our InfoSec team, was a huge win. We were unable to get this with Splunk at the time (not sure if Splunk has made any changes), so this was likely the clinch. Before, we were getting large archives of log data every two hours. We couldn't ingest this into Splunk due to cost, so it was useless data. That data was able to be ingested in real-time with Sumo Logic, resulting in 100's of gigabytes of data being ingested daily from that data source alone. The insight was tremendous!
  • The Developers that were given access to use Sumo Logic were very happy with the data they had access to, and the representation of it within Sumo Logic (through custom created items, and canned apps). One feature we requested, which was a live tail of source data to be able to watch events occur in real-time, went through beta and into production during our use. We were invited to web meetings directly with Sumo Logic developers on prototypes, tried out the beta, and made use of it in production. This feature was extremely helpful during testing, and application deployments, where previously we were having to constantly run new searches after the fact.
We had used Splunk previously. Sumo Logic defeats them when it comes to cost, including the costs that would normally come with supporting/managing/patching/upgrading your own infrastructure and storage. Those were wins, but especially the real-time CDN integrations due to Sumo Logic's collaborations with other vendors.

We had spoken to Logentries and discovered that many of the cons we found with Sumo Logic seemed to have been resolved in their product. Their pitfall was that, at the time, Logentries did not have the ability to get real-time log ingestion from our CDN. They said they had a solution, which was scripted, but we had not evaluated/tested. Logentries also did not have a User / RBAC REST API, and are nowhere near the level of compliance that Sumo Logic had (https://www.sumologic.com/press/2015-02-19/sumo-logic-successfully-completes-pci-data-security-stand...). In the end, I believe Logentries and Sumo Logic would be two good vendors to get involved in a bake-off.
Sumo Logic is best suited, as of the time of this review, for a smaller-to-medium sized enterprise. Medium may be pushing it, depending on the deployment. The larger the enterprise, user access, and server agent count, the harder Sumo Logic is at scaling and realistically using. I have not managed or deployed other log aggregation solutions, so I'm not aware of whether competitors may suffer from the same setbacks as Sumo Logic. The ease of use, ability to deploy quickly, always having the latest version of the web portal (due to it being hosted), and being able to have data readily available for a critical time of the year were great benefits. Sumo Logic had also shown that they were taking our feedback seriously, and seemed to be working on resolutions to many of these issues for 2016. I'm giving a 7 out of 10 based on the Sumo Logic as it was in November 2015. If one is in talks with the vendor, the cons listed here should be mentioned in order to see if they have been resolved.

Sumo Logic Implementation

I was satisfied with the implementation, as at the time, it was the best way to implement the product with the available feature sets in Sumo Logic. User creation and management became more of an issue during continued use, instead of it being an issue related to deploying the product in our environment.
  • Vendor implemented
  • Implemented in-house
Yes - We did a trial/evaluation run, with the assistance of Sumo Logic, for a period of 3-months. This included servers that had not ever had logs ingested into a log aggregation tool, for use by teams. During this stage, we also worked on ingesting logs in real-time from our CDN. This phase was done agentless, as to make it easier to deploy and to tear down if we chose to scrap it.

When we signed a contract, we began adding many more internal log sources -- including the logs that were being ingested into Splunk (so that we could transition completely to Sumo Logic).
Change management was a minor issue with the implementation - Change management was not a big deal, especially during our trial period, since we had gone down the agentless path in our trial run. Agentless was chosen due to the potential change management roadblocks (during a holiday period), and the need to get it designed/implemented very quickly. We later transitioned to agent-based setups, and change management was not too big a deal since we were outside of a holiday period by that point.
  • Sumo Logic agents had a harder time on Windows Server than they had on Linux servers. Certain standard log files were unable to be ingested, such as logs generated by SQL server. Even with help from our solutions engineer, and Sumo Logic support, this issue was not resolved. I have spoken to other customers that did not have this issue, and had seen a demo environment where it was working without problem. I am not sure if this bug was resolved, if it was indeed a bug.
  • Agentless brought about problems later on. It seemed the best choice to implement, to quickly get up and running all the way into a production environment with little hassle. Agents would not have been ideal at the time (Winter 2014), as the only way you could manage/fix source configurations was via the web portal or REST API only. I managed sources via a PowerShell Module I had developed (), as it was the only reasonable way to make changes to large amounts of collectors/sources at a time. In the web portal GUI, one is only able to make modifications to one collector/source at a time. Sumo Logic later introduced the ability to make new changes on the collector locally, via configuration files, thus introducing proper configuration management. This made agentless highly unnecessary, as now we could modify many sources/collectors at a time and not have a single-point of failure (biggest reason not to go agentless!). If the central log collector server used in an agentless setup would run into any issues, you could go for long periods of time collecting zero logs from many sources. Ouch. Since November 2015, there was not a documented way to have redundancy with an agentless setup without major scripting and unavoidable pitfalls.
  • User creation and management: I went more in-depth in my review, but the absence of a user / RBAC API caused problems. Being that Sumo Logic is a hosted solution, accessible from the internet, if someone leaves the company or no longer needs access due to a change of role, it cannot be automated (as of November 2015).