Implement an API for exporting session events #7360
Conversation
xacrimon
force-pushed
the
joel/session-export-api
branch
2 times, most recently
from
1e0c7db
to
59661d8
Compare
|
@xacrimon Regarding streaming the events over, how would we handle print events? For example, an external plugin would get all the print events, but how would the user piece them together (with timing information) to play the session back? Also, most of the events here, like @alex-kovoy @klizhentas Can you review the changes being made here as well? How do we plan to use the session exporter to actually work and how will users use it? |
|
@russjones I think the solution that @xacrimon proposed here is good - it is independent on serialization format. I am not concerned about event duplication. The deduplication should happen on the receiving backend. The fluentd-forwarder should be able to reassemble the session to required format or forward parts of the session to the backend. |
xacrimon
force-pushed
the
joel/session-export-api
branch
from
97e7632
to
3ba6d42
Compare
|
Okay, there is some strange bug with it not picking up all events sometimes. I'll investigate, in the meantime, no need to review. |
|
Fixed the error, integration tests now pass. It doesn't support playing back the old-style session recordings however. Is that a requirement or are they not in use anymore? If we do have to support them, what's the best way to read events from them. |
xacrimon
force-pushed
the
joel/session-export-api
branch
from
374c3b2
to
5d84fe2
Compare
xacrimon
force-pushed
the
joel/session-export-api
branch
from
a159434
to
7c36eb3
Compare
…5348) The code attempts to wait on an existing download if one is already in progress rather than starting a concurrent download of the same session. If this code path runs, we incorrectly defer a call to a nil function, triggering a panic. This bug was introduced in #7360. In some cases, an auth server can see a response from the uploader with an empty session ID. If this is the case, skip emitting the session end and upload events, as there's no action to take. This scenario can happen when multiple auth servers are running upload completers and working on the same uploads simultaneously.
This PR implements a gRPC API available via
IAuditLogto stream audit events from a session recording.Enterprise buddy: https://github.com/gravitational/teleport.e/pull/278
This resolves issue #7305.
There's a couple places in this PR where errors are not relayed correctly due to them being based on cancel contexts. What would be the ideal way to propagate an error upwards when cancelling a context?