Skip to content

Split a metric when there're more than 100 data points #74

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

Merged
merged 2 commits into from
Apr 22, 2021

Conversation

yaozhaoy
Copy link
Contributor

Issue #, if available:
Metric Value List can go above MetricDefinition limits, causing CW missing metrics

Description of changes:

Split a metric into multiple log events if the metric has more than 100 data points

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@yaozhaoy yaozhaoy requested a review from jaredcnance April 21, 2021 17:32
}

@Test
public void testSerializeMetricsWith101DataPoints() throws JsonProcessingException {
Copy link
Member

Choose a reason for hiding this comment

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

The main purpose of this test is just to verify that splitting doesn't impact other metric data points added to the context?

Copy link
Contributor Author

@yaozhaoy yaozhaoy Apr 22, 2021

Choose a reason for hiding this comment

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

Yes. It also tests that the other metrics should also be included in the first event if there're less than 100 metrics for the first event.

metrics.put(metric.getName(), metric);
count++;
Queue<MetricDefinition> metricDefinitions =
new LinkedList<>(rootNode.metrics().values());
Copy link
Member

@jaredcnance jaredcnance Apr 22, 2021

Choose a reason for hiding this comment

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

  1. My personal preference here is to not use the abstract interface for your local variable. The concrete type (LinkedList) won't be changing and there's not much of a need to limit yourself to only the interface. This is just a style comment not a perf comment (dynamic dispatch won't be necessary in this context) so YMMV.
  2. This constructor forces enumeration of the set and allocation of a new list. Is this really necessary? It shouldn't be a significant issue, just something to think about.

Queue<MetricDefinition> metricDefinitions =
new LinkedList<>(rootNode.metrics().values());
while (metricDefinitions.size() > 0) {
MetricDefinition metric = metricDefinitions.peek();
Copy link
Member

Choose a reason for hiding this comment

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

Do we need peek() if we're going to poll() regardless? Can we just poll() here?

@jaredcnance
Copy link
Member

jaredcnance commented Apr 22, 2021

Build was throttled by DockerHub rate limit (still need to migrate images over to ECR). Build succeeded on retry.

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.

2 participants