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

Filebeat setup is not creating index pattern in kibana #19965

Closed
liza-mae opened this issue Jul 16, 2020 · 9 comments · Fixed by #20170
Closed

Filebeat setup is not creating index pattern in kibana #19965

liza-mae opened this issue Jul 16, 2020 · 9 comments · Fixed by #20170
Labels
blocker bug Filebeat Filebeat regression Team:Integrations Label for the Integrations team

Comments

@liza-mae
Copy link

  • Version: 7.9.0 BC1
  • Operating System: Ubuntu 16
  • Steps to Reproduce:
    Install and run ES/Kibana.
    Install Filebeat.

Due to #19964 - I tried running ./filebeat setup --dashboards instead to get around it and it seemed to pass,
Loading dashboards (Kibana must be running and reachable)
Loaded dashboards

However, it is not creating the index and even using filebeat setup does not create index pattern .

@elasticmachine
Copy link
Collaborator

Pinging @elastic/integrations (Team:Integrations)

@elastic elastic deleted a comment from elasticmachine Jul 16, 2020
@LeeDr
Copy link

LeeDr commented Jul 16, 2020

I hit the same problem with 7.9.0 BC1 on centOS 7. Kibana debug logs didn't show anything related to it.

@liza-mae
Copy link
Author

@LeeDr after looking at this closer, I would consider it a blocker since it is causing wider problems in Kibana when creating this index manually and more so when it is the default index pattern.

Screenshot from 2020-07-16 07-37-21

@kaiyan-sheng
Copy link
Contributor

kaiyan-sheng commented Jul 21, 2020

I'm seeing the same issue when trying to create a kibana index pattern for Filebeat:
Screen Shot 2020-07-21 at 4 11 50 PM

Metricbeat seems to work just fine. Maybe it's related to the field count in Filebeat? I don't think user should have to manually change server.maxPayloadBytes in order to get Filebeat working.

@andrewkroh
Copy link
Member

andrewkroh commented Jul 21, 2020

To elaborate on @kaiyan-sheng's last comment, while creating the index pattern in Kibana, it requests all of the fields for filebeat-* and gets back about 6700 fields (almost a 1MB response) then tries to PUT the index pattern it created and fails with HTTP 413. This is same error code we see when Filebeat tries to insert the index pattern that it generates (although the error was silently ignored due to #20121).

Screen Shot 2020-07-21 at 6 49 23 PM

@urso
Copy link

urso commented Jul 22, 2020

This is quite a many fields...

Is the error because of too many fields in general, or does it indicate some other error?
I wonder if the API would allow us to add fields in batches to the index pattern. Then we could try to split the index pattern into batches of 1000 fields and call it until all fields are installed.

@andrewkroh
Copy link
Member

andrewkroh commented Jul 22, 2020

I tried a small hack and I was able to slim down the size of the index pattern request body from Filebeat by omitting some of the parameters with default values (e.g. count=0, analyzed=false). This allows Filebeat setup to work, but even with that working there are still problems in Kibana.

It seems like Kibana still wants to update the index pattern when visiting Discover or opening the Index Pattern UI and this triggers the HTTP 413 despite have already pushed an index pattern.

@andrewkroh
Copy link
Member

andrewkroh commented Jul 22, 2020

I have identified about 2000 fields that should not be present. That's about 1/3 of the fields in the mapping so when we fix that it should help this issue.

$ ./filebeat export index-pattern | jq '.objects[0].attributes.fields | fromjson | .[].name' | sort | uniq | grep -E "(microsoft|cisco|fortinet)\.rsa"

The fields returned in that list were meant to be named ^rsa.* and not be prefixed with their module names (e.g. microsoft). Of the 21 new modules added in #19713, this problem only affected modules that had existing filesets.

andrewkroh added a commit to andrewkroh/beats that referenced this issue Jul 22, 2020
When the fields.yml file is constructed it is done by appending files together and adding some indenting.
In the case of Filebeat, a fileset's fields.yml is appended with an indent of 8 spaces to the module's fields.yml.
This generally allows for all of the filesets fields to become children of the module.

The problem we had was that the new filesets added in elastic#19713 expected that their fields would be root fields
(not children to the module namespace). In cases where the module already existed and had declared
a module namespace field in its fields.yml this resulted in unexpectedly namespaced fieldset fields
(e.g. microsoft.rsa.* instead of rsa.*).

The size of the x-pack/filebeat index-pattern is still large (915885 bytes), but not so large that it goes beyond the Kibana
request payload limit.

Fixes elastic#19965
andrewkroh added a commit that referenced this issue Jul 23, 2020
When the fields.yml file is constructed it is done by appending files together and adding some indenting.
In the case of Filebeat, a fileset's fields.yml is appended with an indent of 8 spaces to the module's fields.yml.
This generally allows for all of the filesets fields to become children of the module.

The problem we had was that the new filesets added in #19713 expected that their fields would be root fields
(not children to the module namespace). In cases where the module already existed and had declared
a module namespace field in its fields.yml this resulted in unexpectedly namespaced fieldset fields
(e.g. microsoft.rsa.* instead of rsa.*).

The size of the x-pack/filebeat index-pattern is still large (915885 bytes), but not so large that it goes beyond the Kibana
request payload limit.

Fixes #19965
andrewkroh added a commit to andrewkroh/beats that referenced this issue Jul 23, 2020
When the fields.yml file is constructed it is done by appending files together and adding some indenting.
In the case of Filebeat, a fileset's fields.yml is appended with an indent of 8 spaces to the module's fields.yml.
This generally allows for all of the filesets fields to become children of the module.

The problem we had was that the new filesets added in elastic#19713 expected that their fields would be root fields
(not children to the module namespace). In cases where the module already existed and had declared
a module namespace field in its fields.yml this resulted in unexpectedly namespaced fieldset fields
(e.g. microsoft.rsa.* instead of rsa.*).

The size of the x-pack/filebeat index-pattern is still large (915885 bytes), but not so large that it goes beyond the Kibana
request payload limit.

Fixes elastic#19965

(cherry picked from commit ea7c05f)
andrewkroh added a commit to andrewkroh/beats that referenced this issue Jul 23, 2020
When the fields.yml file is constructed it is done by appending files together and adding some indenting.
In the case of Filebeat, a fileset's fields.yml is appended with an indent of 8 spaces to the module's fields.yml.
This generally allows for all of the filesets fields to become children of the module.

The problem we had was that the new filesets added in elastic#19713 expected that their fields would be root fields
(not children to the module namespace). In cases where the module already existed and had declared
a module namespace field in its fields.yml this resulted in unexpectedly namespaced fieldset fields
(e.g. microsoft.rsa.* instead of rsa.*).

The size of the x-pack/filebeat index-pattern is still large (915885 bytes), but not so large that it goes beyond the Kibana
request payload limit.

Fixes elastic#19965

(cherry picked from commit ea7c05f)
@andrewkroh
Copy link
Member

Summary of Changes

andrewkroh added a commit that referenced this issue Jul 23, 2020
When the fields.yml file is constructed it is done by appending files together and adding some indenting.
In the case of Filebeat, a fileset's fields.yml is appended with an indent of 8 spaces to the module's fields.yml.
This generally allows for all of the filesets fields to become children of the module.

The problem we had was that the new filesets added in #19713 expected that their fields would be root fields
(not children to the module namespace). In cases where the module already existed and had declared
a module namespace field in its fields.yml this resulted in unexpectedly namespaced fieldset fields
(e.g. microsoft.rsa.* instead of rsa.*).

The size of the x-pack/filebeat index-pattern is still large (915885 bytes), but not so large that it goes beyond the Kibana
request payload limit.

Fixes #19965

(cherry picked from commit ea7c05f)
andrewkroh added a commit that referenced this issue Jul 23, 2020
When the fields.yml file is constructed it is done by appending files together and adding some indenting.
In the case of Filebeat, a fileset's fields.yml is appended with an indent of 8 spaces to the module's fields.yml.
This generally allows for all of the filesets fields to become children of the module.

The problem we had was that the new filesets added in #19713 expected that their fields would be root fields
(not children to the module namespace). In cases where the module already existed and had declared
a module namespace field in its fields.yml this resulted in unexpectedly namespaced fieldset fields
(e.g. microsoft.rsa.* instead of rsa.*).

The size of the x-pack/filebeat index-pattern is still large (915885 bytes), but not so large that it goes beyond the Kibana
request payload limit.

Fixes #19965

(cherry picked from commit ea7c05f)
melchiormoulin pushed a commit to melchiormoulin/beats that referenced this issue Oct 14, 2020
When the fields.yml file is constructed it is done by appending files together and adding some indenting.
In the case of Filebeat, a fileset's fields.yml is appended with an indent of 8 spaces to the module's fields.yml.
This generally allows for all of the filesets fields to become children of the module.

The problem we had was that the new filesets added in elastic#19713 expected that their fields would be root fields
(not children to the module namespace). In cases where the module already existed and had declared
a module namespace field in its fields.yml this resulted in unexpectedly namespaced fieldset fields
(e.g. microsoft.rsa.* instead of rsa.*).

The size of the x-pack/filebeat index-pattern is still large (915885 bytes), but not so large that it goes beyond the Kibana
request payload limit.

Fixes elastic#19965
leweafan pushed a commit to leweafan/beats that referenced this issue Apr 28, 2023
When the fields.yml file is constructed it is done by appending files together and adding some indenting.
In the case of Filebeat, a fileset's fields.yml is appended with an indent of 8 spaces to the module's fields.yml.
This generally allows for all of the filesets fields to become children of the module.

The problem we had was that the new filesets added in elastic#19713 expected that their fields would be root fields
(not children to the module namespace). In cases where the module already existed and had declared
a module namespace field in its fields.yml this resulted in unexpectedly namespaced fieldset fields
(e.g. microsoft.rsa.* instead of rsa.*).

The size of the x-pack/filebeat index-pattern is still large (915885 bytes), but not so large that it goes beyond the Kibana
request payload limit.

Fixes elastic#19965

(cherry picked from commit 84a227a)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker bug Filebeat Filebeat regression Team:Integrations Label for the Integrations team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants