This section helps you to understand what a “Probe” is in Travis Insights, how it is structured, and generally how to edit it yourself.
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.
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 JSON. Because of this, we can use a JSON query language (in this case a DSL of ObjectPath) to track state changes and compare to known/desired configurations.
Configure your probes
A probe consists of the notification which is the short description that appears on the dashboard when an alert is created, as well as a description in the notification details.
For the probe itself, we use a DSL (domain specific language) of the query language called ObjectPath.
Our ObjectPathThe only difference between how we use ObjectPath and the default language arises from the fact that we're applying probes to return a "true" or "false" probe response.
ObjectPath by default returns objects, so we have added the first extra
selectors/operators with the default ObjectPath syntax to apply our probe conditionals. The second set of extra
selectors/operators are used to provide the unique identifier of each item probed for us to report back.
Standard ObjectPath Probe:
$.instances[@.memory > 9000]=> Returns a list of instances whose memory is over 9000.
Travis Insights ObjectPath Probe:
$.instances[*][@.memory > 9000][@.name]=> Scores what % of a instances' memory are over 9000 and returns a list of instance names for those whose memory are not over 9000.
We currently provide two methods of creating/editing probes: “Basic Mode” or “Advanced Mode”.
When creating/editing in “Advanced Mode”, you can provide the exact ObjectPath query you want to be run.
When creating/editing in “Basic Mode”, you are directed through the ObjectPath syntax to help create simple probes. We ask you to provide a base object indicator, a set of preconditions, the actual probe conditionals, and an object key locator.
Base object indicator:
This is an ObjectPath operator that can be used to limit the list provided by the *base object indicator* to only probe a subset of the list: (Note: @ references the object being compared against.)
@.instance_id == "i-123456789" # Would only apply our probe to that specific instance.
This is an ObjectPath operator that contains the actual state we’d like to probe for among our final subset of objects: (Note: @ references the object being compared against.)
@.status == "OK" # Would make sure that all of our instances we're probing are in "status" of "OK"
Object key locator:
This is an ObjectPath selector indicating the uniquely identifying field of the object we’re probing so the system can report back on error: (Note: @ references the object being compared against.)
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.
If you have a probe which ensures our MySQL security patches are up-to-date. These could be a weightings example.
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.