Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/zerver/webhooks/grafana/tests.py

303 lines
8.2 KiB
Python
Raw Normal View History

integrations: Add an incoming webhook for Grafana. Tweaked by tabbott to use formatted suggested in one of the various duplicate PRs for this issue, showing the rule name clearly. Fixes #12951.
2020-04-15 06:06:49 +02:00
from zerver.lib.test_classes import WebhookTestCase
class GrafanaHookTests(WebhookTestCase):
webhooks: Rename STREAM_NAME to CHANNEL_NAME in tests.
2024-05-04 22:02:50 +02:00
CHANNEL_NAME = "grafana"
integrations: Add an incoming webhook for Grafana. Tweaked by tabbott to use formatted suggested in one of the various duplicate PRs for this issue, showing the rule name clearly. Fixes #12951.
2020-04-15 06:06:49 +02:00
URL_TEMPLATE = "/api/v1/external/grafana?&api_key={api_key}&stream={stream}"
webhook: Rename FIXTURE_DIR_NAME to WEBHOOK_DIR_NAME. Since FIXTURE_DIR_NAME is the name of the folder that contains the view and tests modules of the webhook and another folder called "fixtures" that store the fixtures, it is more appropriate to call it WEBHOOK_DIR_NAME, especially when we want to refer to the view module using this variable.
2021-06-26 09:18:33 +02:00
WEBHOOK_DIR_NAME = "grafana"
integrations: Add an incoming webhook for Grafana. Tweaked by tabbott to use formatted suggested in one of the various duplicate PRs for this issue, showing the rule name clearly. Fixes #12951.
2020-04-15 06:06:49 +02:00
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
def test_alert_v7(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "[Alerting] Test notification"
integrations: Add an incoming webhook for Grafana. Tweaked by tabbott to use formatted suggested in one of the various duplicate PRs for this issue, showing the rule name clearly. Fixes #12951.
2020-04-15 06:06:49 +02:00
expected_message = """
integrations: Enhance Grafana integration with alert state. Having the alert state in the message body is useful when alert topics are not defined by alert description but encoded in the url. E.g. in large environments having a topic for each alert [alerting] and [ok] would make it harder to properly track if an alert has been resolved. When each alert is in a single topic, so far, the alert state has been missing. This change will add the current alert state and a fitting icon in front of the alert name.(Similar to the prometheus alertmanager integration) The test cases have been amended to cover all possible alert states, even though realistically grafana only fires the ok and alerting states via webhook.
2021-05-24 23:25:33 +02:00
:alert: **ALERTING**
integrations: Add an incoming webhook for Grafana. Tweaked by tabbott to use formatted suggested in one of the various duplicate PRs for this issue, showing the rule name clearly. Fixes #12951.
2020-04-15 06:06:49 +02:00
[Test rule](http://localhost:3000/)
Someone is testing the alert notification within grafana.
**High value:** 100
**Higher Value:** 200
[Click to view visualization](https://grafana.com/assets/img/blog/mixed_styles.png)
""".strip()
webhook tests: Rename main helper to check_webhook. Almost all webhook tests use this helper, except a few webhooks that write to private streams. Being concise is important here, and the name `self.send_and_test_stream_message` always confused me, since it sounds you're sending a stream message, and it leaves out the webhook piece. We should consider renaming `send_and_test_private_message` to something like `check_webhook_private`, but I couldn't decide on a great name, and it's very rarely used. So for now I just made sure the docstrings of the two sibling functions reference each other.
2020-08-23 15:49:24 +02:00
self.check_webhook(
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
"alert_v7",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
webhook tests: Rename main helper to check_webhook. Almost all webhook tests use this helper, except a few webhooks that write to private streams. Being concise is important here, and the name `self.send_and_test_stream_message` always confused me, since it sounds you're sending a stream message, and it leaves out the webhook piece. We should consider renaming `send_and_test_private_message` to something like `check_webhook_private`, but I couldn't decide on a great name, and it's very rarely used. So for now I just made sure the docstrings of the two sibling functions reference each other.
2020-08-23 15:49:24 +02:00
expected_message,
content_type="application/x-www-form-urlencoded",
)
integrations: Add an incoming webhook for Grafana. Tweaked by tabbott to use formatted suggested in one of the various duplicate PRs for this issue, showing the rule name clearly. Fixes #12951.
2020-04-15 06:06:49 +02:00
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
def test_no_data_alert_v7(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "[Alerting] No Data alert"
integrations: Add an incoming webhook for Grafana. Tweaked by tabbott to use formatted suggested in one of the various duplicate PRs for this issue, showing the rule name clearly. Fixes #12951.
2020-04-15 06:06:49 +02:00
expected_message = """
integrations: Enhance Grafana integration with alert state. Having the alert state in the message body is useful when alert topics are not defined by alert description but encoded in the url. E.g. in large environments having a topic for each alert [alerting] and [ok] would make it harder to properly track if an alert has been resolved. When each alert is in a single topic, so far, the alert state has been missing. This change will add the current alert state and a fitting icon in front of the alert name.(Similar to the prometheus alertmanager integration) The test cases have been amended to cover all possible alert states, even though realistically grafana only fires the ok and alerting states via webhook.
2021-05-24 23:25:33 +02:00
:alert: **ALERTING**
integrations: Add an incoming webhook for Grafana. Tweaked by tabbott to use formatted suggested in one of the various duplicate PRs for this issue, showing the rule name clearly. Fixes #12951.
2020-04-15 06:06:49 +02:00
[No Data alert](http://localhost:3000/d/GG2qhR3Wz/alerttest?fullscreen&edit&tab=alert&panelId=6&orgId=1)
The panel has no data.
""".strip()
webhook tests: Rename main helper to check_webhook. Almost all webhook tests use this helper, except a few webhooks that write to private streams. Being concise is important here, and the name `self.send_and_test_stream_message` always confused me, since it sounds you're sending a stream message, and it leaves out the webhook piece. We should consider renaming `send_and_test_private_message` to something like `check_webhook_private`, but I couldn't decide on a great name, and it's very rarely used. So for now I just made sure the docstrings of the two sibling functions reference each other.
2020-08-23 15:49:24 +02:00
self.check_webhook(
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
"no_data_alert_v7",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
webhook tests: Rename main helper to check_webhook. Almost all webhook tests use this helper, except a few webhooks that write to private streams. Being concise is important here, and the name `self.send_and_test_stream_message` always confused me, since it sounds you're sending a stream message, and it leaves out the webhook piece. We should consider renaming `send_and_test_private_message` to something like `check_webhook_private`, but I couldn't decide on a great name, and it's very rarely used. So for now I just made sure the docstrings of the two sibling functions reference each other.
2020-08-23 15:49:24 +02:00
expected_message,
content_type="application/x-www-form-urlencoded",
)
integrations: Add an incoming webhook for Grafana. Tweaked by tabbott to use formatted suggested in one of the various duplicate PRs for this issue, showing the rule name clearly. Fixes #12951.
2020-04-15 06:06:49 +02:00
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
def test_no_message_alert_v7(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "[Alerting] No Message alert"
integrations: Add an incoming webhook for Grafana. Tweaked by tabbott to use formatted suggested in one of the various duplicate PRs for this issue, showing the rule name clearly. Fixes #12951.
2020-04-15 06:06:49 +02:00
expected_message = """
integrations: Enhance Grafana integration with alert state. Having the alert state in the message body is useful when alert topics are not defined by alert description but encoded in the url. E.g. in large environments having a topic for each alert [alerting] and [ok] would make it harder to properly track if an alert has been resolved. When each alert is in a single topic, so far, the alert state has been missing. This change will add the current alert state and a fitting icon in front of the alert name.(Similar to the prometheus alertmanager integration) The test cases have been amended to cover all possible alert states, even though realistically grafana only fires the ok and alerting states via webhook.
2021-05-24 23:25:33 +02:00
:alert: **ALERTING**
integrations: Add an incoming webhook for Grafana. Tweaked by tabbott to use formatted suggested in one of the various duplicate PRs for this issue, showing the rule name clearly. Fixes #12951.
2020-04-15 06:06:49 +02:00
[No Message alert](http://localhost:3000/d/GG2qhR3Wz/alerttest?fullscreen&edit&tab=alert&panelId=8&orgId=1)
**A-series:** 21.573108436586445
""".strip()
webhook tests: Rename main helper to check_webhook. Almost all webhook tests use this helper, except a few webhooks that write to private streams. Being concise is important here, and the name `self.send_and_test_stream_message` always confused me, since it sounds you're sending a stream message, and it leaves out the webhook piece. We should consider renaming `send_and_test_private_message` to something like `check_webhook_private`, but I couldn't decide on a great name, and it's very rarely used. So for now I just made sure the docstrings of the two sibling functions reference each other.
2020-08-23 15:49:24 +02:00
self.check_webhook(
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
"no_message_alert_v7",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
webhook tests: Rename main helper to check_webhook. Almost all webhook tests use this helper, except a few webhooks that write to private streams. Being concise is important here, and the name `self.send_and_test_stream_message` always confused me, since it sounds you're sending a stream message, and it leaves out the webhook piece. We should consider renaming `send_and_test_private_message` to something like `check_webhook_private`, but I couldn't decide on a great name, and it's very rarely used. So for now I just made sure the docstrings of the two sibling functions reference each other.
2020-08-23 15:49:24 +02:00
expected_message,
content_type="application/x-www-form-urlencoded",
)
integrations: Enhance Grafana integration with alert state. Having the alert state in the message body is useful when alert topics are not defined by alert description but encoded in the url. E.g. in large environments having a topic for each alert [alerting] and [ok] would make it harder to properly track if an alert has been resolved. When each alert is in a single topic, so far, the alert state has been missing. This change will add the current alert state and a fitting icon in front of the alert name.(Similar to the prometheus alertmanager integration) The test cases have been amended to cover all possible alert states, even though realistically grafana only fires the ok and alerting states via webhook.
2021-05-24 23:25:33 +02:00
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
def test_alert_ok_v7(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "[Ok] Test notification"
integrations: Enhance Grafana integration with alert state. Having the alert state in the message body is useful when alert topics are not defined by alert description but encoded in the url. E.g. in large environments having a topic for each alert [alerting] and [ok] would make it harder to properly track if an alert has been resolved. When each alert is in a single topic, so far, the alert state has been missing. This change will add the current alert state and a fitting icon in front of the alert name.(Similar to the prometheus alertmanager integration) The test cases have been amended to cover all possible alert states, even though realistically grafana only fires the ok and alerting states via webhook.
2021-05-24 23:25:33 +02:00
expected_message = """
:squared_ok: **OK**
[Test rule](http://localhost:3000/)
Someone is testing the alert notification within grafana.
**High value:** 0
[Click to view visualization](https://grafana.com/assets/img/blog/mixed_styles.png)
""".strip()
self.check_webhook(
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
"alert_ok_v7",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
integrations: Enhance Grafana integration with alert state. Having the alert state in the message body is useful when alert topics are not defined by alert description but encoded in the url. E.g. in large environments having a topic for each alert [alerting] and [ok] would make it harder to properly track if an alert has been resolved. When each alert is in a single topic, so far, the alert state has been missing. This change will add the current alert state and a fitting icon in front of the alert name.(Similar to the prometheus alertmanager integration) The test cases have been amended to cover all possible alert states, even though realistically grafana only fires the ok and alerting states via webhook.
2021-05-24 23:25:33 +02:00
expected_message,
content_type="application/x-www-form-urlencoded",
)
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
def test_alert_paused_v7(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "[Paused] Test notification"
integrations: Enhance Grafana integration with alert state. Having the alert state in the message body is useful when alert topics are not defined by alert description but encoded in the url. E.g. in large environments having a topic for each alert [alerting] and [ok] would make it harder to properly track if an alert has been resolved. When each alert is in a single topic, so far, the alert state has been missing. This change will add the current alert state and a fitting icon in front of the alert name.(Similar to the prometheus alertmanager integration) The test cases have been amended to cover all possible alert states, even though realistically grafana only fires the ok and alerting states via webhook.
2021-05-24 23:25:33 +02:00
expected_message = """
:info: **PAUSED**
[Test rule](http://localhost:3000/)
Someone is testing the alert notification within grafana.
[Click to view visualization](https://grafana.com/assets/img/blog/mixed_styles.png)
""".strip()
self.check_webhook(
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
"alert_paused_v7",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
integrations: Enhance Grafana integration with alert state. Having the alert state in the message body is useful when alert topics are not defined by alert description but encoded in the url. E.g. in large environments having a topic for each alert [alerting] and [ok] would make it harder to properly track if an alert has been resolved. When each alert is in a single topic, so far, the alert state has been missing. This change will add the current alert state and a fitting icon in front of the alert name.(Similar to the prometheus alertmanager integration) The test cases have been amended to cover all possible alert states, even though realistically grafana only fires the ok and alerting states via webhook.
2021-05-24 23:25:33 +02:00
expected_message,
content_type="application/x-www-form-urlencoded",
)
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
def test_alert_pending_v7(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "[Pending] Test notification"
integrations: Enhance Grafana integration with alert state. Having the alert state in the message body is useful when alert topics are not defined by alert description but encoded in the url. E.g. in large environments having a topic for each alert [alerting] and [ok] would make it harder to properly track if an alert has been resolved. When each alert is in a single topic, so far, the alert state has been missing. This change will add the current alert state and a fitting icon in front of the alert name.(Similar to the prometheus alertmanager integration) The test cases have been amended to cover all possible alert states, even though realistically grafana only fires the ok and alerting states via webhook.
2021-05-24 23:25:33 +02:00
expected_message = """
:info: **PENDING**
[Test rule](http://localhost:3000/)
Someone is testing the alert notification within grafana.
**High value:** 100
**Higher Value:** 200
[Click to view visualization](https://grafana.com/assets/img/blog/mixed_styles.png)
""".strip()
# use fixture named helloworld_hello
self.check_webhook(
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
"alert_pending_v7",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
integrations: Enhance Grafana integration with alert state. Having the alert state in the message body is useful when alert topics are not defined by alert description but encoded in the url. E.g. in large environments having a topic for each alert [alerting] and [ok] would make it harder to properly track if an alert has been resolved. When each alert is in a single topic, so far, the alert state has been missing. This change will add the current alert state and a fitting icon in front of the alert name.(Similar to the prometheus alertmanager integration) The test cases have been amended to cover all possible alert states, even though realistically grafana only fires the ok and alerting states via webhook.
2021-05-24 23:25:33 +02:00
expected_message,
content_type="application/x-www-form-urlencoded",
)
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
def test_alert_v8(self) -> None:
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
expected_topic_name = "[TestAlert]"
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
expected_message = """
:checkbox: **RESOLVED**
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
**TestAlert**
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
This alert was fired at <time:2022-08-31T05:54:04.52289368Z>.
This alert was resolved at <time:2022-08-31T10:30:00.52288431Z>.
Labels:
- alertname: TestAlert
- instance: Grafana
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
Values:
[ metric='foo' labels={instance=bar} value=10 ]
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
Annotations:
- summary: Notification test
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
[Silence](https://zuliptestingwh2.grafana.net/alerting/silence/new?alertmanager=grafana&matcher=alertname%3DTestAlert&matcher=instance%3DGrafana)
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
""".strip()
self.check_webhook(
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
"alert_v8",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
expected_message,
content_type="application/x-www-form-urlencoded",
)
grafana: Rename fixtures to contain Grafana versions. These are guessed, based on the shape of their contents and their dates.
2024-06-07 17:01:09 +02:00
def test_alert_multiple_v8(self) -> None:
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
expected_topic_name_1 = "[High memory usage]"
expected_topic_name_2 = "[High CPU usage]"
expected_message_1 = """
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
:alert: **FIRING**
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
**High memory usage**
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
This alert was fired at <time:2021-10-12T09:51:03.157076+02:00>.
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
Labels:
- alertname: High memory usage
- team: blue
- zone: us-1
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
Values:
[ metric='' labels={} value=14151.331895396988 ]
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
Annotations:
- description: The system has high memory usage
- runbook_url: https://myrunbook.com/runbook/1234
- summary: This alert was triggered for zone us-1
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
[Generator](https://play.grafana.org/alerting/1afz29v7z/edit)
[Silence](https://play.grafana.org/alerting/silence/new?alertmanager=grafana&matchers=alertname%3DT2%2Cteam%3Dblue%2Czone%3Dus-1)
""".strip()
expected_message_2 = """
:alert: **FIRING**
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
**High CPU usage**
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
This alert was fired at <time:2021-10-12T09:56:03.157076+02:00>.
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
Labels:
- alertname: High CPU usage
- team: blue
- zone: eu-1
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
Values:
[ metric='' labels={} value=47043.702386305304 ]
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
Annotations:
- description: The system has high CPU usage
- runbook_url: https://myrunbook.com/runbook/1234
- summary: This alert was triggered for zone eu-1
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
[Generator](https://play.grafana.org/alerting/d1rdpdv7k/edit)
[Silence](https://play.grafana.org/alerting/silence/new?alertmanager=grafana&matchers=alertname%3DT1%2Cteam%3Dblue%2Czone%3Deu-1)
""".strip()
self.subscribe(self.test_user, self.CHANNEL_NAME)
payload = self.get_body("alert_multiple_v8")
msg = self.send_webhook_payload(
self.test_user,
self.url,
payload,
content_type="application/json",
)
msg = self.get_second_to_last_message()
self.assert_channel_message(
message=msg,
channel_name=self.CHANNEL_NAME,
topic_name=expected_topic_name_1,
content=expected_message_1,
)
msg = self.get_last_message()
self.assert_channel_message(
message=msg,
channel_name=self.CHANNEL_NAME,
topic_name=expected_topic_name_2,
content=expected_message_2,
)
def test_alert_values_v11(self) -> None:
expected_topic_name = "[Memory (copy)]" # alertname
expected_message = """
:alert: **FIRING**
**Memory (copy)**
This alert was fired at <time:2024-03-01T02:09:00Z>.
Labels:
- alertname: Memory (copy)
- debug: true
- grafana_folder: device
Values:
- A: 2473545728
- B: 0
- C: 1
- minute: 9
Annotations:
- summary: High memory usage
[Generator](https://play.grafana.org/alerting/grafana/dd2f0260-3cfc-4c65-a4c4-f3f632c551f4/view?orgId=1)
[Silence](https://play.grafana.org/alerting/silence/new?alertmanager=grafana\u0026matcher=alertname%3DMemory+%28copy%29\u0026matcher=debug%3Dtrue\u0026matcher=grafana_folder%3Ddevice\u0026orgId=1)
[Image](https://grafana.com/assets/img/blog/mixed_styles.png)
""".strip()
self.check_webhook(
"alert_values_v11",
expected_topic_name,
expected_message,
content_type="application/x-www-form-urlencoded",
)
def test_alert_no_alertname_v11(self) -> None:
expected_topic_name = "[e6349a25f5ef0e9e]" # fingerprint
expected_message = """
:alert: **FIRING**
This alert was fired at <time:2024-03-01T02:09:00Z>.
Labels:
- debug: true
- grafana_folder: device
Values:
- A: 2473545728
- B: 0
- C: 1
- minute: 9
Annotations:
- summary: High memory usage
[Generator](https://play.grafana.org/alerting/grafana/dd2f0260-3cfc-4c65-a4c4-f3f632c551f4/view?orgId=1)
[Silence](https://play.grafana.org/alerting/silence/new?alertmanager=grafana\u0026matcher=alertname%3DMemory+%28copy%29\u0026matcher=debug%3Dtrue\u0026matcher=grafana_folder%3Ddevice\u0026orgId=1)
[Image](https://grafana.com/assets/img/blog/mixed_styles.png)
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
""".strip()
self.check_webhook(
integration: Update topic & content of grafana webhook. Sending to a topic based on the number of firing alerts makes no sense, and leads to conversations and alerts scattered randomly across topics based on how on fire the alerting is. Send a separate message for each alert in the Grafana webhook payload, with the alert's name as its topic; if no alert name can be found, fall back to the alert's fingerprint. Also include all alert values in the body of the message, along with links to the alert generator, silence, and image, if available. Co-authored-by: Alex Vandiver <alexmv@zulip.com>
2024-02-29 19:10:12 +01:00
"alert_no_alertname_v11",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
grafana: Support notifications from Grafana Alerting. This commit adds support for Grafana's new alerting system, Grafana Alerting. The existing Grafana integration has been modified to detect the version of the notification through the structure of the payload body, since the the structure varies by version. Support for legacy alerting is been continued. Example fixtures have been added for Grafana Alerting's webhooks. Tests updated.
2022-09-03 12:01:08 +02:00
expected_message,
content_type="application/x-www-form-urlencoded",
)