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.

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

Alert conditions do not appear properly after cloning a stream #3608

Closed
ssriley opened this issue Mar 14, 2017 · 1 comment
Closed

Alert conditions do not appear properly after cloning a stream #3608

ssriley opened this issue Mar 14, 2017 · 1 comment
Assignees
Milestone

Comments

@ssriley
Copy link

ssriley commented Mar 14, 2017

When cloning a stream with alert conditions, the alert conditions show up only associated to the newly cloned stream in the web interface.

Expected Behavior

I would expect to be able to manage the alert conditions that are associated to with the original stream and the cloned stream.

What should happen is the newly cloned alert conditions have some text appended to the name so it is unique. That may fix the issue? What would be better is if the alert conditions aren't cloned at all with a stream but rather you could create an alert condition(s) under the alerts section, put them in groups, and apply those alert conditions/groups to streams. This would make the alert conditions more modular and reusable. Similar to how you have setup pipelines rules.

Current Behavior

You do not see the cloned alert conditions associated to both the original stream and the newly cloned stream in the web interface. So the problem is i can't manage the the alert conditions of the original stream in the web GUI because i can't see them. The alert conditions do continue to work with both streams. I think it is because the alert conditions have the exact same name. If I delete the cloned stream, i can then manage the original alert conditions that are tied to the original stream. It seems as though this is a bug.

Possible Solution

Steps to Reproduce (for bugs)

1.Create a stream with alert conditions
2.Clone the stream
3.Try to independently manage the alert conditions associated with the different streams.
4.

Context

We want to make stream template that has most alert conditions and rules already setup so we only have to change a few things when setting up a new stream. We don't want to have to setup everything from scratch each time.

Templating. Making creating streams and alert conditions quicker and easier.

Your Environment

  • Graylog Version: Graylog 2.2.2+691b4b7
  • Elasticsearch Version: 2.4.4
  • MongoDB Version: 2.6.10
  • Operating System: Ubuntu 16.04 LTS
  • Browser version: Chrome 57.0.2987.98 (64-bit)
@jalogisch
Copy link
Contributor

thank you for submitting this bug.

I can confirm this, please see the images below. GL Graylog 2.2.2+691b4b7

one condition

only_one_condition

multiple notifications

alert_interface

addition

The conditions are stacked - when you delete the condition you can reload the page and see the alerting stream changed but the condition still present.

I guess some grouping is done and having the same name and conditions but for different streams does not work currently.

@dennisoelkers dennisoelkers self-assigned this Mar 15, 2017
@dennisoelkers dennisoelkers added this to the 2.2.3 milestone Mar 15, 2017
dennisoelkers added a commit that referenced this issue Mar 15, 2017
Before this change, any alert conditions associated with a stream were
cloned identically (including using the same id) when cloning a stream.
This was leading to a bug, where the alert condition was shown as being
associated with the source of the clone process instead of the target.

With this change, the alert condition is recreated during cloning,
including generating a new id for it.

Fixes #3608.
dennisoelkers added a commit that referenced this issue Mar 15, 2017
Before this change, any alert conditions associated with a stream were
cloned identically (including using the same id) when cloning a stream.
This was leading to a bug, where the alert condition was shown as being
associated with the source of the clone process instead of the target.

With this change, the alert condition is recreated during cloning,
including generating a new id for it.

Fixes #3608.

(cherry picked from commit 0a9f75b)
@ghost ghost assigned joschi Mar 16, 2017
@ghost ghost removed the in progress label Mar 16, 2017
joschi pushed a commit that referenced this issue Mar 16, 2017
…3615)

Before this change, any alert conditions associated with a stream were
cloned identically (including using the same id) when cloning a stream.
This was leading to a bug, where the alert condition was shown as being
associated with the source of the clone process instead of the target.

With this change, the alert condition is recreated during cloning,
including generating a new id for it.

Fixes #3608
(cherry picked from commit 8bfc584)
joschi pushed a commit that referenced this issue Mar 16, 2017
…3616)

Before this change, any alert conditions associated with a stream were
cloned identically (including using the same id) when cloning a stream.
This was leading to a bug, where the alert condition was shown as being
associated with the source of the clone process instead of the target.

With this change, the alert condition is recreated during cloning,
including generating a new id for it.

Fixes #3608

(cherry picked from commit 0a9f75b)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants