Last week we sent out the third of our Early Access Program releases (you can still sign up for the SQL Monitor EAP and get the latest release). There is a new feature – user roles – and an update to the custom metrics and alerts feature.
The most requested feature via SQL Monitor Uservoice has been the ability to have multiple levels of user. However, during our research we heard several times that adding a new set of accounts to manage could potentially be a headache. So we designed with simplicity in mind.
There are now three levels of user:
Administrator – full control including control of user access to SQL Monitor
Standard user - limited access, but can for example manage alerts and configure alert settings
Read-only – can’t configure any settings but can view most areas except the Licensing page etc
The Administrator role is created on intial login. The Administrator can then optionally create the other two levels of access. Each role is activated by a single password that you share with relevant users, avoiding the ‘headache’ of multiple user accounts with specific roles and privelages allocated to them.
We’ve had many suggestions for additional functionality around this feature – for example, extending the control to instance level access or integration with Active Directory – and we’ll certainly consider these suggestions carefully when we’re deciding what goes into a future release. For now, we hope the additional levels of access will provide a useful way of restricting access to parts of SQL Monitor.
Custom metrics and alerts
This new feature, updated in the latest EAP, is one of those features an administrator might wish to restrict access to. It allows the user to make collections from their servers and then receive alerts when certain threshold values are passed.
We’ve made changes to this in the latest EAP. The feature now uses a three page wizard to allow users to:
1. define the metric
2. optionally create an alert based on the metric
3. see a summary before saving them.
We’ve added the ability to choose which databases to run the T-SQL against:
And to test the T-SQL to make sure it is returning a single numeric value:
It’s also possible to create the metrics and alerts in disabled states – for example, you might want to create a metric and an alert but save the alert in a disabled state so you can evaluate the metric before you decide it’s ready to fire alerts.
To support the feature we’ve made available several ready-to-use example metrics and alerts – such as a metric to collect rate of change of database file size in MB/hour with an accompanying alert when the database file size has increased beyond certain thresholds.
Please continue to let us know what you think of the new features and what you think can be improved and we’ll keep you updated on developments…