Assigned
Status Update
No update yet.
Comments
me...@google.com
I have forwarded this request to the engineering team. We will update this issue with any progress updates and a resolution.
er...@disney.io
Hello! Sorry to bring up this issue after almost a year but I wanted to add that we have chosen metric identifier as agent.googleapis.com/memory/percent_used but autoscaling didnt work out for us either. It would be appraciated if you can guide us.
er...@disney.io
Hi, at the moment we are using the cpu_utilization/target_utilization attribute (in app.yaml) for autoscaling in the app engine flexible environment, however it would be great if we can have the way to mention the memory_utilization metrics as well to decide on the auto scaling. It will give us more control of the auto scaling the instances than now.
me...@google.com
Hi, I do not see any memory metrics in neither console nor stackdriver. Is this connected to this issue?
al...@loblaw.ca
Hello Google team, I was directed to this issue by the support team when we raised concerns around the non availability of memory metrics for Auto Scaling. Is this feature 'released' or in roadmap or not considered ? Please provide some details around this
yi...@gmail.com
Hi ,
Can somebody tell the exact metric for memory based autoscaling
Can somebody tell the exact metric for memory based autoscaling
vi...@sportserve.co
May be enhance the functionality of snooze option and create an ability to schedule alert snoozing (like cron) for a defined period.
Very much needed
Very much needed
Description
Create a schedule of Cloud monitoring alert policies. I.e. the alert policy will be enable for 2 hours of the day and disabled for 20 hours.
How this might work:
Ideally this should replicate the functionality of a cron job, which can be set from the console, gcloud command or API.
If applicable, reasons why alternative solutions are not sufficient:
One example you can use Google Cloud Cron http request [1] to update the the alerting policy, setting the alerting policy to disabled/enabled using [2]. When I was replicating this functionality I used [3] to grab the policy as JSON, then to update the policy from enable to disabled you can set the `enabled:` field to `false'.
The down side to this approach is visibility. If another user where to look at this policy it would not be clear why/how the policy has been disabled/enabled/
[1]
[2]
[3]