Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[Stack Monitoring] [R&D] Document how we store, query, and display shard information #125258

Closed
jasonrhodes opened this issue Feb 10, 2022 · 3 comments
Labels
Feature:Stack Monitoring R&D Research and development ticket (not meant to produce code, but to make a decision) Team:Infra Monitoring UI - DEPRECATED DEPRECATED - Label for the Infra Monitoring UI team. Use Team:obs-ux-infra_services

Comments

@jasonrhodes
Copy link
Member

There is an ongoing effort to reduce the amount of inefficient queries against Elasticsearch, related to retrieving information about ES shards. Stack Monitoring is one of the biggest callers of these endpoints* and we are aware of the idea that for a long time, we've been retrieving and storing shard information that we may or may not need to power the monitoring UI(s).

We need to document which endpoints we call, which documents/fields we store (related to ES shards), and whether or not we use those in the UI. If we don't, we should log an issue to remove this retrieval and storage. If we do use them, or if we determine that we should keep the retrieval in place for some reason, we should work with the ES team to determine a new API for querying this information.

*Which ES endpoints are the problematic ones we need to look into here?

Acceptance Criteria

  • A write-up exists documenting
    • the shard-related ES APIs that the elasticsearch MB module calls,
    • the actual fields we store in our monitoring indices from these calls, and
    • which of these fields we display in the monitoring UI
  • New issue(s) is/are filed to either remove some of these calls, adjust the UI, and/or switch to a new ES API that can be more performant/efficient for what we really need

Outstanding Questions:

  • Does ES internal collection have the same problem? cc: @jakelandis
  • Which endpoints are the problem ones from the ES "many shards" perspective?
@jasonrhodes jasonrhodes added Team:Infra Monitoring UI - DEPRECATED DEPRECATED - Label for the Infra Monitoring UI team. Use Team:obs-ux-infra_services R&D Research and development ticket (not meant to produce code, but to make a decision) Feature:Stack Monitoring labels Feb 10, 2022
@elasticmachine
Copy link
Contributor

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

@matschaffer
Copy link
Contributor

matschaffer commented Feb 15, 2022

I think there's some overlap with elastic/beats#29980 (Establish first class monitoring procedure for elasticsearch) here.

Today we just query cluster state which isn't an explicitly stable API and it's also heavy, as outlined in this issue.

@jasonrhodes
Copy link
Member Author

We can probably replace this with the wider effort to document this same information for each module -- elasticsearch module here #127209

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Feature:Stack Monitoring R&D Research and development ticket (not meant to produce code, but to make a decision) Team:Infra Monitoring UI - DEPRECATED DEPRECATED - Label for the Infra Monitoring UI team. Use Team:obs-ux-infra_services
Projects
None yet
Development

No branches or pull requests

3 participants