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

Stats API #11992

Merged
merged 4 commits into from
Jun 12, 2017
Merged

Stats API #11992

merged 4 commits into from
Jun 12, 2017

Conversation

stacey-gammon
Copy link
Contributor

@stacey-gammon stacey-gammon commented May 24, 2017

Release Note:
We introduced a new api endpoint at api/stats which displays counts of saved objects in your kibana index:

{"dashboard":{"total":1},"visualization":{"total":3},"search":{"total":1},"index_pattern":{"total":1},"index":".kibana"}

Currently tracking total counts of:

  • saved searches
  • index patterns
  • visualizations
  • dashboards

@stacey-gammon
Copy link
Contributor Author

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.

@alexfrancoeur
Copy link

@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

@stacey-gammon
Copy link
Contributor Author

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.

@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.

Copy link
Member

@tsullivan tsullivan left a 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


const stats = await getStats(
server.config().get('kibana.index'),
callAdminCluster);
Copy link
Member

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 :)


const requests = types.map(type => {
return getStatsForType(savedObjectsClient, type);
});
Copy link
Member

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));

export async function getStats(kibanaIndex, callAdminCluster) {
const savedObjectsClient = new SavedObjectsClient(kibanaIndex, callAdminCluster);
const types = ['dashboard', 'visualization', 'search', 'index-pattern'];
const stats = {};
Copy link
Member

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

const response = await savedObjectsClient.find({ type, perPage: 0 });
return {
total: response.total
};
Copy link
Member

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 };

@stacey-gammon
Copy link
Contributor Author

Any additional comments @tsullivan, @pickypg?

@stacey-gammon stacey-gammon removed the request for review from tylersmalley June 6, 2017 14:52
Copy link
Member

@tsullivan tsullivan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@stacey-gammon
Copy link
Contributor Author

ping @pickypg :)

callAdminCluster
);

return reply(stats);
Copy link
Contributor

@tylersmalley tylersmalley Jun 9, 2017

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.

Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

neat

Copy link
Member

@pickypg pickypg Jun 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stacey-gammon

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.

Copy link
Contributor Author

@stacey-gammon stacey-gammon Jun 9, 2017

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?

Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor

@tylersmalley tylersmalley Jun 9, 2017

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.

Copy link
Contributor

@tylersmalley tylersmalley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@pickypg pickypg left a 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);
Copy link
Member

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 stacey-gammon merged commit 415bf15 into elastic:master Jun 12, 2017
@jimgoodwin
Copy link

@stacey-gammon could we get a Release Note: paragraph in the description that summarizes the effect of the changes

@stacey-gammon
Copy link
Contributor Author

Done @jimgoodwin - not sure how the ``` will come out though. I can get rid of them if it messes up the formatting.

@tsullivan tsullivan mentioned this pull request Sep 7, 2017
@tsullivan
Copy link
Member

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.

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

Successfully merging this pull request may close these issues.

7 participants