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

[FEAT] Log Aggregation #68

Closed
NeonDaniel opened this issue Jan 31, 2024 · 6 comments
Closed

[FEAT] Log Aggregation #68

NeonDaniel opened this issue Jan 31, 2024 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@NeonDaniel
Copy link
Member

Objective

Currently, many services interact with each other, so viewing synchronized logs is sometimes necessary. Additionally, we have no documented tools for viewing container logs in k8s (k9s is not really a log viewer).

Initial Implementation Requirements

  • Service or workflow to view multiple container logs in real-time
  • Method for viewing multiple container logs from a specific time range

Other Considerations

@NeonDaniel NeonDaniel added the enhancement New feature or request label Jan 31, 2024
@NeonDaniel
Copy link
Member Author

The license for Sentry appears to be modified Apache, so would have to evaluate if that is compatible and acceptable for our use.

Open Telemetry is Apache 2.0 licensed and may also be applicable for metrics reporting in addition to logging

Graylog uses the same license as MongoDb apparently which I believe we have already evaluated as acceptable for our use cases.

@NeonDaniel
Copy link
Member Author

Allure was also mentioned but I have not researched that implementation

@NeonDaniel NeonDaniel self-assigned this Feb 6, 2024
@NeonDaniel
Copy link
Member Author

Official docs for Kubernetes outline some different architecture options. It seems a node logging agent might be the easiest to implement as it requires no changes to containers and only adds one container per node vs a sidecar container per pod.

I believe all of the logging we care about is already using ovos-utils.log so formatting is uniform and log names can be parsed in the logging backend

@NeonDaniel
Copy link
Member Author

From @mikejgray this article outlines some good background information on logging. For the moment, kubetail or one of the other utilities they mention may be sufficient to debug issues with the default logging we have.

Longer-term we may want to use sidecar containers to build structured logs and implement proper aggregation on a dedicated pod

@NeonDaniel
Copy link
Member Author

As discussed, we will get an account opened with Sentry for @NeonKirill to integrate with Klat to start. If this works well, we can extend other services to support this and work it into the diana setup CLI as an optional component

@NeonDaniel
Copy link
Member Author

Closed by #80

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants