Metric 'http.server.request.count' is not available by default for GCE VM

[prasun-dutta]

Describe the bug
We are unable to create an Availability SLI for an auto-instrumented Java application running on a GCE VM.

To Reproduce
Steps to reproduce the behavior:

1. Start a GCE VM with RHEL8 image
2. Install Ops Agent version 2.46.1
3. Customize the agent with below mentioned metrics processor configuration

transform/http_server_request_count:
metric_statements:
- context: metric
statements:
- extract_count_metrics(true) where name == "workload.googleapis.com/http.server.request.duration"
- set(name, "workload.googleapis.com/http.server.request.count") where name == "workload.googleapis.com/http.server.request.duration_count"
- set(unit, "1") where name == "workload.googleapis.com/http.server.request.count"
- set(description, "Count of HTTP server requests.") where name == "workload.googleapis.com/http.server.request.count"

4. Add the transform metrics processor 'transform/http_server_request_count' to the metrics service configuration
5. Restart the agent
6. Hit the Java application endpoint on localhost and port on the GCE VM a few times
7. Metric 'http.server.request.count' should be available in Metrics Explorer

Expected behavior
Metric 'http.server.request.count' should be available by default for auto-instrumented application running on GCE VM.

Environment (please complete the following information):

• VM distro / OS: RHEL 8
• Ops Agent version: 2.46.1

Additional context
Currently, the metric 'http.server.request.duration' is available by default for an auto-instrumented application. And, we are able to get the count of Server requests using this metric by aggregating it on 'Count time series'.

However, that does not help me while creating the Availability SLI (Request Based - Good/Total Ratio) for the Java application. The metric 'http.server.request.duration' can only be used to create a Latency SLI (Request Based - Distribution Cut).

Would it be possible to add the configuration mentioned in Step 3 and 4 in the default otel.yaml? Or please suggest if there is any better way to handle this scenario.

Thanks in advance.

[sophieyfang]

Upstream OSS Community provides solution to support above need. To gather more user data points, may i ask why you'd prefer ops-agent for this need? This will help us on prioritizing the work. Thanks!

[sophieyfang]

If you are able to, would you mind also creating a cloud support ticket with us?