[enterprise-4.4] Jaeger configuration and deployment options (#20643 restored)

_topic_map.yml

@@ -1457,18 +1457,12 @@ Topics:
   Topics:
   - Name: Installing Jaeger
     File: rhbjaeger-installation
-#  - Name: Deploying Jaeger
-#    File: rhbjaeger-deploying
+  - Name: Deploying Jaeger
+    File: rhbjaeger-deploying
   - Name: Upgrading Jaeger
     File: rhbjaeger-updating
   - Name: Removing Jaeger
     File: rhbjaeger-removing
-# Integrations / cross-product stories
-- Name: Integrating Jaeger
-  Dir: jaeger_config
-  Topics:
-  - Name: Integrating Jaeger with serverless applications using OpenShift Serverless
-    File: serverless-jaeger-integration
 
 ---
 Name: Container-native virtualization

jaeger/jaeger_install/rhbjaeger-deploying.adoc

@@ -1,42 +1,71 @@
 [id="deploying-jaeger"]
 = Deploying Jaeger
-include::modules/ossm-document-attributes.adoc[]
+include::modules/jaeger-document-attributes.adoc[]
 :context: jaeger-deploying
 
 toc::[]
 
-The Jaeger Operator includes a custom resource definition (CRD) file that determines the architecture and configuration settings to use when creating the Jaeger custom resources (CR). You can either install the default configuration or modify the custom resource file to better suit your business requirements.
+The Jaeger Operator includes a custom resource definition (CRD) file that defines the architecture and configuration settings for the Jaeger resources. You can either install the default configuration or modify the file to better suit your business requirements.
 
-Each Jaeger instance is associated with a deployment strategy. You define the strategy is defined in the custom resource file and when you create a Jaeger instance the Operator uses the deployment strategy and configuration options in the CR file to create the objects necessary for the deployment.
-The Jaeger Operator currently supports the following deployment strategies:
+Jaeger has predefined deployment strategies. You specify a deployment strategy in the custom resource file. When you create a Jaeger instance the Operator uses this configuration file to create the objects necessary for the deployment.
 
-* *allInOne* (Default) strategy - This strategy is intended for development, testing, and demo purposes. The main backend components, Agent, Collector and Query service, are all packaged into a single executable which is configured (by default) to use in-memory storage.
+.Jaeger custom resource file showing deployment strategy
+[source,yaml]
+----
+apiVersion: jaegertracing.io/v1
+kind: Jaeger
+metadata:
+  name: simple-prod
+spec:
+  strategy: production <1>
+----
 
+<1> The Jaeger Operator currently supports the following deployment strategies:
+
+* *allInOne* (Default) - This strategy is intended for development, testing, and demo purposes. The main backend components, Agent, Collector and Query service, are all packaged into a single executable which is configured (by default) to use in-memory storage.
++
 [NOTE]
 ====
-In-memory storage is not persistent, which means that if the Jaeger instance shuts down, restarts, or is replaced, that your trace data will be lost.  For persistent storage, use the production Elasticsearch deployment strategy.
+In-memory storage is not persistent, which means that if the Jaeger instance shuts down, restarts, or is replaced, that your trace data will be lost.  And in-memory storage cannot be scaled, since each pod has its own memory. For persistent storage, you must use the `production` or `streaming` strategies, which use Elasticsearch as the default storage.
 ====
 
-* *production* strategy - The production strategy is intended for production environments, where long term storage of trace data is important, as well as a more scalable and highly available architecture is required. Each of the backend components is therefore deployed separately.  The Agent can be injected as a sidecar on the instrumented application or as a daemonset. The Query and Collector services are configured with a supported storage type - currently Elasticsearch. Multiple instances of each of these components can be provisioned as required for performance and resilience purposes. For more information about configuring Elasticsearch with {product-title}, see  xref:../../logging/config/cluster-logging-elasticsearch.adoc[Configuring Elasticsearch].
+* *production* - The production strategy is intended for production environments, where long term storage of trace data is important, as well as a more scalable and highly available architecture is required. Each of the backend components is therefore deployed separately.  The Agent can be injected as a sidecar on the instrumented application or as a daemonset. The Query and Collector services are configured with a supported storage type - currently Elasticsearch. Multiple instances of each of these components can be provisioned as required for performance and resilience purposes.
 
-* *streaming* strategy - The streaming strategy is designed to augment the production strategy by providing a streaming capability that effectively sits between the Collector and the backend storage (Elasticsearch). This provides the benefit of reducing the pressure on the backend storage, under high load situations, and enables other trace post-processing capabilities to tap into the real time span data directly from the streaming platform (Kafka).
+* *streaming* - The streaming strategy is designed to augment the production strategy by providing a streaming capability that effectively sits between the Collector and the backend storage (Elasticsearch). This provides the benefit of reducing the pressure on the backend storage, under high load situations, and enables other trace post-processing capabilities to tap into the real time span data directly from the streaming platform (https://access.redhat.com/documentation/en-us/red_hat_amq/7.6/html/using_amq_streams_on_openshift/index[AMQ Streams]/ https://kafka.apache.org/documentation/[Kafka]).
 
 [NOTE]
 ====
 There are two ways to install Jaeger, as part of a service mesh or as a stand alone component. If you have installed Jaeger as part of Red Hat OpenShift Service Mesh, you must configure and deploy Jaeger as part of the xref:../../service_mesh/service_mesh_install/customizing-installation-ossm.adoc#customizing-installation-ossm[ServiceMeshControlPlane].
 ====
 
-
 // The following include statements pull in the module files that comprise the assembly.
 
 include::modules/jaeger-deploy-default.adoc[leveloffset=+1]
 
+include::modules/jaeger-deploy-production-es.adoc[leveloffset=1]
+
+include::modules/jaeger-deploy-streaming.adoc[leveloffset=1]
+
+[id="customizing-jaeger-deployment"]
+= Customizing Jaeger deployment
+
 include::modules/jaeger-config-default.adoc[leveloffset=+1]
 
-include::modules/jaeger-deploy-production-es.adoc[leveloffset=+1]
+include::modules/jaeger-config-collector.adoc[leveloffset=+1]
+
+include::modules/jaeger-config-sampling.adoc[leveloffset=+1]
+
+include::modules/jaeger-config-storage.adoc[leveloffset=+1]
+
+include::modules/jaeger-config-query.adoc[leveloffset=+1]
+
+include::modules/jaeger-config-ingester.adoc[leveloffset=+1]
+
+[id="injecting-sidecars"]
+= Injecting sidecars
 
-include::modules/jaeger-config-production-es.adoc[leveloffset=+1]
+{ProductName} relies on a proxy sidecar within the application’s pod to provide the agent. The Jaeger Operator can inject Jaeger Agent sidecars into Deployment workloads. You can enable automatic sidecar injection or manage it manually.
 
-include::modules/jaeger-deploy-streaming.adoc[leveloffset=+1]
+include::modules/jaeger-sidecar-automatic.adoc[leveloffset=1]
 
-include::modules/jaeger-config-streaming.adoc[leveloffset=+1]
+include::modules/jaeger-sidecar-manual.adoc[leveloffset=1]

jaeger/rhbjaeger-release-notes.adoc

@@ -11,11 +11,6 @@ include::modules/jaeger-product-overview.adoc[leveloffset=+1]
 
 include::modules/support.adoc[leveloffset=+1]
 
-////
-TODO
-include::modules/jaeger-supported-configurations.adoc[leveloffset=+1]
-////
-
 include::modules/jaeger-rn-new-features.adoc[leveloffset=+1]
 
 include::modules/jaeger-rn-known-issues.adoc[leveloffset=+1]

modules/jaeger-config-collector.adoc

@@ -0,0 +1,39 @@
+////
+This REFERENCE module included in the following assemblies:
+-rhbjaeger-deploy.adoc
+////
+
+[id="jaeger-config-collector_{context}"]
+= Jaeger Collector configuration options
+
+The Jaeger Collector is the component responsible for receiving the spans that were captured by the tracer and writing them to a persistent storage (Elasticsearch) when using the `production` strategy, or to AMQ Streams when using the `streaming` strategy.
+
+The collectors are stateless and thus many instances of Jaeger Collector can be run in parallel. Collectors require almost no configuration, except for the location of the Elasticsearch cluster.
+
+.Jaeger collector parameters
+[options="header"]
+[cols="l, a, a"]
+|===
+|Parameter |Description |Values
+|spec:
+ collector:
+  options: {}
+|Configuration options that define the Jaeger Collector.
+|
+
+|kafka:
+  producer:
+    topic: jaeger-spans
+|The `topic` parameter identifies the Kafka configuration used by the collector to produce the messages, and the ingester to consume the messages.
+|Label for the producer
+
+|kafka:
+  producer:
+    brokers: my-cluster-kafka-brokers.kafka:9092
+|Identifies the Kafka configuration used by the Collector to produce the messages.  If brokers are not specified, and you have AMQ Streams 1.4.0+ installed, Jaeger will self-provision Kafka.
+|
+
+|log-level:
+|Logging level for the collector.
+|Possible values: `trace`, `debug`, `info`, `warning`, `error`, `fatal`, `panic`.
+|===

modules/jaeger-config-default.adoc

@@ -0,0 +1,126 @@
+////
+This REFERENCE module included in the following assemblies:
+- rhbjaeger-deploying.adoc
+////
+
+[id="jaeger-config-default_{context}"]
+= Jaeger default configuration options
+:pantheon-module-type: REFERENCE
+
+The Jaeger custom resource (CR) defines the architecture and settings to be used when creating the Jaeger resources. You can modify these parameters to customize your Jaeger implementation to your business needs.
+
+.Jaeger generic YAML example
+[source,yaml]
+----
+apiVersion: jaegertracing.io/v1
+kind: Jaeger
+metadata:
+  name: name
+spec:
+  strategy: <deployment_strategy>
+  allInOne:
+    options: {}
+    resources: {}
+  agent:
+    options: {}
+    resources: {}
+  collector:
+    options: {}
+    resources: {}
+  sampling:
+    options: {}
+  storage:
+    type:
+    options: {}
+  query:
+    options: {}
+    resources: {}
+  ingester:
+    options: {}
+    resources: {}
+  options: {}
+----
+
+.Jaeger parameters
+[options="header"]
+|===
+|Parameter |Description |Values |Default value
+
+|apiVersion:
+|Version of the Application Program Interface to use when creating the object.
+|`jaegertracing.io/v1`
+|`jaegertracing.io/v1`
+
+|kind:
+|Defines the kind of Kubernetes object to create.
+|`jaeger`
+|
+
+|metadata:
+|Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace`.
+|
+|OpenShift automatically generates the `UID` and completes the `namespace` with the name of the project where the object is created.
+
+|name:
+|Name for the object.
+|The name of your Jaeger instance.
+|`jaeger-all-in-one-inmemory`
+
+|spec:
+|Specification for the object to be created.
+|Contains all of the configuration parameters for your Jeager instance.  When a common definition (for all Jaeger components) is required, it is defined under the spec node. When the definition relates to an individual component, it is placed under the spec/<component> node.
+|N/A
+
+|strategy:
+|Jaeger deployment strategy
+|`allInOne`, `production`, or `streaming`
+|`allInOne`
+
+|allInOne:
+|Because the allInOne image deploys the agent, collector, query, ingester, Jaeger UI in a single pod, configuration for this deployment should nest component configuration under the allInOne parameter.
+|
+|
+
+|agent:
+|Configuration options that define the Jaeger agent.
+|
+|
+
+|collector:
+|Configuration options that define the Jaeger Collector.
+|
+|
+
+|sampling:
+|Configuration options that define the sampling strategies for tracing.
+|
+|
+
+|storage:
+|Configuration options that define the storage. All storage related options should be placed under `storage`, rather than under the `allInOne` or other component options.
+|
+|
+
+|query:
+|Configuration options that define the Query service.
+|
+|
+
+|ingester:
+|Configuration options that define the Ingester service.
+|
+|
+
+|===
+
+
+The following example YAML is the minimum required to create a Jaeger instance using the default settings.
+
+.Example minimum required jaeger-all-in-one.yaml
+[source,yaml]
+----
+apiVersion: jaegertracing.io/v1
+kind: Jaeger
+metadata:
+  name: jaeger-all-in-one-inmemory
+----

modules/jaeger-config-ingester.adoc

@@ -0,0 +1,90 @@
+////
+This REFERENCE module included in the following assemblies:
+-rhbjaeger-deploy.adoc
+////
+
+[id="jaeger-config-ingester_{context}"]
+= Jaeger Ingester configuration options
+
+Ingester is a service that reads from Kafka topic and writes to another storage backend (Elasticsearch).  If you are using the `allInOne` or `production` deployment strategies, you do not need to configure the Ingester service.
+
+
+.Jaeger default parameters
+[options="header"]
+[cols="l, a, a, a"]
+|===
+|Parameter |Description |Values |Default value
+|spec:
+  strategy: streaming
+  ingester:
+    options: {}
+|Configuration options that define the Ingester service.
+|
+|
+
+|ingester:
+ options:
+  kafka:
+    consumer:
+      topic: jaeger-spans
+|The `topic` parameter identifies the Kafka configuration used by the collector to produce the messages, and the ingester to consume the messages.
+|Label for the consumer
+|
+
+|ingester:
+  options:
+    kafka:
+      consumer:
+        brokers: my-cluster-kafka-brokers.kafka:9092
+|Identifies the Kafka configuration used by the Ingester to consume the messages.
+|
+|
+
+|ingester:
+  options:
+    ingester:
+      deadlockInterval: 5
+| Specifies the interval (in seconds or minutes) that the Ingester should wait for a message before terminating.
+The deadlock interval is disabled by default (set to 0), to avoid the Ingester being terminated when no messages arrive while the system is being initialized.
+|Minutes and seconds, for example, 1m0s.
+|0
+
+
+|options:
+  log-level:
+|Logging level for the Ingester.
+|Possible values: `trace`, `debug`, `info`, `warning`, `error`, `fatal`, `panic`.
+|
+|===
+
+
+
+.Streaming Collector and Ingester example
+[source,yaml]
+----
+apiVersion: jaegertracing.io/v1
+kind: Jaeger
+metadata:
+  name: simple-streaming
+spec:
+  strategy: streaming
+  collector:
+    options:
+      kafka:
+        producer:
+          topic: jaeger-spans
+          brokers: my-cluster-kafka-brokers.kafka:9092
+  ingester:
+    options:
+      kafka:
+        consumer:
+          topic: jaeger-spans
+          brokers: my-cluster-kafka-brokers.kafka:9092
+      ingester:
+        deadlockInterval: 5
+  storage:
+    type: elasticsearch
+    options:
+      es:
+        server-urls: http://elasticsearch:9200
+----