Make alert configuration levels more discoverable
CONTEXT: In SQL Monitor, you can configure alert behaviour down to the object level (such as the Database or the Job level). This is useful e.g. when we have specific databases with different backup policies to our global configuration, since we can specifiy "special rules" for individual databases.
PROBLEM: It is counterintuitive how to do so, and many people don't spot the left-hand drilldown navigation - this makes you think that you can only configure on the global and the server level! Also, when we have created an override, it's easy to forget so causes surprise when we change the global configuration and the "special" database's behabviour doesn't change.
EXAMPLE SOLUTIONS:
• Autoexpand the left-hand side navigation, draw attention to it
• Add Disks, Jobs and Databases as child-elements to the left-hand navigation
• show the configuration hierarchy when editing alert settings. Highlight levels where overrides exist. Allow to apply new configuration to multiple levels simultaneously
What do you think about these solutions? Got another idea? Let us know in the comments!
Daniel Rothig
shared this idea
currently under investigation
-
BlueCollarCritic
commented
The Alerts are great but very limited in their configuration, Several other ideas here that are alert specific fall under this broader idea of improved Alert Configuration options. I was shocked when I went to configure an alert for the first time and found the choices were to change the level and ion some cases to change the duration (i.e. backups) required to trigger the alert. Beyond changing the alert level and enabling it or disabling it there's not much one can do to change how the alerts work and this is one area that this otherwise great product is very short on.
I have several specific Alert Configuration ideas but I wanted to press the point abiut alert conbfigurations over all needing to be greatly expanded in how they are configured.
-
Niels
commented
At the moment alert ‘Long-running query’ is being triggered on known long running processes. We can off course exclude them from that one rule but we want to be able to make a second configuration to cover the excluded processes. (They are allowed to run longer, not unlimited).
Examples of those processes are ‘BACKUP DATABASE’ or ‘xp_sqlmaint’. These are maintenance jobs, however the same will apply to our application which also have long running batches.