Monitoring
1. Monitoring
Before we dive deep into monitoring, let's take a look at a scenario. Tal is a Cloud network engineer at Cymbal, where networks are incredibly large and complex. There are multiple VPCs and multiple interconnections used and monitored by various teams. Tal faces challenges with maintaining visibility into the network, ensuring optimal network performance, identifying bottlenecks and connectivity issues, analyzing and viewing network insights. With growing complexity, Tal can benefit from a solution to streamline network monitoring and gain actionable insights. Let's explore the comprehensive set of tools that Tal can utilize to monitor the network. To have visibility into the network, Tal can use Google Cloud monitoring to create custom dashboards that contain charts of the metrics that he wants to monitor. For example, Tal can create charts that display instances CPU utilization, the packets or bytes sent and received by those instances, and the packets or bytes dropped by the firewall of those instances. In other words, charts provide visibility into the utilization and network traffic of your VM instances, as shown on this slide. These charts can be customized with filters to remove noise, groups to reduce the number of time series and aggregates to group multiple time series together. For a full list of supported metrics, please refer to the documentation. Now, although charts are extremely useful, they can only provide insight while someone is looking at them, but what if Tal server goes down in the middle of the night or over the weekend? Tal is not always available to look at dashboards and determine whether the servers are available, or of enough capacity or bandwidth. To solve that, Tal can create alerting policies that notify when specific conditions are met. An alerting policy describes the circumstances under which you want to be alerted and how you want to be notified about an incident. The alerting policy can monitor time series data stored by Cloud monitoring, or log stored by Cloud logging. When that data meets the alerting policy condition, Cloud monitoring creates an incident and sends the notifications. Tal can create an alerting policy when the network egress of your VM instance goes above a certain threshold for a specific time frame. When this condition is met, you or someone else can be automatically notified through email, SMS, or other channels in order to troubleshoot this issue. There are also uptime checks that Tal can configure to test the availability of public services from locations around the world, as you can see on this slide. The type of uptime check can be set to HTTP, HTTPS, or TCP. The resource to be checked can be an app engine application, a compute engine instance, a URL of a host, or an AWS instance or load balancer. For each up time check, you can create an alerting policy and view the latency of each global location. Checking up time time helps in monitoring and maintaining service level indicator, service level agreement, and service level objective for availability. Seventy five percent of network outages happen due to misconfiguration. More often than not, these misconfigurations are discovered in production. Not knowing the impact of making a configuration change in firewall rules or routing rules, makes network monitoring reactive rather than proactive, introducing risk and extending mean time to resolution. Network intelligence center enables Tal to prevent networking outages and performance issues before they happen. Centralized monitoring cuts down troubleshooting time and effort, increases network security, and improves the overall user experience. Network intelligent center modules offer network topology, visualization, network connectivity tests, a performance dashboard, and firewall insights. When a virtual machine is unreachable, Tal may need to diagnose the connectivity issue quickly to prevent any issues. For example, there may be an issue between source and destination endpoints in your VPC network. Using the network intelligence center connectivity tests, Tal can self diagnose connectivity issues within Google Cloud or Google Cloud to an external IP address, which could be on premises or on another Cloud, helping to isolate whether the issue is in Google Cloud or not. Tal can create, save, and run tests to help verify the impact of configuration changes and ensure that network intent captured by these tests is not violated proactively preventing network outages. These tests also help assure network security and compliance. Connectivity tests have been used internally by the Google Cloud Support team to resolve customer issues. How can Tal diagnose if the application or the underlying network is the root cause of the issues? Network intelligence centers performance dashboard can show you real-time performance metrics, latency and packet loss between the zones where you have VMs, enabling you to quickly troubleshoot where the packet loss is happening, and indeed, if it's a networking issue at all. Performance dashboard now shows customer project information and also Google Cloud general information. Firewall configuration can be daunting. How can Tal verify that firewall rules are being used in the intended way? Firewall insights enables you to better understand and safely optimize firewall configurations. Firewall insights provides reports that contain information about firewall usage and the impact of various firewall rules on your virtual Private Cloud, VPC network. Make sure to enable firewall rules logging to view the reports. Firewall Insights uses Cloud monitoring metrics and recommender insights. Cloud monitoring collects measurements to help you understand how your applications and system services are performing. A collection of these measurements is generically called a metric. The applications and system services being monitored are called monitored resources. Measurements might include the latency of requests to a service, the amount of disk space available on a machine, the number of tables in your SQL database, the number of wig its sold, and so forth. Recommender is a service that provides recommendations and insights for using resources on Google Cloud. These recommendations and insights are per product or per service, and are generated based on heuristic methods, machine learning, and current resource usage. You can use insights independently from recommendations. Each insight has a specific insight type. Insight types are specific to a single Google Cloud product and resource type. Firewall insights metrics let Tal analyze the way firewall rules are being used. Firewall insights metrics are available through Cloud Monitoring and Google Cloud Console, metrics are derived through firewall rules logging. With firewall insights metrics, you can perform the following tasks. Analyze firewall rule usage, determine if firewall rules are functioning as expected. Track connection behavior. Verify that firewall rules are permitting or blocking the correct traffic over defined time intervals. Diagnose dropped connections. Investigate connections that may be unintentionally blocked by firewall rules. Identify potential threats. Detect anomalies in firewall rule hit counts, which could indicate malicious network activity. Network analyzer automatically monitors your VPC network configurations and detects misconfigurations and suboptimal configurations. It provides insights on network topology, firewall rules, routes, configuration dependencies, and connectivity to services and applications. It identifies network failures, provides root cause information, and suggests possible resolutions. Network analyzer runs continuously and triggers relevant analysis based on near real-time configuration updates in your network. If a network failure is detected, it tries to correlate the failure with recent configuration changes to identify root causes, whenever possible, it provides recommendations to fix the issues. In the example above, an insight of the type error, a GKE node to control plane connectivity is generated. The insight page also describes the following. The root cause. An ingress firewall rule is blocking the connection between the node and the plane. This indicated that the default firewall rules were modified, removed, or shadowed by another firewall rule. A solution. If the root of the problem is a deleted firewall, create a new firewall rule. If it's a shadowed firewall rule that increase the priority, you can use Gemini if you are unsure of where to find a particular performance metric. For example, you can ask Gemini how to find out the average latency between my VMs in US East 4 and US Central 1. Gemini assists you with the dashboard name and its purpose.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.