Loggly is a cloud-based log management service provider. It does not require the use of proprietary software agents to collect log data. The service uses open source technologies, including ElasticSearch, Apache Lucene 4 and Apache Kafka.
$79
per month/billed annually
SolarWinds Papertrail
Score 8.9 out of 10
N/A
Austin based SolarWinds acquired log management tool Papertrail in April, 2015.
N/A
Pricing
SolarWinds Loggly
SolarWinds Papertrail
Editions & Modules
Standard
$79
per month/billed annually
Pro
$159
per month/billed annually
Enterprise
$279
per month/billed annually
No answers on this topic
Offerings
Pricing Offerings
SolarWinds Loggly
SolarWinds Papertrail
Free Trial
Yes
No
Free/Freemium Version
Yes
Yes
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
Free trial for Standard and Pro plans for 14 days with all features.
SolarWinds Loggly is great for capturing and organizing logs from 3rd party sources such as NGINX. Without SolarWinds Loggly it's really difficult to manage the logs overtime, find traffic patterns, and identify issues before they become a problem. Anyone who is routinely searching through massive log files could quickly benefit from the SolarWinds Loggly and it's capabilities.
SolarWinds Papertrail is great if you have multiple separate applications and you want to be able to view and search all the logs in one place. It also works well for alerts based on certain keywords in log entries (for example, ERROR, WARN, etc.) Since only the first four weeks of logs are searchable in Papertrail, it may not work well for use-cases where much older log entries need to remain searchable.
Modern: Loggly is modern: Dashboards, realtime information and the ability speak many different data sources and environments makes it an attractive choice
Configurability: Loggly gets log parsing right: by allowing you to in real time- filtering of log data, tagging and identifying data sources
DevOps friendly: Loggly is very Componentized: You can have an instance of Loggly running that will Monitor your Linux instance, in addition to all of it's services, as an example. Also, you can start/stop Loggly, without affecting your other components
Once the logging limit is exceeded, there are no logs period. Unexpectedly noisy logs often correlate with services misbehaving and potentially leading to disruption. An outage is an awful time to lose visibility into the entire system of apps. Some ways to bridge this gap would be appreciated.
Filtering by tags is not intuitive in the web interface. You may believe that you are performing the same search and filter as last time since the tags entered are the same, however, this is often not the case. The reliable way to know that you have the same filter is to bookmark the URL. This lack of ease in usability results in devs using Loggly less than they could and implementing logs less effectively during development time (since they don't consider themselves likely to view them anyway).
Would like to see a way to onboard our less experienced devs to using Loggly effectively.
Loggly's easy setup, very good customer support, and intuitive interface make Loggly very easy to use. User access management is also very easy as we can tailor the experience for each of our developers to access the information they need without having to wade through other information. While there was a slight learning curve in how to view the logs the way some specifically wanted, everything was possible and quite easy to do.
It's extremely easy to use. I and new colleagues have never had any issues configuring this tool or setting it up, it works almost out of the box with very simple instructions to follow to configure it to our own environment. I would highly recommend it on that ability alone.
The support team have been great when we have logged tickets or had issues, most of the time it is down to user training, however we have had a couple of bugs that they have been able to iron out for us.
I honestly have never had the need to use the support team, as we have not run into any issues so far. If we did however, judging from how the tool itself works, I don't doubt that the team would provide excellent support for any issues that we may possibly run into.
I actually couldn't get anybody from Datadog to engage with me, the main problem we had was that our devices couldn't connect to an encrypted port, but we didn't want to send our logs in plain text over the internet. We implemented an on-net log aggregator which then connects to Loggly over encrypted UDP. In theory Loggly made this particularly easy providing configuration snippets for most of the common log services (e.g. rSyslog, syslog-ng). Unfortunately the documentation was out of date and none of the provided configs worked, fortunately they were close enough that combined with our own syslog-ng experience we were able to get it up and going relatively painlessly. The choice then of going with Loggly, backed by an industry favourite in Solarwinds was a no brainer.
I selected SolarWinds Papertrail because it was cheap and already provided precisely the integration surface required by the Heroku stack. It probably provided the least number of 'useful' features (out of the bunch) due to the nature of my logs and the post-mortem updates that were required to make them usable.
Loggly has alerted us to several bugs, ranging from major to small to "would have been a major problem under load."
It's great having our disparate logs collected and the alerts we have set up around them let us know recently that somebody used an incorrect document to generate a mass email. Users were trying to log in with the link provided but getting 401s and I have an alert configured to tell me about high numbers of 4xx errors.
Metrics and alerts around metrics have given us peace of mind that automated fulfillment systems aren't going off the rails and costing us hundreds of dollars.
