Google Cloud Observability Diskussionen

Google Cloud Observability

(99)4.3/5

46.0

Nps Score

Bereits Google Cloud Observability verwenden?

Alle Google Cloud Observability Diskussionen

# Welche Verbesserungen würden Sie für Google Cloud Operations vorschlagen, um Ihre Überwachungsanforderungen besser zu erfüllen? Welche Verbesserungen würden Sie für Google Cloud Operations vorschlagen, um Ihre Überwachungsanforderungen besser zu erfüllen? ##### Post Metadata

- Posted at: vor über 1 Jahr - Author title: Von G2 als häufig gestellte Frage angeheftet

# Wofür wird Google Cloud Operations (ehemals Stackdriver) verwendet? Wofür wird Google Cloud Operations (ehemals Stackdriver) verwendet? ##### Post Metadata

- Posted at: vor über 2 Jahre - Author title: Von G2 als häufig gestellte Frage angeheftet

# What can you do with Google Cloud Platform? What can you do with Google Cloud Platform? ##### Post Metadata

- Posted at: vor fast 3 Jahre - Author title: Von G2 als häufig gestellte Frage angeheftet

# What is the purpose of cloud debugger? What is the purpose of cloud debugger? ##### Post Metadata

- Posted at: vor über 3 Jahre - Author title: Von G2 als häufig gestellte Frage angeheftet

# What are three types of cloud IAM roles? What are three types of cloud IAM roles? ##### Post Metadata

- Posted at: vor über 3 Jahre - Author title: Von G2 als häufig gestellte Frage angeheftet

# What is Google Cloud Stackdriver? What is Google Cloud Stackdriver? ##### Post Metadata

- Posted at: vor fast 4 Jahre - Author title: Von G2 als häufig gestellte Frage angeheftet

# Custom metrics creation after updating the GKE version from 1.14 TO 1.16, where the Stackdriver has changed from Legacy to System& workload based. Due to recent recommendations on updating the GKE clusters and the older versions being depreciated soon...we have updated our environment clusters from version 1.14 which used Legacy stackdriver Logging and Monitoring to version 1.16 which uses System and Workload logging and Monitoring. While using Legacy Stackdriver logging and Monitoring - our log based metric looks like below. ```resource.type="gke_cluster" resource.labels.cluster_name="microservices" jsonPayload.kind="Event" jsonPayload.involvedObject.kind="Pod" jsonPayload.reason="Killing"``` And Alert created using this metric was useful as if any container is killed....the alert triggers and also gets resolved when the new container is up in that specific workload of GKE(this setting takes care even when random pod ID is stopped and new one gets restarted). Whereas, while using System and Workload settings - our log based metrics resource types have changed a little bit and looks more like below. ```resource.type="k8s_pod" resource.labels.cluster_name="microservices" jsonPayload.kind="Event" jsonPayload.involvedObject.kind="Pod" jsonPayload.reason="Killing"``` And Alert is created using this metric as done previously. In this case any container which is killed and has a random pod ID name does not recover from the alert when a new container is created in that workload. For this same reason, we have to now manually have to acknowledge and silence the incident. As a workaround, I can create separate alerts for each workload using kubernetes.io/container/restart_count, but this is not an ideal solution for our company as we have more than 60 workloads running at any point of time and we usually set up the alerts for a particular namespace to group them and send alerts. It would be great if you can help support us in this issue and I have noticed this is a common issue for all the companies which have updated their GKE clusters and moved from Legacy to System & Workload settings. ##### Post Metadata

- Posted at: vor etwa 5 Jahre

- Net upvotes: 1

# Was ist der beste Weg, um Stackdriver zu lernen? ? ##### Post Metadata

- Posted at: vor etwa 6 Jahre - Author title: Python Developer Intern

- Net upvotes: 1