-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Doc: Add Elastic Agent collection #15528
Conversation
=== Confirm Enrollment | ||
// Include section about confirming enrollment | ||
include::monitoring-confirm.asciidoc[tag=confirm-enrollment-widget] |
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.
The heading is "Confirm Enrollment," but the section leads off with "After enrollment is confirmed..." This makes me think that "Confirm Enrollment" should be part of the previous section, and that we need a more appropriate name for what's going on in this section.
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.
I think that makes sense - I think confirming enrollment is just the resolution of "installing agents"
// Include section about confirming enrollment | ||
include::monitoring-confirm.asciidoc[tag=confirm-enrollment-widget] |
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.
The heading is "Confirm Enrollment," but the section leads off with "After enrollment is confirmed..." This makes me think that "Confirm Enrollment" should be part of the previous section, and that we need a more appropriate name for what's going on in this section.
include::monitoring-mb.asciidoc[tag=define-cluster-uuid] | ||
|
||
[discrete] | ||
[[set-up-monitoring]] |
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.
What do you think about moving this to the stack monitoring section, instead of having this here?
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.
Makes sense! Working on a better approach.
[[create-user]] | ||
=== Create a monitoring user (stack monitoring only) | ||
|
||
Create a user on the production cluster that has the |
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.
We will need to do this for standalone agent too - what do you think about adding this to the stack monitoring section, and the standalone agent tab?
Or, even adding a tabbed section here for Stack Monitoring, Standalone Agent and Fleet managed?
@@ -1,6 +1,6 @@ | |||
[role="xpack"] | |||
[[configuring-logstash]] | |||
== Monitoring {ls} | |||
== Monitoring {ls} (legacy) |
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.
We'll need to figure out if we want to call this "legacy" yet, while dashboards are still in beta
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.
If a user was implementing monitoring from the ground up, we'd likely encourage them to go with agent. Maybe we can add a note in the MB section saying it's still a viable option, but they might want to consider one of the new approaches instead? Let's get Trevor's input.
=== Confirm Enrollment | ||
// Include section about confirming enrollment | ||
include::monitoring-confirm.asciidoc[tag=confirm-enrollment-widget] |
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.
I think that makes sense - I think confirming enrollment is just the resolution of "installing agents"
|
||
You can use {agent} to collect monitoring data for: | ||
|
||
- dashboard. <Brief description with link> |
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.
- dashboard. <Brief description with link> | |
- {ls} Dashboards. <Brief description with link> |
You can use {agent} to collect monitoring data for: | ||
|
||
- dashboard. <Brief description with link> | ||
- stack. <Brief description with link> |
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.
- stack. <Brief description with link> | |
- Legacy Stack Monitoring UI. <Brief description with link> |
I'm not sure how best to distinguish between the two - I think "Legacy Stack Monitoring UI" might work
When you've completed the prerequisites, you're ready to install and configure {agent} for your monitoring use case. | ||
|
||
- dashboard. <Brief description with link> | ||
- stack. <Brief description with link> |
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.
Same comments as earlier on how we reference each of these UIs
6588dfc
to
c4cf77b
Compare
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.
This is looking great - I like the changes and the organization that you've put in here
|
||
Install and configure {agent} to collect {ls} monitoring data for dashboards. | ||
We'll walk you through the process in these steps: | ||
|
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.
What do you think about adding a link to the general agent installation page somewhere, for more details than we will give here? I'm not sure if this is the right place, but it might work here, or at the bottom of this section?
-- | ||
[role="screenshot"] | ||
image::images/kibana-home.png[{kib} home page] | ||
-- |
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.
What do you think about having a widget in a follow-up PR that shows the serverless flow?
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.
I agree with the "follow-up PR" idea, but I have a different approach I'll run by you.
|
||
Prerequisites: | ||
[[create-user-ea]] | ||
.Create a monitoring user |
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.
.Create a monitoring user | |
.Create a monitoring user (standalone agent only) |
We don't need to create a monitoring user if the user is using fleet here
[[view-assets-ead]] | ||
=== View assets | ||
// Include section about viewing assets | ||
include::monitoring-confirm.asciidoc[tag=confirm-enrollment-widget] |
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.
What do you think about splitting this content into logs
and metrics
- Logs dashboards are common to both, and could be a shared doc.
While, sadly, both sets of assets are installed regardless of which metric collection method is used, they only have relevance in the Dashboards.
I was wondering if we should have a an explanatory section for Dashboards, which explains what each of the dashboards are (or at least an inventory), and one for Stack Monitoring, which says that these dashboards are not populated when dashboard collection is disabled?
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.
Definitely worth exploring in a follow-up PR.
@karenzone I updated the screenshots, removing those that weren't used, and fixed up the differences between the fleet managed and standalone screenshots |
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.
I'm happy with this as a first pass - I think we can add extra information on the dashboard contents, and I'd like to add a section on how to install on serverless, but this LGTM
Co-authored-by: Rob Bavey <[email protected]>
Clean up screenshots - delete those that aren't used, and use the same font size for agent flyout
d262339
to
179d5f3
Compare
SonarQube Quality Gate |
💚 Build Succeeded
History
|
#48869 |
@logstashmachine backport 8.11 |
Co-authored-by: Rob Bavey <[email protected]> (cherry picked from commit c060c00)
Co-authored-by: Rob Bavey <[email protected]> (cherry picked from commit c060c00) Co-authored-by: Karen Metts <[email protected]>
Related: https://github.com/elastic/ingest-dev/issues/2462
Related: #15439
Based on : #15508
This work starts with all the goodness in #15508 from @robbavey, removes extra heading levels for easier parsing, smooths flow, and ideally, sets us up for easier maintenance going forward.
PREVIEW: https://logstash_15528.docs-preview.app.elstc.co/guide/en/logstash/master/monitoring-with-ea.html