LogicMonitor Reviews

We use it to monitor the performance and health of all our internal IT systems in our data center as well as our customer equipment that we have out on customer sites. We have our own stuff in our own data center, but we also have hundreds of devices out on our customer sites where we need to monitor and manage the health and performance of them.

Before we were using LogicMonitor, we didn't really have visibility on a lot of things. We went from almost nothing at all, e.g., no visibility on things, no good monitoring, and not being alerted or aware of problems when they would arise, to putting in LogicMonitor across our whole estate and customers' environments now. This has meant that we have been able to centralize that function. When something goes wrong, we can react to it quickly. We can resolve it before it impacts our customers. That is massively important.

We went from nothing to pretty much full visibility across our internal and external estates of equipment, which has been massive for us in terms of being able to resolve problems faster and provide better customer service to our customers. At the end of the day, our customers pay us to be on top of their stuff. LogicMonitor helps us do what we are supposed to do for our customers. So, it is very good from our perspective.

We only have one monitoring tool, and that is LogicMonitor. It does pretty much everything we need under one roof. They are very good at rapidly releasing new features. It's not like we have to wait six months or a year between new features and data sources. There is very quick development. If there is something that doesn't do it for us, I know I can just raise it with support or our delivery representative, and there is a good chance that that will be looked at. If it's not too much effort, we will see it released in the next few months. So, the solution is very good from that perspective. We have everything in LogicMonitor.

We monitor stuff that is on-prem and in the cloud. It is very good comprehensively for that. It is brilliant. I could probably only count a couple of times where there has been something I have needed to monitor that hasn't had a data source or something in LogicMonitor. It is only niche products where I guess it wouldn't necessarily make financial sense for them to actually develop something for this at the moment. For example, we started using a fairly new product, which we rolled out for a lot of our customers, and noticed when we first started using it that there were a limited amount of data sources in LogicMonitor for it. Over the last couple of months, that has been developed significantly. Generally, if it doesn't do something that we want it to do, there is a chance that it will do it at some point and that process is usually quite quick. 

We are very happy with it from a future-proofing perspective. With the amount of updates that LogicMonitor pushes out, I have no concerns that LogicMonitor won't be able to keep up with them as the IT environment changes for our customers and ourselves going forward. It will be great for that.

We are using the solution for on-prem, all our applications, and network monitoring. It fits everything. We use it for monitoring and reporting on our ESX, Pure Storage, Cisco, F5, Palo Alto environments. We also use it for alerting, graphing, and capacity planning. We use it for everything.

We are using the latest version. We have LogicMonitor Collectors onsite in our data center, but the dashboard and everything else is all the cloud model. We use both AWS and Azure as our cloud providers.

It has improved our organization with its capacity planning. We have a performance environment that we use to benchmark our applications. We use it to say, "Okay, at a certain level of concurrency, we know where our application will fall over." Therefore, we are using LogicMonitor dashboards to tell us that we're good. Our platform can handle X number of clients concurrently hitting us at a time. That's how we use it to size our business, e.g., size our ESX environment and Internet pipes. 

Our capacity planning team consumes the data on the dashboards. The bread and butter of using the data in the dashboards is to inform, "Hey, what upgrades do we need to make in six months?" So, that data gets consumed regularly by other teams.

In the three and a half years that I've been using it, we haven't had false positives. I'm the primary network engineer, so I can say with confidence, "We have the environment tuned to the point where we don't get false positives."

Sparx Solutions is a managed service provider. We primarily use the LogicMonitor platform for monitoring, maintenance, and management of our managed services and customers' infrastructure. In terms of management, it is more around monitoring and alerting. That is essentially the core component that we use it for. However, there are other features integrated into the platform that we get value out of.

We have baked LogicMonitor into our core services, in terms of MSP and managed service offerings. We use this tool to fundamentally provide network monitoring services to our customers. It is definitely a great tool and something that we use daily.

We have multiple users using these solutions. They are technicians and engineers. Essentially, they use this platform for different purposes. So, a support resource will be able to use it to identify alarms and when there is a new ticket that needs to be created to remediate a problem. Engineers may use this platform to obtain valuable insight into the systems that they are working on, e.g., if they would like to understand whether a device has a really high CPU before they plan a change, etc. There are different use cases for using the platform. One of the main use cases is having users use the platform to provide support services.

We deploy probes, which are hosted by us. These connect back to the LogicMonitor platform in the cloud.

In terms of alerting, there is already a prebuilt alert threshold for a lot of the metrics. It is quite smart out-of-the-box. You may even identify issues which were not visible to you before by just introducing monitoring from the LogicMonitor platform. 

To a certain extent, there are mapping functionalities within the platform. A lot of these sorts of features, which are desired, come straight out-of-the-box. By being able to drop a Collector in the environment, you can quickly identify a lot of key information. Maybe some information, which you didn't previously have visibility to, becomes very visible. That sort of insight is very good information and allows us to be able to provide more value to our customers by having a better understanding out-of-the-box.

We use it for alarming on Cisco Voice systems, the Unified Communication stuff. We monitor all the gateways, trunks, SIP trunks, servers, and make sure all of the application is functioning, calls are being completed, and that there are no performance issues on the network or the voice system.

We used a different monitoring tool to do the Cisco Voice monitoring and our customers were very unhappy with us. It was missing stuff when monitoring, meaning it wasn't fully knowledgeable about checking all the OIDs and other things. It wasn't robust enough to allow us to customize it and build it out. Customers were getting very unhappy with that and they didn't like the dashboards, the graphs, and the reporting that came out of the other tool. When we moved over to LogicMonitor and we were able to show everything that we could actually deliver, a lot of our customers that were leaving came back to us or have provided us more services. We now have a proper tool that can deliver the services that we actually need, and that we've actually quoted and have contracts for.

The solution's ability to alert us if the cloud loses contact with on-prem collectors means we get alarms when a customer's collector isn't calling home anymore. That allows our engineers to know that there's some sort of serious outage. Either there's a power outage, the server crashed, or the internet's down. That's something that triggers our engineers to look at the customer and figure out why the monitoring solution is down. Is it the monitoring solution itself, is it the customer, or is it an act of God?

In addition, we had a lot of false positives before because we used a lot of VPN tunnels with other solutions. Moving to a SaaS solution and using LogicMonitor and the cloud has helped us a ton because it's improved reliability, SLAs, and uptimes. We've seen a 70 to 80 percent decrease in false-positive alarms.

Another benefit is that we went from three monitoring systems down to one. The first solution was Prognosis, which was developed by Integrated Research. The other tool was N-central, which is now provided by SolarWinds. We consolidated those two tools down into just LogicMonitor.

We've also been able to automate things such as cleaning up disk space or restarting a service. If the monitoring system catches a service not running, instead of initially sending off an alarm and creating a ticket, it's going to do some self-healing, to try to restart that service or run a script that cleans up some disk space. If that still doesn't fix the issue, it then passes the alarm on to create a ticket for a human to look at. 

That saves us time because, obviously, it doesn't disrupt an engineer and force him to try to log in to that customer and try to start the service or look at logs. It just says, "Hey, we restarted it. Everything's up and running," and there is no real impact to the company or business. It didn't take time for an engineer to look at it, respond to a ticket, and close the ticket. If a single service isn't running, that's about 15 minutes, at least, of an engineer's time. If an engineer doesn't have to do that three times a day, he's saving about an hour.

We use it for monitoring our customer networks, for monitoring network devices, and we also use it for monitoring our hosted environment.

We're a managed service provider. We have LogicMonitor deployed so that we not only have our devices input into the system, but we also manage a lot of resources for our clients in it. We have it set up so that they can only see their items in there, through a lot of access control. We have a local presence with the collectors, the polling stations, while the data resides in the cloud. Once we pull the data, it then shifts all the data up to the cloud for long-term storage. LogicMonitor is all SaaS-based, other than the local collectors.

Before LogicMonitor, we were using another tool, and deployment of that tool took a lot of time, effort, and energy from our team, and it was very customized. While the end-product could have been great, because everything is so customizable, the problem was that we couldn't get up and running very quickly. With LogicMonitor, we didn't lose any of that customized look and feel, but we were able to get up and running so much faster. We went from onboarding even simple networks over the course of weeks to down to about a week.

We're able to monitor most of the things that our customers worry or care about. That's mostly because of the flexibility of LogicMonitor. The beautiful part about this is that if something is not currently in the system at the moment, the support from LogicMonitor has meant that it gets ramped up pretty quickly.

For customers who have multiple monitoring platforms, it's definitely very easy to simplify and get to a situation where there is one place for monitoring everything. That's definitely been helpful for them.

LogicMonitor's collectors, along with its templated integrations and dashboards, enable us to automate our onboarding process and roll it out to new customers. We've learned how to make it our own, based on what LogicMonitor provides us. We've been able to make ourselves more efficient, absolutely. The faster we can get online and onboard customers, the faster we can get to the point of turning their service on. That means that we can go from a non-paying customer who has agreed to work with us, to a paying customer who's now fully onboarded. We then have them working through the specifics of a managed services solution, outside of the monitoring tool, which is very important for us.

The breadth of things it's able to monitor, the simplicity of the deployment, and how quickly we can get it up and running are the biggest factors when it comes to helping us win new business. Functionally, there are no aspects of LogicMonitor that hinder that ability. It has definitely helped our margins, as an MSP, especially on the monitoring side, because we can get up and running so quickly. It's an absolute must for us to have the tool.

