Skip to content

Colin Millerchip

← Redgate Monitor

My feedback

2 results found

  1. Custom metric: alert when value changed

    19 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    10 comments  ·  Suggestions  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    An error occurred while saving the comment
    Colin Millerchip commented  · 

    Hi Thomas,

    Thanks for creating the new UV requests - since one of them meets the aims of this discussion, I'll close off this request and transfer the votes across to that thread when this discussion is finished.

    Regarding the documentation, I'm not seeing the same as you. For eg, jump to this Custom Metric on the on-line demo:
    http://monitor.red-gate.com/Configuration/Custom-Metrics/Edit/26#/?v=1

    Click on the question mark at "Use collected or calculated values", and the description includes this text, under "When should I use calculated values?":

    “SQL Monitor can calculate the rate for you by finding the difference between each pair of consecutive values and dividing it by the number of seconds between each collection. The result gives the rate of change per second.”

    Do you see the same? If not, could you be using an old version of SQL Monitor?

    Best regards,

    Colin.

    An error occurred while saving the comment
    Colin Millerchip commented  · 

    Hi Thomas,

    You shouldn't need to multiply the calculated value, because you can configure the alert to fire if the calculated value is greater than 0, which should work regardless of the collection frequency.

    In terms of your second comment, I can't think of an easy way to have a single custom metric/alert work for both adding and dropping database: potentially the Custom Metrics could write values into a temp table and then return the absolute value of the difference between the last two values, but that's quite hacky.

    As to your third observation (that the creation of 2 databases in the time period between collection would only raise one alert), I can't think of a simple way of address this.
    One observation here is that the alert contains the value of the metric when the alert is raised: so this value will be higher if more than one database is created/deleted between collections.
    [In this situation, you probably would want to multiply the metric by the number of seconds between collections, to make it easy to spot that the alert was associated with more than one database creation event.]

    Another thought is that you could create a DDL trigger that wrote to the event log when a database was created, so each database creation event would then trigger a "SQL Server error log entry" alert in SQL Monitor. But this feels like a sledgehammer to crack a nut.

    Thanks for triggering this discussion. This has teased out a number of potential problems and/or feature requests:
    - built-in alerts for creation or deletion of a database
    - allow for more than one alert to be triggered from a single Custom Metric
    - the option to alert based on the Custom Metric not being equal to a value, in addition to the current logic of the value passing through thresholds from either above or below each threshold

    If any of these sound useful to you, could you please create UserVoice requests so that people can vote for that specific feature.

    Thanks,

    Colin.

    PS I believe that the built-in documentation (question mark) does state that the calculated value is the rate per-second -- can you tell me where you're looking that you can't see this?

    An error occurred while saving the comment
    Colin Millerchip commented  · 

    When you create a Custom Metric, you can define whether the metric uses the collected value or the calculated value: the latter is the rate of change (per second) between collections.
    I think this should give you what you need?
    http://documentation.red-gate.com/display/SM4/Step+1.+Define+metric

  2. Install SQL Monitor without needing to provision a (large) SQL Server database

    153 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    34 comments  ·  Suggestions  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    Adam responded

    We’ve made some improvements in this area but will leave it open so you can continue to give us your suggestions

    An error occurred while saving the comment
    Colin Millerchip commented  · 

    Thanks for the comment. We specifically decided to store the data repository in SQL Server, because it's a technology that our customers are familiar with, and they can manage it using their existing maintenance processes. It will be interested to see if others would prefer we support another backend database platform.

Feedback and Knowledge Base

(thinking…)