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.

Probes information

At the top of the probes list a drop-down list lets you decide which probes to display, All Probes, Active Probes, or Inactive Probes.

The probes list separates in columns different information:

  • Type, displays how the probe was created, as a built-in probe (Native Probe) or as a Custom Probe.
  • Product, shows the company or community member that contributed/sponsored the probe. The contributor’s name is a link to its main informational page. Order the probes alphabetically using the arrow next to the column’s name.
  • Category, indicates the probe category (Infrastructure, Monitoring, Source Control, etc.)
  • Message, displays de predefined message set in built-in probes or the message you added while creating a custom probe.
  • Tags, lets you organize probes according to your needs, you can create 10 tags in each probe and add or remove them in the modal view.
  • Status, shows if it is an Active or Inactive probe.

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:

  • Product: You have a drop-down list with all registered plugins in your Travis Insights account, the category (Infrastructure, Monitoring, Source Control, etc.), and the type (Native, Custom).
  • 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 the 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 predefined 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 to Plugin and Probe types. To edit and check the functionality you can open the Probe Editor by clicking the EDIT QUERY button.

    SREQL Language

    SREQL is a readable and easy scripting language based on SQL syntax that allows you to track state changes and compare them to known/desired configurations.
    Example
    SREQL language:
    SELECT name FROM $.Animals.Dogs WHERE @.Breed = " Rottweiler " ASSERT @.Age > 2 => Returns ....................
    For more information about SREQL visit the SREQL language page
  • Tags: In this field add tags to identify and order better your probes, you have 20 characters for each tag including spaces and you can add 10 tags maximum per probe. Start writing tag names in the +Add Tag space, you can select a tag from the list that displays the ones created before.

  • 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 visit 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.