Change LogsDB "Not Supported" message to "Caution" message as soon as three "how to check" sections are available.

[MikePaquette]

What can we change to make the docs better?

Related Issues

The change proposed here should follow the change suggested in #6518.
In other words, #6518 should be implemented as soon as possible. Even though this issue would essentially replace the "not supported" message, we need to friendlier "not supported" message asap.

What can we change to make the docs better?

Current docs are creating confusion with customers and Elastic field personnel. Want to remove the "not recommeded" status as soon as we can document for users how to determine when it's safe to enable LogsDB.

Doc URL

Doc URL: https://www.elastic.co/guide/en/security/8.17/detections-logsdb-index-mode-impact.html
Github issue link(s)/Other resources: None

Customers and Elastic field personnel have expressed confusion about the current "not supported" statement with regards to logsdb index mode, and have asked us to provide some clarification regarding new deployments vs. existing deployments.

We want to change the "not supported" language to "caution" language as soon as we can provide the three

As a short-term solution, we should replace the current text with something like:

Logsdb index mode is fully supported, and is recommended for all Elastic Security deployments. Users with existing Elastic Security deployments are advised to fully understand and accept the documented changes to detection alert documents, runtime fields, and rule actions (see below), and ensure that their deployment has sufficient excess hot data tier CPU  capacity to support the LogsDB ingest/indexing process.  Enabling LogsDB without sufficient excess hot data tier CPU capacity may result in data ingestion backups and/or security detection rule timeouts and errors.

* 	How to determine whether your hot tier CPU has enough headroom to enable LogsDB
* 	How to check for rule actions that are accessing _source
* 	Checking runtime fields that may be affected by LogsDB

Doc URL

Doc URL: https://www.elastic.co/guide/en/security/8.17/detections-logsdb-index-mode-impact.html

Which documentation set needs improvement?

ESS and serverless

Software version

Any version where LogsDB impact statement docs are included.

[MikePaquette]

cc: @tylerperk Can you help us with a documented process for customers to determine their average not tier CPU, say over the last 30-90 days?

[marshallmain]

• How to check for rule actions that are accessing _source

Rule actions are unaffected by the format of _source. We normalize the data format in context.alerts in rule notifications so the access pattern documented in https://www.elastic.co/guide/en/security/current/rules-ui-create.html#placeholder-examples should work regardless of logsdb usage.

Edit: Arrays of objects do not get normalized by our code so could be impacted. We already have a note in the docs about this on the logsdb page:
If you send alert notifications by enabling {kibana-ref}/alerting-getting-started.html#alerting-concepts-actions[actions] to the external systems that have workflows or automations based on fields formatted from the original source, they may be affected. In particular, this can happen when the fields used are arrays of objects.

• Checking runtime fields that may be affected by LogsDB

Runtime fields with scripts that reference params._source may need to be updated in accordance with the docs here. Scripts that currently use dotted field names to access source fields will need to be converted to use the nested access pattern instead, unless the object being accessed has subobjects set to false. Fields that are not mapped also need to be accessed in scripts using the nested access pattern (i.e. params._source['foo']['bar']['baz'] or params._source.foo.bar.baz, not params._source['foo.bar.baz']).

[nastasha-solomon]

Notes from my meeting with Marshall today:

• I'll open a PR against this page add docs for the following items:
  • How CPU and storage needs are affected when you enabled logsdb index mode (@marshallmain is providing some language for this)
  • Checking runtime fields that may be affected by LogsDB (more info above)
• Doc updates will assume that the reader/Security user is deciding whether to enable logsdb mode for their ES instance.
• If the doc updates mention performance metrics, linking to this blog for more info might be an option.
• Updates apply to 8.17-8.x, 9.0, and Serverless.