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 8.0 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
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.
Security Onion was a much better fit for our uses at this time. The more we integrate into a hybrid environment the more need for Loggly but at this time Security Onion accomplishes our goals.
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 proved to be very easy to set up and integrate with our existing systems without having to add extra agents or roll our own everything. Insights others give for Java performance may be better than we've seen with Loggly, but in terms of log aggregation and data insights …
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 …
We have a Nagios Log Server, however needed specialist help to get it running before it fell over, which is why we went down the Loggly route. We also use Microsoft Cloud App Security, however we find using this as well as Loggly gives us double the power to search for issues …
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.
SolarWinds Loggly integrates well with other SOlarWinds products, and that is ultimately why we chose to use Loggly. LogDNA was fine for our needs, but costly for only providing logging.
Graylog would also have met our requirements, but since we then needed to run a virtual machine (with huge disk space) and also needed more work for setup and maintenance, our calculations resulted in Loggly being more cost effective. Icinga is not made for log file monitoring …
With Loggly we can manage not only AWS apps but all the apps we have (not only Cloud-based apps). It is also very convenient to add users that need to have access to a given log streams: we do not need to manage an AWS IAM role/user. And the search engine is way more easy and …
Loggly is at another level at indexing and search experience. However, since CloudWatch has the full history with least cost it is always the fallback. So if Loggly has something like S3 glacier kind of feature for keeping old logs which are least accessed with less cost, that …
I've used ELK, Sumo, Splunk, Cloudtrail/watch, Sentinel. You get what you pay for. If you have the time, expertise, and budget for a Splunk setup, you can't beat it. ELK is great for OSS shops but takes more hand-holding to scale and stabilize. Loggly, for us, was closer to …
Loggly was the easiest to use and the one that really allowed us to get a full view of what's going on with our services, and proactively solve problems.
I honestly didn't shop around that much. I came from CloudWatch, which though it has been improving, was very frustrating when it came to just setting up a simple alarm when a specific log message is found, or extracting useful metrics from logs. Loggly was recommended to me by …
Price and ease of deployment were huge factors in our decision to use Loggly. Loggly is actually within reach for most companies while also being very easy to setup. Elasticsearch, for instance, had wildly outdated documentation when I was previewing all these tools so I was …
I have used EFK stack (ElasticSearch, Fluentd, and Kibana) and Splunk. Solarwind Loggly is the most flexible managed service out of these solutions and suitable for companies embracing the SaaS model
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 …
Logstash can be compared to other ETL frameworks or tools, but it is also complementary to several, for example, Kafka. I would not only suggest using Logstash when the rest of the ELK stack is available, but also for a self-hosted event collection pipeline for various …
Logstash is similar to any service which can be the single point to collect and transform data. Kafka is a very good candidate, but it fails for applications not using Kafka. Kafka streams do pretty much the same thing. On one hand, I personally trust Kafka more, but then Kafka …
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.
Logstash is a must in an ELK stack, which I am sure is going to be the #1 case. At any point when you have several sources, Logstash can be the common point to aggregate, and categorize those data. Then send this new data to its destination. Very handy. It is free and open source. It may not be appropriate to analyze data-sets dependent on each other but from a different data source. Reason being Logstash works on data at hand, and not wait for other data to arrive. It would be unwise for Logstashh to handle complicated, long-running transformations because this is injected and ejected. The faster you do it, the safer.
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.
Memory: Logstash is a HOG, if you are deploying it on commodity (i.e. cheap and old) hardware: You will need at least 2GB, just for Logstash. So don't expect to run your entire ELK stack on one AMD Athlon machine.
Overlap: Logstash fills in an area of the ELK stack that makes the most sense: as a log file transformer / shipper. However, if you start breaking that stack, with the addition of other components- you start seeing where features of Logstash may be implemented or solved in the additional components much easier (or better, or to a higher degree of resolution)
More Overlap: Since my team employs Syslog-ng extensively- Logstash can sometimes get in the way (and this may be a problem for DevOps stacks overall): You can configure Syslog to record certain information from a source, filter that data, and even export that data in a particular format. Logstash will pick that data up, and then parse it. However, if you don't keep your Syslog-ng configuration files, and your Logstash configuration files in sync, your results will not be what you expected, and this will translate into (sometimes) hours/days of work, hunting down a line item in a configuration file.
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.
As I said earlier, for a production-grade OpenStack Telco cloud, Logstash brings high value in flexibility, compliance, and troubleshooting efficiency. However, this brings a higher infra & ops cost on resources, but that is not a problem in big datacenters because there is no resource crunch in terms of servers or CPU/RAM
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 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.
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
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.
It is very difficult to give any figures on ROI, as it depends on many factors, and in a Telcocloud environment, it is much complex to find out; however, I would give some points below on ROI
ROI based on flexibility is very high, as it reduces the time to find RCA
ROI based on integration is very high because it supports multi-vendor environments, avoiding vendor lock-in & works across multi-cloud setups
ROI on resource consumption is less because Logstash in 2-3 times more resource-intensive as compared to its lightweight alternatives resulting in latency
