Foglight for Databases Reviews

Foglight for Databases is used for database monitoring across all SQL servers and Oracle databases. The monitoring covers database health, deadlocks, long-running queries, disk space usage, historical usage of active sessions, data growth, log file growth, cluster health, and CPU memory metrics.

Foglight for Databases provides both real-time data and historical views. The real-time activity data is used for alerts and historical data is reviewed for trend analysis.

Alerts have been set up in Foglight for Databases for long-running queries and blocking sessions. The tool is used to check for intensive database queries, including resource and CPU-intensive queries, to identify which queries are causing high CPU, wait times, or high memory usage.

When the application team reports that a job is running slow, I monitor the job or query from Foglight for Databases to determine where it is getting stuck or why it is performing poorly. I can check for missing indexes and review the execution plan. If missing indexes are identified, they can be created to improve performance. The tool helps significantly from a performance perspective.

Issues and their root causes can be identified through the GUI mode in Foglight for Databases. Foglight for Databases enables monitoring of multiple database platforms, including Oracle and MS SQL databases. The tool is deployed solely for monitoring, using real-time monitoring and historical data views for application support and database support operations.

The most valuable feature of Foglight for Databases is a centralized location where all reports can be accessed, including session information and execution plans. There is no need to remember specific queries or DMVs; the GUI provides the desired results directly.

When blocking occurs, users begin to experience access issues. Upon receiving notification, I can kill the blocking query, allowing users to regain application access and preventing business impact.

Locating data using the Angular UI of Foglight for Databases is straightforward. There is no need to remember commands; the GUI is simple and intuitive.

Overall, Foglight for Databases is reliable and helps with generating alerts and monitoring database health and historical data in database operations.

An improvement was observed in Foglight for Databases regarding the automatic closure of alerts or incidents once the issue is resolved. Previously, incidents were not automatically closed, but this has been fixed. From my experience, I have not encountered other significant difficulties. The tool could be somewhat more user-friendly, as proper knowledge is required to set up servers and use it effectively.

I have been working with Foglight for Databases for approximately four years.

Foglight for Databases receives a rating of nine in terms of scalability. I have used it for Oracle and SQL databases, but I am not certain if it supports all databases, which is why the rating is nine rather than ten.

I do not communicate frequently with technical support for Foglight for Databases, as upgrades and maintenance are handled by my lead. I have never contacted support.

Before Foglight for Databases, basic SQL Server database monitoring was performed using SQL native tools with no external applications. By the time I began working, Foglight for Databases was already implemented.

I am not aware of the pricing and licensing details for Foglight for Databases. I have set up Foglight monitoring for servers, but I am uncertain about the licensing aspect.

Documentation for Foglight for Databases setup for new servers is used for implementation. The tool generates database permissions and provides a ready-made database permission script that can be executed on the SQL Server to automatically grant the required permissions. The documents used for setup may have been provided by Foglight for Databases or created internally, but the permission script was provided by Foglight for Databases and functions effectively.

Foglight for Databases provides real-time data that is invaluable for analyzing ongoing issues with database servers. I give this product a review rating of ten.

Foglight for Databases serves multiple purposes in my organization, with the primary use being the multi-database aspect, where I can have the status and availability of all databases in a single view. Currently, on a daily basis, this means staying alert to the alerts that Foglight provides. With the additional complement of Performance Investigator, it has been of great help to evaluate issues that require historical information and investigation, which is quite solid in that regard.

Currently, we have a system that entered production this year, and Performance Investigator has been invaluable in evaluating response times, especially outside business hours, and in directing the development team to which queries have problems and how to optimize them.

Thanks to Foglight for Databases, we have had a positive impact in our area. We are a very small team with only one database administrator, and if we wanted to go deeper, we would need people with different flavors of databases. This tool helps us have a better overall vision of all types of databases. Specifically, we have had performance issues where we identified users who executed procedures without declaring them, which leaves us with an audit trail that helps in decisions regarding access or processes that run outside appropriate hours.

