Quest Foglight for Databases Reviews

We use it as a monitoring tool, which is what it's designed for. And we generally only scratch the surface of it. We use it for checking blocking and locking deadlocks, server activity, database activity, running baselines, et cetera. We don't constantly look at it; we only look at it if we've noticed a problem. It could be something that might be brought to our attention where a particular database might not be running as fast as it should. The first thing we jump into is fog Foglight to see if anything jumps out at us.

We have it running locally inside our server room and have three instances of it. Two of them are current, one of them is going to get updated next week.

One of the benefits we see from it is the fact that it already has an answer for us without us really having to ask around. I jump right to that baseline chart and I can show everybody that, between this time and that time, the databases were running as they should be. That way, we know we have to look at something outside of the database as being the issue.

Foglight definitely saves us time when it comes to root cause analysis. We have one senior DBA who will also run some code within SQL Server to double-check a few things, but for the most part he will jump right into Foglight and use that to try to pinpoint where the problem is. He will then take any code he finds in there and throw it into SQL Server to decipher things there.

One of the features that we find most valuable is the logging that it does, because it's very lightweight logging, and that is something we were looking for. We were looking for a software package that won't impact our servers while it monitors them. We capture the SQL statements that are going through the database, the users that are hitting it, and potentially any issues that might be coming up with those users using a particular line of code. It does capture the code that it's running and we might be able to take that and say, "Okay, this code is not efficient enough." We might need to rewrite it before we can put it back into production.

The real-time activity screens are also helpful. The first thing I look at is the baseline. That is my automatic go-to. If somebody is complaining that a database is running slowly, I'll present them with a screenshot of the chart showing that the database is running what I call "baseline normal," meaning it's within our minimum/maximum range of how the database should be running at that point in time during the day. That way, if there is something that is running slowly, we can eliminate the database as being an issue and perhaps look at the server, network activity, or something outside of the realm of the database as being the issue. One of the other DBAs who uses the software generally looks at the locking and deadlocks and at any code that jumps out at him that might not be running as efficiently as it should.

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.

We have been using Quest Foglight for Databases since November of 2016.

It's up about 99 percent of the time.

Generally, if it ever goes down, it's because of something that has happened on our side and nothing that Foglight created or caused. I'm very proud to say that if it goes down, it is rarely due to Foglight.

About two or three years ago, we did have an issue where the Foglight service was stopping by itself. I got a hold of tech support and they determined what the problem was. It was a setting somewhere and they were able to rectify that by making some changes to it. We haven't had that issue since.

If we were to venture outside of SQL Server and go to Oracle or any of the other products that Foglight supports, we would probably buy the cartridges that would interface with Foglight to run those as well. It's very scalable. We're very glad that we've already got our foot in the door with Quest and with Foglight, because we're familiar with it. We don't want to have to start over with somebody else.

It's used by our whole database team—that's 10 of us—but generally only three or four of us look at it. The main interface is good, but once you start drilling down, it can be very intimidating. We have about 300 developers, managers, and directors who all have access to it. Out of them, only about 25 percent of them use it. It can be a rather intimidating interface. It's not as user-friendly as it could be.

If I run into a question, I can email my liaison and she can usually get an answer to me within a couple of hours and, if not, by the end of the day. One of the things that stands out with their Premier Support is their speed, how fast they will get back to me on things.

I can't say enough good things about their tech support. They are always on top of things and that's why, every year when it comes up to renew it, it has never been a question. As soon as I have an issue, I put in a ticket number and, within 30 to 45 minutes if not less, I have a reply. And that is even for a low-priority issue.

They stay on top of everything. They are really good about making sure things are fixed. And even if something carries over to the next day or the next week, because I haven't had time to get it to it, they will email me every couple of days and ask, "How's everything going? Is the problem still there? Is there anything we can do to help?" They stay on top of absolutely everything.

The Premier Support has definitely been an influence in purchasing licenses from Quest. We have 147 licenses for Foglight and at this point we're only using about 112. But every year, when it comes time to renew those, the question is never, "Should we reduce the cost of our licenses?" because we will add more servers to this. The Premier Support drives that fact. We did have an issue where one of the servers was down and it wasn't because of Foglight. The server was just down. My directors said, "We need to get this thing back up. We need Foglight to help us determine what other problems are going on." I mentioned it to my liaison at Quest and she said, "I've got somebody ready to help you. If you need any help at all, they'll be happy to remote in and give you a hand."

We were an IDERA SQL Diagnostic Manager company for a number of years and everybody loved it because the interface was not scary, it wasn't intimidating. But the problem with IDERA was that they didn't have a web solution at the time. That's why we looked at Foglight. It already had a web solution and that's what we wanted.

When we decided to go with Foglight, a lot of people stopped using the diagnostics part because it was very intimidating. Even though I offered training and I created a lot of documents—because when we started with it in 2016, that kind of documentation didn't exist—a lot of the people came into Foglight "kicking and screaming." They still won't use it because they feel it's too intimidating. They will open something up and not know what to do. It's not very user-friendly. You have to click on a lot of stuff to find the information. I'm used to it and a number of our end-users are used to it. They know where to go for the information. But some of the people who used the Diagnostic Manager from IDERA still refuse to use Foglight to this day, because it's very intimidating.

The very first time I set it up as a demo, I had it set up in less than an hour. I was really impressed. I thought for sure it was going to be a task, but I was able to set it up within an hour for a test scenario, and that was key for us. When we actually purchased it, we had one of my server engineers set it up and I asked him how hard it was. He said, "I had one of the instances set up in about 45 minutes." For him it was also very easy.

Our implementation strategy, when we set this up initially in 2016, was to break it into three groups. We had an instance of Foglight for our production servers, we had an instance of Foglight for our development servers, and we had an instance of Foglight for our servers over in Leeds, in the United Kingdom. That way, we could use the federated Foglight to look at all of them, but we could also just look at the production stuff or the development setup, et cetera.

I wish I could give you a number, but it definitely does save us time. The logging it has saves us time because we can use the timeline and go back. We've had people say, "What happened 17 hours ago at this time?" We can use Foglight to go back and see what happened. It could have been that at nine o'clock the previous night there had been an issue they weren't aware of. We can use Foglight to go back and check that out. SQL Server doesn't keep those kinds of logs. Fortunately Foglight does. It has saved us more time than I can count.

The pricing has never been a question. We just renewed in November, for the fifth year in a row. It's never a question of whether we need to renew this or the Premiere Support.

When we first started looking at Foglight, we wanted to go to a web-based operation, so our end-users wouldn't have to install a program on their computers. We wanted a setup where all they had to do was log in to something. I found Foglight through a Google search, of course, and thought I would give it a try. As I said, within an hour, I had things set up and running, whereas with the IDERA Web Solution I was having all kinds of problems. IDERA's web solution was just coming out at that time, in 2016. We haven't looked back ever since. We have never questioned, "Should we go to another solution?"

We do wish the Foglight interface was less confusing, but with a few of us who know how to look at it, read it, and interpret the data, it's a good solution. We just wish more end-users would take advantage of it.

Don't be afraid of the interface, because you can't break anything. Click on absolutely anything and everything you can find. That's how I learned it. I took a good two or three weeks, once we did implement this. Anytime I could click on something, I was clicking on it just to see where it was going to take me. I would jot some notes down to tell me, "This took me here, that took me there." Don't be afraid to click on something.

If my mouse will click on it, then I'll click on it. If anything, it's going to give me some information that I might not have had before. And if it leads me down a dead end road, I just back out of it. In that situation it may be because it's information that is either over my head, or it's information that's not needed. But I'm not afraid to click on anything because Foglight is there to help me. It's like tapping somebody on the shoulder and saying, "Hey, what's going on in here?"

When you purchase it you will get a liaison. I would recommend touching base with them as often as you can. The forums for Quest have also come a long way since 2016. Back then, they were barely existent, but they've come a long way. Use the forums. Don't be afraid to ask questions. There's no such thing as a stupid question because if you're asking, then you know somebody else has asked it.

Sometimes we'll use Foglight to drill down and see what's causing an issue. If things are baseline normal for us and we've already eliminated the database as being an issue, then we have to look at the server team, the network team, and even web support to see if they are alright. We really don't use it to track server activity other than CPU usage, memory usage, and the like. When we drill down, even though we've eliminated the database as the source of the issue, we use Foglight because sometimes it will show that we're getting some CXPACKET issues, which tells us it might be a network issue. So we do look at some of the other aspects of it, after eliminating the database as the issue, to troubleshoot.

