Quest Foglight for Databases OverviewUNIXBusinessApplication

Quest Foglight for Databases is the #2 ranked solution in top Database Development and Management tools. PeerSpot users give Quest Foglight for Databases an average rating of 8.6 out of 10. Quest Foglight for Databases is most commonly compared to Quest Spotlight: Quest Foglight for Databases vs Quest Spotlight. Quest Foglight for Databases is popular among the large enterprise segment, accounting for 67% of users researching this solution on PeerSpot. The top industry researching this solution are professionals from a computer software company, accounting for 14% of all views.
Quest Foglight for Databases Buyer's Guide

Download the Quest Foglight for Databases Buyer's Guide including reviews and more. Updated: November 2022

What is Quest Foglight for Databases?

Foglight identifies and resolves performance issues across your applications, databases and virtual environments. The Foglight family of products easily integrates with your existing tools, so you can monitor and analyze data from almost any source across your infrastructure and view it through a single interface with our customizable, unified monitoring platform

Quest Foglight for Databases Customers

CommitDBA

Quest Foglight for Databases Video

Quest Foglight for Databases Pricing Advice

What users are saying about Quest Foglight for Databases pricing:
  • "This is like the "Cadillac" of performance monitoring software. It's not cheap... I am currently with a company that I was able to convince that the product is worth the cost."
  • "Compared to the other tools on the market, Foglight is okay in terms of pricing and licensing."
  • "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."
  • Quest Foglight for Databases Reviews

    Filter by:
    Filter Reviews
    Industry
    Loading...
    Filter Unavailable
    Company Size
    Loading...
    Filter Unavailable
    Job Level
    Loading...
    Filter Unavailable
    Rating
    Loading...
    Filter Unavailable
    Considered
    Loading...
    Filter Unavailable
    Order by:
    Loading...
    • Date
    • Highest Rating
    • Lowest Rating
    • Review Length
    Search:
    Showingreviews based on the current filters. Reset all filters
    Vadim Kulikov - PeerSpot reviewer
    Senior Engineer at a computer software company with 11-50 employees
    Real User
    Top 10
    Excels at displaying intensive database queries and enables me to address things before they become real problems
    Pros and Cons
    • "One of the hardest things to do in database management is to evaluate performance deviation across time. The adaptive baseline that Quest is using is by far the most helpful. That doesn't necessarily mean I use it on a daily basis, but it is something that I have not been able to find in any other tool, at the same level."
    • "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."

    What is our primary use case?

    A lot of things that Foglight does could be derived from DMVs and extended events. I'm going to sound like a salesperson, but I have to be a salesperson to sell the value of a product to my company. They need to understand that to answer some of the questions they ask, not having a tool like this will make my answers very speculative.

    As a DBA, you have to be able to answer three questions. The first is: What's happening right now? Why is the system slow or why are things not responding? That is probably the most trivial for an experienced DBA. That is where the tool's value might not be as obvious, as you can look at the sp_who or DMV and pretty much tell what's going on without having to pay money for a license for a product like Foglight.

    The second question is: What just happened? There could be just a couple of seconds difference between the first and second questions. But the effort to answer the second question is significantly higher because it is water under the bridge. You need some kind of monitoring solution implemented, even if it's just a basic solution where you capture a certain timeframe, so you can roll back and review what just happened. However, there will still be a significant amount of speculation because, usually, you can't afford to monitor every single metric, and there are hundreds of them. The issue could be the OS, it could be infrastructure-related, or it could be that the SQL code is not performing well because it's not written well. So the second question is significantly harder to answer, and that's where a tool like this will become very helpful.

    The third question is: What has been going on? That is by far the hardest question to answer without this type of tool. This is the type of question a manager might ask for the purposes of resource planning. Or a senior VP might say, "Hey, how are we doing? Can we bring on another customer? Can we sustain a 20 percent increase in workload?" I don't know how I would answer that question without having this type of solution. I work in the industry quite a bit and there is, unfortunately, a lot of misunderstanding due to a lack of a comprehensive view of infrastructure.

    There's no way to answer that question without getting some kind of baseline tool. Unfortunately, in most of the shops I work for, only one question is usually being answered relatively accurately, and that is "What is going on?" And it's a luxury because by the time a customer escalates an issue and it gets interpreted by support people, there's a gap. That gap could be a couple of minutes, a couple of hours, or a couple of days.

    How has it helped my organization?

    Ultimately, when you negotiate how many licenses you need, you always find the most problematic instances. You also have to also evaluate the culture and maturity of an organization. Unfortunately, there is often a lot of legacy code to maintain. It's not always easy to identify those things quickly.

    In that context, Foglight has been pretty spectacular in terms of the number of times I have been able to answer questions that nobody could answer before. I used the tool and showed my team how you use the tool to answer a lot of those questions, and some of those questions were pretty complex. We'll have deadlocks, we'll have locking conflicts, we will have blocking, and we'll have unexpected CPU spikes. Obviously, there is some complexity involved with the architecture and that is not always clear, but the tool is phenomenally helpful in enabling us to change and repair things.

    We have also been able to predict a problem. A lot of times you can see a particular process starting to misbehave. Visually, you can see the spike, and it is something that could potentially lead to a bigger problem because the process will not scale. It gives you an opportunity to address things before they become real problems.

    When it comes to displaying intensive database queries, Foglight is the best tool. Spotlight does not do that very well and Foglight is fantastic. It enables what they call a multidimensional analysis. You have a visual presentation of query resource utilization and you can slice it by the type of resource. You can also slice it by the number of executions.

    For example, a few times I've seen a server running very hot, the CPU would be 80-plus percent, and people are starting to freak out. But in reality, the box is very healthy. It has no locks or blocking. Rather, it's utilizing the CPU because that's what you want it to do. You always need to juxtapose multiple metrics simultaneously, and Foglight is really good for that. It has a dashboard where you can look at multiple parameters and components at the same time. If I see the CPU goes up and I also see the number of connections goes up and the number of batches per second goes up, to me it just means that SQL Server is working hard because we are processing fast and we are able to have more work done in a particular time frame.

    A lot of times, when you do have problems, you actually see the CPU go down. People say, "Well, what's the problem?" The problem is that you have some internal blocking or locking, or some kind of resource contention, and the CPU cannot process as many batches per second.

    When it comes to identifying the least performant queries, or queries that are performant but that are just very hyper with a lot of calls to them, that is where the tool really shines. It allows you to identify those things quickly.

    What is most valuable?

    Thinking about my favorite feature in Foglight is like thinking about my favorite food. One of the hardest things to do in database management is to evaluate performance deviation across time. The adaptive baseline that Quest is using is by far the most helpful. That doesn't necessarily mean I use it on a daily basis, but it is something that I have not been able to find in any other tool, at the same level. Microsoft and Query Store do provide performance monitoring. There are a lot of legacy, built-in, free-of-charge tools that do part of the job, but not as comprehensively. Foglight's adaptive baseline monitoring and measuring of deviation is one of the best features of the solution.

    What needs improvement?

    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.

    Buyer's Guide
    Quest Foglight for Databases
    November 2022
    Learn what your peers think about Quest Foglight for Databases. Get advice and tips from experienced pros sharing their opinions. Updated: November 2022.
    656,474 professionals have used our research since 2012.

    For how long have I used the solution?

    I've been using Quest Foglight for Databases since 2010, approximately.

    What do I think about the scalability of the solution?

    Our company is growing. It has almost doubled in size over the past few years. We do get more servers now and we are considering upgrading to the enterprise model.

    How are customer service and support?

    I had some issues with support. It's possible that they were because I wasn't able to respond to some of their requests.

    How would you rate customer service and support?

    Neutral

    Which solution did I use previously and why did I switch?

    There was a prior version of the product called PASS, Performance Analysis for SQL Server. While Foglight is an eight out of 10, that product would be a nine. From what I understand, they had to change the architecture of the product because the previous implementation was very difficult to maintain. They had a completely different architecture with a memory-resident client that was scrubbing memory up to 50 times per second. That meant the tool was much more responsive and provided a lot of active information, but because of the need for internal information every time Microsoft changed its product, which now happens a lot, they had to have a team of experts to constantly work with Microsoft to modify the agent that was in memory, and it became very difficult. 

    They had to move on to a different architecture, and that is the architecture we're discussing today, which is not as responsive. And while it retained a lot of functionality and added some, it lost the feel that the previous one had. 

    I still rate Foglight pretty high because I can't think of any other tool that goes above five or six out of 10.

    What's my experience with pricing, setup cost, and licensing?

    This is like the "Cadillac" of performance monitoring software. It's not cheap. I work for different companies and some were not able to afford it, so I can't say that I have consistently used it for over the last 10 years. But I have used it at different places and I am currently with a company that I was able to convince that the product is worth the cost.

    Which other solutions did I evaluate?

    I have had a look at other tools including Redgate SQL Toolbelt and Idera. They are monitoring solutions and they each have something that I like very much, but none of them came close to the comprehensiveness of Foglight. It's a very mature product and has been around for a very long time. 

    I am a little bit biased and I told my team, "Look guys, I have used a lot of tools but I like this the best. I'm very biased because I have used Quest tools so much. I am very proficient with them, so you need to check me on this." We had multiple meetings and presentations and there was agreement that Foglight, while being the most expensive tool, was the most comprehensive. The value was there.

    There are tools out there these days to build something like Foglight on a budget. But if you go that route, what you don't have is a team of engineers who are subject matter experts who are working directly with the database vendor so that they're ahead of all the new features. When new features come out, if you have a "homemade" system, you have to stop what you're doing and concentrate on improving your solution.

    I go to presentations often and there are some brilliant DBAs who have built their own dashboards, and I'm very impressed. These guys are unbelievable. But if I ask them, "So how much time does it take you to maintain it?" they usually won't tell me. A lot of the time, they don't maintain it because they build it for what they think they need. But eventually, if you stop maintaining a product, it becomes less accurate.

    You have to evaluate your labor and how much time you're spending on maintaining a product as opposed to providing value for your company. If a product like Foglight is updated and functions well, it's kind of cliche, but it's like having a full-time DBA on staff for which you're only paying the cost of a license. The couple of hundred dollars for a license is basically a DBA that you have hired because you don't have to do those things. The tool does them for you.

    It's not even the time involved, it's also a matter of staying focused on something. You can only juggle so many balls. If you constantly have to concentrate on tinkering with performance monitoring, you're not spending as much time developing your solutions.

    What other advice do I have?

    If I get a ticket that says, "We had an outage a couple of hours ago," I'm lucky. Most of the time a ticket will say, "Let's evaluate this outage we had a month ago." Even with a tool like Foglight, that becomes significantly more difficult. The tools are very granular but the farther in time you go, the less granular they become. That's just common sense to save on storage. Once you lose the granularity, some of the intermittent issues might be lost.

    That is why I always tell folks that if something happens or they're suspicious of something, "Before you file a formal request give me a heads-up on it right away." If I look at it quickly, I might be able to pinpoint the exact root cause. If we wait for the formal workload to escalate to me, the answer could be much less accurate. A lot of times it requires a lot of domain knowledge to be able to ascertain if it's related to the infrastructure, the syntax, or both, or just some weird thing that we usually attribute to hiccups with the cloud.

    There's a companion product called Quest Spotlight that has some functionality in common with Foglight. But I'm glad that they will never really collapse into one. I believe this has been their strategy for at least for the past five years. Spotlight is something that I have used longer than Foglight because it's a cheaper tool. I wouldn't say less sophisticated, but it's targeting less senior people. In other words, it's very easy to navigate and could be used by executives and people who are not necessarily IT-savvy. Whereas Foglight is a lot more in-depth and requires significant expertise to derive the information you're looking for.

    I often find that an initial estimate about the root cause is wrong. You're not working with a static environment, especially if you have mixed workloads such as online transaction processing with a lot of in and out, as well as decision support systems where you have a long query reporting. They're not easily separable these days. People just assume a database is supposed to do both. While it does do both, it's hard to fine-tune it for both. One is a race car and the other is a truck. How do you make a race car haul a lot of loads and how do you make a truck super nimble and fast? So you're constantly adjusting things.

    Sometimes I have to go back and look at the baseline. The answer might be that it's Tuesday, and on Tuesday we usually have a bigger workload. Sometimes the answer is that nothing is going on, it's just the nature of the best.

    I have to be able to separate the tool's capabilities from the inconsistency in performance due to the fact that a lot of stuff is going on and things are not always consistent. It's not always easy to pinpoint what is really causing an issue, but Foglight certainly helps to identify actual resource contention.

    The solution helps in both ways because you're able to look at the baseline and see that on Tuesday this spike is acceptable. But you can also look at what it is about Tuesday that is causing us to run so much slower.

    I've been hearing for the past 10 years that my job is obsolete and that AI is going to take over. At first, I was nervous about that. Now, I'm just laughing because, with every year and more functionality, it is becoming much harder to make tuning decisions. SQL Server claims to have auto tuning but it's very limited in scope. Any experienced engineer will tell you that when SQL Server comes up with any kind of advisories or any kind of suggestions on the index build, you have to take it with a grain of salt because its view is very limited. There are a tremendous number of dimensions you need to be able to evaluate. I feel we're still far away from a self-healing, self-tuning system.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Flag as inappropriate
    PeerSpot user
    John Waclawski - PeerSpot reviewer
    Database Administrator at AmTrust Financial Services, Inc.
    Real User
    Top 5
    Helps us eliminate the database as the source of an issue and saves us time in finding root cause
    Pros and Cons
    • "The real-time activity screens are also helpful... 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."
    • "When we decided to go with Foglight, a lot of people stopped using the diagnostics part because it was very intimidating... 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."

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?

    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.

    For how long have I used the solution?

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

    What do I think about the stability of the solution?

    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.

    What do I think about the scalability of the solution?

    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.

    How are customer service and technical support?

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

    Which solution did I use previously and why did I switch?

    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.

    How was the initial setup?

    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.

    What was our ROI?

    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.

    What's my experience with pricing, setup cost, and licensing?

    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.

    Which other solutions did I evaluate?

    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.

    What other advice do I have?

    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.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    PeerSpot user
    Buyer's Guide
    Quest Foglight for Databases
    November 2022
    Learn what your peers think about Quest Foglight for Databases. Get advice and tips from experienced pros sharing their opinions. Updated: November 2022.
    656,474 professionals have used our research since 2012.
    Vinothsingh Elumalai - PeerSpot reviewer
    Lead Software Engineer at Lowe's Companies
    Real User
    Top 5
    Really helpful for assessing database performance, but we have had issues with the stability
    Pros and Cons
    • "We can visualize all the different types of DB servers that we are monitoring in a single pane of glass. It uses a 360-degree overview of the database, for each of those databases that we are monitoring. That includes what kind of resource utilization is happening and what kind of DB parameters are getting monitored, as well as the different types of DB parameters that are being offered for each database type."
    • "The system is not that stable. We have been facing a lot of issues. We built a new store environment of Foglight, an environment for monitoring the Lowe's store servers, which are all Db2 servers. The objective is to monitor 800 Db2 servers in each Foglight instance. Up to 150 Db2 servers, the environment was working fine. The moment it crossed 150 or 160, we started having a lot of stability issues."

    What is our primary use case?

    We are using version 5.9.5 as well as 5.9.7. Ours is a huge database infra so we are using two different environments to monitor our corporate and store servers.

    We have thousands of DB servers that have to be monitored across our environment, which includes Lowe's stores across the U.S. We support the infra and the monitoring for all the stores and the store-related applications, as well as the servers which support those applications. With the DB servers being an integral part of all those applications, we thought we should have a separate monitoring tool just to monitor them.

    Foglight ensures that we have a dedicated monitoring tool to monitor all our store and corporate DB servers.

    How has it helped my organization?

    There is something called SQL PI which Foglight offers, although it is only used for Oracle and SQL servers at this point in time. But that feature is really helpful for us in terms of assessing the performance of a database, or to see what kind of consumption is happening which could cause performance issues in a database. To an extent, Foglight is helping us to find the root cause. From a very high-level overview, across the whole Lowe's organization, if you ask me what kind of SQL query is taking a very long time to run and that might trigger a performance issue, we are able to access that from Foglight. In terms of metrics, we look at the tablespace data, the database space, the log space, as well as the availability rates of the databases, up or down, and how often downtime is occurring. These are some of the critical metrics which help us to measure the performance and increase the performance of the databases if required.

    We have more than seven different types of platforms in Foglight. The fact that it enables us to monitor multiple platforms is a really cool feature. It gives us a single pane of glass to look at all the different types of databases in one place. That helps our database teams. We are the monitoring team that provides the monitoring solutions for our customers who are the different types of DB guys or DB teams. We are monitoring Oracle, SQL, MongoDB, Db2, Sybase, and Cassandra databases. Foglight gives all these DB teams a single tool to log into and look at the databases. They can see the performance of a database at any point in time, or they can take a look at the alerts for their databases. While the teams don't use it proactively to see if there are any long-running queries, they can always pull a report for the past month or so and see what kinds of queries are taking a very long time. That can help the database guys to ensure that the SQL query performance is improved. It also has a feature, out-of-the-box, to display long-running queries, which is really helpful.

    What is most valuable?

    It's important that Foglight supports different databases, starting with Oracle and including SQL, MySQL, Apache Cassandra, Db2, and MongoDB.

    Another good thing about Foglight is that we can visualize all the different types of DB servers that we are monitoring in a single pane of glass. It uses a 360-degree overview of the database, for each of those databases that we are monitoring. That includes what kind of resource utilization is happening and what kind of DB parameters are getting monitored, as well as the different types of DB parameters that are being offered for each database type.

    The UI is pretty simple. You don't need to write any custom scripts, the kind that are used in open source tools. You need to ensure that the DB servers that you're going to add have the necessary DB permissions, and the DB users, for the DB server to connect to Foglight. Once you have that, no matter what type of database, it's just a matter of clicking to add a database that you want to monitor. From the UI perspective, Foglight is good. They can improve it a bit here and there, but overall it's an okay UI.

    What needs improvement?

    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.

    For how long have I used the solution?

    I have been using Quest Foglight for Databases for one and half years.

    What do I think about the stability of the solution?

    The system is not that stable. We have been facing a lot of issues. We built a new store environment of Foglight, an environment for monitoring the Lowe's store servers, which are all Db2 servers. The objective is to monitor 800 Db2 servers in each Foglight instance. Up to 150 Db2 servers, the environment was working fine. The moment it crossed 150 or 160, we started having a lot of stability issues. The Agent Manager was restarting frequently, like every five minutes. Because of that a lot of alerts were generated. We have been working with Quest since last week but no resolution has been found.

    When it comes to stability, they really need to work on that and then find a way to handle a larger number of databases, regardless of the platform. They need to find a way to handle more load on the Foglight Management Servers and the Agent Managers.

    What do I think about the scalability of the solution?

    When we initially procured Foglight, the intention was to monitor only our corporate DB servers, of which there are around 500 to 600, including both production and QA environments.

    We have now set up another six new Foglight environments to monitor our store DB servers. There are 1,800 Lowe's stores and each store has 2 DBs. So altogether we are trying to monitor 3,600 DB servers, which is a huge infra. I have heard Quest saying that they have not seen such a huge infra where any of their customers is monitoring thousands of DB servers.

    The usage is really increasing and we have not even added one-sixth of the servers that we are planning to monitor. But we are facing stability issues already. I'm really worried about what will happen if we start adding more servers than those I just talked about.

    How are customer service and technical support?

    When we started with Foglight at Lowe's, it was a new tool for us. We didn't have any background in using the tool. The support guys were really helpful in setting up the environment for us, and whatever issues we were facing at those earlier stages, and even today, we got—and are getting—correct support from Quest.

    Although there are times where it takes longer than expected to resolve an issue, at the end of the day they try to find out the root cause and ensure that correct solutions are provided.

    If it's a Sev 2 issue, they try to resolve it within a day. We have a dedicated support person from Quest who is supporting us on a daily basis. That means we can go through the pending issues everyday, for an hour or so, and ensure that the support is given on time, right then and there. 

    But we have been having an issue since last week and we have been working together with the person, but the issue has not been resolved yet. At times there are cases where the first-line support should go back to their R&D team and come up with a solution. That's what is happening in this particular case. On average, it doesn't take them more than a day to resolve an issue, but in extreme cases like this, it is taking more than a week to come up with the proper solution.

    Which solution did I use previously and why did I switch?

    Prior to Foglight, we used an open source monitoring tool called Nagios. We used that to monitor both our infra and databases. Because it was an open source tool, we needed to write a lot of custom scripts. Foglight offers a lot of out-of-the-box, database-related metrics, which the DB teams here are looking for. Foglight has helped us avoid a lot of the time needed to create custom scripts, compared to when we were using Nagios.

    Ultimately we switched because we're monitoring thousands of servers. Since Nagios is an open source tool, there is a limit on the number of servers that you can monitor in a single instance. We had close to 50 Nagios instances, which were monitoring all our infra servers, including database monitoring. We wanted to have a single pane of glass to view all our database servers. We wanted one tool to monitor just the DB servers. That's the whole point of having Foglight in place.

    How was the initial setup?

    It took us some time to get accustomed to Foglight installations. The very first time, we had help from Quest support. After a couple of installations, it was okay. But I'm sure that they could make the installation process much simpler. The total installation process shouldn't take more than an hour, with all the configurations set up. They need to bring that time down to something like that.

    Prior to installation, there are a lot of prerequisites that the customer needs to take care of. For example, building a new machine to be a Foglight Management Server or the Agent Manager, as well as the database server. You need to work with the architects to build the architecture based on the number of servers or the type of monitoring that you're going to do.

    In terms of the architecture, Foglight has a Management Server which is connected to the Agent Manager and the database. The DB agents are installed on the Agent Manager which communicates with the FMS and the data is sent to the database. Since ours is a huge infra, we needed to build a lot of machines to start with. To set up our corporate environment, we had to procure more than 10 or 12 different types of servers.

    What happens is that since Foglight supports multiple databases, each Agent Manager has a restriction on monitoring in terms of the number of DB servers. Let's take Db2 servers as an example. If you are planning to monitor more than 800 Db2 servers, you need to have an Agent Manager with a lot of resources. When I say a lot of resources, that means you should have an eight-core CPU, 48 GBs of RAM, and 100 GB storage, minimum.

    These are requirements that not every organization can handle. Foglight has to find a way to reduce these resource dependencies. That is something they need to work on.

    We have three people who look after the maintenance and the operations side of Foglight. We have a senior software engineer, a software engineer, and me, as lead engineer, who look after all the rules and tasks. Sometimes Foglight causes a headwind against us, meaning you need to do regular patching. And if you're adding more servers you need to again work with the vendor. There are a lot of issues in terms of maintaining Foglight. It's really painful. We have about 200 users of the solution, who are all database admins for the different DB platforms. Occasionally, application teams use it as well.

    What about the implementation team?

    We did reach out to PSO which is a third-party vendor for Quest, to integrate Foglight with our event management tool. Every time when we want to create customized rules, we also need to reach out to them.

    That is really painful. I have to pay for custom rules that our DB guys are looking for. I cannot create them on my own because there are a lot of attributes and variables that you need to be aware of, from the application, when creating a custom rule. PSO is the only vendor that can do that. That causes a delay.

    What was our ROI?

    We still have a couple of more years before our license expires. Hopefully, starting next year, we will see benefit, in terms of ROI, from using Foglight.

    What's my experience with pricing, setup cost, and licensing?

    As far as I know, compared to the other tools on the market, Foglight is okay in terms of pricing and licensing.

    Apart from the enterprise license we have, there is the cost of the third-party integration that we talked about. If you need to integrate, you need to procure an additional license from PSO. 

    If you want to set up, say, five new Foglight instances, and you want to integrate all five of them through the third-party, for each of those instances you need to procure an additional license, which would start around $1,000 each. That's something I have talked about with the vendor, something which they should work on. Maybe they could include all those integration licenses as a package.

    What other advice do I have?

    We have had a lot of stability issues since we brought in Foglight to Lowe's. From the stability standpoint, Foglight really has to work and improve.

    I know that Foglight is capable of monitoring OS parameters as well as cloud DB instances, but we're not really using those features. We're just using Foglight to monitor the DB infra, purely from the database metric standpoint.

    The time it saves us when it comes to a root cause analysis differs from case to case. There are instances where the metrics that we are monitoring on the DB servers have really helped us to narrow down the root cause. For example, it could be an ORA-600 error which is causing our Oracle database server to have a performance issue. If that's the case, Foglight raises an alert and sends an email to the DB team. As a result, they may disable that particular alert or look into the alert. They may end up opening a case with Oracle.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    PeerSpot user
    Pini Dibask - PeerSpot reviewer
    Pini DibaskProduct Manager, Performance Monitoring at Quest Software
    Real User

    Hello Vinothsingh,


    Thank you for your thorough review. We appreciate your valuable feedback.


    It's important that customers will follow our sizing requirements in order to ensure best stability and performance of the Foglight application. We had an issue with the DB2 sizing not being crystal clear, and we fixed that as part of the recent 5.9.7.20 release documentation (which was GA on December 28th, 2020).


    We are always looking to improve ourselves and I'm glad that based on your feedback we've improved our documentation for DB2 sizing.


    Foglight’s stability and overall product usability is our #1 priority. We've invested significant efforts in this area. For example, we recently announced our new Performance Investigator (PI) repository for increased stability and performance (you can read more about it here : https://www.quest.com/community/blogs/b/database-management/posts/announcing-foglight-s-new-performance-investigator-pi-repository).


    We will continue to focus on addressing the market and our customers needs and at the same time ensure awesome user experience for our customers.


    I am also than happy to further discuss over the phone, if you are interested.


    Thanks again for your feedback.


    Pini Dibask,


    Foglight Product Manager

    Anthony Nicoletti - PeerSpot reviewer
    Database Administrator, Information Technology at a healthcare company with 1,001-5,000 employees
    Real User
    Top 5
    Tells me, from the ground up, what's going on and when, and enables me to do much more than I could otherwise
    Pros and Cons
    • "Foglight's Change Tracking capabilities are another huge feature. It is wonderful to be able to do that. People don't realize the amount of information that Foglight gathers from a given server or instance. It gets down to the version of SQL, the disk array, everything that's there. Any change that's made, any upgrade to SQL, shows up on the dashboard almost immediately. You don't know how much time you save just having a tool in your back pocket that does that for you."
    • "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... 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."

    What is our primary use case?

    We use it to monitor about 500 instances, 500 servers, and it keeps up with everything. I monitor Foglight. I wake up in the morning and it's the first thing I look at, because I can depend on it.

    We have it on VMs in-house and it performs very well.

    How has it helped my organization?

    The solution has nothing to do with how the organization functions. It has a lot to do with how I do my job, and how I can help the organization stay on top of things. I need to know, from the ground up, what's going on and when it is happening. The tool allows me to know that. I don't know that the company realizes the value of it. Of course they do, because they're paying for it, but the DBA team, for sure, knows the value of it.

    It allows me to do more than I could otherwise. The tool does your job for you in a lot of ways. If I had to collect all that information myself about 500 different instances, I'd need a year to do it. It does that every day. Now, I'm free to fight those fights and still have time to do the upgrades and do the other things, the fun stuff, including building stuff, instead of just troubleshooting all the time. It brings with it a growth factor too, for any DBA that wants to show their value. Just watching a monitored screen is not going to provide much value, in the eyes of the bosses. But when you can do that and do upgrades and other stuff in a week, then you start to show value. It provides you time to do everything else because it does so much.

    We also get emails from Foglight every day about long running queries, long running jobs, and broken jobs. Again, it's really doing my job for me. I just have to respond to it. It tells me what I need to do and I do it.

    We can also drill down and do root cause analysis for most things. That's a huge benefit of the tool. We mostly have Windows boxes. Between the drill-down for root cause and Event Viewer, you can decipher what the root cause of anything was, or just prove what it was. The same information comes out of Foglight that would come out of Event Viewer. It saves us tons of time. I couldn't do all of my job in one week if I didn't have the tool. The company would probably have to hire another person if we didn't have it.

    What is most valuable?

    We created a dashboard called "Morning Coffee," and when I'm having my coffee in the morning, everything that has happened, good or bad, shows up on that dashboard. That's my favorite, because that's where I make my money. That's where I show my value to the company, because when things start to tilt in the wrong direction, I know it. To me, that's huge. You could talk about the emails that come out that tell you the server is down—any application can do that. But to collectively have information for all 500 instances, at my fingertips, is huge.

    That dashboard is custom made. The gentleman I work with, Brant, actually created the dashboard. He has a section for failed jobs. He has a section for failed backups. He has a section for servers down, which hopefully is never populated. Everything you'd want to know about anything that happened while you were sleeping is there, and it's actually there for however long is necessary. It could be 24 hours. It could be two weeks.

    Also, it never seems to fail on the alerts. The alerts are solid.

    Foglight's Change Tracking capabilities are another huge feature. It is wonderful to be able to do that. People don't realize the amount of information that Foglight gathers from a given server or instance. It gets down to the version of SQL, the disk array, everything that's there. Any change that's made, any upgrade to SQL, shows up on the dashboard almost immediately. You don't know how much time you save just having a tool in your back pocket that does that for you.

    The solution also provides real-time activity screens. You can drill down into real-time for

    • CPU
    • memory
    • disk space
    • sessions
    • activity
    • transactions. 

    Anything you want to see is there, and there's a drill-down for each server that shows you that information. It's a separate page that comes up, and shows you, like a dashboard does, everything at once. Then you can drill down further into anything there that might show a problem or a problem that is about to happen. That drill-down feature and the ability to see everything that's going on, on the server, is a really nice feature. It's great because you want a screen to show you stuff before the end-user screams, and this feature allows you to know that information. With it, I know when things are going awry before the end-user does, and you can't ask for more out of a tool.

    It also enables us to monitor multiple database platforms. We monitor, in-house, something like eight versions of SQL, most of which are on different OSs, different servers, different hardware. We're not doing Oracle yet.

    The Performance Investigator feature in this tool is really good. We only use it for production, but it drills down to the narrowest bit. If you were to log in to my system, I could tell you, the next day, when you logged in. If the SA account logged in three months ago, I can tell you that. The SQL PI is really a huge feature in the tool.

    What needs improvement?

    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.

    For how long have I used the solution?

    I have been using Quest Foglight for Databases solidly for two years. Prior to that, I used it off and on for another two to three years.

    What do I think about the stability of the solution?

    The stability has been awesome. In the last six months we've had one slowdown, and it was easily resolved. We rebooted the environment and it went away. That's one hitch in two years.

    What do I think about the scalability of the solution?

    It does a much better job, when it comes to scalability, than Grid Control. We've got 500 instances, just SQL, on there. That's huge. I can see that it would handle another 500.

    How are customer service and technical support?

    Their technical support is great. They are super-fabulous. You open up a ticket and someone always gets back to you either by email or on a phone call. They're really good. I'm an Oracle guy, and I used Oracle support forever, and it's tremendous what Quest does as far as support goes. It's their standard support and it's wonderful.

    How was the initial setup?

    I wasn't here for the brand-new implementation. They've been using it for longer than I've been here, but I've been adding to the environment as we go along.

    When you introduce a new target, a new server into Foglight, that is really straightforward. They make it so simple to do and it does all the work. You say, "This is what I want. This is the name," and it goes after it, and it installs agents everywhere they need to be on the OS to launch the database. It's a two- or three-minute process, if that. That part is wonderful.

    For maintenance, for our environment, we need two DBAs: one full-time, and one helper. That's how we have it now. Brant and I handle the environment. He's the lead, and I'm his backup, but I'm there every step of the way. The two of us use it 100 percent every day. We have six or seven users of the solution and, if you include management, there are probably 12, as we have that many accounts in the tool. All of the users are DBAs.

    What was our ROI?

    If you don't have this tool, you need at least another body. If you think of the going rate for a DBA, and at least one or even two of them, annually, that is ROI. 

    In addition, you're not going to get the work done, work that the tool does for you, before you even wake up in the morning. It really is immeasurable. If you've never had Foglight, you don't know. But if you used to work without it, once you've used it, I'm not sure you'd want to do your job without it anymore.

    Aside from the alerts, the emails you get in the morning, and the alarms that go off, it's the collection of data that is valuable. You can go back to any time you want, pull a report out and hand it to somebody and say, "This is what this CPU looked like for the last year and half, and we need help with it." If I had to go collect that information, it would be totally impossible. I don't know how many people you'd need to do that.

    Which other solutions did I evaluate?

    I'm an Oracle guy and I've used Oracle's Grid Control, which is similar to Foglight. Foglight offers so much more. I was an instructor and I actually taught Grid Control. While Grid Control is good, I'm not sure it's as stable or as powerful, but it's good. It does the same type of thing. It handles a server with any of the databases on there. 

    One thing that Grid Control does, and I'm not sure if Foglight does this—and it would be a nice-to-have—is that it enables me to pick out two or three servers in my environment and do a comparison among them. 

    If Foglight had that, that would be really nice for a multitude of reasons, one being licensing. Thinking it through, there are a whole bunch of applications for that kind of capability. For example, if you're planning an upgrade across the board, what are you upgrading, and why? If you could pull that information out of Foglight easily, that would be great. I can create a report and get the same information, but my point is that, in Grid Control, there was a standard page that allowed me to do a comparison within the application.

    What other advice do I have?

    The biggest thing I've learned from using it is the reduction in effort that is required to do my job. Don't tell my boss that.

    My advice is "buy it." You won't know until you use it. I've been a DBA for 22 years and it really is an awesome tool.

    We use Foglight to display the most intensive database queries, but it's on a per-server, per-instance basis. We haven't created a dashboard for that, although we probably should. I can drill down into a server and I can tell you, from top to bottom, which queries are the most expensive. It could help us to improve query efficiency but we don't use it that way. We have vendor-supported applications and they're responsible for that. So that's not our focal point.

    Overall, it really is a good tool. I think it's the best on the market.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    PeerSpot user
    Manager of Database Services at a energy/utilities company with 1,001-5,000 employees
    Real User
    Top 20
    Enables us to drill down and see what is causing an issue
    Pros and Cons
    • "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."
    • "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."

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    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.

    What needs improvement?

    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.

    For how long have I used the solution?

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

    What do I think about the stability of the solution?

    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.

    What do I think about the scalability of the solution?

    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.

    How are customer service and technical support?

    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.

    Which solution did I use previously and why did I switch?

    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.

    How was the initial setup?

    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.

    What about the implementation team?

    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.

    What was our ROI?

    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.

    What's my experience with pricing, setup cost, and licensing?

    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.

    Which other solutions did I evaluate?

    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.

    What other advice do I have?

    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.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    PeerSpot user
    Sales & Operations Planning Manager at a retailer with 201-500 employees
    Real User
    Alerts us to issues before they becomes production issues, helping our productivity and reducing downtime
    Pros and Cons
    • "The alarms alert proactively if there are any potential or ongoing issues with the databases that we support. That means we can take preventive or corrective action before the issue becomes a big issue. And the SQL PI features enable us to drill down into performance issues in our databases so that we can improve performance, which is important."
    • "The version that I'm using is not the latest version, so there might have been some improvement, but the OS monitoring is a bit lacking, and the high-availability option is a bit complicated to set up and it doesn't work all the time."

    What is our primary use case?

    Foglight is used by our company to monitor production and development databases. It's being used to alert us if there are any database issues, including availability and those that are server-related. We also use Foglight SQL PI (Performance Investigator) features to troubleshoot any performance issues.

    How has it helped my organization?

    There are very specific database alerts that Foglight provides, to make us aware of an issue before it becomes a production issue. It can prevent us from having a production outage, which, if one were to happen, would increase our cost of business or decrease revenue flow. Foglight has the effect of improving our overall productivity, reducing downtime, and increasing profits.

    It also enables us to monitor multiple database platforms, including Oracle, SQL Server, Db2, and MySQL. In the future, we will add Postgres to the monitoring tool. It gives us one platform with one interface to look at the entire enterprise, which promotes efficiency and ease of use.

    Foglight's ability to quickly diagnose and resolve emerging issues is almost indispensable. That is especially true for SQL Server which has a very limited number of tools that you can use to drill down into issues. You can only do a limited number of things in SQL Server. Foglight has been extremely useful for us for troubleshooting emerging issues in SQL Server.

    In addition, we use the solution to display intensive database queries and that has been very useful. We can find out which queries are high consumers and find out why they're using so many resources, or we can contact the user to find out what they were doing and see if they can stop what they're doing.

    What is most valuable?

    The alarms and the SQL PI features are both very useful, and we are happy to have them. The alarms alert proactively if there are any potential or ongoing issues with the databases that we support. That means we can take preventive or corrective action before the issue becomes a big issue. And the SQL PI features enable us to drill down into performance issues in our databases so that we can improve performance, which is important. The drill-down capability is mostly for historical investigation.

    The solution also provides real-time activity screens. For example, there is a feature that shows us the connected users or the current CPU utilization or even the top activities inside the database server. This information allows us to perform troubleshooting on a real-time basis, as opposed to in a post-mortem or historical investigation. Whenever there is an issue taking place, we can use the real-time features to look into the issues right away. That means the solution we provide will be a lot more timely.

    For how long have I used the solution?

    I have been using Foglight for three years.

    What do I think about the stability of the solution?

    It's very stable. 

    It could use some improvement from the high-availability standpoint. There have been a couple of incidents where it did not fail over correctly, which resulted in more issues. But they have been few and far between. Overall, I would say it's very stable.

    What do I think about the scalability of the solution?

    We have not tried to scale upward or horizontally yet. So far, the number of databases that we monitor has been organically increasing by a few percent a year. Foglight has been able to handle it. I don't think we have any significant scaling needs.

    How are customer service and support?

    Their technical support is one of the excellent points of the company. Technical support has been A-plus-plus, five stars. I would give it six stars if I could.

    Every instance has been excellent. There has not been any time where I have felt they have been lacking in support. The engineer has always been knowledgeable, the response has always been timely, and the solution has always been effective. I cannot say enough good things about their technical support.

    We use their Premier Support and it adds value to our investment in the solution. Although I don't deal with purchasing at all, the Premier Support would probably help influence the purchasing of additional licenses. If I was being asked by the decision-maker if we should buy more products from this company, it would definitely be two thumbs up as far as I'm concerned because their support is such a good experience. 

    How would you rate customer service and support?

    Positive

    How was the initial setup?

    The setup was very complex. Our deployment model is a high-availability, multi-node environment. We had to have a consultant from Quest come in and help us. We needed a significant number of employees involved on our side. It was treated as a major project. It took us about six months to go from inception to production.

    We have it deployed in multiple data centers on the East Coast, West Coast, and the Midwest. We have high-availability servers located in both California and the East Coast. It's deployed only for the DBA team, which consists of less than 10 users. We are using it primarily as a DBA tool. But we are monitoring upwards of 500 production databases.

    Maintenance is usually done by one person. There are backups that are automated, so they don't require any people, and there are occasional server reboots, which one person can do.

    What was our ROI?

    While I don't deal with the pricing of products, so I don't know what the investment cost was, the return on investment in Foglight is quantifiable. There are definitely multiple instances where we prevent outages or resolve issues in a very timely manner.

    Which other solutions did I evaluate?

    We evaluated SolarWinds intensively, among multiple applications, before we decided on Foglight.

    What other advice do I have?

    The version that I'm using is not the latest version, so there might have been some improvement, but the OS monitoring is a bit lacking, and the high-availability option is a bit complicated to set up and it doesn't work all the time. 

    The solution does allow OS monitoring, but that capability in the version we are using is not as efficient as the database monitoring. So we only use a limited number of functions when it comes to OS monitoring. Our version is 5.9.7. I hear that the newer version, 6.1, has better features and integration with OS monitoring, but we haven't started using 6.1 yet.

    We use the solution's ability to proactively alert us to long-running queries, but we have not found it to be very useful. It's not because of the product. It just gives us a lot of alerts. The problem is that there is no cut-and-dry way to monitor long-running queries. Some queries would be expected to finish within five seconds, while other queries are expected to run for minutes or even hours. As far as I know, there's no easy way to set different thresholds for multiple queries. As a result, even though we use those alerts, we typically only look at them when a user reports an issue.

    For Oracle, even though I imagined Foglight would be very useful, we do not use it as much because Oracle has its own built-in capabilities. Oracle has its own diagnostic pack, which gives you a very accurate performance snapshot within the last however many minutes you need. And most Oracle DBAs are already familiar with that feature. We tend to use the built-in Oracle features and we do not use Foglight's features that much on Oracle. It's not because the Foglight features are not good, it's just that Oracle already has built-in features to monitor ongoing issues on a very accurate basis.

    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Flag as inappropriate
    PeerSpot user
    Senior Engineer at a financial services firm with 5,001-10,000 employees
    Real User
    Top 20
    Enables us to monitor multiple database platforms, and our DBAs have all the information they need assembled in one place
    Pros and Cons
    • "Foglight is also able to help the DBAs proactively fix problems before they become an issue. It provides them with real-time activity screens that help in this regard. The DBAs are able to go to these screens and look at what's happening in real time, and that buys them time. It helps them see problems ahead of time and find solutions to them."
    • "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."

    What is our primary use case?

    Primarily, we use it to monitor about 1,500 databases for availability and for database space, among other metrics.

    How has it helped my organization?

    It enables us to monitor multiple database platforms. We have MS SQL, Oracle, Db2, and Sybase. We also have Vertica and other platforms for which we use a custom monitoring solution from Foglight. That ability has been very helpful because the DBAs don't have to go to different vendors to get the information. It's all assembled in one place and it buys them time and makes it simple to find out what's going on with the databases.

    Using it, we're also able to monitor the OS, hybrid clouds, and hardware across different platforms. For the most part, it would just be the Linux and Windows platforms, because those are the main two that we use. This ability is handy because of the resulting simplicity for the DBAs.

    What is most valuable?

    We have four flavors of databases and we're able to monitor them all using a single pane. That comes in handy to the DBAs.

    Foglight is also able to help the DBAs proactively fix problems before they become an issue. It provides them with real-time activity screens that help in this regard. The DBAs are able to go to these screens and look at what's happening in real time, and that buys them time. It helps them see problems ahead of time and find solutions to them.

    What needs improvement?

    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.

    For how long have I used the solution?

    I have been using Quest Foglight For Databases for about five and a half years. I'm not a DBA. I just stand up the platform and make sure it is available for use by our DBAs.

    What do I think about the stability of the solution?

    I've had problems with its stability in the past, but they were because the platform was not tuned correctly. One thing that I would suggest is that they should put that information out there: How to tune the platform and make sure that it's running at its optimum capacity. I had problems with it for a long time, and it took a while before we could get it running with optimum performance. If I had known how to do it ahead of time, we could have saved some time.

    What do I think about the scalability of the solution?

    The scalability is very good for us. The one thing that we've been told is that when you have more than 800 databases, you have to spawn another management station. I hope that can be expanded for a single FMS (Foglight Management Server). The number of databases that one FMS can monitor in an optimum way should be more than 800. We haven't had that problem yet, but we are fast approaching that number and it's a concern.

    We've never used the SQL-PI component of it but we plan to use it, and that will make it that much more beneficial. It will provide analyses of the database processes. It will be beneficial for our SQL queries and for how to approach the configuration of indices.

    How are customer service and technical support?

    Their technical support is a nine out of 10. There is always room for improvement. There are times when a question is asked and it takes a little longer than expected to get a response back. It may be that they are juggling the needs of other customers, and I understand that. But that would be the only complaint.

    We have their Premier Support. One of the advantages is that we're able to have 'round-the-clock support. There are times when you have a problem and you can't wait until the next day or, if it's a Friday, until Monday. When we need help right away, that has been very helpful.

    Which solution did I use previously and why did I switch?

    I'm not aware of any previous solution. When I joined the company, Foglight was in use already.

    How was the initial setup?

    The process is very straightforward. It's more like plug-and-play and very easy. I have rarely had to call support to help with any installation.

    We normally have to do the installation in a non-cloud environment and test it out. If there are any problems we encounter with any of the rules, we iron them out with support. Once things are satisfactory and we're confident, we'll push it into production.

    In our environment it takes a long time to deploy, but that's not something to do with the product. It's a result of the resources we have and the fact that we have a lot of hoops to go through to get things validated internally. But none of that has anything to do with the Quest product.

    What about the implementation team?

    We use the help of a consultant from Quest to deploy. They are always available, but they have to work with our bottlenecks, internally. I appreciate that they are very flexible in working with us.

    What other advice do I have?

    It's a great product. It's probably one of the best in this class and people should not hesitate getting on board with the product. I have found it's very useful for my DBAs.

    There are certain situations where you actually need professional services, rather than going in there and getting yourself mired up in something that you can't fix yourself. You should really consider the use of professional services before you get involved in problems that you can't fix yourself.

    Which deployment model are you using for this solution?

    Private Cloud
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    PeerSpot user
    Buyer's Guide
    Download our free Quest Foglight for Databases Report and get advice and tips from experienced pros sharing their opinions.
    Updated: November 2022
    Buyer's Guide
    Download our free Quest Foglight for Databases Report and get advice and tips from experienced pros sharing their opinions.