In zztat the gauge is where the measurements take place. The gauge acts as a filter for the data produced by your metric and only lets data points pass which we consider "not good". In other words, the gauge's filters are to be set up in such a way that they match the problematic values.
To use the all-too-familiar example of tablespaces - you want your gauge to return the tablespaces which are running full so that it can act on it; you don't want it to return the tablespaces that have enough free space. The metric's job is to capture "all the data" that you'd like to collect (and archive). The gauge just filters the data that needs further attention.
Like zztat's metrics, a gauge can operate in different modes, controlled by the flags which are assigned to it. Without any flags, a gauge is referred to as a standard gauge and is executed normally through the Oracle scheduler.
A standard gauge is defined by the following characteristics:
- The gauge is assigned to a standard metric.
- A gauge job is scheduled and executed by the Oracle scheduler.
- The gauge is assigned a default volume, expressed in a temporal fashion.
An auto-sync gauge is defined by the following characteristics:
- The gauge is automatically triggered by the SYNC process when the corresponding metric has completed its snapshot.
- The gauge volume is ignored - all data collected by the metric is scanned.
- If there are multiple gauges defined for the metric in question, they will fire in alphabetical order, but asynchronously (virtually at the same time).
Please note that there is currently no means to establish dependency between multiple auto-sync gauges - e.g. they will always fire at the same time and you can't (yet) instruct zztat to let one gauge complete before the next one fires. This may change in future versions.
Logic Brings Order to Chaos
By default when you are creating a gauge, any columns that you will add to the gauge which will act as filters for your data, will be combined using the logical OR operator. For example, if you are defining a gauge to monitor tablespace free space, you may want to check if the percentage free space falls below a certain threshold OR the amount of space available falls below a certain threshold. In these cases, logical OR makes perfect sense.
You may however have a requirement to combine the filters with the logical AND operator instead. This is supported and can be achieved by setting the LOGICAL_AND flag on the gauge. An example of this would be the default session wait gauge SES_LATCH, which filters the events by type and then has gauge columns that act only if the type matches the desired type (in this case latches) AND the threshold exceeds our warning / critical limits.
This exists to ensure that even if you're adding a new gauge to an existing metric, that might have week or months worth of data, unless you explicitly want it to, it will not scan your entire history when it runs. The default volume for such cases is 7 days worth of data.
The volume also automatically tunes itself, if it detects that the time elapsed since the last run exceeds the default volume
Gauge & Metric Compatibility
Please note that certain modes are incompatible. This means that if you are defining a standard metric, the gauges must be standard gauges as well. And, if you are defining an auto-sync metric, the gauges must be auto-sync gauges. This may change in future versions to allow for more flexible combinations.
Regardless of the gauge type, what you will always need when creating a gauge, is the gauge query. Please see the page on gauge queries for details such as limitations on what is supported and what is not, as well as some guidelines on how to write your gauge queries: Gauge Queries
Gauge columns are what filters the data returned by the base gauge query. For your gauge to execute, you must define at least one gauge column. For all the various options, please see the page on Gauge Columns.
To eliminate certain data points from the checks the gauge is doing (for example if you do not wish to monitor certain tablespaces) you may add ignores to the gauge. These act as preliminary filters and are injected into the gauge query before the gauge column filters. For all the details on ignores, please see this page: Gauge Ignores.
The final gauge component is the gauge overrides. They may be used when a certain data point requires a different warning or critical threshold, for example if a specific tablespace is highly critical and you want to immediately react if it ever reaches 50%, whereas for your other "normal" tablespaces you may want to use the default thresholds of, for example, 80% or 85%. For details on how to use and define overrides, please see this page: Gauge Overrides