The solution also has the capability to monitor a variety of aspects, such as the OS, hybrid clouds, and hardware across different platforms, but we really don't use that because we have a server team that does so. It monitors the system utilization. Of course, we can see if there's a load somewhere or if memory is being excessively hit. If the disk is busy, we might look at that and tell the storage team that they might want to look at their disk drives. Is there a problem going on with the storage state? Or the server team might look at the servers and say, "Yeah, the servers are being excessively hit." It's a good catch-all, but we can only make suggestions with Foglight when it comes to anything outside of the databases. When it is inside of the databases, Foglight gives us a wealth of information that we can take to the table and say, "This is what we found to be the problem, and this is what we think should be the solution."

In terms of using it to proactively alert us to long-running queries, we're getting into that frame of mind. We have it available, but a lot of our developers have created their own little pieces of code that check things on their side, to alert them, and those are not necessarily run through Foglight. We do use the alarms a little bit for checking on our availability groups to see if a failover has happened because we may not be aware of it. We also have alerts set up for databases that might not be backed up recently. We use that almost daily. Overall, we don't use the alarm part of it as much as we should, but we're getting there.

We are using Foglight to monitor both SQL Server and Oracle Databases across the enterprise and across multiple directory domains.

Our Foglight installation is on-premises and on virtual servers.

In general, it helps us become more proactive rather than reactive. DBAs can go in and look at the different alarms and tweak thresholds. Obviously, if we wanted to be proactive, we would want to catch some of these issues while they are still in the warning or critical stage before they become fatal alarms. So, the biggest benefit to the organization is the fact that we can proactively monitor databases and prevent downtime. For example, this could be resource contention, where we could look at memory, CPU, or storage. If it is starting to creep up and show yellow or orange on the dashboard that means the DBA needs to either troubleshoot what could be grabbing all those resources or plan to extend some resources, before they run out.

When we use the solution for monitoring databases, it enables us to drill down and see what is causing an issue, e.g., if something doesn’t look right, especially if the DBA is seeing a pattern. If it is something that recurs a couple of times, then we would definitely leverage Foglight as well to drill down and take a look at activities. We also have the Performance Investigator in the environment, which I find to be handy because you can drill down into actual connections and look up which users are connected, which workstations are connected, and which servers are connected, then try to drill down on the problematic session/query. Sometimes, if we are troubleshooting performance, then we will need to drill down into the end user or the actual client machine where the connection is coming from. We have the ability to go back and adjust the timeline to drill down to a specific time window. That is where the Performance Investigator does a great job. This has saved us lots of time with root cause analysis. It could save anywhere from hours to days. If you are trying to track things down without these types of tools, then it becomes really challenging.

The ability to monitor multiple database platforms streamlines our database operations. The single pane of glass is what we were really after when we picked Foglight. We knew we wanted something that could monitor cross-platform because it does save a lot of time to use the same tool. The one thing that I like with Foglight is that we don't have to install anything locally, like agents, directly on the database servers. That was also a big seller because it simplifies things.

Right now, we leverage the infrastructure cartridges, which come with Foglight for Oracle and SQL, for OS monitoring. This is very important because we do have to monitor the storage CPU, memory, and network.

The main reason why we picked Foglight: We can have a single pane of glass for both SQL and Oracle across our entire environment, which has been very useful to us. The main use cases are for monitoring health of our databases and being able to assist with performance troubleshooting.

Foglight provides real-time activity screens. Typically, we go to the real-time dashboard when we are troubleshooting issues. If there is something going on, then a DBA needs to drill down more and try to pinpoint the activity currently going on that might be causing the issue.

We use the solution to display the most intensive database queries. This ties in with our performance troubleshooting. This is usually one of the first things we go and check if we are troubleshooting performance. So, if an end user calls us complaining that the database is slow, this is typically where we start.

We use Foglight's ability to proactively alert us to long-running queries. For example, something was causing us grief with one of our integration pieces. So, we needed a way to detect long-running queries.

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.

We have been using it for over three years. It will be four years in June.

It is stable. Over a span of four years, we have done cartridge updates and Foglight management-ware updates. We haven't encountered any major issues at all.

To maintain it, we just have one primary and one backup DBA.

We purchased the Auto Maintenance Cartridge, which was a good call because it helped alleviate a lot of the maintenance work. Prior to that, it did take the DBAs a bit of time to maintain it. However, with the Auto Maintenance Cartridge, it automated some of these tasks. This probably saves the DBAs a couple of hours a week.

Scalability is very good. You just need to make sure that your Foglight infrastructure is sized appropriately. That is where Quest Professional Services came in and gave us advice on what to watch out for, in terms of how many agents each management server can support.

One of the nice things with Foglight is that we were able to grant access outside of the DBA team, like our operations support team. For example, if they are troubleshooting an application issue, then they could quickly go into Foglight and check whether the database is up or down on the dashboard without having to call the DBAs. From that perspective, it has offloaded some of the calls to the DBAs.

SQL and Oracle are the two database platforms that we are supporting internally. From that perspective, we will continue leveraging Foglight. Even when we do start moving databases to the public cloud, it will be our first choice. We would try to evaluate and do a PoC of monitoring the cloud database with Foglight. As long as everything looks good, I don't see us deviating from the use of Foglight.

About a year or so in, we engaged professional services to integrate our Foglight with ServiceNow. So, we have automated incident ticket creation now with Foglight.

Quest Premier Support has been great. They are probably one of the best ones when compared to other vendors. They are very responsive. We have a great technical account manager as well. Anytime we have to log a support call, it gets dealt with and resolved very quickly.

Quest Premier Support has added value to our overall investment. Support definitely plays a role in the effectiveness of the product. When we do upgrades of our Foglight systems, or if we encounter issues, their support really becomes important. They resolve the issues quickly to minimize any gaps in our monitoring.

Before Foglight, we really didn't have any type of "enterprise database monitoring tool". What the DBAs had before was a bunch of scripts, which wasn't really a monitoring tool. It was just a bunch of scripts that ran, then emailed the DBAs the issues. On the Oracle side, we didn't have diagnostic and tuning packs at all before. So, it was really a big gap. Foglight was way more cost-effective.

The installation was straightforward; it wasn't too difficult. Understanding the thresholds tends to take a bit more work. The DBAs need to tweak the threshold when they set things up, so they don't get inundated with alarms. However, with any type of monitoring tool, you need to do that anyway.

The deployment took a couple of months. We had provisioned a bunch of virtual servers for this implementation, and we needed to monitor multiple directory domains.

When we did the initial deployment, we engaged Quest Professional Services to help us size out what we would need and architect the Foglight solution. We had to make sure we had the Foglight agents configured properly across the enterprise. However, once it was all set up and configured, the registering of databases for day-to-day use was all straightforward.

We only had two DBAs involved in the setup, one was more SQL-focused and the other was more Oracle-focused.

We have seen ROI. It was a good investment because now we have insight into the health and performance of our databases. Previously, there were a lot of unknowns and risks. Now, we can be proactive with our database health. In addition to that, we were able to get a lot more insights into how our databases are being used. We have also leveraged some of the custom dashboarding. We did a custom dashboard to monitor one of our data synchronization screens. This was handy because we just published that as part of the Foglight, as an additional dashboard.

We are currently licensed for Foglight for Oracle and SQL Server, along with LiteSpeed, which is their backup solution for SQL Server.

It is cost-effective. With our EA, it is really based on the scale of our database environment. We found the Quest team to be reasonable and flexible when it comes to pricing and scaling of licenses.

We did evaluate other options. It was very limited, probably about three or four vendors. As far as cross database platform monitoring tools goes, Foglight stood out. What we noticed with some of the other products is that they were either good at monitoring one platform only or didn’t go deep into database monitoring/troubleshooting. That was one differentiator. The other differentiator was the cost to be able to monitor enterprise-wide.

Foglight allows you to go in, modify, or create custom rules. As a user of Foglight, when you create rules and dashboards, it is important to document them. If you are not careful about coming up with proper naming standards and documentation for anything custom that you create on top of what comes out-of-the-box, then when you have staff turnover over time and you are trying to go back and understand how things were configured, it becomes challenging.

Each environment is different. Different companies have different use cases. Understand your requirements and your use case. That is the key prior to jumping into implementing any product.

I would rate this solution as a nine out of 10.

I used it when working for a client, in a situation where you takeover management of the systems.

Maintenance was not done properly for over two years before I came in. The solution crashed over the next year, then we migrated the client to another monitoring platform.

• Baselines
• Advisers
• Reoccurring events 
• Its reporting capabilities are immense.
• The deployment is good to work with.
• History capabilities

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)

No

Yes see other pieces I wrote regarding correctly size the backend DB Server for Foglight

Use to have very basic monitoring like PRTG, N-Able, Zabbix

No setup is awesome complicated (at least the old versions I used to work with)

in house

Have no idea

Red Gate would be the winner!

Red Gate SQLMONITOR

IDERA Diagnostig Manager

It will not fix nothing, you still have to be on expert level