Skip to content

Conversation

@abhishekrb19
Copy link
Contributor

@abhishekrb19 abhishekrb19 commented Dec 23, 2025

The metrics ingest/merge/time, ingest/merge/cpu and ingest/persists/cpu metrics have been documented but were previously reported as zero because they were not set in the streaming and batch appendators (it probably regressed in a refactor).

These metrics are now set by the appendators and will be reported during the persist and merge phases for realtime and batch ingestion. Updated unit tests to verify that these values are emitted (non-zero values).

Also, cleaned up KafkaIndexTaskTest and KinesisIndexTaskTest by initializing a StubServiceEmitter as a non-static member in the base class SeekableStreamIndexTaskTestBase so it can be used by each unit test as needed.

Release note

Correctly report ingest/merge/time, ingest/merge/cpu and ingest/persists/cpu metrics for streaming and batch ingestion tasks, which were previously always misreported as zero values.

This PR has:

- Adds the missing streaming appendator metrics
for ingest/merge/time, ingest/merge/cpu and ingest/persists/cpu
Init ServiceEmitter as non-static to reuse individually for
each test

Add a helper in the base class for asserting segment generation metrics
@abhishekrb19 abhishekrb19 changed the title Emit missing ingest/merge/time, ingest/merge/cpu and ingest/persists/cpu metrics for streaming tasks Emit missing ingest/merge/time, ingest/merge/cpu and ingest/persists/cpu metrics Dec 23, 2025
Copy link
Contributor

@jtuglu1 jtuglu1 left a comment

Choose a reason for hiding this comment

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

LGTM – left minor comments.

throw e;
}
finally {
metrics.incrementNumPersists();
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: can we move the increments below the time-sensitive metric emissions? Given we are reporting at nano-scale, chance of interrupt and/or delay due to atomic load+store can skew the nano count by X-XXns.

identifier,
segment.getSize(),
indexes.size(),
(mergeFinishTime - startTime) / 1000000,
Copy link
Contributor

@jtuglu1 jtuglu1 Dec 23, 2025

Choose a reason for hiding this comment

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

👍 We should probably make sure this is not being done elsewhere. For future readers, System.nanoTime() is actually more expensive than System.getCurrentTimeMillis() so if you need milli-level precision, just use the latter from the start. Milli itself is also expensive: https://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants