filebeat/input/{v2,logv2}: add Redirector interface for general input migration#49613
filebeat/input/{v2,logv2}: add Redirector interface for general input migration#49613efd6 wants to merge 1 commit intoelastic:mainfrom
Conversation
🤖 GitHub commentsJust comment with:
|
|
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
7fb1e17 to
c0d3721
Compare
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (9)
✅ Files skipped from review due to trivial changes (4)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughAdds a redirect mechanism for Filebeat inputs: a new exported ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
… migration Add an optional Redirector interface to the v2 input system so the Loader can transparently redirect one input type to another. This replaces the bespoke approach where logv2 directly imported and instantiated the filestream plugin. The Loader checks for Redirector before calling Create. If Redirect returns a non-empty target type, the Loader resolves the target from its plugin registry and calls its Create with the translated config. Only one redirect hop is allowed. Delete follows the same redirect path so CheckConfig cleanup operates on the correct target. Refactor the logv2 manager to implement Redirector instead of holding a direct reference to the filestream manager. This removes logv2's import of the filestream package, eliminates a duplicate filestream manager instance (and its redundant Init call), and makes the pattern reusable for future V2-to-V2 migrations such as httpjson to cel.
c0d3721 to
acbaa75
Compare
|
@efd6 Is it correct that we separately pursued an approach where we'd migrate to cel but let it get old httpjson input cursor data? What's the status of that? Was that unsuccessful, or just incomplete, or is it not the same use case as this? |
|
This is essentially that, or at least an evolution of it (there was a shared state proposal that was abandoned, which may be what you are thinking of). There was an early, ugly, alternative approach that hid CEL in HTTP JSON. That has been abandoned as it was too ugly. There is also the non-cursor-state case that's handled by fleet; that is in parallel with this (I have notes for a KB article for how to use them together and when to do so). The logic for the collection of HTTP JSON cursor state is in the partner PR. |
Proposed commit message
Note
It may be worth reading the partner PR, #49614, to this to see its operation in context.
Checklist
stresstest.shscript to run them under stress conditions and race detector to verify their stability../changelog/fragmentsusing the changelog tool.Disruptive User Impact
Author's Checklist
How to test this PR locally
Related issues
Use cases
Screenshots
Logs