Google Cloud Observability
1. Google Cloud Observability
We start by looking at the components of Google Cloud Observability. The integrated managed services in Google Cloud Observability help you manage your running services and applications. Cloud Monitoring provides visibility into the performance, availability, and overall health of cloud applications. You can collect metrics, events, and metadata from Google Cloud services and applications, and create alerting policies to provide timely awareness of problems in your applications. Cloud Logging is a fully managed service that ingests application and platform log data, as well as custom log data from GKE environments, VMs, and other services inside and outside of Google Cloud. Cloud Logging lets you search and filter your logs, and provides you the ability to troubleshoot and analyze log data for your applications. Error Reporting counts, analyzes, and aggregates errors produced in your running cloud services. You add the error reporting library to your application, and then report an error when it occurs. The Error Reporting dashboard displays a summary of each error found and the number of occurrences of each error, and notifications can be sent when a new or resolved error occurs. Cloud Trace is a distributed tracing system for Google Cloud that collects latency data from applications and displays it in near real-time in the Google Cloud console. Cloud Trace helps you understand how long it takes your application to handle incoming requests and analyze latency across services in the application. Cloud Profiler uses statistical techniques, and low-impact instrumentation that runs across all production application instances to provide a complete picture of an application’s performance without slowing it down. Cloud Profiler helps you identify and eliminate potential performance issues. Cloud Monitoring helps increase reliability by giving users the ability to monitor Google Cloud and multi-cloud environments to identify trends and prevent issues. With Cloud Monitoring, you can reduce monitoring overhead and improve your signal-to-noise ratio, letting you detect and fix problems faster. Why should application developers care about monitoring their applications? Monitoring is the foundation of application reliability. With Cloud Monitoring, you can build custom dashboards and use out-of-the-box dashboards to answer basic questions about your application. You can monitor your apps and infrastructure, whether they are running in Google Cloud, on-premises, or in other clouds. These dashboards let you monitor the health of your infrastructure and applications and easily spot anomalies. Monitoring over time also lets you see trends in application usage patterns. How large is my database, and how fast is it growing? How quickly is my daily active user count growing? Which features of my application are used the most? Monitoring also can tell you what needs urgent attention. Is the application broken, or will it soon break? Alerting on metric trends or limits lets you be notified of issues and fix them before they cause catastrophic failures. Monitoring can also be useful for conducting retrospective analysis. The latency of our application increased dramatically overnight -- what else happened around the same time? Is there a condition that I can alert on to let me fix the issue before it affects users? At a minimum, there are some key metrics that you should capture for your applications. You should create application dashboards that include the four golden signals: Latency, traffic, errors, and saturation. Latency is the amount of time that it takes to serve a request. Make sure to distinguish between the latency of successful and unsuccessful requests. For example, an HTTP error that occurs due to a loss of connection to a database or another backend service, might be solved really quickly. However, because an HTTP 500 error indicates a failed request, including 500 errors in your overall latency might result in misleading metrics. Traffic is a measure of how much demand is placed on your system. It's measured as a system-specific metric. For example, web server traffic is measured as the number of HTTP or HTTPS requests per second. Traffic to a NoSQL database is measured as the number of read or write operations per second. Errors indicate the number of failed requests. Criteria for failure might be anything like an explicit error, such as an HTTP 500 error, or a successful HTTP 200 response but with incorrect content. It might also be a policy error. For example, your application promises a response time of one second, but some requests take over a second. Saturation indicates how full your application is, or what resources are being stretched and reaching target capacity. Systems can degrade in performance before they achieve 100% utilization, so make sure to set utilization targets carefully.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.