An early pain point for OSSM 3 users has been the experience of integrating with user workload monitoring and the new distributed tracing stack (particularly the later). 

This impacts both OSSM 2.6 and 3, as users must make this migration in OSSM 2.6 before migrating to OSSM 3.0, thus any updates in procedures should be considered for both the 2.6 and 3.0 sets of documentation. See below for links to current docs.

• OSSM 2.6 User Workload Monitoring
• OSSM 3.0 User Workload Monitoring
• OSSM 2.6 Tempo/OTEL Integration
• OSSM 3.0 Tempo/OTEL integration

While these are all separate procedures, they are not completely independent as they all potentially use the Istio Telemetry API to scope metrics/traces and there is potential for collisions if these configurations are not aligned are not aligned. The docs need to ensure a consistent procedure if they are setup together.

• An example was highlighted by rhn-support-ddelcian in [this document|https://docs.google.com/document/d/1sXaXeKwDm2ffqEEE7QuKyax6DKsWsz2VEdi0fX2jQGw/edit?disco=AAABgjxEzYU.] Daniel has also provided his own documented steps for setting up OTEL+Tempo here, which should be cross checked with our documentation, which includes using mTLS strict mode. In his own words - "In step #4 of this section, we should state that if the user defines multiple selector-less Telemetry CRs in istio-system (which applies to all mesh namespaces), these should be consolidated/merged into one Telemetry CR, otherwise, it will only consider the first Telemetry CR and ignore the rest.  This is important especially when one is integrating UWM to use the external prometheus extension as well as the external otel extension for tracing."
• There may be additional enhancements that we can make between now and

Engineering acceptance criteria: 

• Draft content for specific doc updates to the existing procedures listed above.