# What improvements would you suggest for Google Cloud Operations to better meet your monitoring needs? What improvements would you suggest for Google Cloud Operations to better meet your monitoring needs? ##### Post Metadata

# What is Google Cloud Operations (formerly Stackdriver) used for? What is Google Cloud Operations (formerly Stackdriver) used for? ##### Post Metadata

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

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

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

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

# 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 - Net upvotes: 1

# What is the best way to learn Stackdriver? ? ##### Post Metadata - Net upvotes: 1