mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
add jaeger
This commit is contained in:
1
jaeger/images
Symbolic link
1
jaeger/images
Symbolic link
@@ -0,0 +1 @@
|
||||
../images
|
||||
1
jaeger/jaeger_arch/images
Symbolic link
1
jaeger/jaeger_arch/images
Symbolic link
@@ -0,0 +1 @@
|
||||
../images/
|
||||
1
jaeger/jaeger_arch/modules
Symbolic link
1
jaeger/jaeger_arch/modules
Symbolic link
@@ -0,0 +1 @@
|
||||
../modules/
|
||||
44
jaeger/jaeger_arch/rhbjaeger-architecture.adoc
Normal file
44
jaeger/jaeger_arch/rhbjaeger-architecture.adoc
Normal file
@@ -0,0 +1,44 @@
|
||||
[id="jaeger-architecture"]
|
||||
= Jaeger architecture
|
||||
include::modules/jaeger-document-attributes.adoc[]
|
||||
:context: jaeger-architecture
|
||||
|
||||
toc::[]
|
||||
|
||||
Every time a user takes an action in an application, a request is executed by the architecture that may require dozens of different services to participate in order to produce a response.
|
||||
Jaeger lets you perform distributed tracing, which records the path of a request through various microservices that make up an application.
|
||||
|
||||
_Distributed tracing_ is a technique that is used to tie the information about different units of work together — usually executed in different processes or hosts — to understand a whole chain of events in a distributed transaction.
|
||||
Developers can visualize call flows in large microservice architectures with distributed tracing.
|
||||
It's valuable for understanding serialization, parallelism, and sources of latency.
|
||||
|
||||
Jaeger records the execution of individual requests across the whole stack of microservices, and presents them as traces. A _trace_ is a data/execution path through the system. An end-to-end trace is comprised of one or more spans.
|
||||
|
||||
A _span_ represents a logical unit of work in Jaeger that has an operation name, the start time of the operation, and the duration, as well as potentially tags and logs. Spans may be nested and ordered to model causal relationships.
|
||||
|
||||
// The following include statements pull in the module files that comprise the assembly.
|
||||
|
||||
include::modules/jaeger-product-overview.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/jaeger-features.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/jaeger-architecture.adoc[leveloffset=+1]
|
||||
|
||||
////
|
||||
TODO
|
||||
WRITE more detailed component docs
|
||||
|
||||
include::modules/jaeger-client-java.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/jaeger-agent.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/jaeger-collector.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/jaeger-data-store.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/jaeger-query.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/jaeger-ingester.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/jaeger-console.adoc[leveloffset=+1]
|
||||
////
|
||||
1
jaeger/jaeger_config/images
Symbolic link
1
jaeger/jaeger_config/images
Symbolic link
@@ -0,0 +1 @@
|
||||
../images/
|
||||
1
jaeger/jaeger_config/modules
Symbolic link
1
jaeger/jaeger_config/modules
Symbolic link
@@ -0,0 +1 @@
|
||||
../modules/
|
||||
11
jaeger/jaeger_config/serverless-jaeger-integration.adoc
Normal file
11
jaeger/jaeger_config/serverless-jaeger-integration.adoc
Normal file
@@ -0,0 +1,11 @@
|
||||
include::modules/serverless-document-attributes.adoc[]
|
||||
[id="serverless-jaeger-integration"]
|
||||
= Integrating Jaeger with serverless applications using OpenShift Serverless
|
||||
:context: serverless-jaeger-integration
|
||||
include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
Using Jaeger with xref:../../serverless/serverless-getting-started.adoc#serverless-getting-started[{ServerlessProductName}] allows you to enable distributed tracing for your serverless applications on {product-title}.
|
||||
|
||||
include::modules/serverless-jaeger-config.adoc[leveloffset=+1]
|
||||
1
jaeger/jaeger_install/images
Symbolic link
1
jaeger/jaeger_install/images
Symbolic link
@@ -0,0 +1 @@
|
||||
../images/
|
||||
1
jaeger/jaeger_install/modules
Symbolic link
1
jaeger/jaeger_install/modules
Symbolic link
@@ -0,0 +1 @@
|
||||
../modules/
|
||||
27
jaeger/jaeger_install/rhbjaeger-removing.adoc
Normal file
27
jaeger/jaeger_install/rhbjaeger-removing.adoc
Normal file
@@ -0,0 +1,27 @@
|
||||
[id="removing-jaeger"]
|
||||
= Removing Jaeger
|
||||
include::modules/jaeger-document-attributes.adoc[]
|
||||
:context: removing-jaeger
|
||||
|
||||
toc::[]
|
||||
|
||||
The steps for removing Jaeger from an {product-title} cluster are as follows:
|
||||
|
||||
. Shut down any Jaeger pods.
|
||||
. Remove any Jaeger instances.
|
||||
. Remove the Jaeger Operator.
|
||||
|
||||
include::modules/jaeger-removing-instance.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/jaeger-removing-instance-cli.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
== Removing the Jaeger Operator
|
||||
|
||||
.Procedure
|
||||
|
||||
. Follow the instructions for xref:../../operators/admin/olm-deleting-operators-from-cluster.adoc#olm-deleting-operators-from-a-cluster[Deleting Operators from a cluster].
|
||||
|
||||
* Remove the Jaeger Operator.
|
||||
|
||||
* After the Jaeger Operator has been removed, if appropriate, remove the Elasticsearch Operator.
|
||||
12
jaeger/jaeger_install/rhbjaeger-updating.adoc
Normal file
12
jaeger/jaeger_install/rhbjaeger-updating.adoc
Normal file
@@ -0,0 +1,12 @@
|
||||
[id="upgrading-jaeger"]
|
||||
= Upgrading Jaeger
|
||||
include::modules/jaeger-document-attributes.adoc[]
|
||||
:context: upgrading-jaeger
|
||||
|
||||
toc::[]
|
||||
|
||||
The Operator Lifecycle Manager (OLM) controls the installation, upgrade, and role-based access control (RBAC) of Operators in a cluster. The OLM runs by default in {product-title}.
|
||||
The OLM queries for available Operators as well as upgrades for installed Operators.
|
||||
For more information about how {product-title} handled upgrades, refer to the xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-understanding-olm[Operator Lifecycle Manager] documentation.
|
||||
|
||||
The update approach used by the Jaeger Operator upgrades the managed Jaeger instances to the version associated with the Operator. Whenever a new version of the Jaeger Operator is installed, all the Jaeger application instances managed by the Operator will be upgraded to the Operator’s version. For example, if version 1.10 is installed (both Operator and backend components) and the Operator is upgraded to version 1.11, then as soon as the Operator upgrade has completed, the Operator will scan for running Jaeger instances and upgrade them to 1.11 as well.
|
||||
16
jaeger/rhbjaeger-release-notes.adoc
Normal file
16
jaeger/rhbjaeger-release-notes.adoc
Normal file
@@ -0,0 +1,16 @@
|
||||
[id="jaeger-release-notes"]
|
||||
= Jaeger Release Notes
|
||||
include::modules/jaeger-document-attributes.adoc[]
|
||||
:context: jaeger-release-notes
|
||||
|
||||
toc::[]
|
||||
|
||||
// The following include statements pull in the module files that comprise the assembly.
|
||||
|
||||
include::modules/jaeger-product-overview.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/support.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/jaeger-rn-new-features.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/jaeger-rn-known-issues.adoc[leveloffset=+1]
|
||||
Reference in New Issue
Block a user