Skip to content

[router]Integrate router request_size, response_size and key_size metrics to otel #1939

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 22 commits into
base: main
Choose a base branch
from

Conversation

namithanivead
Copy link
Contributor

@namithanivead namithanivead commented Jul 17, 2025

Problem Statement

Add router request_size, response_size and key_size metrics in OTel

Solution

This change add

  • CALL_SIZE metrics in Otel with dimensions request and response sizes. Along with this tehuti metrics request_size, response_size will also be updated
  • KEY_SIZE to measure the keysize in bytes when KeyValueProfilingEnabled

Code changes

  • Added new code behind a config. If so list the config names and their default values in the PR description.
  • Introduced new log lines.
    • Confirmed if logs need to be rate limited to avoid excessive logging.

Concurrency-Specific Checks

Both reviewer and PR author to verify

  • Code has no race conditions or thread safety issues.
  • Proper synchronization mechanisms (e.g., synchronized, RWLock) are used where needed.
  • No blocking calls inside critical sections that could lead to deadlocks or performance degradation.
  • Verified thread-safe collections are used (e.g., ConcurrentHashMap, CopyOnWriteArrayList).
  • Validated proper exception handling in multi-threaded code to avoid silent thread termination.

How was this PR tested?

  • [ X] New unit tests added.
  • New integration tests added.
  • Modified or extended existing tests.
  • Verified backward compatibility (if applicable).

Does this PR introduce any user-facing or breaking changes?

  • [ X] No. You can skip the rest of this section.
  • Yes. Clearly explain the behavior change and its impact.

@namithanivead namithanivead marked this pull request as draft July 17, 2025 05:07
@@ -101,7 +103,8 @@ public class RouterHttpRequestStats extends AbstractVeniceHttpStats {
private final Sensor badRequestKeyCountSensor;

/** OTel metrics yet to be added */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Move this comment to be below the requestSizeMetric metric.

CALL_SIZE.getMetricEntity(),
otelRepository,
this::registerSensorFinal,
RouterTehutiMetricNameEnum.REQUEST_SIZE,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will add RESPONSE_SIZE to this PR as well right?

otelRepository,
this::registerSensorFinal,
RouterTehutiMetricNameEnum.REQUEST_SIZE,
singletonList(new Avg()),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Original requestSizeSensor was not just Avg()

it had TehutiUtils.getPercentileStat(getName(), getFullMetricName("request_size")), new Avg()

@@ -179,6 +184,8 @@ public RouterHttpRequestStats(
Rate requestRate = new OccurrenceRate();
Rate healthyRequestRate = new OccurrenceRate();
Rate tardyRequestRate = new OccurrenceRate();
SampledStat requestSize = new Avg();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is requestSize used somewhere else? If not, I think we can remove the local variable.

* Size of request and response in bytes
*/
CALL_SIZE(
MetricType.HISTOGRAM, MetricUnit.NUMBER, "Size of request and response in bytes",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@m-nagarajan , probably a question for you, do we have to define a new unit for bytes here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added new unit for BYTES

Comment on lines +102 to +104
assertEquals(
metricsRepository.getMetric("." + storeName + "--" + REQUEST_SIZE.getMetricName() + ".Avg").value(),
512.0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this only tests the tehuti metrics part, can we also add a test to verify the correctness of the OTEL metrics?

@namithanivead namithanivead changed the title [router]Integrate router request_size metrics to otel [router]Integrate router request_size, response_size and key_size metrics to otel Jul 21, 2025
@namithanivead namithanivead marked this pull request as ready for review August 1, 2025 18:24
Comment on lines +473 to +474
if (isKeyValueProfilingEnabled) {
if (storeName.equals(STORE_NAME_FOR_TOTAL_STAT)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite follow why we changed the condition here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The condition was updated to handle metric creation correctly based on the type of profiling enabled (isKeyValueProfilingEnabled) and the specific store being monitored (storeName).
When isKeyValueProfilingEnabled is true:

If storeName.equals(STORE_NAME_FOR_TOTAL_STAT), we only want to emit Tehuti metrics (not OTEL). So, we create the metrics the same way, but pass null for OTEL to ensure only Tehuti sensors are registered.

For other stores (i.e., storeName != STORE_NAME_FOR_TOTAL_STAT), we only want to emit OTEL metrics (not Tehuti), so we skip the Tehuti sensor setup.

When isKeyValueProfilingEnabled is false:

We fallback to the default behavior: emit OTEL metrics for response size only (no key size sensors).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants