Welcome. In this video, we'll discuss the importance of proactively monitoring hardware and database performance in MongoDB. We'll also discuss the key components of an effective monitoring strategy, including metrics, alerts, and our response plan for resolving our alerts. To maintain database performance, we need a well structured monitoring strategy. It's important to establish monitoring processes in preproduction environments rather than adding them as an afterthought. This is because monitoring helps detect issues early before they become serious problems. It can help us understand our scaling needs, reduce costs by making sure we only spend on what we need based on real data, and maintain optimal performance in our application. In this video, we'll focus on metrics related to query performance. While this is one of the most common issues you'll encounter, what you learn will help you monitor your database for any number of potential issues. When building a monitoring solution, it's important to understand the key areas that need to be monitored. We can split these areas of concern into two categories, hardware concerns and database concerns. Let's take a look at each, starting with hardware. When monitoring our hardware, we'll focus primarily on how we utilize memory and how our network utilization can impact performance. The performance of our database operations rely heavily on how efficiently we use memory. For example, when MongoDB accesses data that isn't in RAM, page faults occur, leading to additional disk read operations. This can impact latency, especially during peak operational times when quick data retrieval is essential. A good strategy for monitoring page faults is to regularly monitor memory usage. This information enables us to optimize our dataset configurations, ensuring critical data remains in RAM. This will reduce page faults and the need for page eviction. Next, we have resident memory, which is the portion of RAM that MongoDB actively uses. Monitoring this is vital since faster memory access boosts database operations, particularly queries. However, if MongoDB consumes too much RAM, it can strain other system processes. Persistent high usage may indicate the need for more RAM or database adjustments. Ideally, MongoDB's resident memory should stay below eighty percent of the total available memory. Next, we have the working set, which refers to the portion of indexes and documents frequently used by the application. To keep queries running quickly, WiredTiger, MongoDB's default storage engine, keeps data that is accessed frequently in memory. This in memory set is known as the WiredTiger internal cache. Ideally, the working set should fit into WiredTiger's internal cache. Database performance is impacted when the working set exceeds the internal cache size. Monitoring all of the different aspects of your memory usage is easy with MongoDB Atlas. With Atlas, you can directly monitor memory usage and gain insights into your working set with metrics such as system memory and MAC system memory. Memory usage is just one aspect of your hardware that you need to monitor. Next, monitoring your network metric is crucial in maintaining smooth and efficient database access. Any degradation due to network issues can negatively impact query performance, user experience, and transaction integrity. Consistent monitoring of network metrics, such as data transfer rates and network traffic, will help identify bottlenecks. In MongoDB Atlas, you can track network activity in the MongoDB metrics section, where the network metric provides insights into incoming data or bytes in, outgoing data or bytes out, and the total request count. Establishing a baseline during normal operations will help us identify deviations that warrant investigation. Now that we understand how hardware can impact query performance, let's dive into the database concerns. First, let's look at connections and cursors. An excessive number of connections might indicate connection mismanagement, potentially leading to increased latency and query execution. On the other hand, too few connections may suggest underutilization. For more information on connection limits, check out the MongoDB documentation. Similarly, a large number of open cursors constrain the database, and an increase in timed out cursors can indicate that queries are taking too long to run. Finally, document metrics track the performance of CRUD operations across the cluster. This early detection of potential discrepancies ensures continuous, consistent data operations and reliability across replicas. As we can see, there are several hardware and database concerns to focus on for monitoring. To ensure optimal query performance and user experience, we need an effective monitoring strategy that includes three components, metrics, alerts, and a response plan. Metrics offer quantitative insights into database performance. When we monitor metrics like query execution times and resource utilization, we can gauge the health and efficiency of our system. By configuring alerts, we can be notified when metrics exceed defined thresholds beyond a certain time frame. If a query takes twice as long as expected, an alert prompts immediate investigation and resolution, allowing us to address potential problems before they affect the user experience. Finally, having a response plan gives us predefined steps to take following an alert. For example, if an alert related to slow query response is triggered, our team follows a laid out protocol, checking logs, putting out fires, and adjusting database configurations or optimizing the specific query in question. Good job. In this video, we learned that establishing proactive monitoring in preproduction environments for both hardware and database concerns is crucial for optimal performance and early issue detection. Then we focused on the importance of monitoring query performance metrics, like execution times and resource utilization, to ensure a smooth user experience. Finally, we understood that an effective monitoring strategy includes defining key metrics, configuring alerts for deviations, and establishing clear procedures for responding to these alerts.