Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

3. Custom Observer Scripts

3.1 Custom Observer Scripts Concept

Default checks done by observer can be replaced or complemented by custom user scripts. The DBA or system administrator can add own checks to the environment. It could be connectivity checks, storage checks, application checks, anything they might want to validate for the environment.

...

Info

Check Failure of Custom observer script (regardless whether because of server unreachability or check failure) always creates new event in the dashboard. These events will not be cleared.

3.2 Custom Observer Scripts vs. Default Observer Checks

Custom (or user) scripts can then be combined with existing Observer checks in following logical relations:

...

Example of primary host down and user script check disable:

...

3.3 Configuring Custom Observer Scripts

Custom observer scripts can be enabled in the Observer configuration as follows:

...

Both = C. Custom Observer Scripts Rule AND Default Observer Failed Checks (Both)

3.4 Custom Observer Scripts Additional Information

When using “Either” or “Both” mode, default observer check will be always executed first. Once the default observer check is done, then observer will execute user script with following five parameters:

  • DDC name - a name of DDC for which the check is being executed.

  • status - is a state of the previous rule in the rule chain (previous rule is the Observer's own connectivity and system health check), can be one of the following:

    • ok - previous rule returned no errors

    • fail - previous rule returned an error

  • role - the database role of the database where the error occurred, can be one of the following:

    • not_applicable - this is when there's no error

    • P - the previous error was on primary

    • S - the previous error was on standby

  • error_type - type of error occurred:

    • err_none - no error

    • err_connection - there was a connection error

    • err_database - there was an error on a database, or the database is in an invalid state

  • hostname - if the error_type is not err_none - will contain a hostname of the node where the error occurred, otherwise, this parameter is empty.

So for example, if the Default observer check is successful, user script for configuration SLASH on primary host czlin0231 will be called with following parameters:

Code Block
SLASH ok P err_none

If Default observer check is unsuccessful, user script for configuration SLASH on primary host czlin0231 will be called with following parameters (in this example primary database is down):

Code Block
SLASH fail P err_connection czlin0231

you can make use of this behavior to make various corrective actions in your code.