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.

Sign up for GitHub

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

Jump to bottom

[Discuss] Set the default ops.interval back to 10s? #20899

Closed
tsullivan opened this issue Jul 17, 2018 · 5 comments
Closed

[Discuss] Set the default ops.interval back to 10s? #20899

tsullivan opened this issue Jul 17, 2018 · 5 comments
Labels
discuss Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@tsullivan
Copy link
Member

The original default setting for the kibana.yml ops.interval was 10s. It was changed to 5s to help show more continuity in the Kibana Monitoring dashboard charts - with the data being generated at 10s intervals, uploaded to Elasticsearch every 10s, and then rendered in a date histogram chart with 10s intervals, it was very possible to get gaps in the chart when you zoom in to a small time range.

Using 5s was a quick way to deal with the granularity of the data, and we didn't worry about missing any data points because our internal listener for the ops monitoring event in Hapi fires with every ops event, which is the same rate as the ops.interval setting. However, we plan to expose the stats in a public API for an external collector to take the data through a pipeline on its way to the monitoring cluster. Typically a collector like Metricbeat would be configured to pull the API every 10 seconds. The event listener refreshes the data when it fires [1] so if it fires every 5s and Metricbeat pull every 10s, then Metricbeat will miss half of the data.

[1] A longer-term goal is to have the event listener accumulate the stats data when it fires. The data exposed in the public API should be in absolutes, but for the short-term, the data is relative to an amount of time configured by ops.interval.

cc @pickypg @ycombinator @chrisronline
@kobelb kobelb added the Team:Monitoring Stack Monitoring team label Aug 7, 2018
@tsullivan
Copy link
Member Author

@chrisronline this issue looks stale. Do you think it can be closed?

@tsullivan tsullivan added the stale Used to mark issues that were closed for being stale label Feb 16, 2021
@chrisronline
Copy link
Contributor

Yea I don't know about this one. The platform team took over stats collection so I'm not sure where they are with it. cc @joshdover

@joshdover
Copy link
Contributor

I think this issue is still valid. We are still using a 5s default and the accumulated data is dumped between each refresh. Will re-assign to our team.

@joshdover joshdover added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc and removed Team:Monitoring Stack Monitoring team stale Used to mark issues that were closed for being stale labels Mar 10, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

@pgayvallet
Copy link
Contributor

We didn't get back on the issue for 5 years now, so I will assume that keeping that 5s value is fine, and close the issue.

Feel free to reopen if you think I shouldn't have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
discuss Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@chrisronline @kobelb @tsullivan @pgayvallet @joshdover @elasticmachine