Implement log shipping to Graylog via GELF #8410
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed changes
Related issues
There are not related issues but this subject has been previously discussed with Linkare within the scope of the OpenCTI implementation for the CCB (https://ccb.belgium.be/).
Checklist
Further comments
We added an extra step to the application shutdown so that it now waits for the loggers to flush. This was previously not very relevant but sending data via the network introduces some latency that makes this necessary. Failing to do so results in the loss of some of the last log messages. This is particularly critical in the cases where the application fails as those messages will probably include the details of the relevant error.
No new tests were added for this functionality as that would require setting up an integration testing environment containing at least a Graylog instance plus subordinate MongoDB and Elasticsearch instances. Furthermore, having the test communicate with Graylog, so as to assert that the logs where correctly stored, would not be a trivial implementation. All in all, we estimate the effort required to implement all of this would dwarf the effort put into such a small change.
On the other hand, the changes proposed are all opt-in so they shouldn't break any existing behaviour. The little code that is unavoidable will actually run on every startup and shutdown and thus all existing tests will at least validate that the new functionality has no negative effects when not explicitly enabled.