-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
API keys do not reflect the need for read_pipeline #26466
Conversation
As discussed in the PR #26465 the docs should reflect that read_pipeline is needed when using modules. Users usually just copy and paste the JSON payload and might experience failures when running any beat with modules.
💚 Build Succeeded
Expand to view the summary
Build stats
Trends 🧪❕ Flaky test reportNo test was executed to be analysed. |
Pinging @elastic/agent (Team:Agent) |
Pinging @elastic/obs-docs (Team:Docs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good from a doc perspective, though I did not test the change to make sure it works.
Let me know if you want me to backport/forwardport this. Also, if there are other docs that require updates, can you create an issue in GitHub to describe the change? Thanks! |
Hi @dedemorton |
As discussed in the PR elastic#26465 the docs should reflect that read_pipeline is needed when using modules. Users usually just copy and paste the JSON payload and might experience failures when running any beat with modules.
As discussed in the PR elastic#26465 the docs should reflect that read_pipeline is needed when using modules. Users usually just copy and paste the JSON payload and might experience failures when running any beat with modules.
As discussed in the PR #26465 the docs should reflect that read_pipeline is needed when using modules. Users usually just copy and paste the JSON payload and might experience failures when running any beat with modules. Co-authored-by: Philipp Kahr <[email protected]>
As discussed in the PR #26465 the docs should reflect that read_pipeline is needed when using modules. Users usually just copy and paste the JSON payload and might experience failures when running any beat with modules. Co-authored-by: Philipp Kahr <[email protected]>
* master: (25 commits) fix: Force PLATFORMS environment variable when we build Elastic Agent dependencies on arm64 (elastic#26415) macos for metricbeat to run in the extended meta-stage (elastic#26573) Packaging: add arm7 platform in the main pipeline (elastic#26575) [Heartbeat] Skip flakey timer queue test (elastic#26592) Update to "read_pipeline" permission (elastic#26465) (elastic#26580) API keys do not reflect the need for read_pipeline (elastic#26466) (elastic#26582) Add Fleet agent.id to Agent monitoring data (elastic#26548) Add kinesis metricset (elastic#25989) Refactor of system/memory metricset (elastic#26334) Introduce httpcommon package in libbeat (add support for Proxy) (elastic#25219) [Filebeat] change multiline configuration in awss3 input to parsers (elastic#25873) docs: Hint for the error "Error extracting container id" (elastic#25824) [Docs] Fixed metricbeat redis exported field CPU descriptions (elastic#25846) (elastic#26496) Update urllib to 1.26.5. (elastic#26380) Update golang.org/x/crypto (elastic#26448) [Filebeat] Update Fortinet Ingest Pipeline (elastic#24816) Move parsers outside of filestream input so others can use them as well (elastic#26541) [Filebeat] Fix `threatintel.indicator.url.full` field not populating (elastic#26508) [Filebeat] Add network direction processor to Zeek and Suricata modules (elastic#24620) Logging code cleanup related to Nomad auto-discovery (elastic#26498) ...
What does this PR do?
As discussed in the PR #26465 the docs should reflect that read_pipeline is needed when using modules. Users usually just copy and paste the JSON payload and might experience failures when running any beat with modules.
Additionally, this change should be reflected on all beats API key docs.