-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Stats API #11992
Stats API #11992
Conversation
17d9d17
to
6d9a6aa
Compare
Modifying the .kibana index turned out to be more of a challenge than originally thought. I looked into changing the mapping to allow aggregations on visualization sub type and it sounds like this can't be done without a manual migration step (operations team tagged below can confirm). Filed #12117 which is a blocker for that portion of the stats. @tylersmalley @jbudz -- Given where the operations team is at and the extra complexity involved with modifying the index to allow for visualization sub type tracking, (in addition more efficient type tracking if we made type a searchable and aggregatable field), how likely do you think it is that this can happen in time for 6.0, with some time left for me to modify the stats API to take advantage of the new fields? If we don't get it in to 6.0, can we make these index changes in 6.1? I don't think it will be a BWC change, but do we write migration steps for minor releases? Or will we have to wait till 7.0 to add the additional metrics? @alexfrancoeur @pickypg @tsullivan -- based on the response from my questions above, I'm wondering if we should check this in as is so we at least have some stats to track for 6.0, and push the additional stats till 6.x, 7.0 at worst. |
@stacey-gammon I'm comfortable with treating visualization sub-type as a secondary priority. The first comment of this PR is a bit unclear but based on our previous conversations I'd assume that we can track the total number of saved objects for each type of saved object. Is that correct? Total number of dashboards, visualizations, index patterns, saved searches, etc. Each one of these being a separate ES query for now. If there is no bandwidth from the ops team (which it doesn't sound like there is) I'd be comfortable with introducing these metrics for 6.0 and enhancing with visualization sub-types in a 6.x release |
@alexfrancoeur - Yep exactly, and that is solved by the current state of this PR (I updated the description). I'll go ahead and bump this into the review process so we can at least have that ready to go for 6.0, and will wait on the additional stats/efficiency enhancements for more bandwidth from the ops team. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, but I had a few minor suggestions
src/server/stats/stats_mixin.js
Outdated
|
||
const stats = await getStats( | ||
server.config().get('kibana.index'), | ||
callAdminCluster); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The )
looks like it should go 1 line down :)
src/server/stats/stats.js
Outdated
|
||
const requests = types.map(type => { | ||
return getStatsForType(savedObjectsClient, type); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be simply:
const requests = types.map(type => getStatsForType(savedObjectsClient, type));
src/server/stats/stats.js
Outdated
export async function getStats(kibanaIndex, callAdminCluster) { | ||
const savedObjectsClient = new SavedObjectsClient(kibanaIndex, callAdminCluster); | ||
const types = ['dashboard', 'visualization', 'search', 'index-pattern']; | ||
const stats = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be moved down closer to where it is first referenced
src/server/stats/stats.js
Outdated
const response = await savedObjectsClient.find({ type, perPage: 0 }); | ||
return { | ||
total: response.total | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const { total } = await savedObjectsClient.find({ type, perPage: 0 });
return { total };
6d9a6aa
to
b571688
Compare
Any additional comments @tsullivan, @pickypg? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
ping @pickypg :) |
callAdminCluster | ||
); | ||
|
||
return reply(stats); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can reply with the promise instead of awaiting it. Just a nitpick, doesn't need to be changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And then the handler doesn't need to be marked as async
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
neat
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return Promise.resolve(getStats(server.config().get('kibana.index'), callAdminCluster));
Unless not modifying the return actually works? I would be surprised if that were the case, but JS has done crazier things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pickypg, It worked when I tested it, but using the above doesn't seem to work (I don't see an error, it just hangs). Do I need to wrap your return with the reply?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
async
/ await
is all just sugar on top of Promise
, so the method is already returning a Promise
that you choose to await
against to get the value (or throw the exception). So I'm guessing if it worked, then you simply can stick with what you've got and can avoid my extra fluff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh doh! Yes, my example was missing reply
wrapping the Promise
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You shouldn't need Promise.resolve
since getStats
returns a promise. Just need to return the getStats
call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
callAdminCluster | ||
); | ||
|
||
return reply(stats); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And then the handler doesn't need to be marked as async
.
@stacey-gammon could we get a Release Note: paragraph in the description that summarizes the effect of the changes |
Done @jimgoodwin - not sure how the ``` will come out though. I can get rid of them if it messes up the formatting. |
I'm rolling back this PR for 6.0, but parts of it will be available in 6.1+. There will be no HTTP API. The mixin provides a server method in 6.1+, and that functionality will remain. @jimgoodwin @stacey-gammon sorry for the churn, but let's make sure there's no mention of this change in the release notes. |
Release Note:
We introduced a new api endpoint at
api/stats
which displays counts of saved objects in your kibana index:Currently tracking total counts of: