Try it out!

Configuring Probes

This section helps you to understand what a “Probe” is in Travis Insights, how it is structured, and how to edit it yourself.

Probes definition

Each plugin type has a list of predefined probes, you can see the configuration of each one at the moment of setting a probe. Review the Plugin Types section to find a list of predefined probes according to each plugin type.

Probes functionality

The vast majority of the data which flows through the Travis Insights system is “state” data, this data will tell us about the current state/configuration/status of the infrastructure. Within Travis Insights, this data is all encoded into SREQL.

Configure your probes

To add new probes, the “New Probe” button displays two options:

  • New built-in probe: With default information filled up.
  • New custom probe: With empty fields to configure all data.

In the Add new Built-in Probe and Add new Custom Probe windows, you will find the following fields:

  • Plugin Type: You have a drop–down list with all available plugins, for more information visit the plugins page.
  • Probe: This option is only available for Built-in Probes according to the plugin you are adding, you will find a list of predefined probes in each plugin type, for more information visit plugin types page.
  • Notification: You can set the Notification you want to have according to the selected plugin and probe. In Built-in Probes this field has already some information.
  • Description: The description gives you a better idea of what the Notification is for, you can find here some clues to solve it. In Built-in Probes this field has already some information.
  • Query: In this field you can set some SREQL language queries, defining the probe action. In Built-in Probes this field is already defined according Plugin and Probe types. To edit and check the functionality you can open the Probe Editor by clicking the EDIT QUERY button.

    SREQL

    SREQL is a readable and easy scripting languaje based on SQL syntax that allows you to track state changes and compare to known/desired configurations.

    Example
    SREQL languaje:
    SELECT name FROM $.Animals.Dogs WHERE @.Breed = " Rottweiler " ASSERT @.Age > 2 => Returns ....................

    For more information about SREQL visit the SREQL language page.

  • Category: In this section you find two subsections. A field where you can add a help link with some relevant information for the probe and the Weighting Probes subsection, for more information see below the Weighting Probes information.

Weighting Probes

Probes are weighted from 0 to 1 across three categories (Security, Cost, and Delivery) and three sub-categories (Architecture, Maintenance, and Support) based on how critical the information is. For example, a probe for a severe security vulnerability will have a higher rating (closer to 1) than a probe for servers that aren’t following proper naming conventions/policies.

Security: Probes that relate to the overall security of the system like public network exposure, secure system configuration, patching, passwords, IAM, etc.

  • Architecture: Relates to the security posture of the overall design and setup of the environment.
  • Support: Relates to how the security posture affects the short-term supportability of the environment.
  • Maintenance: Relates to how security posture impacts long-term maintenance costs.

Cost: Probes that relate to the overall cost-effectiveness system like reserved instance usage, proper instance sizing, any sort of unused, paid capacity, etc.

  • Architecture: Relates to the relative cost-effectiveness of the overall design and setup of the environment.
  • Support: Relates to the relative cost-effectiveness of the short-term supportability of the environment.
  • Maintenance: Relates to the relative cost-effectiveness of long-term maintenance costs.

Delivery: Probes that relate to the overall delivery of the system/end product like uptime, response times, SLAs, maximum concurrent sessions, etc.

  • Architecture: Relates to the robustness/stability of the overall design and setup of the environment.
  • Support: Relates to the robustness/stability of the environment and its impact on short-term supportability/management of the environment.
  • Maintenance: Relates to the robustness/stability of the environment and its impact on long-term maintenance costs.
Info: This is not an exact science, your weighting may differ, you can edit the plugin weights according to your needs.

For example:

If you have a probe which ensures our MySQL security patches are up-to-date. These could be a weightings example.

sub-category security cost delivery
Architecture 0 0 0
Support 0.75 0 0
Maintenance 0.75 0 0
Info: Probes with 0 as a weighting, don't get counted on the weight average percentage.

We generally try to avoid “double counting” on probe weightings (i.e. one could argue that security patching also has an impact on delivery and/or cost, but it is primarily a security issue) unless the issue is so severe that it warrants doing so to raise it to the top of our list. Likewise, when the impact is spread evenly across sub-categories, we try to just split the weight evenly between them.

As a rule of thumb, a highly impactful probe will have a total score total of 2.5+. A probe of average importance will be weighted in the 1.5 - 2.5 range. A probe of low importance will range between 0.5 - 1.5 in weighting.