Custom Thresholds


Custom Performance Thresholds

In Viakoo Release 2.10, we released a new capability to allow Viakoo Users to add thresholds to create their own tickets and alerts. The feature requires STAFF-level users and above, and they can now define thresholds or modify existing thresholds for their environments to get the alerting behavior they would like from the Viakoo service. This complements the full, built-in diagnostic system with an ability to select any performance value and create a condition. The condition, if TRUE, will cause a Viakoo ticket to open at the chosen priority level.  This gives users a powerful way to leverage and customize their Viakoo service to fit their needs.

Threshold Ingredients

A threshold uses the following parameters to create a condition, which is evaluated to determine when to open threshold ticket:

  1. A Performance Type for which the threshold is being defined,
  2. A Value which is the value of the threshold,
  3. A Relation Operator to compare the Performance Measure against the Threshold Value,
  4. A length of Time, which is how long the expression needs to be TRUE before opening a ticket,
  5. A Priority to give the threshold tickets,
  6. Whether to Auto Close the ticket when the threshold expression is no longer TRUE. Otherwise, users have to Manually close the ticket,
  7. A Message to include in the event list associated with each ticket.

There is also a navigation context associated with the threshold. Thresholds are defined and managed in the “Threshold” section of the “Admin” tab in your Viakoo dashboard. Thresholds only create tickets within the location (i.e., “navigation context”) that they are defined.  A navigation context can be at a Company-, Region-, Site- or even a Server-level.

Creating a Threshold

To create a threshold, navigate to the context (e.g., Company or Site) where you would like to define a new threshold. You need to have at least a STAFF level permission for that context. When you have navigated to the context,  go to the “THRESHOLDS” section within the “ADMIN” tab (see “Threshold Administration” example).


To create a threshold, now click on the  symbol in the upper right of THRESHOLDS administration. This would bring up the “Create Threshold” popup.

For example, if when system “CPU: Load” exceeds 95% CPU for over 60 minutes you want to open a CRITICAL (Alerting) ticket, you would populate the pop-up as follows:

Entering appropriate values in the “Add a New Threshold” pop-up and click the “Add Threshold” button. You’ll then get a confirmation pop-up where you can confirm that you have set it up correctly.

Click on the to remove a threshold or undo a modification of inherited threshold (see more on deletion and restoring below).

Threshold Hierarchies

Thresholds defined at your company level are inherited by every site and server in your company. Conversely, a threshold defined at a single server will not open tickets for other servers or in other sites within your company.  

In addition, users can modify thresholds provided as “defaults” by the Viakoo service or your service provider.  For example, a threshold defined by default is the one for CPU temperature. The system defines a threshold which will open a WARNING ticket if the CPU Temperature exceeds 90-degrees Celsius for over 20 minutes.  

Users can modify or disable this threshold for their entire company, a single region, a single site or even a single server. The modification only affects the context in your hierarchy where you modified it.  

Moreover, if you modify it at your company level, you can modify or disable it at any subordinate level.

In this example, we can imagine the following scenario:

  1. As an administrator of MyCompany, you would like an earlier warning than 90-degrees, and modify this threshold to use 85-degrees instead.
  2. The Administrator of the company’s “MyWestRegion” decides he wants these thresholds to open tickets with an Alert-level priority (CRITICAL) so that he’ll get push notifications to his phone.
  3. Simultaneously, the Administrator of the company’s “MyEastRegion” doesn’t want to be bothered with tickets associated with this threshold at all and disables this for all of his infrastructure.
  4. Then a Staff member has a single server at the “MyDenverSite” which is actually a laptop used as a viewing station that tends to run hot. Rather than bumping the threshold value up for this one system he just disables the threshold for this one server, “Svr A”.

In this example, you can see how a single threshold can be tailored at any level in the hierarchy to customize the tickets that may generate around this particular measure.  The same mechanism that allows users to modify built-in thresholds also allows you to modify any custom thresholds you create.

Multiple Thresholds for Same Measure

This mechanism also allows you to create multiple thresholds on the same measure. For example, you could set a threshold when CPU Load falls below 0.5% which might indicate that software you are expecting to run is not running at all. This would be active simultaneously with the threshold for over 95% that you just created giving you the ability to define a range of safe operation, getting alerted to either excessively high or excessively low measures.

Modifying, Restoring or Deleting Thresholds

Understanding this hierarchical structure, there are ways of making changes to these customizations of thresholds. There are key points to understand:

  1. Modifying or disabling a threshold at a subordinate context to where the initial threshold is defined creates a new child threshold. The original threshold becomes the root threshold and is the parent threshold of the new child threshold.
  2. In the context of where a root threshold is defined, you have the ability to DELETE the threshold. In the context where a child threshold is defined, you have the ability to REVERT to the value of the parent context. In both those situations, you will see a icon next to the threshold.
    1. If you are in a context that is merely inheriting the threshold, modifying or disabling a threshold will actually create an implicit child threshold in the current context.

    Cleaning Up Threshold Trees

    Threshold tree hierarchies can become complicated if you are adding, modifying and disabling thresholds from multiple locations. Modifying, deleting and reverting thresholds have an “ALL” option which has the effect of purging all descendent thresholds. This can help you clean up excess thresholds that might have been created as you were refining how and where you wanted your threshold to create tickets. Specifically:

    • When modifying a root threshold (or at least a parent threshold), you have the option to Save All, which has the effect of removing all children thresholds and causing all locations under the current context to inherit the new version of the threshold.
    • When at a parent threshold, which is itself a child of some inherited threshold, you have the option to Revert All, which has the effect of removing the current threshold and all ancestor thresholds meaning that the entire context will go back to using the inherited threshold.
    • When at a root threshold, you have the option to Delete All, which has the effect of removing the current threshold and all ancestor thresholds. However, using a simple Delete of the root threshold, has the effect of only removing the current root threshold and all direct children thresholds will become their own root thresholds.



Have more questions? Submit a request