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

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

Anonymous | TrustRadius Reviewer
Score 6 out of 10
Vetted Review
Verified User

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.
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.