Skip to content

Conversation

@boratanrikulu
Copy link
Member

Summary

  • Fix Apache metrics corruption where field names contained 64+ repeated "apache." prefixes
  • Add deduplicatePrefix() function to normalize measurement names before building lookup keys
  • Add unit tests for the deduplication logic

Technical Details

Root Cause

When originalName arrives corrupted (e.g., "apache.apache.apache..."), the field lookup key at rename.go:220 becomes:

"apache.apache.apache...BusyWorkers"

This doesn't match fieldReplaces["apache.BusyWorkers"], so it falls back to ChangeNames() which returns the corrupted name.

Fix

The deduplicatePrefix() function normalizes corrupted measurement names before building lookup keys:

  • "apache.apache.apache""apache"
  • "nginx.nginx.nginx""nginx"

This ensures the lookup key is always "apache.BusyWorkers" which correctly maps to "workers.busy".

Test Plan

  • Unit tests for deduplicatePrefix() covering normal inputs and edge cases
  • Integration test with corrupted measurement name verifying correct field rename

…ixes

Fix Apache metrics corruption where field names contained 64+ repeated
"apache." prefixes (e.g., "apache.apache.apache...bytespersec").

The root cause: when originalName arrives corrupted, the lookup key
becomes "apache.apache.apache.BusyWorkers" which doesn't match
fieldReplaces["apache.BusyWorkers"], falling back to ChangeNames()
which preserves the corruption.

The fix adds deduplicatePrefix() to normalize measurement names before
building lookup keys (e.g., "apache.apache.apache" → "apache").
@otisg
Copy link
Member

otisg commented Jan 25, 2026

When originalName arrives corrupted (e.g., "apache.apache.apache..."), ....

But why does it arrive corrupted? Where does it come from in this corrupt format? Isn't that what we should figure out and fix the problem at the source?

@boratanrikulu
Copy link
Member Author

But why does it arrive corrupted? Where does it come from in this corrupt format? Isn't that what we should figure out and fix the problem at the source?

Yes valid questions but I couldn't find the source so far. If I understand correctly it could be related to re-try logic but I'm not total sure.

@boratanrikulu
Copy link
Member Author

even with patch, still seeing weird names, will close this for now.

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