In terms of how it has positively impacted my organization, Foglight for Databases has continually improved, as the number of cases specifically related to performance and response times has decreased. Another area where it has helped significantly is now that we have grown and are working with cloud topics and integrating those services. Regarding improvements we have seen, they are evident in monitoring through dashboards, which are very fast for analysis.

I have been using Foglight for Databases for approximately three years. Initially, we started with the Oracle module, and now we have incorporated three engines that we manage, which are MySQL and SQL Server.

One of the best features that Foglight for Databases offers me is that it is multi-platform with respect to databases. It is not limited to a single type and offers scalability with any type of database that can be incorporated into the company, providing analysis tools quickly regarding server and database performance, which makes it very useful within the IT area.

I would also highlight the reporting aspect in Foglight for Databases, which can be customized and provides a lot of information. There is so much information that you have to be very thorough. It is not really a drawback, but given that there is so much information, you have to be very careful about what information you need, because Foglight has much to offer.

Overall, I strongly highlight Performance Investigator for the different dimensions it handles. It is very useful for audit topics and performance, especially the historical aspect, which allows us to manage month-to-month periods and identify our bottlenecks during the month. It is a great help for the database area because it is focused and you can extract a lot of information related to what you need. Regarding availability, it has also been of great help in alerting us in case of any type of unavailability and in sending email notifications.

Primarily, given that Foglight for Databases is so multi-platform with different databases such as Oracle, SQL Server, and MySQL, the reports are very specific for each engine. An improvement could be at the availability level for all the services we have registered at the database level, regardless of the engine, providing availability or backup information in a report that covers all databases, not necessarily by database, but in a general report.

I have been using Foglight for Databases for approximately three years. Initially, we started with the Oracle module, and now we have incorporated three engines that we manage, which are MySQL and SQL Server.

Foglight for Databases is entirely a stable solution and very useful for dealing with contingencies in daily operations.

The scalability of Foglight for Databases has been good and will continue to be so, because it does not close the possibility of other engines or other flavors of databases according to the company's needs.

I have had little need for support, but when I have needed it, it has worked well.

I would rate customer support with a nine, primarily because I do not give it a ten since I feel that more information or training is needed to better leverage the tool.

Before implementing Foglight for Databases, we worked with Oracle databases and acquired Spotlight and Toad. With the growth of the project, new databases such as SQL Server and MySQL were added, and others could be added in the future. We still use Spotlight only for Oracle, but it is limited to that database. Foglight helped us achieve greater growth in monitoring.

I have had a good experience with the licensing costs of Foglight for Databases, as we have a provider who has given us good prices, and so far we have not had any cost problems. Regarding configuration, we have support from a provider in Chile that has met expectations so far.

Instead of evaluating several products, I evaluated within the Quest brand what could help us according to our needs, and Quest as a brand completely fulfilled those needs with Foglight for Databases.

Instead of evaluating several products, I evaluated within the Quest brand what could help us according to our needs, and Quest as a brand completely fulfilled those needs with Foglight for Databases.

I have had a good experience with the licensing costs of Foglight for Databases, as we have a provider who has given us good prices, and so far we have not had any cost problems. Regarding configuration, we have support from a provider in Chile that has met expectations so far.

Instead of evaluating several products, I evaluated within the Quest brand what could help us according to our needs, and Quest as a brand completely fulfilled those needs with Foglight for Databases.

I would say that you should evaluate the tool in terms that it might initially seem like a higher cost, but it brings many benefits. For me, one of the most useful components has been Performance Investigator, because it completely helps with bottlenecks or performance problems quickly, evaluating whether the root is at the server level, at the development level, or at the database level.

I want to compliment the tool, especially the support of Performance Investigator. My overall rating for this product is a ten.

I primarily use the solution for database monitoring, specifically for Oracle, Microsoft SQL Server, Postgres, SAP HANA, and AWS Redshift.

I find it extremely helpful to use Foglight to triage any database issues, specifically performance issues using what Foglight calls PI investigator. It is a very powerful workload analysis tool that helps me understand where bottlenecks are. It allows me to see performance issues as end users report them. It can save time and effort when doing root cause analysis. It enables me to obtain information quicker and easier compared to manually compiling it.

Foglight provides us with a near-real-time activity database. It's not 100% real-time. It has less than a minute latency. It allows us to see performance issues as end-users report them. 

We started seeing benefits pretty much immediately. 

We use Foglight to display intensive databases. However, it's not something we monitor regularly. It's only something we kind of dig into as we troubleshoot and triage issues. It does help us determine potential IT help issues. 

When we use Foglight, we find it helps drill down holistically into potential bottlenecks. It helps us to see what is going on in the database.

Foglight allows us to monitor multiple database platforms. We use, for example, Oracle, SQL Server, Postgres, Amazon Redshift, and SAP HANA. It gives us insight into our entire landscape of production workloads in near real-time.

The solution saves costs when performing root cause analysis. It can save time and effort when doing root cause analysis. It allows us to obtain information quicker and easier than by manually compiling information.

It would be amazing if they could enable the "Performance Investigator" functionality across all database platforms. 

I've been talking to their product development team about enhancements that I would like to see in very specific cartridges. I've been discussing these enhancements, however, nothing has materialized from these conversations. Something that could be improved is the integration of customer feedback into the product roadmap to build the features and functionality that real customers could benefit from.

I have been using the solution for probably three plus years now. I've used it since the SolarWinds incident.

The platform is very stable. We have not run into any performance issues on the platform.

It is easy for me to manage and easy to scale up.

We use support when we come across issues, and they are very responsive. I am pretty happy with the quality of service that they provide. We do not pay for any premium support.

Positive

I used to use SolarWinds monitoring prior to their security breach. I also use Oracle Enterprise Manager in parallel to Quest Foglight currently. We switched to Quest due to a security breach in SolarWinds. 

It was relatively easy to deploy the solution.

With the help of professional services, it took three to four weeks for the initial setup.

We have one person on our team handling the deployment on our end.

We're running installed software, so it does require maintenance. When there are upgrades, we have to do them. When we add new technologies that we want to monitor, we have to add the cartridges. We're managing the platform ourselves.

Quest product support assisted with the implementation.

The pricing is palatable. We've already done one renewal and we are in our second contract. We're happy thus far.

I would give the solution a nine out of ten. 

I recommend doing due diligence, looking for best in class solutions, and doing proof of concepts if you can afford the time. The product will speak for itself.

We use Quest Foglight for Databases for production monitoring of our databases, including Postgres, Microsoft SQL Server, and MySQL. We proactively manage our customer databases that support our SaaS application.

We had some licensing constraints with our previous solution Idera. When we crafted the contract with Quest on Foglight, we were able to go from basically 30% coverage of our production environment to 100% coverage. We have better visibility into the environment since putting it in place.

We implemented the solution’s Angular UI. It took us a day to do it, and we just stepped in and started using it. It was pretty straightforward and easy. The overall data availability in the Angular UI is good. We are not seeing any gaps from the legacy UI to the new UI for the things that we were relying on. Everything that we expected to be there is there. It proactively alerts us of long-running queries.

In terms of the capability to quickly diagnose and resolve emerging issues, some things are disconnected from the rest of our observability platform. It takes a few steps to get from incident to resolution, but once we step into Foglight, we are able to quickly get to the data that we need to understand what is going on.

It provides real-time activity data. We run a 24/7 shop. If there are any database performance issues, we have to act on them pretty quickly.

We do not use it much to display intensive database queries. It is not really our core use case, but when we are troubleshooting application performance, it does get used in that manner at times.

It enables us to drill down and see what is causing the issue to an extent. Because we run a dynamic ORM, it is a little difficult to ascertain exactly what is happening from a database query perspective, but that has nothing to do with the tool itself. It is more about how we dynamically generate the SQL queries.

It enables us to monitor multiple database platforms. We have Microsoft SQL Server, Postgres, and MySQL. Prior to having Quest Foglight for Databases, we did not have anything centralized to provide this level of insight into our platform, and we now have it.

It does exactly what it is supposed to do, and it does not do anything more, which is what we want. We do not want it to start venturing outside of what it is good at and what it is built for.

The profiler allows us to look at the profiles of the database queries that are being run over time. It allows us to go back to our customers and say that these are some of the queries causing them some headaches. It gives us the opportunity to provide suggestions on how to improve their experience.

The monitoring capabilities for Postgres should be at par with SQL Server. This is the area where we push back on our Quest representative. We want more insights into Postgres.

We have been using the solution for about two years now.

We do not have any issues with it. Sometimes the UI takes a little bit longer to render, but other than that, it is fine.

It is monitoring a little over 600 databases. It is perfectly fine for us.

We have Premier Support. They are very responsive, and they come back with direct and concise directions and answers.

Premier Support has added value in terms of response time. Generally, whenever we send something to them, we get a response within a few hours, and it is pretty straight to the point. We would have figured it out eventually. Having Premier Support shortens the timeline a little.

Neutral

We were using Idera. We had some licensing constraints with it.

It is deployed in AWS, but it is very similar to an on-prem deployment. It is as if it is deployed inside the data center.

After we got the license file, within a week, we had full coverage of our environment.

It requires minimal maintenance. We do a little bit of maintenance on it once a quarter.

It was implemented in-house. We did have a professional service contract with Quest, but that was just to have someone available from Quest to address our backend calls if we had questions. We had two people involved in the implementation.

For root cause analysis, it definitely provides us additional capabilities of getting down to where the core issue is. Due to the nature of our application, it is usually upstream, not at the database level, but it allows us to see what is happening.

I do not have any metrics, but it costs us more from a time perspective because we now have more visibility into the environment, which is a good thing.

Pricing is very reasonable. We were able to construct a pretty easy contract with Quest, who were very easy to work with and very amenable to what we are trying to do. It worked out well for us.

We looked at a couple of other solutions, like Redgate SQL Monitor, but they did not have cross-platform support. There are not too many solutions on the market that offer cross-platform support like Quest Foglight.

I would rate Quest Foglight for Databases a seven out of ten.

We use it for monitoring SQL databases, specifically to assess database contention. Additionally, we utilize it for real-time monitoring before deploying changes to production environments.

It provides real-time activity data. When people are saying that things are slow and not moving, we log in, identify the query that is causing the slowdowns, and address the query. It helps us determine what is causing slowdowns and address them.

We were able to see its benefits immediately. We got it to know what is going on in the database. We could very quickly identify the issue.

It enables us to monitor multiple databases. We are currently monitoring two SQL databases. One is our production server, and the other one is our test server. Before putting things in production, we test them in the test environment to ensure that there are no slowdowns with any new implementations. I know it is capable of monitoring many different types of databases, but we just use it for two SQL Servers.

It is good to quickly diagnose and resolve emerging issues. That is why we got it. It enables us to drill down and see what is causing the issue if something does not look right.

I find the SQL statements and activity highlights helpful. We look at them and see what is happening on a database. The graph and resource consumption have helped a few times. We were able to determine a network problem. Because we looked at it every day and saw this network rate increasing, we knew something was going on in the network. We could then investigate. That helped a couple of times.

What I really like is the SQL PI feature, which allows us to drill down into queries and identify what is causing contention in the database. Using the SQL PI feature, I am able to drill down into the queries, see what is blocking, and try to improve it.

It would be helpful to have more communication about new features. The concept of intensive database queries sounds beneficial, but I am not aware of how to access this feature. 

Better communication and alerts regarding the transaction logs getting full would also be beneficial. What I have noticed is that if the log files on the SQL server are full, we cannot log in and have to do some cleanup on the Foglight DB. It would be good if they could monitor that and alert us when it is getting too full. That will be handy so that we do not have to wait till it stops working and then clean up the transaction logs. I know we can set up some backups for the transaction logs. It schedules some backups on the transaction log table but sometimes, the backups might not run. It would be handy if there was some indicator saying that the transaction logs are getting full.

I do not like the OS monitoring part of it much. It does not tell me much. It has a nice graphical interface showing the system, the CPU, the files, and some real-time things going on there, but all that is not that useful. The most useful part for me is SQL PI. There are advisories, but most of the time, I ignore them. I look at them only when there is a major problem, and even then, they do not specifically tell me what the issue might be. It just gives an overview. It is not detailed.

I have been using this solution for more than five years.

It is generally stable. However, if transaction logs get full without proper cleanup, it can affect performance.

Previously, when I was using the embedded SQL, there was some lagging. There were some performance issues. That was one of the reasons for moving away from that and going to the SQL Server instance. The transition to SQL Server improved stability from the previous embedded SQL setup. The only issue is when the transaction logs are full.

The support is okay. I would rate them a seven out of ten.

Neutral

I have not used anything to this extent. I have done a few things in SQL Management Studio.

I like the Quest Foglight solution because it is easy and quick. We can quickly see what is going on at a glance. It also has real-time monitoring. With most tools, if there is something going on in a database, you only get a snapshot of time. It is not tracking the history, and the history is the big thing.

It is fully on-premises. We only use it for two servers, and we prefer it to be on-premises. Most of our servers are on-premises.

The deployment was not that difficult. The first version I had was the embedded SQL Server. For version 7.1, I had a dedicated SQL server. Their team helped with that, and it was fine. It was not too difficult. 

It did not take that long. There is not much to do here. Once we have the instance up, we just set up the agent on the databases we want to monitor.

The deployment was done by me with the assistance of Foglight support.

I would rate Quest Foglight for Databases a six out of ten. The product is good, but communication on updates and new features should be improved. We do not always know what is going on with the product.

Which deployment model are you using for this solution?

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.

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.

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.

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.

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

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.

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

Neutral

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.

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.

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.

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.

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.

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.

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.

I have been using Foglight for three years.

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.

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.

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. 

Positive

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.

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.

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

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.

We use the solution for SQL Server and auction. We have a couple of customers using it for the other case. Other customers are also extending the infrastructure monitoring from the virtualization and the storage.

A feature called Workload Analysis is an important feature. We always offer to our customers which is better than a database. It has a heterogeneous environment. We can monitor from the same console with different database platforms. It is very useful for the DDS responsible for more than one database. Compared to other tools with database vendors, it's more inexpensive. Also, the price is a major factor for us to position to our customers.

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

I have been using Quest Foglight for Databases as a system integrator for 15-16 years. We are currently using V7.1 of the solution.

The product is stable.

I rate the solution’s stability an eight out of ten.

We have nine customers using this solution.

I rate the solution’s scalability an eight out of ten.

Customer service is responsive, but it has not been so responsive for the last two years. The resources dealing with tickets are taking too much time to respond. We have to wait a week to get an answer or a response. When they respond, they provide the right response. We have lost opportunities during the POC because of the slightly delayed response.

Neutral

The initial setup is straightforward. We have the expertise to run standard installations with high availability. It depends on the customer and the setup complexity of the environment. The monitoring part can go up and running in one day. Setup may take a week, but we have a customer where we started at 10 AM and ended at 02 PM. It was running and monitoring around 15 equal server database instances in four hours.

Three people are required for the deployment, including one for the database and two for the infrastructure.

The licensing model is straightforward. From day one, we know about the charges and costs involved in a project.

I rate the product’s pricing a five out of ten, where one is cheap and ten is expensive.

Overall, I rate the solution a nine out of ten.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.