Wiki source code of Cleanup Alerting in Manage
Last modified by Eva Torken on 2023/08/23 16:19
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{container}}{{container layoutStyle="columns"}}(((In this microlearning, we'll take a look how to cleanup Alerting from an eMagiz project. | ||
| 2 | |||
| 3 | Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]]. | ||
| 4 | |||
| 5 | == 1. Prerequisites == | ||
| 6 | |||
| 7 | * Novice knowledge of the eMagiz platform | ||
| 8 | |||
| 9 | == 2. Key concepts == | ||
| 10 | |||
| 11 | This microlearning is about cleaning up the Alerting as configured in the Manage phase. Alerts can be set on various ways and levels * please inspect the related microlearnings around alerting to understand more about that. During the cleanup of various systems, flows and runtime, the Alerting needs to remain current with the integration model. | ||
| 12 | |||
| 13 | == 3. Cleanup the Alerting in Manage == | ||
| 14 | |||
| 15 | === 3.1 Scenario's when to cleanup the Alerting phase === | ||
| 16 | |||
| 17 | * A user is no longer active on the integration model. | ||
| 18 | ** The user may still be referenced in the notification settings and should be removed | ||
| 19 | * A specific runtime is removed from the integration model that is referenced in the Alerting | ||
| 20 | * A flow or integration is removed from the integration model that is reference in the Alerting | ||
| 21 | |||
| 22 | === 3.1 Steps to clean === | ||
| 23 | |||
| 24 | Once you have opened your model you should navigate to the Manage environment. From here you should open the Alerting section under Manage and select Triggers. Here you can change the relevant triggers. | ||
| 25 | |||
| 26 | **Queue specific** | ||
| 27 | |||
| 28 | If you have configured the alerting following the best practice outlined in the user guide for Alerting, the following triggers (at least!!!) need to be changed. For your specific situation more triggers could be relevant | ||
| 29 | |||
| 30 | * Standard – Queue consumers too high | ||
| 31 | * Standard – Queue consumers too low | ||
| 32 | |||
| 33 | **Runtime specific** | ||
| 34 | |||
| 35 | If you are removing the last flow belonging to a system and you have followed the best practice outlined here the following triggers (at least!!!) need to be changed. For your specific situation more triggers could be relevant | ||
| 36 | |||
| 37 | * Standard – Data measurements missing | ||
| 38 | * Standard – Log entries missing | ||
| 39 | * Standard – Error log entry | ||
| 40 | |||
| 41 | * Once you have located the candidates, update and/or remove the triggers relevant for update | ||
| 42 | * Review if you need to remove a notification setting in case a trigger is removed. If yes, remove it. | ||
| 43 | * Review if you need to remove a tag in case the tag is not used in any trigger. If yes, remove it. | ||
| 44 | |||
| 45 | == 4. Key takeaways == | ||
| 46 | |||
| 47 | * Cleaning up the Alert phase is important to ensure no false positive alerts are created/used | ||
| 48 | * Review the Alert setting at each release to production (post deployment step) to keep things manageable | ||
| 49 | |||
| 50 | == 5. Suggested Additional Readings == | ||
| 51 | |||
| 52 | None | ||
| 53 | |||
| 54 | |||
| 55 | )))((({{toc/}}))){{/container}}{{/container}} |