Skip to content
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

Integrate Packetbeat with Agent #21356

Closed
andrewstucki opened this issue Sep 28, 2020 · 6 comments · Fixed by #22145
Closed

Integrate Packetbeat with Agent #21356

andrewstucki opened this issue Sep 28, 2020 · 6 comments · Fixed by #22145
Assignees

Comments

@andrewstucki
Copy link
Contributor

Describe the enhancement:

Integrate packetbeat with agent.

@andrewstucki andrewstucki self-assigned this Sep 28, 2020
@botelastic botelastic bot added the needs_team Indicates that the issue/PR needs a Team:* label label Sep 28, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/siem (Team:SIEM)

@botelastic botelastic bot removed the needs_team Indicates that the issue/PR needs a Team:* label label Sep 29, 2020
@andrewkroh
Copy link
Member

Relates: #22227

@andrewstucki
Copy link
Contributor Author

See discussion in #22227 for details about the spec file format.

Packages

We probably want to have multiple packages -- a single package for something like Network Traffic that we can use to enable flow data as well as potentially our protocol dissectors. Additionally, we should be able to have packet-type inputs in other packages that would allow another entrypoint for integration to specific products.

Indexing strategy

Really, the indexing strategy is an implementation detail of the packages, but it will require updating the default index patterns that get created when you use agent. I'm leaning towards having things coming from Packetbeat wind up in their own network-* indices, but we should continue that conversation.

@ruflin
Copy link
Member

ruflin commented Nov 16, 2020

Related to indexing strategy, the part I'm most interested about is how you think of the dataset part?

@andrewstucki
Copy link
Contributor Author

@ruflin dataset generally just defaults to {package}.{stream} unless its explicitly overridden (which I don't believe a single package is currently doing) -- so it doesn't seem to me like Packetbeat indexing strategy should diverge from what other packages are doing.

Was there an attempt to move away from this in other packages?

The main reason I brought up network-* as potentially a new indexing pattern is that network traffic events don't quite make sense to try and jam into a logs-* or metrics-* index, and adopting network-* (I believe) would require changes to add support for creation of those index patterns on the Kibana side.

Any thoughts @andrewkroh ?

@ruflin
Copy link
Member

ruflin commented Nov 17, 2020

@andrewstucki I think there are parts in endpoint package which do not fully follow this logic but probably not relevant in this context here. We need to make a difference here between inputs and the specific config for this input. For example the logfile input is used in many packages and has stream configs for it. So this ends up being nginx.access, nginx.error etc. Even though both use the logfile input, the resulting dataset structure is different because of the ingest pipeline processing.

How does fit packetbeat into this? Is http just the same as logfile input or is it the dataset itself? In the case of nginx and we fetch http traffic on the machine for nginx, what should the dataset name be in this case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants