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.

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

Elastic Agent should aggregate the log from his subprocesses #221

Closed
4 tasks
Tracked by #189 ...
ph opened this issue Mar 17, 2022 · 5 comments · Fixed by elastic/elastic-agent-libs#88
Closed
4 tasks
Tracked by #189 ...

Elastic Agent should aggregate the log from his subprocesses #221

ph opened this issue Mar 17, 2022 · 5 comments · Fixed by elastic/elastic-agent-libs#88
Assignees
Labels
estimation:Week Task that represents a week of work. Team:Elastic-Agent-Control-Plane Label for the Agent Control Plane team V2-Architecture v8.6.0

Comments

@ph
Copy link
Contributor

ph commented Mar 17, 2022

Running processes for the Elastic Agent should be considered an implementation details, currently, each process is responsible for writing their own log and handling the file rotation. Instead, each process should write their log to stdout and Elastic Agent should aggregate them and write them to his own logs and also handle the file rotation.

Tasks:

  • The impact of these changes with the existing data stream.
  • Make sure that we can identify which component is failing.
  • Allow the code to be flexible so we could stream these events directly to Elasticsearch
  • Allow the code later to receive events from a gRPC connection to Endpoint.

This work is related to #88

@ph ph added the Team:Elastic-Agent-Control-Plane Label for the Agent Control Plane team label Mar 17, 2022
@ph ph changed the title Elastic Agent should aggregate the log from his subprocess Elastic Agent should aggregate the log from his subprocesses Mar 17, 2022
@ph
Copy link
Contributor Author

ph commented Mar 17, 2022

@jlind23 @AndersonQ I believe this work is related to #88

@cmacknz
Copy link
Member

cmacknz commented Sep 14, 2022

Speaking with @blakerouse we're not sure if this approach simplifies logging in the way we expected. The initial v2 architecture is more likely to ship with a logging architecture similar to that from v1.

@blakerouse can add more details later on the approach we should take instead.

@cmacknz
Copy link
Member

cmacknz commented Oct 20, 2022

With the decision to revert to v1 style logging, we should remove the ElasticAgentLog service from the control protocol that was added to support the originally proposed logging model: https://github.com/elastic/elastic-agent-client/blob/3e014f7c0e838727f2596e3463f5110590e529cf/elastic-agent-client.proto#L540-L548

@blakerouse
Copy link
Contributor

After discussion with @cmacknz, we are going to try and using an io.Reader approach to read from the spawned processes stdout/stderr, parse the message, attribute the event, and write it to the Elastic Agent logger. Benefits for this approach include:

  • Input developers do not need to worry about logging to a file, file rotation, etc.
  • Settings for log size and rotation will affect the whole Elastic Agent, not each individual input (which causes the size and number of files to be X factor larger than what would be expected)
  • Unified view of what the Elastic Agent is doing, currently in v1 it is not clear what each input is doing as they are written to their own files.

For Endpoint Security, it will still write to its own file, Elastic Agent will read from that file and provide the same logic as if that was a spawned subprocess and it was reading from stdout/stderr.

@cmacknz
Copy link
Member

cmacknz commented Nov 30, 2022

I think we can close this. There is follow up work to do but that is tracked in #1814.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
estimation:Week Task that represents a week of work. Team:Elastic-Agent-Control-Plane Label for the Agent Control Plane team V2-Architecture v8.6.0
Projects
None yet
6 participants