packetbeat application layer analyzers -> pluggable modules#1101
packetbeat application layer analyzers -> pluggable modules#1101ruflin merged 2 commits intoelastic:masterfrom
Conversation
|
Great work! LGTM. |
| "github.com/elastic/beats/packetbeat/beater" | ||
|
|
||
| // import support protocol modules | ||
| _ "github.com/elastic/beats/packetbeat/protos/amqp" |
There was a problem hiding this comment.
We should automate this in the future. Also on my list for metricbeat, so perhaps we will be able to use the same script.
There was a problem hiding this comment.
not sure I'd want to full automate this. nice thing about having imports in main.go only is, one can import a very basic packetbeat as is, without any modules (for example to have a flowsbeat connection only flow information).
There was a problem hiding this comment.
By automate I mean the generation of this list based on the directories that exist. In metricbeat I put the list in a different package: https://github.com/elastic/beats/tree/master/metricbeat/include
The advantage of this if someone creates a beat with only one module he can either include all other modules and metricsets he wants one by one or he can just link to `_ "github.com/elastic/beats/metricbeat/include" and gets all the official modules of metricbeat without having to update it all the time.
|
This change feels really good. It is quite large and which makes it hard to follow as lots of things moved around. I focused more on if the tests stayed the same as there were much fewer changes on the test side. It LGTM and I suggest to merge this one as soon as the builds go green. |
|
Yeah, was a little surprised about this of PR, but I have had to do all modules at once. For review concentrate on packetbeat/protos/protos.go and registry.go + maybe one module (e.g. http) initialization. Updates to all modules are basically similar:
|
packetbeat application layer analyzers -> pluggable modules
No description provided.