You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Changed remote write queue_config fields like max_shards, capacity, max_samples_per_send.
SIGHUP'd the server.
What did you expect to see?
New config to be applied.
What did you see instead? Under which circumstances?
A panic.
After the following restart, the server came back OK. It's just that with a runtime config reload, the metrics of the new remote write queues collide with the old metrics.
Somehow, the unregister call added in #7188 isn't called in time or doesn't work as expected.
@beorn7 I think I know what the issue is, but to make sure, did this only happen when you changed a remote write config that has a name? Or does it happen on queues with auto-generated names as well?
The reported case happened with named queues. We currently do not have queues with auto-generated names. (I guess if the auto-generated name changes because of the parameter changes, then there won't be a problem because the name is part of the registration.)
What did you do?
Changed remote write
queue_config
fields likemax_shards
,capacity
,max_samples_per_send
.SIGHUP'd the server.
What did you expect to see?
New config to be applied.
What did you see instead? Under which circumstances?
A panic.
After the following restart, the server came back OK. It's just that with a runtime config reload, the metrics of the new remote write queues collide with the old metrics.
Somehow, the unregister call added in #7188 isn't called in time or doesn't work as expected.
Environment
Prometheus version:
2.19.1
Logs:
The text was updated successfully, but these errors were encountered: