[
https://issues.apache.org/jira/browse/CAMEL-23650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18085858#comment-18085858
]
Karol Krawczyk commented on CAMEL-23650:
----------------------------------------
Investigated this. Confirming the behavior and where it comes from:
The verbose shutdown dump isn't enabled by Camel core defaults —
camel.metrics.logMetricsOnShutdown defaults to false. It's turned on by
camel-observability-services, whose observability-services.properties
sets:
camel.metrics.logMetricsOnShutdown=true
camel.metrics.logMetricsOnShutdownFilters=app.info,camel.exchanges.*,process.cpu.usage,jvm.memory.max,jvm.memory.used
camel.metrics.logMetricsOnShutdownFormat=prometheus
At shutdown, MicrometerPrometheus.doStop() then logs each scrape line via
LOG.warn("#METRIC-START#...#METRIC-END#"). The WARN level looks intentional
(the inline comment notes it guarantees the lines print even
at higher log thresholds, so a scraper can recover metrics before the JVM
exits) — which matches the production rationale you mentioned.
So the question is how you'd prefer to fix the dev-mode noise. Two options:
A) Make the component profile-aware: in MicrometerPrometheus.doStop() check
camel.main.profile; when dev, skip the dump (or drop it to INFO/DEBUG) while
keeping WARN for prod.
B) Keep the component logic untouched and stop enabling the flag in dev — e.g.
have the dev/JBang run (or a dev-specific observability-services profile) set
camel.metrics.logMetricsOnShutdown=false.
Which direction do you prefer? Happy to put up the PR once you've picked.
> camel-micrometer - Do not spam log at WARN in dev mode
> ------------------------------------------------------
>
> Key: CAMEL-23650
> URL: https://issues.apache.org/jira/browse/CAMEL-23650
> Project: Camel
> Issue Type: Improvement
> Reporter: Claus Ibsen
> Priority: Minor
> Fix For: 4.21.0
>
>
> 2026-05-29 17:59:21.850 WARN 49747 --- [ main]
> crometer.prometheus.MicrometerPrometheus : Micrometer service is stopping,
> here a list of metrics collected so far.
> 2026-05-29 17:59:21.859 WARN 49747 --- [ main]
> crometer.prometheus.MicrometerPrometheus : #METRIC-START## HELP app_info
> #METRIC-END#
> 2026-05-29 17:59:21.859 WARN 49747 --- [ main]
> crometer.prometheus.MicrometerPrometheus : #METRIC-START## TYPE app_info
> gauge#METRIC-END#
> 2026-05-29 17:59:21.859 WARN 49747 --- [ main]
> crometer.prometheus.MicrometerPrometheus :
> #METRIC-START#app_info\{camel_context="timer-log",camel_runtime_provider="Main",camel_runtime_version="4.21.0-SNAPSHOT",camel_version="4.21.0-SNAPSHOT"}
> 1#METRIC-END#
> 2026-05-29 17:59:21.860 WARN 49747 --- [ main]
> crometer.prometheus.MicrometerPrometheus : #METRIC-START## HELP
> camel_exchanges_last_timestamp Last exchange processed time in milliseconds
> since the Unix epoch#METRIC-END#
> 2026-05-29 17:59:21.860 WARN 49747 --- [ main]
> crometer.prometheus.MicrometerPrometheus : #METRIC-START## TYPE
> camel_exchanges_last_timestamp gauge#METRIC-END#
> 2026-05-29 17:59:21.860 WARN 49747 --- [ main]
> crometer.prometheus.MicrometerPrometheus :
> #METRIC-START#camel_exchanges_last_timestamp 1.780070361573E12#METRIC-END#
> 2026-05-29 17:59:21.860 WARN 49747 --- [ main]
> crometer.prometheus.MicrometerPrometheus : #METRIC-START## HELP
> jvm_memory_max_bytes The maximum amount of memory in bytes that can be used
> for memory management#METRIC-END#
>
> This seems to be for production use when a JVM is crashing and you hope to
> get a little bit of logging before its dead.
>
> But for developers that has fast feedback loop then this is annoying.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
