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
cilium statedb dump command & bugtool #26256
Conversation
cb1eb83
to
a9e5a49
Compare
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.
yay, this'll make :manager: happy
Make the JSON output easier for humans to read. Signed-off-by: Jussi Maki <jussi@isovalent.com>
To support simple dumping of the whole statedb contents for sysdump purposes this adds a simple /statedb/dump API that serializes the whole database as JSON. Signed-off-by: Jussi Maki <jussi@isovalent.com>
Once cilium#25000 is merged this handler can be moved into pkg/statedb. Signed-off-by: Jussi Maki <jussi@isovalent.com>
a9e5a49
to
c1620cb
Compare
Signed-off-by: Jussi Maki <jussi@isovalent.com>
Dump the contents of StateDB as JSON in bugtool for inspecting the internal cilium-agent state. Signed-off-by: Jussi Maki <jussi@isovalent.com>
c1620cb
to
eb3c987
Compare
/test |
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.
Looks good
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.
Looks pretty trivially correct and will help with debugging the l2 responder / announcer feature in 1.14.
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.
foundations changes lgtm
@aanm is on PTO for a bit, api hence covered mostly by Nate - changing the review request to him. |
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.
@joamaki Nice work! LGTM
Might be no opt here so feel free to disregard!
Not sure about the volumes at play but we're intermixing writeByte, writeString.
If memory serves the later is a bit slower and given we're looping, figured I'll flag.
Given our sysdump perf issues on some clusters might be worth seeing if there is a diet plan
and put this on the bench?
@@ -64,22 +64,25 @@ func (db *stateDB) WriteJSON(w io.Writer) error { | |||
if err != nil { | |||
return err | |||
} | |||
buf.WriteString("\"" + table + "\": [\n") | |||
buf.WriteString(" \"" + table + "\": [\n") | |||
obj := iter.Next() |
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.
Might make sense to roll this initializer in the for loop below.
I'm not sure I follow your comment with In any case, we're writing to a buffered writer, afaik the writes should amortize to be comparably fast to a raw memcpy; the volume of data is not expected to be huge at this time, since there's just one statedb table.
I agree that performance hasn't been the foremost concern of sysdumps. I'm reading your comment as a suggestion to put the collection of the statedb information behind a flag? I'm not opposed in general, but so far we've just slurped as much information as possible into a sysdump -- changing that will imo confuse debugging efforts of people unaware, due to missing information. If we want to do this, I'd advocate for doing it in some coordinated fashion over all of the sysdump information. I'd rather not have to go back and forth with requesting sysdumps with different configurations to get to the information needed to debug an issue, and usually I don't know which component is to blame before looking at a sysdump... |
@bimmlerd Thank you! I was not advocating introducing a flag, just a general comment on sysdump efficiency and benchmarking to optimize outputs. |
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
As requested by
:manager:
:Adds the API handler
/statedb/dump
and implements "cilium statedb dump"on top to dump the contents of StateDB as JSON.
Extends sysdump to call "cilium statedb dump" to include the output in sysdump.