Goal:
Provide a supported OpenTracing capability for Application teams.

Problem:
MicroService applications increase the difficulty of monitoring and analyzing performance anomalies for Application Operators over traditional monolithic applications because of the number of calls across the network. Application Operators need tools to monitor and research the activity of distributed MicroService applications if they are going to be able to deploy, maintain, and scale the applications to an enterprise standard. A distributed tracing based solution can provide Application Operators insight into the performance of their distributed applications and facilitate the discovery of faults and performance issues.

OCP users have suffered with application monitoring tools that are either not fully supported or simply not available from Red Hat. Not having the expected monitoring capabilities presents a barrier to adoption for application teams who might otherwise deploy on OCP clusters.

OpenShift provides Jaeger as the implementation of OpenTracing in Service Mesh. Not all users will install Service Mesh across their entire cluster. Providing Jeager as an Open
Tracing implementation for use outside of Service Mesh provides users the option to applying tracing to a subset of their cluster where the overhead of Service Mesh may not be desired.

Why this is important:

Eliminating “Naked Cluster” sales is a strategic goal for Red Hat. Providing sufficient monitoring tools to make application teams confident that they can be successful deploying in OCP should enable more sales of OCP with RH Middleware.

Dependencies

Prioritized epics + deliverables (in scope / not in scope):

• Install Jaeger backend and frontend components into a namespace using the Jaeger operator.
• Provide Jaeger Clients for:
  • EAP
  • Thorntail
  • Tomcat
  • Spring Boot
  • vert.X
  • Data Grid
• Document configuration of all Jaeger clients.
• Documentation of the installation of the Jaeger Operator
• Provide the Jaeger Trace View. This will not be linked with any other OpenShift UI. Deployments of Jaeger covered by this epic should be considered an application running in OpenShift.
• Display a Service Dependency View (call graph) based upon queries defined by the user in the UI. This view will display a subset of the service dependencies, and not the full display of all historical connections. This is a stretch goal and a strong possibility exists that it will be dropped.
• Support on OpenShift 4.2 and later
• Support on OpenShift x86_64 clusters

• Out of Scope
  • Service Dependency View (network graph) based upon Flink or Spark
  • backendInstallation/Support outside of OpensShift
  • Support on architectures other than x86_64
  • Documentation of the configuration of Tracing on the Runtimes (EAP, Spring Boot, etc.)

Estimate (XS, S, M, L, XL, XXL):

Previous Work:

• Jaeger images delivered as part of Service Mesh
• Jaeger Operator

Customers:

Open questions:

When will we support Node.js(javascript) with distributed tracing?
OpenTelemetry will provide javascript clients and we will review and possibly adopt them at a later date.

Do we need to ensure that a Jaeger install cannot be installed into a service mesh namespace? Probably, I don’t see how this would be desirable-jd.

Link to Epic:

Other docs:
https://docs.google.com/document/d/1WSxEwdQP4Lm2NcuDWD_d1jQxvZgSd3DPnhhYgMaAylU/edit?usp=sharing