Emit a metric for tablets that have more files than the scan max and are not compacting
- Dominant language
- Java
- Stars
- 1.2k
- Forks
- 487
- Avg merge
- 4d 5h
- Merged PRs (30d)
- 13
Description
**Is your feature request related to a problem? Please describe.**
This issue is about the problem described in #4089
**Describe the solution you'd like**
Accumulo will periodically iterate through all tablets and plan compactions for each tablet (this happens [here](https://github.com/apache/accumulo/blob/f9897862dd4e6ff4892239ff5ebeb8ed6e34bc68/server/tserver/src/main/java/org/apache/accumulo/tserver/compactions/CompactionManager.java#L98-L184)). When it does this it should count tablets that are over the scan file max, are not currently running any compactions, and did not plan any new compactions. This count should be emitted as a per compaction service metric after each iteration through all tablets.
**Describe alternatives you've considered**
#4089 outlines logging a periodic warning for this same situation.
Contributor guide
Research direction
Start in server/tserver/src/main/java/org/apache/accumulo/tserver/compactions/CompactionManager.java, around the tablet iteration at lines 98-184, and inspect how per-compaction-service metrics are emitted. Trace the existing compaction planning results and verify the count is emitted after each full iteration for tablets exceeding the scan file max without active or newly planned compactions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend, observability
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 38/100