|
1 | 1 | [id="deploying-jaeger"] |
2 | 2 | = Deploying Jaeger |
3 | | -include::modules/jaeger-document-attributes.adoc[] |
| 3 | +include::modules/ossm-document-attributes.adoc[] |
4 | 4 | :context: jaeger-deploying |
5 | 5 |
|
6 | 6 | toc::[] |
7 | 7 |
|
8 | | -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. |
| 8 | +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. |
9 | 9 |
|
10 | | -Jaeger has pre-defined 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. |
| 10 | +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. |
| 11 | +The Jaeger Operator currently supports the following deployment strategies: |
11 | 12 |
|
12 | | -.Jaeger custom resource file showing deployment strategy |
13 | | -[source,yaml] |
14 | | ----- |
15 | | -apiVersion: jaegertracing.io/v1 |
16 | | -kind: Jaeger |
17 | | -metadata: |
18 | | - name: simple-prod |
19 | | -spec: |
20 | | - strategy: production <1> |
21 | | ----- |
| 13 | +* *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. |
22 | 14 |
|
23 | | -<1> The Jaeger Operator currently supports the following deployment strategies: |
24 | | - |
25 | | -* *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. |
26 | | -+ |
27 | 15 | [NOTE] |
28 | 16 | ==== |
29 | | -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. |
| 17 | +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. |
30 | 18 | ==== |
31 | 19 |
|
32 | | -* *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. |
| 20 | +* *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]. |
33 | 21 |
|
34 | | -* *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]). |
| 22 | +* *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). |
35 | 23 |
|
36 | 24 | [NOTE] |
37 | 25 | ==== |
38 | 26 | 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]. |
39 | 27 | ==== |
40 | 28 |
|
41 | 29 |
|
42 | | - |
43 | 30 | // The following include statements pull in the module files that comprise the assembly. |
44 | 31 |
|
45 | 32 | include::modules/jaeger-deploy-default.adoc[leveloffset=+1] |
46 | 33 |
|
47 | | -include::modules/jaeger-deploy-production-es.adoc[leveloffset=1] |
48 | | - |
49 | | -include::modules/jaeger-deploy-streaming.adoc[leveloffset=1] |
50 | | - |
51 | | -[id="customizing-jaeger-deployment"] |
52 | | -= Customizing Jaeger deployment |
53 | | - |
54 | 34 | include::modules/jaeger-config-default.adoc[leveloffset=+1] |
55 | 35 |
|
56 | | -include::modules/jaeger-config-collector.adoc[leveloffset=+1] |
57 | | - |
58 | | -include::modules/jaeger-config-sampling.adoc[leveloffset=+1] |
59 | | - |
60 | | -include::modules/jaeger-config-storage.adoc[leveloffset=+1] |
61 | | - |
62 | | -include::modules/jaeger-config-query.adoc[leveloffset=+1] |
63 | | - |
64 | | -include::modules/jaeger-config-ingester.adoc[leveloffset=+1] |
65 | | - |
66 | | -[id="injecting-sidecars"] |
67 | | -= Injecting sidecars |
| 36 | +include::modules/jaeger-deploy-production-es.adoc[leveloffset=+1] |
68 | 37 |
|
69 | | -{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. |
| 38 | +include::modules/jaeger-config-production-es.adoc[leveloffset=+1] |
70 | 39 |
|
71 | | -include::modules/jaeger-sidecar-automatic.adoc[leveloffset=1] |
| 40 | +include::modules/jaeger-deploy-streaming.adoc[leveloffset=+1] |
72 | 41 |
|
73 | | -include::modules/jaeger-sidecar-manual.adoc[leveloffset=1] |
| 42 | +include::modules/jaeger-config-streaming.adoc[leveloffset=+1] |
0 commit comments