Restructure docs for RUM agent and ES related parts. #1088
Conversation
docs/exploring-es-data.asciidoc
Outdated
| For getting an overview of existing indices you can run: | ||
| ["source","sh"] | ||
| ------------------------------------------------------------ | ||
| GET _cat/indices |
There was a problem hiding this comment.
Maybe filtering apm would be even more useful GET _cat/indices/apm*?
docs/exploring-es-data.asciidoc
Outdated
|
|
||
| ["source","sh"] | ||
| ------------------------------------------------------------ | ||
| GET _cat/templates |
There was a problem hiding this comment.
Same as with indices GET _cat/templates/apm*? Just a thought
docs/exploring-es-data.asciidoc
Outdated
|
|
||
| [partintro] | ||
| -- | ||
| By default Elastic APM data are stored in different index types. |
There was a problem hiding this comment.
different index types -> different indices
There was a problem hiding this comment.
Should be "data is stored"
docs/exploring-es-data.asciidoc
Outdated
| -- | ||
| By default Elastic APM data are stored in different index types. | ||
|
|
||
| Indices storing monitored data are built in the format of `apm-[version]-[type]-[date]` by default. |
There was a problem hiding this comment.
monitored data sounds odd but I'm not sure what else to call the onboarding docs
There was a problem hiding this comment.
Not sure you need to say "monitored data" here. Maybe just say something like:
The indices are named `apm-[version]-[type]-[date]` by default.
Then give an example. The way it's worded right now, sounds like the indices themselves use some kind of special format, but really it's jut the index name that uses the format.
There was a problem hiding this comment.
I like the level of detail that you've added here. The content needs a technical edit. Rather than adding a bunch of comments to this review, though, I think the content should be edited in a separate pass after the PR is reviewed for technical accuracy and merged. I've added the PR to the meta issue that I created here to track edits: #1090
docs/exploring-es-data.asciidoc
Outdated
|
|
||
| This format makes it easy to query for all Elastic APM data at once by using `apm-*`. | ||
|
|
||
| It also allows for querying documents that have been collected with a specific APM Server version, e.g. `apm-6.3.0*`. |
There was a problem hiding this comment.
i think you should either remove the e.g. apm-6.3.0* bit or use a variable pulling the current version
docs/errors.asciidoc
Outdated
| Some of the key attributes of an error are described in more detail: | ||
| Errors can either relate to monitored <<transactions, transactions>> | ||
| or be monitored stand alone, | ||
| depending on how your APM agents are set up. |
There was a problem hiding this comment.
reading this, i guess someone will want to know how to set up an agent to relate errors and transactions...
docs/exploring-es-data.asciidoc
Outdated
| [partintro] | ||
| -- | ||
| By default Elastic APM data are stored in different indices, | ||
| in the format of `apm-[version]-[type]-[date]`. |
There was a problem hiding this comment.
I'll add a line here saying that type is one of error, transaction, etc.; or a link to the event types section
docs/span-indices.asciidoc
Outdated
| Spans are monitored as parts of <<transactions, transactions>>. | ||
| They are stored in their separate indices `apm-[version]-span-[date]` though. | ||
|
|
||
| Spans at least collect information about when the code path execution started, |
There was a problem hiding this comment.
what do you mean with "at least"?
|
Forgot to mention: this could be split in 2 commits (or prs, it doesn't matter): |
* Remove the auto generated fields listing, and explain how users can fetch the APM template instead. * Add a separate RUM section and split up sourcemap docs according to the existing structure. * Introduce a new part how to explore data in ES and move everything related. * This leads to only having a general overview of Event Types left on top level, for easier high level understanding of APM Events.
|
I suggest to backport to 6.x and 6.3. In 6.3 we already have experimental RUM support, so I would experimental to those section. |
simitt
force-pushed
the
docs-cleanup-fields
branch
from
4db2b48 to
7de27b1
Compare
|
After rebasing onto master this is the index overview:
|
|
@roncohen I added the
|
* Add a separate RUM section and split up sourcemap docs according to the existing structure. * Introduce a new part how to explore data in ES and move everything related, except for the fields section. * Keep Event Types on top level, but move ES examples to ES section
* Add a separate RUM section and split up sourcemap docs according to the existing structure. * Introduce a new part how to explore data in ES and move everything related, except for the fields section. * Keep Event Types on top level, but move ES examples to ES section
* Add a separate RUM section and split up sourcemap docs according to the existing structure. * Introduce a new part how to explore data in ES and move everything related, except for the fields section. * Keep Event Types on top level, but move ES examples to ES section
* Add a separate RUM section and split up sourcemap docs according to the existing structure. * Introduce a new part how to explore data in ES and move everything related, except for the fields section. * Keep Event Types on top level, but move ES examples to ES section
5 participants
fetch the APM template instead.
the existing structure. Use RUM instead of frontend.
related.
top level, for easier high level understanding of APM Events.
Builds on top of elastic/docs#395
implements #1083
High level overview:
Changed Event Types
RUM w. Source Mapping
Exploring data in ES