Assigned
Status Update
Comments
se...@google.com <se...@google.com> #2
Hello,
Thank you for reaching out. I'm going to create an internal feature request. Please keep in mind that this feature request has to be analyzed and considered by the product team and I can't provide you ETA for it to be delivered. However, you can keep track of the status by following this thread.
i....@saltosystems.com <i....@saltosystems.com> #3
Any update?
[Deleted User] <[Deleted User]> #4
We'd be very interested in such a feature!
Description
This will create a feature request which anybody can view and comment on.
Please describe your requested enhancement. Good feature requests will solve common problems or enable new use cases.
What you would like to accomplish:
We are currently experiencing an issue with really high outbound network latency from the serverless environment (which there is an open P1 for, but besides the point).
To help us debug, we've had to provide support / SRE with some metrics to show how slow things can be: we are already ingesting a lot of application performance data into Cloud Trace that shows the problem, but there is no way to turn it into a time series metric, which is what SRE want to see an overview of the problem.
We'd like the ability to (without modifying the application) get a distribution metric into Monitoring based on ingested trace spans: in the same way a Logging metric works.
How this might work:
Just like Logging metrics, we'd set a filter (default service, App Engine) and a span type or filter ("sql/query") and it would be ingested as a distribution metric.
In Monitoring, we could have graphing and alerting on a mean average or percentiles.
If applicable, reasons why alternative solutions are not sufficient:
At the moment, we've deployed specific test applications in another App Engine version, that logs timing information that is picked up by Logging metrics.
This has been enough to give a rough idea during the case, but it just runs every minute from Cloud Scheduler, so it doesn't give as broad a picture of real application performance, that we do frustratingly have locked away in the existing trace spans.
Other information (workarounds you have tried, documentation consulted, etc):