[libbeat] Don't swallow Kibana index pattern errors

[andrewkroh]

What does this PR do?

While running 'beat setup --dashboads' any errors that occur while importing the generated Kibana index pattern or silently ignored.
This changes that by causing the dashboard setup to stop and return the error. Dashboards won't work without the index pattern anyways.

Why is it important?

Errors with the Kibana index pattern were undetected. The only hint of an error is that the index pattern doesn't exist in Kibana after setup.

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.

Logs

2020-07-21T18:26:27.006-0400 ERROR instance/beat.go:935 Exiting: 1 error: error loading index pattern: returned 413 to import file: <nil>. Response: {"statusCode":413,"error":"Request Entity Too Large","message":"Payload content length greater than maximum allowed: 1048576"}

[elasticmachine]

Pinging @elastic/integrations-services (Team:Services)

[andrewkroh]

On a related note ./filebeat export index-pattern | wc -c returns a 1304593 byte document (1.24MiB).

[andrewkroh]

Looks like the index pattern issue was reported in #19965.

[elasticmachine]

💚 Build Succeeded

Expand to view the summary

Build stats

• Build Cause: [Pull request #20121 opened]

• Start Time: 2020-07-21T22:34:07.298+0000

• Duration: 75 min 8 sec

Test stats 🧪

Test	Results
Failed	0
Passed	17739
Skipped	1902
Total	19641

[andrewstucki]

do we have linter rules to look for unchecked errors? I'm assuming not because they're generally noisy and not always useful, but wondering if we should in the long-run b/c that for sure would have caught this.

[andrewkroh]

None at this time. We've had a few in the past and they weren't removed for any good reason AFAIK. I think it was just that nobody was maintaining them. Previously we used Hound CI to comment, but it wasn't very configurable IIRC. And before that we had reviewdog running.

I use golangci-lint locally when I'm making changes. I'd be interested in trying out their Github action on PRs. https://github.com/marketplace/actions/run-golangci-lint

[andrewstucki]

that would be nice, I just ran it over the whole codebase, there are a good number of ineffectual assignments/lack off error checks it found: https://gist.github.com/andrewstucki/5cfc32b8024ac23bd4ae1edb2bbb4565