influxdata / influxdb

Scalable datastore for metrics, events, and real-time analytics
https://influxdata.com
Apache License 2.0
28.21k stars 3.51k forks source link

InfluxDB 2 Cloud doesn't expose /health endpoint at root URL #19357

Open bednar opened 3 years ago

bednar commented 3 years ago

According to swagger definition the /health and /ready endpoint should be exposed at root path, but it works only for OSS instances.

https://github.com/influxdata/influxdb/blob/26cf6af07aeb2956ddf5792a31269a94c0f0528e/http/swagger.yml#L2002

Steps to reproduce: List the minimal actions needed to reproduce the behaviour.

  1. curl -i -X GET https://us-west-2-1.aws.cloud2.influxdata.com/health \
    -H "Authorization: Token mytoken"

Expected behavior: Return JSON with health information.

HTTP/2 200 
date: Tue, 18 Aug 2020 08:28:06 GMT
content-type: application/json; charset=utf-8
content-length: 994
vary: Accept-Encoding
strict-transport-security: max-age=15724800; includeSubDomains

{
    "authorizations": "/api/v2/authorizations",
    "backup": "/api/v2/backup",
    "buckets": "/api/v2/buckets",
    "checks": "/api/v2/checks",
    "dashboards": "/api/v2/dashboards",
    "delete": "/api/v2/delete",
    "external": {
        "statusFeed": "https://www.influxdata.com/feed/json"
    },
    "flags": "/api/v2/flags",
    "labels": "/api/v2/labels",
    "me": "/api/v2/me",
    "notificationEndpoints": "/api/v2/notificationEndpoints",
    "notificationRules": "/api/v2/notificationRules",
    "orgs": "/api/v2/orgs",
    "plugins": "/api/v2/telegraf/plugins",
    "query": {
        "analyze": "/api/v2/query/analyze",
        "ast": "/api/v2/query/ast",
        "self": "/api/v2/query",
        "suggestions": "/api/v2/query/suggestions"
    },
    "scrapers": "/api/v2/scrapers",
    "setup": "/api/v2/setup",
    "signin": "/api/v2/signin",
    "signout": "/api/v2/signout",
    "sources": "/api/v2/sources",
    "swagger": "/api/v2/swagger.json",
    "system": {
        "debug": "/debug/pprof",
        "health": "/health",
        "metrics": "/metrics"
    },
    "tasks": "/api/v2/tasks",
    "telegrafs": "/api/v2/telegrafs",
    "users": "/api/v2/users",
    "variables": "/api/v2/variables",
    "write": "/api/v2/write"
}

Actual behavior: Return HTML page:

HTTP/2 200 
date: Tue, 18 Aug 2020 08:28:19 GMT
content-type: text/html
content-length: 1017
vary: Accept-Encoding
strict-transport-security: max-age=15724800; includeSubDomains
last-modified: Mon, 17 Aug 2020 23:09:22 GMT
vary: Accept-Encoding
etag: "5f3b0e22-3f9"
accept-ranges: bytes

<!doctype html><html><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>InfluxDB 2.0</title><base href="/"><script>(function (w, d, s, l, i) {
          w[l] = w[l] || [];
          w[l].push({
            'gtm.start': new Date().getTime(),
            event: 'gtm.js'
          });
          var f = d.getElementsByTagName(s)[0],
          j = d.createElement(s),
          dl = l != 'dataLayer' ? '&l=' + l : '';
          j.async = true;
          j.src =
          'https://www.googletagmanager.com/gtm.js?id=' + i + dl;
          f.parentNode.insertBefore(j, f);
        })(window, document, 'script', 'dataLayer', 'GTM-NXMTGSW');</script><link rel="shortcut icon" href="/favicon.ico"></head><body><div id="react-root" data-basepath=""></div><noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-NXMTGSW" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript><script src="/static/73c966a93a.js"></script></body></html>%

Environment info:

Swagger definition:

image

Related to https://github.com/influxdata/influxdb-client-java/issues/143

rbetts commented 3 years ago

The "expected behavior" is NOT the expected behaviour in cloud. A change to expose that information in cloud is not valid, as I far as I understand it.

rbetts commented 3 years ago

(1) Verify that we never expose the k8s /health or /ready endpoints on a public cloud API endpoint. These should only be bind’d to internal interfaces in cloud and should not be part of the public API. (2) Verify what the /health and /ready endpoints return in OSS. (3) Verify if OSS has /api/v2/health and /api/v2/ready routes in addition to /health and /ready (4) Verify which endpoint is used by the CLI ping command. Then let’s get together and see what sorts out from this. I think the cleanest implementation is to support a top level /ping endpoint for OSS and for Cloud that returns a 200 OK when up and to port all the liveness checks to that. OSS will need to possibly report health/status information that’s not appropriate within cloud. We can figure out how to have OSS-only endpoints for those things.

bednar commented 3 years ago

Hi @rbetts,

I've prepare change for exposing /ping endpoint.

Could you check it out:

?

Regards