elastic / beats

:tropical_fish: Beats - Lightweight shippers for Elasticsearch & Logstash
https://www.elastic.co/products/beats
Other
12.14k stars 4.91k forks source link

Add `not` condition to lightweight Elastic Synthetics monitors #40266

Open renzedj opened 2 months ago

renzedj commented 2 months ago

Use Case

As a user, I have a requirement to run a lightweight test in a specific subnet to validate that it is isolated from our internal network to ensure that there is no route to the internal network from this specific subnet.

Details

We have an external-facing subnet that has a requirement that it is isolated from our internal network. In other words, there MUST NOT be any route from this subnet to our internal network; it MUST have access to the Internet only. I am currently validating this with a lightweight monitor. This monitor shows that it fails with a DNS error and/or timeout when attempting to reach hosts on our internal network. Any other result (e.g., HTTP 2xx, 3xx, 4xx, or 5xx error) means that there is a route between this subnet and our internal network and is, therefore, a failure.

In this situation, the test is successful if the lightweight monitor fails with either a DNS or TIMEOUT error. Any other result is a failure. However, in the dashboard, a DNS or TIMEOUT error shows as a failure, and an HTTP 200 result would show a success, and alerts would be sent accordingly.

This requirement is discussed in this post in the Elastic forums.

Requested Enhancement

Add a succeeds_on_failure switch under the check object in lightweight monitors, which would negate the condition.

E.g.,

---
heartbeat.monitors:
  - id: '6a35124b-8545-4d45-84be-96b38cb83fe7'
    name: 'google.com'
    type: 'http'
    enabled: true
    alert.status.enabled: true      
    check:
      request.method: 'GET'
      succeeds_on_failure: true # New switch, default: false
    response:
      include_body: 'on_error'
      include_headers: true
    urls: 'https://google.com'
    schedule: '@every 5m'
    timeout: '15s'
botelastic[bot] commented 2 months ago

This issue doesn't have a Team:<team> label.

renzedj commented 1 week ago

bump