Skip to content

executor: stop fabricating log_rate=0 in the container metrics processor - #1213

Open
acosta11 wants to merge 2 commits into
cloudfoundry:developfrom
acosta11:fix/remove-fabricated-log-rate-emit
Open

acosta11 wants to merge 2 commits into
cloudfoundry:developfrom
acosta11:fix/remove-fabricated-log-rate-emit

Conversation

@acosta11

Copy link
Copy Markdown
Member

Summary

App log rate sporadically incorrectly shows as 0 due to a fabricated metric emission that was recently added; remove the metric emission. See commit message for more details.

Backward Compatibility

Breaking Change? No

DefaultMetricsProcessor.ProcessAndSend calls SendAppLogRate(0, 0, tags) on
every container-metrics tick for every container with a source_id, in
addition to depot/log_streamer.logRateLimiter, which already emits the
real log_rate/log_rate_limit gauge pair on its own ticker whenever
container_metrics_report_interval (rep job property) is enabled.

Both components send envelopes with the same metric-key set (source_id +
instance_id), and CAPI's ContainerMetricBatcher deduplicates incoming
envelopes by that key. Which value wins depends on arrival order, so the
fabricated zero from this path intermittently displaces the real
measurement in `cf app` / Log Cache output, making log rate limiting look
disabled even when it is actively throttling.

There is no reason for the metrics processor to emit this metric at all:
it always sends 0, 0 — never a real reading — and removing it does not
change the emitter that actually measures log rate.

Added a spec asserting SendAppLogRate is never called by the metrics
processor; log_rate now comes from exactly one place in this codebase,
depot/log_streamer/log_rate_limiter.go:109.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mariash
mariash previously approved these changes Sep 28, 2026
Comment thread src/code.cloudfoundry.org/executor/containermetrics/reporters_runner_test.go Outdated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Pending Merge | Prioritized

Development

Successfully merging this pull request may close these issues.

3 participants