Access Keys:
Skip to content (Access Key - 0)

Hi,

I am trying to use dynamic variables outlined in the http://www.rivermuse.org/display/CDOC/Dynamic+variables+Core. But, I am unable to figure out the connection between the tables: variable, alert_rules, conditions and actions.

Please find my requirements below:

1. Server A sends a critical alert if it is down.
2. If Server A is in maintenance, then the critical alert should be cleared out.
3. List of servers in maintenance is stored in a database table say rivermuse.maintenance.

Thanks,
Sunil.

Comments (9)

 

  1. 01 Mar 2010

    Oleksii Novikov says:

    Hi Sunil, You can use intermediate tables to link variables and rules/actions. ...

    Hi Sunil,

    You can use intermediate tables to link variables and rules/actions. Alert_rules_vars table links a variable to alert rule, actions_vars links variable to the action.

    As for your particular case, here is how to do your correlation:

    • Create a variable in the variables table with the following fields:
      • Name: UnderMaintanance
      • Alias: $UnderMaintanance
      • agent: leave empty
      • data_type: 'integer' or '1'
      • dynamic: 1
      • value: select count (name) from maintenance where name = $alert_host. Change this to match your table's structure
      • Automatic: 0
      • tbl_class and tbl_entity: leave empty
    • In alert_rules_vars link newly created variable to the alert rule which handles the message about server being down. Put rule id into rule_id field and variable id into var_id.
    • Create a condition with the following filter: $type = 'ServerDown' and $UnderMaintanance != 0. For all other fields use the same values as in ServerDown condition from default condition set. Except for 'up_action' field, put there a name of what ever action you want to run.
    • Define an action with type '4' and filter field set to 'id = $id' and owner field set to '$System' or other user. Set automatic field to 0 and all other fields just leave empty

    The above configuration will instruct omosd to link the variable to the alert with the value being the result of select statement in variables definition. After that yarpd will pick up the alert and if the $UnderMaintanance is more then zero it will run action and close the alert.

    Hope this'll help. Please let me know if you have any questions.

    Oleksii

    1. 26 Feb 2010

      Sunil M says:

      Hi Oleksii, Fantastic. This worked. Thanks a lot. I think it would be good i...

      Hi Oleksii,

      Fantastic. This worked. Thanks a lot.
      I think it would be good if this example is put in the wiki because I had real trouble figuring out and this use case might prove a good understanding to the wider audience.

      Thanks,
      Sunil.

      1. 26 Feb 2010

        Oleksii Novikov says:

        Hi Sunil, I'm glad to help. We are working on the doc pages to make them better...

        Hi Sunil,

        I'm glad to help. We are working on the doc pages to make them better.

        Oleksii

        1. 26 Feb 2010

          Sunil M says:

          Hi Oleksii, I have a question about the Rivermuse design. If an alert comes re...

          Hi Oleksii,

          I have a question about the Rivermuse design. If an alert comes repeatedly, only last_occurred and count get changed but not the dynamic variables. Is there a specific reason for that? Because, I want that the dynamic variables to be re-calculated.

          Thanks,
          Sunil.

          1. 26 Feb 2010

            Oleksii Novikov says:

            Hi Sunil, Yes, this is how de-duplication works. Only fields from initial messa...

            Hi Sunil,

            Yes, this is how de-duplication works. Only fields from initial message are stored into alert, all other messages producing the same discriminator add a record to the alert's "journal" and update count and last_occurred fields. If we did update dynamic variables in the alert we would also have to update all other fields in the alert because alerts_vars table is nothing else but extension for the alerts table. But this would override fields which could have already been changed by user (severity, state, assignee, etc) which is not what user would expect. That's why we don't do that.

            You can see all events (including those with new dynamic variables values) linked to the particular alert in the events and events_vars tables.

            I can presume, that you're working out the scenario, like
            1. On first ServerDown alert, the server is not under maintenance, so you don't close alert
            2. But when duplicating ServerDown comes, server is already under maintenance and you want to close this alert.

            Is that correct?

            1. 26 Feb 2010

              Sunil M says:

              Yes Oleksii, thats right. Is there any other way to work on the scenario? Than...

              Yes Oleksii, thats right. Is there any other way to work on the scenario?

              Thanks,
              Sunil.

              1. 01 Mar 2010

                Oleksii Novikov says:

                Hi Sunil, Sorry for long delay. You can do the following workaround. 1. In ac...

                Hi Sunil,

                Sorry for long delay.

                You can do the following workaround.

                1. In action, linked to you ServerDownUnderMaintanance, instead of closing alert you can force yarpd to recalc the dynamic variable. To do that, change action type to 3 and link the UnderMaintanance variable to this action using actions_vars table (leave value_tpl empty, so yarpd will take the SELECT statement from variable definition).

                2. Create a timed (set run_every to enything greater than 0, for example 60) condition with filter $type = ServerDown. Don't put $UnderMaintanance in this filter, because you can't reference variables from timed condition's filter directly but you can do that in action, see step 3

                3. Create an action with type 4 (CloseAlert) and filter id = $id and $UnderMaintanance > 0. Link this action to the condition from step 2.

                This will produce the desired result

                Oleksii

              2. 02 Mar 2010

                Oleksii Novikov says:

                Hi Sunil, This behaviuor (not updating dynamic variables, when alert is duplica...

                Hi Sunil,

                This behaviuor (not updating dynamic variables, when alert is duplicated) is actually a bug, we'll fix it in next versions. see here http://jira.rivermuse.org/browse/CORE-622

                Oleksii

                1. 02 Mar 2010

                  Sunil M says:

                  Thanks Oleksii. I had the same thought that the dynamic variables should be upd...

                  Thanks Oleksii. I had the same thought that the dynamic variables should be updated.

                  Thanks,
                  Sunil.
Adaptavist Theme Builder (3.3.5-M4-SNAPSHOT-conf210) Powered by Atlassian Confluence 2.10, the Enterprise Wiki.