Seeing how easy it is to manage devices, how simple it is to add, remove, or modify a device, and the amount of data that's included out-of-the-box whenever you add a device, makes it far superior to any product. There are no add-ons needed. You license a resource or a device and you don't have to worry about adding a plugin to get all the additional metrics and the full depth of device data. This just happened last week on a customer demonstration call with a customer that has experience with SolarWinds. The customer saw how easy it was to get up and running on LogicMonitor and they were immediately sold and said, "Okay, give me a quote." That's a real scenario in which this product helped us. It's those aspects that not only help us gain new customers, but also to retain customers.

Overall, LogicMonitor saves us time. It's hard to quantify how much now, given that we've been using it for as long as we have.

When I consider LogicMonitor for future-proofing our business, with the ability to monitor customers' future IT environments, I'm pretty comfortable with it. That's because anything that we have come to them to request—whether it be a new feature, or having input into the UX and UI designs—they've been very open and very responsive to. Their support has been very accommodating. When it comes to looking at what could potentially be coming down the road, or to being future-proofed, I feel pretty good, given my experience with the types of special requests I've brought to them.

We use it to make sure that proper tuning is done for the existing monitoring.

In addition, our university has a number of schools and each is a customer of the main IT organization that manages and provides support for all the colleges, like the law school, the business school, the medical school, the arts school, etc. The goal, and one of the main use cases that we were planning and thinking about, was to be able to onboard all the devices, all the applications, all the databases, as required by individual schools.

We also wanted them to be able to create their own dashboard, tweak it, manage it, delete from it, and add to it. 

It's deployed as a SaaS model. LogicMonitor is out in the cloud.

When we were using Nagios and we had alerts but there was only red, yellow, green. Here, the good thing is that you have escalation: level-one, two, three, which are clearly defined, and what action needs to be taken for each level. The clear escalation chain and tuning helps, because we don't want to wake up the director for 80 percent of the cases. That would be ridiculous. But when necessary, the right people should be alerted, especially for the production environment. If something has been "red" or there has been no interaction for half an hour, it's important to know that and to take the necessary actions.

That's a key thing, being a production-operations team member, because I don't want my team to be flooded with all the noise of alerts for something which can be tackled by a specific team. Having escalation chains, so that the alert goes to the right team to look into that and take action, means the prod-ops team doesn't need to even look into it. We don't even need to ticket it. We only keep aware of it through the daily alert dashboards. That has made a big difference in our overall resource planning, because previously we had 400 to 450 daily alerts. By using this feature we cut that down to 150 to 200 which are "candidate alerts" that production-operations needs to take action on. They may require creating a ticket, or calling the right people, or doing some activity that needs intervention or escalation to the next level. We have been able to cut down on our resources. We don't need to have four members actively looking into the dashboard. We can validate things with one or two employees.

LogicMonitor has also helped to consolidate the number of monitoring tools we need. We had some third-party monitoring, four or five things, and they're all consolidated with LogicMonitor. The only exception is IBM Tivoli Workload Scheduler. But what we did was we integrated that via Slack. I'm not really sure why we weren't able to consolidate TWS. The plan is to get rid of TWS, but we could not do so immediately, until there is an alternate route. But apart from that, everything has been consolidated using LogicMonitor.

We were especially able to consolidate third-party cloud monitoring for AWS. There were discussions about how we could also integrate or combine Azure monitoring resources through LogicMonitor. The team has mentioned that it has plug-ins that it can use to combine that. We also had separate backup scheduling software, a tool that had separate monitoring, and that has also been combined with LogicMonitor.

And LogicMonitor has absolutely reduced the number of false positives compared to how many we were getting with other monitoring platforms. At a minimum they have been reduced by 50 percent. The scope of more tuning and going through the learning curve helped to bring it down. Within the first two or three months, we were able to bring the false positives down by 50 percent. That's a big achievement. That is the main reason we initiated this project of getting into LogicMonitor. There have been further talks internally about how we can eliminate them further, and bring it down by 70 percent compared to the false positives we were getting. That's our goal. So far, it has reduced the time we used to spend on them by 50 percent, both offshore and onsite, as we have an offshore team in India that works 24/7. We used to have multiple people in each shift and we have reduced that down to a single person in each shift. That's a big step in the right direction.

We use it in a few different ways:

• For general monitoring of operating systems. 
• Leveraging some customized offerings, specifically for creating application monitoring. 
• Some external site-to-site monitoring in various places, ensuring that our websites and external pieces are available over an Internet connection. 

It has given us a clearer view into our environment because it's able to look in and pull things off of the event viewer or log files. We have been able build dashboards and drill down on things, which has helped improve our time to respond. Also, in the case of specific conditions being met in X log, we have been able to get in and take a look at that a lot faster rather than trying to connect and parse through the log and figure it out. It's able to flag that and work us towards a solution faster than normal.

