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.

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.

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.

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.

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

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

I was the only one involved in the initial setup in our company. There was a little complexity to it, but overall it was very straightforward. We didn't have any real issues getting it set up and running. 

You've got to let it run for a while before you determine what is white noise and what are actionable items. Then you have to go back in and say, "This is not something to alert on, but it is something that I still want to log." Sometimes that white noise does come in handy when you're looking at troubleshooting a long-running issue.

From start to finish, the deployment took a week.

First off, I had to get all the servers built and we did virtuals. But I had to get a tie-in with our server team to get those set up and running. The requirements, themselves, were pretty straightforward. I could present to the server team exactly what we needed and how we needed to set it up. Getting the basic infrastructure in place was what took the most time. Once we actually started the install of Foglight, it was pretty simple.

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.

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.

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