Use it if your devs can log effectively or you'll end up in a jam when you hit your cap
Anonymous | TrustRadius Reviewer
September 19, 2020

Use it if your devs can log effectively or you'll end up in a jam when you hit your cap

Score 6 out of 10
Vetted Review
Verified User
Review Source

Overall Satisfaction with SolarWinds Loggly

Loggly is one of the ways that allow us to possibly capture the behavior of our software applications both during development and when they are running live. Our Development Teams can add logging to their code and they and site reliability engineers can investigate when the information is logged. Incident management has set up some alerts against particular messages to possibly warn before potential service disruptions occur.
  • It can log whatever a developer decides to add information about.
  • Zooming in on a particular time frame is helpful.
  • The ability to tag/label events.
  • 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.
  • 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.
As far as I can tell, people at my organization do not use the ready-to-use dashboards and/or are not aware of them. I have not used them to troubleshoot. We attempt to filter by time frame and by tags that indicate environments and service names. Development teams look for their own services' tags.
We also use New Relic. For example, we'll use it to query for particular API requests to services and see what their response status codes were. Much of our stack is in Azure, so we have the monitoring that comes with that, and some even know how to use them: Metrics, Application Insights.
If it were possible to consolidate everything to a single approach, I'd do it right away. Less cognitive load for everyone in the organization so they can focus on finding the info they need and solving the problems. However, if a single solution can't give us all the features then we get the features where we can.
This is a good choice if you have developers that understand using logging levels appropriately (i.e. not simply blasting every possible piece of information to logs, knowing to use debug and info levels). If you have people who know how to set up alerts based on logs, you can find it very useful also. However, if you are missing a critical mass of this experience and skill level at your organization, you'll find your logs are very noisy and hard to search through for what you want, subsequently degrading devs' enthusiasm for learning and using them. Furthermore, you may often hit your logging limit and lose logs during critical times. Use this solution if you're confident your technical folks are up to speed on effective logging practices.