Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add http endpoint support #795

Closed
wants to merge 1 commit into from

Conversation

mblaschke
Copy link

Add support for custom endpoint (IP/Port or full hostname) to make probes possible in specific and complex environments and to test the service chain:

  • support for checking services in a service chain (app gateway -> loadbalancer -> ingress controller -> app) to test http response of eg. the kubernetes ingress (from inside the cluster by using xxx.xxx.svc.cluster.local as endpoint where you cannot reach the loadbalancer due to cloud limitations) and get the ability to setup alerts on probe failure and TLS certificate expiry
  • support for checking of "hidden" services which are not directly reachable (eg where there is a NAT in between cloud and on premise and DNS resolves to on premise IPs)
  • easier use of prometheus-operator for such checks/environments

example module configuration:

  http_2xx_example_with_endpoint:
    prober: http
    timeout: 5s
    http:
      endpoint: "1.1.1.1:443"
      valid_http_versions: ["HTTP/1.1", "HTTP/2.0"]
      valid_status_codes: []  # Defaults to 2xx
      method: GET
      preferred_ip_protocol: "ip4" # defaults to "ip6"
      ip_protocol_fallback: false  # no fallback to "ip6"

  http_2xx_ingress_internal:
    prober: http
    timeout: 5s
    http:
      endpoint: "controller.ingress.svc.cluster.local:80"
      valid_http_versions: ["HTTP/1.1", "HTTP/2.0"]
      valid_status_codes: []  # Defaults to 2xx
      method: GET
      preferred_ip_protocol: "ip4" # defaults to "ip6"
      ip_protocol_fallback: false  # no fallback to "ip6"

Signed-off-by: Markus Blaschke <[email protected]>
@roidelapluie
Copy link
Member

Should we instead have an extra HTTP parameter? &target=1.1.1.1&hostname=example.com ? WDYT?

@2mf
Copy link

2mf commented Jun 23, 2021

I really would love the hostname parameter, since I need to probe internal as well as external IPs. I can't not use DNS since I need to test specific endpoints for specific hostnames.

@roidelapluie
Copy link
Member

instead of endpoint, you can use Headers: Host in the current blackbox exporter.

I have a design doc to enable this per probe: https://docs.google.com/document/d/1VwqXi2TOb5KXaZY6Iio7411x64pJao3GusX8MqYsJ2g/edit

@mblaschke
Copy link
Author

The extra hostname parameter would be also ok. I just want to avoid creating one configuration entry for only one probe.

@roidelapluie
Copy link
Member

Okay, let's focus on #823 .

@roidelapluie
Copy link
Member

#823 is merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants