-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Support complete file ingestion on update #39854
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
Comments
Pinging code owners for receiver/filelog: @djaglowski @andrzej-stencel. See Adding Labels via Comments if you do not have permissions to add labels yourself. For example, comment '/label priority:p2 -needs-triaged' to set the priority and remove the needs-triaged label. |
Pinging code owners for pkg/stanza: @djaglowski. See Adding Labels via Comments if you do not have permissions to add labels yourself. For example, comment '/label priority:p2 -needs-triaged' to set the priority and remove the needs-triaged label. |
Adding labels for related components with the goal of moving conversation along, not stating any opinion on my end. |
If I understand it correctly, you want to send all contents of a file if it is modified?
is my understanding correct? |
(Triage) removing |
If we want to unilaterally reingest the entire file anyway, perhaps using something like |
Component(s)
No response
Is your feature request related to a problem? Please describe.
We want to watch a file, and ingest all its contents on any modification of the file. The receiver should always keep the modification stamp of the file and compare it regularly to the file mstamp, or watch for file changes. Whenever this happens, the receiver should then read the entirety of the file and send it as logs.
Files watched would be configuration files of critical services, where all information must be logged for audit purposes.
Describe the solution you'd like
This is an exploratory issue that may result in a new component or an addition to an existing component.
The filelogreceiver may look like a possible approach to tackling this problem, however, it is not at all geared towards this use case. It is likely the stanza library has all the elements necessary to perform the work.
It is unclear if you actually need to persist modification timestamps - a first version can just assume on start that reading all files and send their contents is ok.
We should also set some sane limits, such that past a max size, the receiver should raise an error instead of accepting to read the file. That limit can be set by the user. A reasonable limit is 10K bytes.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: