Remove X-Pack Usage API endpoint #20800
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tsullivan
force-pushed
the
usage/remove-xpack-usage-api
branch
4 times, most recently
from
5bb9f7a to
2f704b8
Compare
/api/_xpack/usage was added as a target for 6.4.0 but it will not be used. Instead, the /api/stats response will include usage info on everything that gets registered with the usage service in /src/server/usage /api/_kibana/v1/stats is a GET API that was added in 6.2, during a point where we thought providing usage stats through a public API would be OK for capturing internally, with the benefit of having it be visible. However, we've pivoted away from that idea because it doesn't line up too well with the existing flow of data, where usage stats are combined with the "Kibana stats" such as process uptime and number of requests. We want to shift how we collect stats from Kibana, but it will be gradual. It might be a while before we have an architecture that makes sense for a standalone public API for the usage stats This endpoint was never documented, and isn't used anywhere in the code. It does incur a maintenance cost though. Therefore, instead of waiting for a next major version to remove this API, I'm removing it for 6.4. It will be marked in the release notes as a breaking change. Since it was never documented, it should not provide a problem.
tsullivan
force-pushed
the
usage/remove-xpack-usage-api
branch
from
2f704b8 to
7d554c6
Compare
Contributor
💚 Build Succeeded |
tsullivan
changed the title
4 tasks
tsullivan
added a commit
to tsullivan/kibana
that referenced
this pull request
Jul 19, 2018
/api/_xpack/usage was added as a target for 6.4.0 but it will not be used. Instead, the /api/stats response will include usage info on everything that gets registered with the usage service in /src/server/usage /api/_kibana/v1/stats is a GET API that was added in 6.2, during a point where we thought providing usage stats through a public API would be OK for capturing internally, with the benefit of having it be visible. However, we've pivoted away from that idea because it doesn't line up too well with the existing flow of data, where usage stats are combined with the "Kibana stats" such as process uptime and number of requests. We want to shift how we collect stats from Kibana, but it will be gradual. It might be a while before we have an architecture that makes sense for a standalone public API for the usage stats This endpoint was never documented, and isn't used anywhere in the code. It does incur a maintenance cost though. Therefore, instead of waiting for a next major version to remove this API, I'm removing it for 6.4. It will be marked in the release notes as a breaking change. Since it was never documented, it should not provide a problem.
tsullivan
added a commit
that referenced
this pull request
Jul 20, 2018
/api/_xpack/usage was added as a target for 6.4.0 but it will not be used. Instead, the /api/stats response will include usage info on everything that gets registered with the usage service in /src/server/usage /api/_kibana/v1/stats is a GET API that was added in 6.2, during a point where we thought providing usage stats through a public API would be OK for capturing internally, with the benefit of having it be visible. However, we've pivoted away from that idea because it doesn't line up too well with the existing flow of data, where usage stats are combined with the "Kibana stats" such as process uptime and number of requests. We want to shift how we collect stats from Kibana, but it will be gradual. It might be a while before we have an architecture that makes sense for a standalone public API for the usage stats This endpoint was never documented, and isn't used anywhere in the code. It does incur a maintenance cost though. Therefore, instead of waiting for a next major version to remove this API, I'm removing it for 6.4. It will be marked in the release notes as a breaking change. Since it was never documented, it should not provide a problem.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Depended on #20577
Part of #20393
/api/_xpack/usagewas added as a target for 6.4.0 but it will not beused. Instead, the
/api/stats?extended=trueresponse will includeusage info on everything that gets registered with the usage service in
/src/server/usage/api/_kibana/v1/statsis a GET API that was added in 6.2, during a pointwhere we thought providing usage stats through a public API would be OK
for capturing internally, with the benefit of having it be visible.
However, we've pivoted away from that idea because it doesn't line up
too well with the existing flow of data, where usage stats are combined
with the "Kibana stats" such as process uptime and number of requests.
We want to shift how we collect stats from Kibana, but it will be
gradual. It might be a while before we have an architecture that makes
sense for a standalone public API for the usage stats
This endpoint was never documented, and isn't used anywhere in the code.
It does incur a maintenance cost though.
Therefore, instead of waiting for a next major version to remove this
API, I'm removing it for 6.4. It will be marked in the release notes as
a breaking change. Since it was never documented, it should not provide
a problem.
Release notes: We removed a public HTTP API endpoint of
/api/_kibana/v1/stats. This endpoint was meant for internal consumption only, but since it was public we're considering it a breaking change. The data provided by this endpoint is available as theusagefield of a new/api/stats?extended=true. The new/api/statsendpoint is still meant for internal consumption, but we're going to keep working on improvements to it and it'll eventually be documented as an API we'll support publicly.