filebeat/input/journald: allow specifying since when to read journald entries

[efd6]

What does this PR do?

This allows users to specify a relative time offset for starting to read journald entries, or as a fallback for cursor restarts.

Why is it important?

This is required for an integration enhancement.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• [Journald] Add Ignore older than setting integrations#6060.

Use cases

Screenshots

Logs

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-07-27T17:48:13.322+0000

• Duration: 74 min 19 sec

Test stats 🧪

Test	Results
Failed	0
Passed	8090
Skipped	757
Total	8847

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[rdner]

Do we have existing integration/e2e tests working with journald? If so we need to update them in order to test this new option. If not, we need to file an issue to add them ASAP.

[rdner]

Why not require.ErrorIs?

[efd6]

I avoid assertion libraries for the reasons stated in the Go wiki.

[rdner]

@efd6 this is a very strange statement to make since our entire codebase is using the testify library and it makes our tests more concise. Even this file is importing both assert and require and they're used in another test.

I've read the reasons stated in the wiki and I think it's coming from misunderstanding how testify works:

• assert does not stop the test and lets it run further but fails it at the end of the run
• require fails the test immediately and does not run further.

so, developers are free to choose the behaviour when necessary.

[efd6]

The final part is the most sigificant:

Assert libraries make it too easy to write imprecise tests and inevitably end up duplicating features already in the language, like expression evaluation, comparisons, sometimes even more. Strive to write tests that are precise both about what went wrong and what went right, and make use of Go itself instead of creating a mini-language inside Go.

My experience with assert libraries, particularly testify, is that they make test failure outputs needlessly complex as the cost for the concision that is gained. It's important that comprehensibility, rather than concision is the goal for test code. Test should should really be completely transparent, concise code is often not this is an excellent decades-long study in that. The other issue is that as the quoted text above says, they make it easy for authors to write imprecise tests; this often presents as a test which says nothing other than where the failure happened and what the comparands were. Assert libraries usually (testify does) provide a format/args list to decorate failures with; in my experience, these are almost never used because the author favours the proximate terness and concision over the long term clarity that a well though out test provides.

[rdner]

That still sounds like a personal preference and not argumentation. The whole code base is using testify, the decision was made and the new tests should maintain consistency, thank you.

[belimawr]

The only last thing I'm missing is a test to ensure the feature works, especially that the pointer deference does not panic.
There is a test on https://github.com/elastic/beats/blob/main/filebeat/input/journald/input_test.go that you can use as a start point.

[belimawr]

The new changes look good, thanks!

However I'm still missing a test that actually tests the functionality of using the Since value when reading the journal. Could you add this last one, please?

[efd6]

Aren't we then testing the behaviour of journald which was rejected here?

[belimawr]

Aren't we then testing the behaviour of journald which was rejected here?

They're two different things, at least the way I see them.

#35408 (comment) was a general comment about the ideal way of testing our code.

This one is about having some sort of tests that actually run the implemented code in the input (the run function).

It is about having some test ensuring the added code does not break anything, ideally it would not rely on journald, but if it does, it's also ok. We can always improve add more tests later, but it is important to have some tests actually running the implemented code.

[efd6]

From what I can see it is not possible to test Run without involving journald. This is because the only way we can get to the path here is after calling journald.open which returns a real sdjournal value that we cannot mock. What this test would tell us is that a call to the SeekRealtimeUsec method (indirected via the interface in that package) does what the sdjournal docs and tests say it does since we already know from the tests that I've added here that it is not possible to reach a state where inp.Since is nil and the mode returned by seekBy is journalread.SeekSince, so we cannot cause a nil-deref of inp.Since. Whether there are issues in the use (*sdjournal.Journal).SeekRealtimeUsec? We can see that from the testing that that package does.

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b i6060-journald upstream/i6060-journald
git merge upstream/main
git push upstream i6060-journald

[andrewkroh]

However I'm still missing a test that actually tests the functionality of using the Since value when reading the journal. Could you add this last one, please?

@belimawr I pushed in two test cases to verify that seek: since and cursor_seek_fallback: since are working. Please take another look.