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
Logstash
Score 7.6 out of 10
N/A
N/A
N/A
Pricing
SolarWinds Loggly
Logstash
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
Logstash
Free Trial
Yes
No
Free/Freemium Version
Yes
No
Premium Consulting/Integration Services
Yes
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.
—
More Pricing Information
Community Pulse
SolarWinds Loggly
Logstash
Considered Both Products
SolarWinds Loggly
Verified User
Engineer
Chose SolarWinds Loggly
We found that Loggly is a very good balance between functionality and costs. With the ability to analyze different log files across different platforms gives it just a bit of a bigger edge compared to other monitoring systems.
Loggly was a mistake. We selected it to get a cheap vendor-hosted solution up and running quickly but have come to regret the decision and should have spent the effort to set up the right tool from the beginning.
We chose Loggly because we found it to be a good balance between costs, functionality, and available documentation/integrations. Logentries and PaperTrail were pretty closely tied for second place at the time. All 3 of the main contenders have been bought out by other companies …
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.
Perfect for projects where Elasticsearch makes sense: if you decide to employ ES in a project, then you will almost inevitably use LogStash, and you should anyways. Such projects would include: 1. Data Science (reading, recording or measure web-based Analytics, Metrics) 2. Web Scraping (which was one of our earlier projects involving LogStash) 3. Syslog-ng Management: While I did point out that it can be a bit of an electric boo-ga-loo in finding an errant configuration item, it is still worth it to implement Syslog-ng management via LogStash: being able to fine-tune your log messages and then pipe them to other sources, depending on the data being read in, is incredibly powerful, and I would say is exemplar of what modern Computer Science looks like: Less Specialization in mathematics, and more specialization in storing and recording data (i.e. Less Engineering, and more Design).
Putting our logs in one place and making them searchable. We use AWS, and CloudWatch has always been a little frustrating in this regard (though it has gotten better recently).
Deriving metrics from our logs. I think log-based metrics is such a good idea because your logs are the ultimate source for truth in regards to what the hell is going on inside your app. I have really loved the simplicity with which I can just count certain statements and call that a metric because just through the normal course of development certain log statements just naturally become a straightforward recording of an event having occurred.
Alerts. I actually have a few complaints about email alerts, but just the way I was able to set them up so easily has been huge. Since we started using Loggly, there have been at least 3 bugs that Loggly exposed that were frankly very bad. And withoutt Loggly or without a user reporting them, we would have never known they were happening! This is stuff I tried to set up in CloudWatch in various ways, but because of my own ignorance or perhaps the complexity/limitations of CloudWatch (or the complexity of my stack?), I wasn't getting the information that I needed until I was able to just tell Loggly to send me an email whenever the word "error" showed up.
Logstash design is definitely perfect for the use case of ELK. Logstash has "drivers" using which it can inject from virtually any source. This takes the headache from source to implement those "drivers" to store data to ES.
Logstash is fast, very fast. As per my observance, you don't need more than 1 or 2 servers for even big size projects.
Data in different shape, size, and formats? No worries, Logstash can handle it. It lets you write simple rules to programmatically take decisions real-time on data.
You can change your data on the fly! This is the CORE power of Logstash. The concept is similar to Kafka streams, the difference being the source and destination are application and ES respectively.
We have to use a log aggregating device to ship our logs to Loggly as our network devices can not connect on an encrypted protocol. I would prefer if we could use some sort of VPN-based connector to ship logs securely.
Sometimes when drilled down, it can be difficult to fully reset a search term to back all the way out of a drill down.
Since it's a Java product, JVM tuning must be done for handling high-load.
The persistent queue feature is nice, but I feel like most companies would want to use Kafka as a general storage location for persistent messages for all consumers to use. Using some pipeline of "Kafka input -> filter plugins -> Kafka output" seems like a good solution for data enrichment without needing to maintain a custom Kafka consumer to accomplish a similar feature.
I would like to see more documentation around creating a distributed Logstash cluster because I imagine for high ingestion use cases, that would be necessary.
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.
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.
We were using Zabbix. While it is an open-source solution that you can install for free the following things were limitations of the solution. 1) The scale and uptime of the solution are now your own problem. Since we were hosting at AWS this meant we still had a cost of the AWS solution. 2) The product is complicated from a configuration standpoint. In order to get anything meaningful out of it, you had to invest a lot of time and effort. We did consider NewRelic. I have experience with that product and do think that it is a solid alternative. Ultimately experience with the simplicity and speed of deployment with Loggly encouraged me to suggest using this again.
MongoDB and Azure SQL Database are just that: Databases, and they allow you to pipe data into a database, which means that alot of the log filtering becomes a simple exercise of querying information from a DBMS. However, LogStash was chosen for it's ease of integration into our choice of using ELK Elasticsearch is an obvious inclusion: Using Logstash with it's native DevOps stack its really rational
Unfortunately, we hit our logging cap on a weekly basis and we lose logs after that.
We have lost logs after hitting the maximum during service outages. We have become accustomed to not being able to rely on having them, then things go poorly.
Positive: Learning curve was relatively easy for our team. We were up and running within a sprint.
Positive: Managing Logstash has generally been easy. We configure it, and usually, don't have to worry about misbehavior.
Negative: Updating/Rehydrating Logstash servers have been little challenging. We sometimes even loose data while Logstash is down. It requires more in-depth research and experiments to figure the fine-grained details.
Negative: This is now one more application/skill/server to manage. Like any other servers, it requires proper grooming or else you will get in trouble. This is also a single point of failure which can have the ability to make other servers useless if it is not running.