We have a few custom data sources that we have defined, especially for our application. It is able to leverage a specific data source and build monitoring rather than just having it be a part of the general monitoring. It is segmented and customized for what we actually need, which has been pretty helpful.

Custom data sources have given us a bit more information from a point in time and historically viewpoint. In the console, it is easy to compare week-over-week or month-over-month traffic and numbers. As changes are made in the environment, we can look and have better historical knowledge, and say, "We started seeing this spike three months ago and this is the change we made," or, "We started seeing this CPU usage reduced after the last patch or software update." It lets us be able to compare and get a better insight into the environment over a longer period, rather than just at a point in time, when investigating an issue.

The solution has allowed us to have specific alerting for specific messages. If we know that X messages on a notification let us know this state has happened, we can then set that to be either an email notification or a tracking notification. In the cases of a log meaning that we have a specific issue, we can have it send an email and let us know. Thus, we have a better, faster response. We also have integrations with PagerDuty, which allows us to be able to make things very specific as to the level of intervention and the specific timing of that intervention. It has been nice to be able to customize that down to even a message type and timing metric.

The solution’s ability to alert us if the cloud loses contact with the on-prem collectors has been helpful to know. E.g., if we are having an issue with our Internet connection or some of our less monitored environments, such as our lower environments in different data centers where we don't have as heavy of monitoring. Therefore, it's helpful to have that external check there versus our production environments which are heavily monitored. Typically, we are intervening before it times out to say that it's lost the connection. It's been helpful to have that kind of information. This way, we know either via a page or email if there is any sort of latency or a timing issue with it connecting to the cloud. It's been helpful that it's not just a relying on the Internet connection at our site, but is able to see into our environment, then it monitors when there are connectivity or timeout issues.

We use it for anomaly detection because our software is designed to function in a specific way. Therefore, anomaly detection is helpful when there are issues that may not be breaking the software but when it is running in a nonstandard way, then we can be alerted and notified so we can jump on that issue. Whether the issue will be fixed it in the moment or handed off to development to find a solution, it's helpful to have that view into how it's running over the long-term.

It is a pretty robust solution. There are a lot of customizations that you can put in for what you want it to be checking, viewing, and alerting on. As we get alerting and realize that that's not something we need to be alerted on or it happens to be normal behavior, a lot of that information can be put back into the system, to say, "Alright, this may look like an anomaly, but it isn't." Therefore, we can customize it so it gets smarter as it goes on, and we're really only being notified for actual issues rather than suspected issues.

It's been helpful to be able to have some information to be able to pass along to development that's very specific as to what the issues are. E.g., we can see an anomaly during periods of time while this is running, then pass that along so development can figure out, "Is it a database issue, an application issue, or possibly a DNS level issue?" They also determine if there are further things that need to be dug into or if it is something that can just be fixed by a code change. 

The solution’s automated and agentless discovery, deployment, and configuration seems to work pretty well for standard pieces, like Windows servers and your standard hardware. It has been able to find and add those piece in. Normally, if I'm running into an issue with finding something, it's usually because it's missing a plugin or piece that just needs to be implemented, which just needs to be added in manually. However, 99 percent of the time, it finds things automatically without a problem.

If I summarize LogicMonitor, it is a single windowpane. You don't have to run four hardware stats and software stats on multiple screens during the monitoring of services. It gives you flexibility. It has the capability to pull up your data sources as well. So, it is like a single window, where you can see all your resources recorded, e.g., what value are you deriving out of your software?

We have our own product that we are specialized in. We needed something to help us with the setting up of the monitoring part.

Our customers are very happy. They are running Dell EMC hardware, so they don't need a Dell EMC monitoring window and our software windows. With LogicMonitor, they can see what is happening inside Dell EMC in a single, unified view that completely monitors their alerts.

We have some customers who are running a mix of Dell EMC, HPE, and Cisco hardware. We have our own software, as a service organization. We don't sell hardware. Whenever we reach out to our customers, we give LogicMonitor as a dashboard to them so they don't need to monitor the hardware side separately. For example, if my service is running on their hardware X, that means they don't need to monitor hardware X and our services too. LogicMonitor has the capability of monitoring their hardware as well as our services. This is how LogicMonitor helps us.

LogicMonitor has the ability to alert us if the cloud loses contact with on-prem collectors. We have more than 50 on-prem collectors, and there is the flexibility of putting an escalation chain to every collector. So, if a collector goes down, then whatever escalation mechanism is bound to that particular collector can fire. For example:

• If an email has been attached to that collector, that email will come. 
• If a call is attached, that call comes via mobile. 
• If an SMS is there, then that SMS comes via mobile. 
• Third-party external integrations over PagerDuty or any HTTP delivery also happen because they have the ability to send alerts through Slack as well.