Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Graylog 3.0: Sidecar not updating Filebeat configuration when switching configurations #352

Closed
bitfactory-henno-schooljan opened this issue Feb 21, 2019 · 0 comments
Closed

Graylog 3.0: Sidecar not updating Filebeat configuration when switching configurations #352

bitfactory-henno-schooljan opened this issue Feb 21, 2019 · 0 comments
Assignees
@mpfz0r
Labels
bug triaged

Comments

@bitfactory-henno-schooljan
Copy link

When there is already a configuration applied to a sidecar in Graylog 3.0, the sidecar does not reload its configuration immediately when a new configuration is applied. However it will apply its new configuration when doing one of these things:

  • first removing the configuration using 'Clear selection' and then reapplying a configuration.
  • restarting the Sidecar process.
  • editing the configuration itself.
  • restarting the Graylog server.

Expected Behavior

When a configuration is applied to a sidecar collector and we apply a different configuration, it should reload its configuration without any further action.

Current Behavior

When a configuration is applied to a sidecar collector and we apply a different configuration, it does not reload its configuration unless we first remove the configuration, restart the Sidecar ourselves, restart the Graylog server or edit the configuration itself.

Steps to Reproduce (for bugs)

  1. Create 2 different configurations.
  2. Create a sidecar with a filebeat collector.
  3. Apply configuration 1 to the filebeat collector.
  4. Sidecar will reconfigure itself.
  5. Apply configuration 2 to the filebeat collector.
  6. Sidecar will not reconfigure itself.

Your Environment

  • Graylog Version: 3.0.0
  • Elasticsearch Version: 6.4.2
  • MongoDB Version: 3.2.11
  • Operating System: Debian 9.8

Extra notes

  • Since this is a Graylog - Sidecar communication issue, the issue is reproduced in Graylog itself, and I do not have detailed knowledge of the internals, I filed this under the Graylog project. My apologies if it turns out to be a Sidecar specific issue ;-)
  • I also only have Filebeat to test with, maybe this affects other collectors as well.
@mpfz0r mpfz0r self-assigned this Mar 6, 2019
@mpfz0r mpfz0r transferred this issue from Graylog2/graylog2-server Mar 7, 2019
mpfz0r added a commit that referenced this issue Mar 7, 2019
@mpfz0r
Wipe configchecksums also on assignment changes
d68d605 
If an assignemnt is changed to switch a backend from
one configuration to another, we would still send configuration requests
using the old checksum.
The server will respond with `NotModified` and we don't try to restart
the backend.

Instead of also resetting the checksum when we update the assignment
store, simply wipe the entire checksum map if either the assignment
or the backends have changed.

Fixes #352
@mpfz0r mpfz0r mentioned this issue Mar 7, 2019
Merged
mpfz0r added a commit that referenced this issue Mar 8, 2019
@mpfz0r
Wipe configchecksums also on assignment changes
5cbc3d2 
If an assignemnt is changed to switch a backend from
one configuration to another, we would still send configuration requests
using the old checksum.
The server will respond with `NotModified` and we don't try to restart
the backend.

Instead of also resetting the checksum when we update the assignment
store, simply wipe the entire checksum map if either the assignment
or the backends have changed.

Fixes #352
mariussturm pushed a commit that referenced this issue Mar 11, 2019
@mpfz0r
Wipe configchecksums also on assignment changes (#353)
dca0b17 
If an assignemnt is changed to switch a backend from
one configuration to another, we would still send configuration requests
using the old checksum.
The server will respond with `NotModified` and we don't try to restart
the backend.

Instead of also resetting the checksum when we update the assignment
store, simply wipe the entire checksum map if either the assignment
or the backends have changed.

Fixes #352
mpfz0r added a commit that referenced this issue Apr 1, 2019
@mpfz0r
Wipe configchecksums also on assignment changes (#353)
778dae4 
If an assignemnt is changed to switch a backend from
one configuration to another, we would still send configuration requests
using the old checksum.
The server will respond with `NotModified` and we don't try to restart
the backend.

Instead of also resetting the checksum when we update the assignment
store, simply wipe the entire checksum map if either the assignment
or the backends have changed.

Fixes #352

(cherry picked from commit dca0b17)
@mpfz0r mpfz0r mentioned this issue Apr 1, 2019
Merged
mariussturm pushed a commit that referenced this issue Apr 1, 2019
@mpfz0r
Wipe configchecksums also on assignment changes (backport) (#357)
09e30f3 
* Wipe configchecksums also on assignment changes (#353)

If an assignemnt is changed to switch a backend from
one configuration to another, we would still send configuration requests
using the old checksum.
The server will respond with `NotModified` and we don't try to restart
the backend.

Instead of also resetting the checksum when we update the assignment
store, simply wipe the entire checksum map if either the assignment
or the backends have changed.

Fixes #352

(cherry picked from commit dca0b17)

* Bump version to 1.0.1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mpfz0r mpfz0r

Labels
bug triaged
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mpfz0r @bitfactory-henno-schooljan