Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Processor: Time in State

The Time in State processor measures time when a value is in the range. For each input DS, monitor it over the last time_window seconds. If at any moment, for the state in state_range, the amount of time we have been in that state over the last time_window seconds falls into a range specified in the corresponding state_range entry, we set the corresponding output DS to 'true'. Otherwise, the output DS for a given input DS is nominally 'false'. (previously called 'time_in_state_check')

Parameter Description
Input Types Discrete-State (DS)
Output Types Discrete-State (DS)
Time Window (time_window) How long to monitor state. (seconds or an expression that evaluates to integer)
State Range (state_range) Map state value to its allowed time range in seconds. dict mapping from a single possible state to a single range of time during the most recent time_window seconds that the value from input state is allowed to be in that state. At least one of the range object's two fields must be specified. The omitted field is regarded as "infinity". The fields are numbers (integers or floats) or expressions evaluated into numbers. State is a string or an expression that evaluates to string.
Graph Query (graph_query)

One or more queries on graph specified as strings, or a list of such queries. (String will be deprecated in a future release.) Multiple queries should provide all the named nodes referenced by the expression fields (including additional_properties). Graph query is executed on the "operation" graph. Results of the queries can be accessed using the "query_result" variable with the appropriate index. For example, if querying property set nodes under name "ps", the result will be available as "query_result[0]["ps"]".

In collector processors (*_collector, if_counter) it is used to choose a set of nodes for further processing (for example, all leaf devices, or all interfaces between leaf and spine devices)

In other processors it is used for general parameterization and it is only supported as a list of queries.

graph_query: "node("system", role="leaf", name="system").
              out("hosted_interfaces").
              node("interface", name="iface").out("link").
              node("link", role="spine_leaf")"
graph_query: ["node("system", role="leaf", name="system")",
              "node("system", role="spine", name="system")"]

Non-collector processors containing the graph_query configuration parameter, can be parameterized to use data from arbitrary nodes in the graph, such as property set nodes. Property sets allow you to parameterize macro level SLAs for individual business units. In the example below, graph_query matches a node of type property_set with label probe_propset. It's accessed using the special query_result variable, where Index 0 means it's the first node in query results. If a query returned N nodes, they could be accessed using indices starting from 0 to N-1. ps is what the actual node is referred to in the query; the rest depends on the structure of the node. The int() casting is required because values of property_set nodes are strings. Here it's assumed that a property set node has the label probe_propset and that the value accumulate_duration was already created.

graph_query: [node("property_set", label="probe_propset", name="ps")]
duration: int(query_result[0]["ps"].values["accumulate_duration"])

Another example is a that probes can validate a compliance requirement; the compliance value may change over time and/or it can be used by more than one probe. Also, a probe can validate NOS versions on devices. In this case, property sets can be used to define the current NOS version requirement. If it changes tomorrow: change the property set value, instead of going under the probe stage.
Anomaly MetricLog Retention Duration Retain anomaly metric data in MetricDb for specified time period
Anomaly MetricLog Retention Size Maximum allowed size, in bytes of anomaly metric data to store in MetricDB
Anomaly Metric Logging Enable metric logging for anomalies
Enable Streaming (enable_streaming) Makes samples of output stages streamed if enabled. An optional boolean that defaults to False. If set to True, all output stages of this processor are streamed in the generic protobuf schema.
Raise Anomaly (raise_anomaly) Outputs “true” and “false” values, “true” meaning an appropriate item is anomalous, and "false" meaning the item is not anomalous. When Raise Anomaly is set to True, an actual anomaly is generated in addition to a sample in the output.

Example: Time in State

Config is set to:

The above configuration means that for the input DS, we will set output to True and optionally raise an anomaly if the input is in the "down" state for more-than one second out of the last two seconds.

In the sample below, certain values are capitalized to indicate what has changed from the previous time.

Sample Input at time t=0

Sample Output at time t=0

Sample Input at time t=1:

Sample Output at time t=1

Sample Input at time t=2:

Sample Output at time t=2

Sample Input at time t=3:

Sample Output at time t=3

Sample Input at time t=4:

Sample Output at time t=4

If expressions are used for min or max fields for states specified in the state property, then they are evaluated for each input item which results into item-specific thresholds. Properties of the respective output items are extended by range_min or range_max keys with calculated values.

If state key is an expression, output items are extended with state key. The same applies for time_window property.

Configuration:

Sample Input at times t=0..6:

Sample Output at time t=6: