You have deployed an application on Anthos clusters (formerly Anthos GKE). According to the SRE practices at your company, you need to be alerted if request latency is above a certain threshold for a specified amount of time. What should you do?
A.
Install Anthos Service Mesh on your cluster. Use the Google Cloud Console to define a Service Level Objective (SLO), and create an alerting policy based on this SLO.
B.
Enable the Cloud Trace API on your project, and use Cloud Monitoring Alerts to send an alert based on the Cloud Trace metrics.
C.
Use Cloud Profiler to follow up the request latency. Create a custom metric in Cloud Monitoring based on the results of Cloud Profiler, and create an Alerting policy in case this metric exceeds the threshold.
D.
Configure Anthos Config Management on your cluster, and create a yaml file that defines the SLO and alerting policy you want to deploy in your cluster.
Cloud Service Mesh displays a Latency graph on the Metrics page for each of your services. The Latency graph shows you the latency over time, which can help you determine a latency threshold or upper bound for a service.
https://cloud.google.com/service-mesh/docs/observability/slo-overview
Cloud Monitoring can trigger an alert when a Service is on track to violate an SLO. You can create an alerting policy based on the rate of consumption of your error budget. All alerts on error budgets have the same basic condition: a specified percentage of the error budget for the compliance period is consumed in a lookback period, which is a time period, such as the previous 60 minutes. When you create the alerting policy, Anthos Service Mesh automatically sets most of the conditions for the alert based on the settings in the SLO. You specify the lookback period and the consumption percentage.
https://cloud.google.com/service-mesh/docs/observability/alert-policy-slo
Why not B....
Cloud Trace is a distributed tracing system that collects latency data from the applications and displays it in near real-time. It allows you to follow a sample request through your distributed system, observe the network calls and profile your system end to end.
Note that Cloud Trace is disabled by default.
The Anthos Service Mesh pages provide a link to the traces in the Cloud Trace page in the Cloud Console.
https://cloud.google.com/service-mesh/docs/observability/accessing-traces
In Anthos clusters you need to install Anthos service mesh? From this link you need to install it only on GKE and on-premises platforms
https://cloud.google.com/service-mesh/docs/observability/accessing-traces
I think A is about monitoring and alerting without any further investigation, while Trace is for finding the root cause/detective purposes, when you look into a call and track this call step by step through each endpoint, the call is going through.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
vladik820
Highly Voted 2 years, 4 months agoOuss_123
Most Recent 3 days, 13 hours agocchiaramelli
2 months agotamj123
2 months, 2 weeks agoexamch
11 months, 4 weeks agomegumin
1 year, 1 month agoJay_Krish
1 year, 3 months agoRitwickKumar
1 year, 4 months agoigor_nov1
1 year, 4 months agoAMohanty
1 year, 4 months agoAzureDP900
1 year, 6 months agosivre
1 year, 9 months agoryzior
1 year, 6 months agokimharsh
1 year, 6 months agoShawnn
9 months, 3 weeks ago[Removed]
1 year, 10 months agoharoldbenites
1 year, 10 months agotechnodev
1 year, 11 months agovincy2202
2 years agonqthien041292
2 years, 1 month ago