[Internal]: Osquery documentation pages

[raqueltabuyo]

Description

We are retaking the Osquery project and there are some conflicts in the documentation of Osquery Manager integration: https://www.elastic.co/docs/reference/integrations/osquery_manager
The documentation has not been updated since long time and there are features that are redundant and others that are important but not been documented yet.
There are several topics that require review from Elastic docs team:

• Removal of Exported field page, it is redundant as it is something already documented in osquery official docs. https://www.elastic.co/docs/reference/kibana/osquery-exported-fields
• Add Elastic osquery tables, this tables are an additional on top of official native osquery tables: https://github.com/elastic/beats/blob/main/x-pack/osquerybeat/ext/osquery-extension/README.md. These tables are created by Elastic and are not documented in the official osquery site: https://osquery.io/schema/5.20.0/
• Investigate where is the right place to include the Elastic tables, if it is via a link to each table within the integration documentation page or if as a new site or if it is possible to have it within the docs autopopulated from Github readme and not in Kibana integration information.
• Rename of Documentation section to Investigate with Osquery to reflect better the link to the documentation site, also add a better description to the site.

Below a graphical representation of what it was described above:

Resources

There are Elastic osquery tables that exist but are not documented (i.e., host_groups) and we are planning to add more tables in 9.3 like Amcacheand Browser history. In future releases, we will add more tables.

Issue for old not documented Elastic osquery tables: elastic/beats#47593

Which documentation set does this change impact?

Elastic On-Prem and Cloud (all)

Feature differences

Identical

What release is this request related to?

N/A

Serverless release

January 2026

Collaboration model

The documentation team

Point of contact.

Main contact: @raqueltabuyo

Stakeholders: @marc-gr @brian-mckinney

[florent-leborgne]

Thanks for creating the issue @raqueltabuyo :)

A few more details on what we discussed this morning.

With this set of changes, we'll have osquery docs split between Security solution docs (narrative, how tos) and Integration docs (integration "reference"), instead of also having some standalone pieces in the Kibana reference. These change should improve the exhaustiveness/accuracy of the docs, and provide better linking to useful resources and information between these various pieces.

Removal of Exported field page, it is redundant as it is something already documented in osquery official docs. https://www.elastic.co/docs/reference/kibana/osquery-exported-fields

We should replace this with a link to the official osquery docs. To do this, we can remove & redirect the current reference page to the integrations > osquery page, and add the direct link to the osquery docs directly in the integration doc

Add Elastic osquery tables, this tables are an additional on top of official native osquery tables: https://github.com/elastic/beats/blob/main/x-pack/osquerybeat/ext/osquery-extension/README.md. These tables are created by Elastic and are not documented in the official osquery site: https://osquery.io/schema/5.20.0/
Investigate where is the right place to include the Elastic tables, if it is via a link to each table within the integration documentation page or if as a new site or if it is possible to have it within the docs autopopulated from Github readme and not in Kibana integration information.

@colleenmcginnis Would this be something possible to do with the current workflow? From what we discussed with @raqueltabuyo:

• Those would be too long to show in the Kibana UI, do we have a way to have these show only in the generated doc page?
• If not, i'd say it may be fine to link to the github files that contain this information, instead of trying to maintain some other page elsewhere and half-lost in the kibana reference. Wdyt?

Rename of Documentation section to Investigate with Osquery to reflect better the link to the documentation site, also add a better description to the site.

This should be fairly straightforward. It does look strange to have a Documentation section inside of the documentation. It would make sense only if that content only lived in the Kibana UI.

[colleenmcginnis]

Those would be too long to show in the Kibana UI, do we have a way to have these show only in the generated doc page?

No.

We probably wouldn't want to build this out unless there were additional use cases (which there might be!). If we did want to pursue this, I think there are two general approaches we could take:

• Filter out content in Kibana:
  • Include all tables in the integrations repo README.
  • Then the content with the tables would be published to EPR.
  • In the docs, publish unedited content from EPR.
  • In Kibana, filter out content we don't want to include. (This would require work from the devs working on Fleet UI.)
• Inject content into docs:
  • Do not include the tables in the integrations repo README.
  • Then the content that's published to EPR would not include the tables.
  • In Kibana, publish unedited content from EPR.
  • In the docs, fetch the additional table content from somewhere and inject it into the content from EPR. (This would require work from the Ingest docs team.)

[bmorelli25]

I'd like to split this issue into two separate issues as we have some tasks that can be completed now by the experience docs team and some that will require further discussion/alignment and then potentially tooling changes by the ingest docs team.

Work the experience docs team can do now has been moved to #4207:

• renaming section headings
• removing duplicative docs
• linking to osquery tables

Let's retain this issue for discussions around the ideal way to show osquery tables, which might mean building content only in the generated doc page (not Kibana).