Foglight does have a component that allows you to look at things in real time, but it's not as friendly or as efficient in terms of responsiveness as Quest Spotlight is. Foglight might be lacking in this department. It could be just the nature of the beast, it could be the fact that it's web-based, as opposed to Spotlight being a fat client running on C#. I use both tools in conjunction with each other; they are a part of the toolset. Foglight might not be as helpful. 

It's also possible that part of the issue is how Foglight is deployed. We always try to save on cost and because it requires a SQL license, you don't necessarily have the luxury of putting it on a super fast server. It could be related to that. But I have noticed that it's not as responsive for determining, in real time, what's going on.

The way I have understood things is that there was an attempt to merge Spotlight functionality with Foglight. They have somewhat done that, even though I still feel that they're not going to be able to completely kill Spotlight. That tool is done so well and it's really serving a purpose in terms of a real-time, very fast analysis of multiple metrics.

I don't like what they did with Foglight because it's an attempt to merge. It's like a sports car versus a heavy-duty truck. They are both fantastic, but when you try to jack up a truck to work fast, it doesn't work very well.

There have been times where the database guys have used Foglight to find the root cause and it has taken longer than anticipated. One type of feedback we have gotten from our DB guys, especially when it comes to root cause, is that Foglight can improve. There are tools on the market that actually show where the issue is happening. It could be a performance issue or it could be another issue that is causing the database to go down. What we have been told by our DB guys is that Foglight should improve when it comes to root cause analysis.

There are thousands of objects within the Foglight Management Server. At times what happens is that these objects consume a lot of resources and that causes the database, or Foglight itself, to go down. To then identify which object is consuming a lot of resources is really difficult. At times it's very cumbersome. It would help if they could ensure that the performance of their tool is improved. Maybe they can try to eliminate some of those thousands of objects and just keep the important ones that are really necessary.

Or if they can come up with a way to let customers know what objects are causing, or potentially cause, performance issues and then give an option to the customer to change the threshold on those objects, that would help. I'm stressing this point because there have been cases where Foglight has gone down and, because of that, all the database servers have been impacted. One of the reasons was that some of the host processes, and the objects related to the databases, were breaching the default threshold. It takes us some time to identify that and then change the threshold and work with the Quest team to bring the tool back up. Foglight should really work on that and come up with a handy solution.

One thing that I would like, and it's probably something that I could set up internally, is something other than a dashboard which I have to look at to know that a server is down. I'd like bells and whistles to go off. While the tool allows you to prioritize those, based on the severity of the server—if it's high-level production or low-level production—I'd like to know, by having something tell me, if I'm not in front of the screen, that I have a server down.

If I look at the dashboard I know there's a server down. But if I'm not looking at it, if I'm looking at some other problem, I want to know about it. You can do that, you can use SMSs and alerts to your phone, and I could set it up to handle that, but it would be nice if, out-of-the-box, Foglight did that.

Foglight does a lot out-of-the-box, but there are times when you need something that it doesn't come with; a custom solution. I would like the rule development code to be made available so we don't always have to be referred to professional services for custom solutions. For example, if we want to exclude certain databases from a particular rule, we shouldn't have to go to support and to professional services for that solution. If the code and syntax were available, we have resources that could quickly turn something like that around. 

But having said that, the help is there if we need it. It's just that it probably costs some money to do that.

The reporting is very confusing. It's not very intuitive. I've used it on occasion, but I've really struggled with getting the reporting to work correctly for me. It's too cumbersome and too busy. I don't like using this expression, but they should dumb it down a little bit because it can be very confusing without proper training.

I've also had a lot of people ask me about customizing some dashboards and I've worked on that on occasion, but again, that's more confusing than it is helpful, although I do have a couple I use myself. I had planned on having some classroom training on this aspect, before all the COVID stuff started. We'll probably end up doing that but, of course, we will have to do it via video conference. But customizing the dashboards is something that could be simplified a little bit. 

The alarms could also be a little bit less confusing. You would expect maybe two or three options in a dropdown but there are about 20 options. They give you a lot of information that is not pertinent to what I'm looking for.

If they can improve the reporting, custom dashboards, and the interface, this product would be an absolute solid 10.

I had never used Foglight before I got to this company, because I didn't have the time. I had other responsibilities besides just DBA work so I couldn't focus on what Foglight could give me. Having said that, there's still a lot of "noise." I get a lot of alerts that, while important, are not critical. Then I have to dig in and figure out how to turn alerts off, but not the logging. I want to be able to go back, once we get the other big issues out of the way, and start fine-tuning some of those other areas, but I don't necessarily want to receive an email for all of them. Over this past weekend I had 400 emails from Foglight. That's a lot. And at least 395 of them were white noise.

They need to make an interface where it's easier to turn the alerts off but not turn the alarm off. The other senior DBA on staff got frustrated with the alerts, so he just went and turned the alarm completely off. I said to him that while it won't alert us anymore, we'll also lose visibility into that aspect. It's something that we do want to be able to see at some point, just not right now.

The data model needs improvement when it comes to creating custom reports. That is an area where it needs a bit of improvement. Foglight gathers a lot of information around our databases as part of its monitoring. While I know all this information is in there, trying to pull the metric we want out for custom reports is sometimes hard to find. One nice thing about Foglight is that you can create custom dashboards, which you can easily convert to reports. We would be doing a lot more of that if it weren't for the challenging data model.

Some customers have issues with the way the data gets read and accumulated. They are expecting a different way of data monitoring. After explanation, they understand what exactly they are doing. Quest Foglight primarily focuses on database monitoring. Some customers question its capabilities for application performance monitoring, specifically for Java applications and duplicate detection. End-to-end user experience monitoring was once available but is also currently absent. Foglight provides deep insights for DBAs and infrastructure teams but lacks dedicated application capabilities and user experience monitoring. Foglight must be combined with other specialized tools for comprehensive end-to-end monitoring encompassing applications, networks, databases, operating systems, and infrastructure.

Performance: When holding data for two years for 20 SQL Servers, the reporting becomes sluggish and unresponsive.

Advise is to size the DB server behind Foglight correctly (which means very big)