Description
Description
I would expect every O11y App to have a page like this one https://www.elastic.co/guide/en/security/8.7/detections-permissions-section.html
Kibana O11y Apps
APM
URL: https://www.elastic.co/guide/en/apm/guide/current/apm-data-streams.html
Problem:
APM also relies on other system indices
.apm...
APM has also a very complex querying architecture (with fallbacks) due to the fact some data gets pre-aggregated by APM Server and stores already aggregated histograms in order to be faster visualizing graphs.
Infra
URL: https://www.elastic.co/guide/en/observability/current/configure-settings.html
Uptime & Synthetics
URL: https://www.elastic.co/guide/en/observability/current/configure-uptime-settings.html
Actionable Obs
URL: https://www.elastic.co/guide/en/kibana/8.7/alerting-setup.html
Problem:
It's not fully clear if we should provide access to the o11y indices of each kind of alert or something else
ML Jobs for O11y
URL: https://www.elastic.co/guide/en/machine-learning/current/ootb-ml-jobs.html
Problem:
It's not fully clear what are the permissions to provide in order to setup & run those only on specific APM data.
Resources
Especially if the customer is fully 8.x and eventually using only Elastic Agents managed by Fleet, the suggestion to use namespaces per team might be an option (with consequences on many more data streams being created and possible scalability issues).
We do not do a great job at communicating in the docs what are the indices to put there and at least from my perspective, we should be more opinionated in the docs to push customers/users to avoid customizing index names as much as possible. Customizing index names often lead to problems with Index Templates not being applied and therefore the queries executed by the Kibana app failing behind the scenes because of mapping issues.
Collaboration
The documentation team will investigate the issue and create the initial content.
Point of contact.
Main contact: @
Stakeholders: