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

Implement MetricStateStore #273

Open
5 tasks
dillu24 opened this issue Jun 8, 2022 · 0 comments
Open
5 tasks

Implement MetricStateStore #273

dillu24 opened this issue Jun 8, 2022 · 0 comments

Comments

@dillu24
Copy link
Collaborator

dillu24 commented Jun 8, 2022

Technical Story

When receiving an alert from the Alerter the AlertStore performs the following:

  • It stores the alert in Mongo
  • Stores the state of the alerted metric inside Redis. This is then used by the API/UI to display the problems in the Overview Dashboard.

Following the SRP (single responsibility principle) the AlertStore should perform one job only, that being of storing the alert in Mongo. Therefore, we need to create another component which continuously checks the values of each metric and compares them to the alertable thresholds/conditions.

In order to do this change we need to perform the following tasks:

  • Remove metric state storing logic from the AlertStore
  • Remove internal alerts mechanism as it would no longer be needed
  • Develop the MetricsStateStore by integrating each monitorable in a granular way using the Strategy pattern

Description

The aim of this ticket is to implement the MetricStateStore component.

Resources:

Requirements

To implement the MetricStateStore you need to perform the following:

  • Create the connections with RabbitMQ such that the MetricStateStore is able to receive the transformed data and alerts configs for every monitorable type
  • Implement the routing key <-> strategy logic so that the appropriate strategy is executed for the receive msgs' routing key
  • Implement the heartbeat integration logic
  • Update the StoreManager component to take the MetricStateStore in consideration
  • Update the run_alerter.py to include the MetricStateStore config queues

Acceptance criteria

Scenario: The MetricStateStore is able to store the monitorables state for every monitorable type

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

1 participant