[elasticsearch] Add the local query parameter when fetching cluster state #36586
Conversation
miltonhultgren
added
module
Team:Infra Monitoring UI - DEPRECATED
botelastic
bot
added
needs_team
|
@DaveCTurner FYI, following up on the comment you made in a recent Discuss thread, I'm hoping I understood correctly the changes suggested. |
|
Admittedly I don't read Golang so good, but I could well believe that this does indeed add the |
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
💚 Flaky test reportTests succeeded. 🤖 GitHub commentsExpand to view the GitHub comments
To re-run your PR in the CI, just comment with:
|
| @@ -31,7 +31,7 @@ func init() { | |||
| } | |||
|
|
|||
| const ( | |||
| statePath = "/_cluster/state/version,nodes,master_node,routing_table" | |||
| statePath = "/_cluster/state/version,nodes,master_node,routing_table?local=true" | |||
There was a problem hiding this comment.
Would we miss data in a scope: cluster scenario where we only have one metricbeat process ? i'd expect local=true to be set only when scope: node
There was a problem hiding this comment.
While developing this, I compared the results of the API with and without this flag and they were the same.
Maybe the result could differ between types of nodes, like a master nodes reply versus a data nodes reply, that I didn't compare. I just looked at if a data nodes reply changed between the versions (with and without flag).
@DaveCTurner Can you confirm if that's always the case?
There was a problem hiding this comment.
No (or at least this change doesn't make a meaningful difference in that regard). The ?local=true parameter means "give me your local copy of the entire cluster state rather than forwarding this request to the elected master" but you get the same state either way (in fact sometimes you'll get a slightly fresher state with ?local=true, and sometimes ?local=true will succeed when ?local=false would fail, so this seems like the right change)
There was a problem hiding this comment.
"No" as in:
Would we miss data in a
scope: clusterscenario where we only have one metricbeat process ?
No
Can you confirm if that's always the case?
Yes
There was a problem hiding this comment.
Thanks for the insight!
…tate (#36586) (#36656) * [elasticsearch] Add the local query parameter when fetching cluster state * Fix lint issues (cherry picked from commit 2830492) Co-authored-by: Milton Hultgren <[email protected]>
…tate (elastic#36586) * [elasticsearch] Add the local query parameter when fetching cluster state * Fix lint issues
When using
scope: clusterwe expect the cluster to be exposed through a single endpoint (either a single non-master eligible node or a load balancer across all non-master eligible nodes).Because we use parts of the cluster state for many things across various metricsets it is important that we request the parts we need from the non-master eligible nodes to not cause undue load on the master eligible nodes, by adding
local=truewe ensure that the state is only fetched from the node we're talking to and not via the master node.