If you were talking to someone whose organization is considering Quest Foglight for Databases, what would you say?
How would you rate it and why? Any other tips or advice?
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.
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.
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.
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.
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.
If you've got the time for it, the time to focus on databases in general, then Foglight is definitely worth the expense because of the information that it can provide for you. The biggest lesson I have learned from using this solution is that it's worth it. It enables you to pin down troubleshooting within 30 minutes to an hour, whereas before, you'd be pouring over reports or data from queries for days. That's huge. The CIO has told me that since we've started using Foglight, we've actually gotten ahead of some of these issues and we're actually being proactive instead of reactive. We're in it all day, every day. I and at least two other DBAs are in it regularly, as well as some AppDev team members that we're trying to get to use it. We've got other database wannabes that are using it and our systems admins use it as well. Overall, there are 10 to 15 users. In the IT department, it is used pretty extensively. There aren't a lot of tools that I've tried to integrate it with. I'm in the process, when I have the time, of integrating it with ServiceNow.
What do you like most about Quest Foglight for Databases?
Thanks for sharing your thoughts with the community!