support for per request/principal domain metrics

[havetisyan]

Description

By default, only a single metric is recorded where the request and principal domain names are specified as labels along with the API name, http status code, and the http method. With this default behavior the cardinality of the metrics could result in a large number of time series which could be difficult to manage. By setting this property to true, 3 metrics are generated and reported:

• {metric-name}_requestDomain - only contains a single attribute - requestDomainName
• {metric-name}_principalDomain - only contains a single attribute - principalDomainName
• {metric-name} - contains 3 attributes, httpMethod, apiName and httpStatusCode

This will significantly reduce the cardinality of the metrics recorded.

Contribution Checklist:

• The pull request does not introduce any breaking changes
• I have read the contribution guidelines.
• Create an issue and link to the pull request.

Attach Screenshots (Optional)

[gemini-code-assist]

Summary of Changes

Hello @havetisyan, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses the potential for high cardinality in OpenTelemetry metrics by introducing a configurable mechanism to separate domain-specific attributes into distinct metrics. Previously, a single metric captured all details (request domain, principal domain, API name, HTTP status, method), which could lead to an explosion of time series. With the new athenz.otel_separate_domain_metrics property, users can opt to generate three separate metrics—one for request domain, one for principal domain, and a third for core API attributes—thereby significantly reducing overall metric cardinality and improving manageability.

Highlights

• Metric Cardinality Reduction: Introduced a new configuration property, athenz.otel_separate_domain_metrics, to manage and reduce the cardinality of OpenTelemetry metrics by separating domain-specific attributes.
• Separate Domain Metrics Implementation: When the new property is enabled, instead of a single metric with multiple labels, three distinct metrics are generated: one for the request domain, one for the principal domain, and a third for general API attributes (HTTP method, status, API name).
• OpenTelemetry Integration Updates: Modified the OpenTelemetryMetric class to conditionally apply the new metric separation logic for both counter increments and timer recordings, ensuring attributes are correctly assigned to the appropriate metric.
• New Dependency Added: The jetty-util library has been added as a new dependency to the server_common module.
• Enhanced Test Coverage: New unit tests have been added and existing ones updated in OpenTelemetryMetricTest to thoroughly validate the behavior of the separate domain metrics functionality for both incrementing counters and stopping timers.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a feature to separate metrics by domain to reduce cardinality, controlled by a new system property. The implementation refactors the metric increment and timing logic to handle this new separation. While the overall approach is sound, I've identified a potential issue where the refactoring might lead to unintended extra metrics being reported. I've suggested a fix to prevent this. Additionally, I've provided some feedback on improving the robustness of the new tests.