|
1 | 1 | # Creating a new monitor |
2 | | -This guide will walk through the steps to set up a new Monitor. |
| 2 | +This guide will walk through the steps to set up a new Monitor. The file [monitor_template.py](../resources/monitor_template.py) serves as a template for creating a new monitor. It includes all the necessary imports and settings to get started. |
3 | 3 |
|
4 | 4 | As a demonstration, the Monitor that will be designed is intended to **search for users with invalid registration data**, specifically when their name is empty. |
5 | 5 |
|
@@ -75,6 +75,13 @@ from monitor_utils import ( |
75 | 75 | ) |
76 | 76 | ``` |
77 | 77 |
|
| 78 | +# The issue data type |
| 79 | +The `IssueDataType` class defines the structure of the data that represents an issue. It serves as a type annotation in the monitor's default functions, making development more intuitive and error-resistant while also providing a clear contract for the issue data structure. |
| 80 | + |
| 81 | +Define a class called `IssueDataType`, that inherits from `TypedDict`, and includes all the fields that will be present in the issue data for the monitor. |
| 82 | + |
| 83 | +**Attention**: The `IssueDataType` class must contain the field specified in the `model_id_key` parameter of the `IssueOptions` setting. This ensures that the issue’s unique identifier is consistently used across your monitor’s configuration. This setting will be presented in the [**Issue options**](#issue-options) section. |
| 84 | + |
78 | 85 | # The settings |
79 | 86 | To set up the monitor’s behavior, issues, and alerts, use the provided Options dataclasses. These settings define how the monitor will manage issues and alerts. |
80 | 87 |
|
@@ -166,13 +173,6 @@ Priority levels definition. For the defined rule, what value should trigger each |
166 | 173 |
|
167 | 174 | All priority levels defaults to `None`. If a level is set to `None`, it will not be triggered. |
168 | 175 |
|
169 | | -# The issue data type |
170 | | -The `IssueDataType` class defines the structure of the data that represents an issue. It serves as a type annotation in the monitor's default functions, making development more intuitive and error-resistant. |
171 | | - |
172 | | -Define a class called `IssueDataType`, that inherits from `TypedDict`, and includes all the fields that will be present in the issue data for the monitor. |
173 | | - |
174 | | -**Attention**: The `IssueDataType` class must contain the field specified in the `model_id_key` parameter of the `IssueOptions` setting. This ensures that the issue’s unique identifier is consistently used across your monitor’s configuration. |
175 | | - |
176 | 176 | ### Example |
177 | 177 | For the user registration monitor, the issue data type should include the `id` and `name` fields, as these are the essential fields for identifying and tracking the issue. |
178 | 178 |
|
|
0 commit comments