This Total Seminars course covers the exam certification topics. For information on additional study resources—including practice tests, lab simulations, books, and discounted exam vouchers—visit totalsem.com/linkedin. LinkedIn Learning members receive special pricing.
This course was created by Total Seminars. We are pleased to offer this training in our library.
Skill Level Beginner
- All right, so at this point we have planned and designed our database and database systems. We have implemented or deployed them. We have actually gone through the process of maintaining databases. We've learned to maintain the database management system. Now, we need to think about how we keep a close eye on all of this stuff that we might have deployed. This is about monitoring. So I want to start out in this episode by answering an important question, why monitor? What are some of the motivations behind choosing to monitor our databases and our database management systems? Well, the first one and probably the most obvious we think of when we think of monitoring is ensuring performance. So we want to make sure that we're able to achieve the results we need with the performance levels required. Users don't want to sit there for 15 minutes waiting on a report to run, if it could run in 10 minutes or 5 if the system was just designed appropriately. So that's the first thing, ensuring performance. The second is one that people often don't think of, insuring functionality. In other words, we can monitor for those times when something is attempted, but it couldn't be completed. Well, if it's being attempted, it must mean someone needs it, or at least they think they do. Now you might evaluate it and find someone's trying to do something they didn't need to do, and so your log that said an attempt failed is meaningless. But, at times, it's failing because people are trying to do what they need to do, but it's not working. So some functionality is missing, and monitoring could reveal that to us, especially with alerts and things like that. And then the third one, another common reason for monitoring, is ensuring security. And now what we're doing is making sure that our systems do comply with any type of regulatory compliance or organizational compliance and things like that that are required. So we understand why we might want to monitor so that we can ensure performance, we can ensure security, we can ensure functionality, but what are we going to use to do this? Well, we need to know the monitoring tools. Of course, AWS monitoring, there's stuff built in, so we can use the different monitoring tools built into AWS. And we'll be looking at those tools throughout this chapter. We also have instance monitoring. What this means is, inside of the EC2 instance, we have an operating system, and operating systems generally have some kind of monitoring capability. So basically, what we're saying is we're using the operating system monitoring capabilities built into the operating system running in the instance. And then we have third party monitoring. Now what we're dealing with is looking in the marketplace and saying, does someone have a better mousetrap? Does someone have a tool that will help me to monitor better than what's built into AWS or built into the operating systems? And we'll talk a little bit about some options that might exist there later on. Now, we know why, we know what, now we need to ask what we're going to aim at, what are our monitoring targets? Well, one big one is CPU utilization. We want to make sure that our CPUs are handling the workload thrown at them. And we've heard this many times throughout this course, but this comes back to the class that we're using. So the instance class, whether it's a database instance or an EC2 instance, is it capable enough? Memory utilization is in that same category. It's impacted by the class. Although, in some cases, with some services, you can adjust them out of memory related to the database. For example, if I'm using an unmanaged, instance-based database with SQL Server, not only is there memory configured in the instance configuration, but within SQL Server Management Studio, I can go in and say how much memory that I want SQL Server to use to buffer information. So, if I have a lot of memory given to the instance, but in SQL Server it's configured to only use maybe two gigabytes of memory, then I'm not getting all the benefit I could out of that instance. So it's about knowing those kind of things, as well. And then there are the connections, how many users are connecting to the database and the throughput? How much of the bandwidth for my network connection is being consumed? There's the database size that we might want to monitor so we know how large it's growing to be and how that could be impacting performance. Of course, we might want to know about errors that happen, and we might even want to make it, so that, when there are errors, we receive alerts, meaning that we're notified that an error has occurred. So to take all of these things into consideration, what we want to do is come up with a good monitoring plan, and the good engineers at AWS have suggested that you need to answer a few questions to come up with a good monitoring plan. In fact, they have six questions they want you to answer. Number one, what are your monitoring goals? Why are you monitoring? Are you focusing on the best performance you can get? Are you focusing on discovering areas where functionality is missing? Are you focusing on security? What are your goals? What resources will you monitor? Are you going to monitor only AWS RDS databases? Maybe you're going to monitor DynamoDB databases, as well. Redshift, instance based databases. What resources? How often will you monitor these resources? Do you want to monitor them all the time, or do you just want to check in once a week or something, which could reduce your costs for using some of the advanced monitoring capabilities of AWS? What monitoring tools will you use? Is the free, built-in monitoring capabilities enough, or do you want to use enhanced monitoring, for example, in RDS? And there are other decisions you have to make and other areas of AWS. Who will perform the monitoring task? Who's in charge of doing the monitoring, watching this? Is it the DBA or is it somebody else that's going to be in charge of that, maybe the general AWS administrator, for example? And who should be notified when something goes wrong? So, if you create alerts, who's going to be notified that something has happened within that system that's causing it to be problematic? These are the six questions that the AWS engineering team has determined you need to answer to come up with a good monitoring plan. The rest of this chapter is going to focus on the tools that we can implement and utilize based on our answers to those questions.