Closed litepl closed 4 months ago
I don't know about this... you can write your own listener and catch RefreshScopeRefreshedEvent
, right?
I was not too verbose on the above comment, but IMO, I don't understand what log statement you would want.
When we log: "Detected change in config maps" for example, we know that a change has happened, as such we issue that log statement. But in case of calling /actuator/refresh
- what would you expect to happen? Something along the lines of :
refresh endpoint called, reloading configmap/secret based property sources.
If so, then why can't you do it in your app? You will need something along the lines of:
class MyListener implements ApplicationListener<RefreshScopeRefreshedEvent> {
@Override
public void onApplicationEvent(RefreshScopeRefreshedEvent event) {
// log whatever you want
}
}
register this one as a @Bean/@Component/etc
and you are good. We could probably add it too, but that might be, or not be a good option.
@ryanjbaxter thoughts?
I don't think that this is what OP is asking for. That log statement still comes when we receive an event from kubernetes about the state of a certain configmap.
What they want is a log statement when /actuator/refresh
is called directly, like with curl
for example. This is how I read this, at least.
Exactly. That's because of migration to Spring Cloud Configuration Watcher which calls /actuator/refresh.
@litepl I think you should have mentioned that in the initial description. We have a bunch of logs from configuration watcher side for this. At the moment they are on debug
mode though. For example, this this log statement.
But again, that is in the configuration watcher, not your application. Will that suite your needs?
Not exactly. To me, it'd be better to have that information in the app's log, not in sckcw ones. It's easier to create alerts for that as an example.
Yes. Not I want to, I would like to :D It's a kind request
I am still inclined not to do this. A log statement there does nothing useful, imho; but if someone really needs it, its really easy to write your own Listener as outlined above.
Especially since a call to /refresh
might come from some other caller, not only the configuration watcher. We can't even distinguish where the call comes from, as such the log statement can not even contain "configmaps" or "secrets" words.
We do have proper logs that would make far more sense and they come from the configuration watcher, from the source. If alerts can be created on the app, then Im sure alerts can be created on the watcher also.
This is my view on this issue, at least at the moment :)
Well this is not the repo for the request as the code that handles the /refresh
endpoint lives in Spring Cloud Commons. It is not specific to Kubernetes its any Spring Cloud application. If you would like, you can submit a PR to add the log statement and we can see what the rest of the team thinks.
Is your feature request related to a problem? Please describe. When an "old-style" reload finds some changes in configmap o secret it puts some info into the log like:
calling /actuator/refresh says nothing in the log
Describe the solution you'd like It would be nice to have such a log when calling /actuator/refresh endpoint
Describe alternatives you've considered None
Additional context None