-
Notifications
You must be signed in to change notification settings - Fork 1.8k
OBSDOCS-1699: 3.8 docs preview for Suppport's hackathon #102927
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
fb122f4
1308a0c
0daa3f6
5cbc10c
83f93f5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,60 @@ | ||
| // Module included in the following assemblies: | ||
| // | ||
| // * observability/otel/otel-configuration-of-otel-intro.adoc | ||
|
|
||
| :_mod-docs-content-type: REFERENCE | ||
| [id="otel-collector-profile-signal_{context}"] | ||
| = Profile signal | ||
|
|
||
| [role="_abstract"] | ||
| The Profile signal is an emerging telemetry data format for observing code execution and resource consumption. | ||
|
|
||
| :FeatureName: The Profile signal | ||
| include::snippets/technology-preview.adoc[leveloffset=+1] | ||
|
|
||
| The Profile signal allows you to pinpoint inefficient code down to specific functions. Such profiling allows you to precisely identify performance bottlenecks and resource inefficiencies down to the specific line of code. By correlating such high-fidelity profile data with traces, metrics, and logs, it enables comprehensive performance analysis and targeted code optimization in production environments. | ||
|
|
||
| Profiling can target an application or operating system: | ||
|
|
||
| * Using profiling to observe an application can help developers validate code performance, prevent regressions, and monitor resource consumption such as of memory and CPU, and thus identify and improve inefficient code. | ||
| * Using profiling to observe operating systems can provide insights into the infrastracture, system calls, kernel operations, and I/O wait times, and thus help in optimizing infrastructure for efficiency and cost savings. | ||
| .OpenTelemetry Collector custom resource with the enabled Profile signal | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🤖 [error] AsciiDocDITA.BlockTitle: Block titles can only be assigned to examples, figures, and tables in DITA. |
||
| [source,yaml] | ||
| ---- | ||
| apiVersion: opentelemetry.io/v1beta1 | ||
| kind: OpenTelemetryCollector | ||
| metadata: | ||
| name: otel-profiles-collector | ||
| namespace: otel-profile | ||
| spec: | ||
| args: | ||
| feature-gates: service.profilesSupport # <1> | ||
| config: | ||
| receivers: | ||
| otlp: # <2> | ||
| protocols: | ||
| grpc: | ||
| endpoint: '0.0.0.0:4317' | ||
| http: | ||
| endpoint: '0.0.0.0:4318' | ||
| exporters: | ||
| otlp/pyroscope: | ||
| endpoint: "pyroscope.pyroscope-monitoring.svc.cluster.local:4317" # <3> | ||
| service: | ||
| pipelines: # <4> | ||
| profiles: | ||
| receivers: [otlp] | ||
| exporters: [otlp/pyroscope] | ||
| # ... | ||
| ---- | ||
| <1> Enables profiles by setting the `feature-gates` field as shown here. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🤖 [error] AsciiDocDITA.CalloutList: Callouts are not supported in DITA. |
||
| <2> Configures the OTLP Receiver to set up the OpenTelemetry Collector to receive profiling data via the OTLP. | ||
| <3> Configures where to export profiles to, such as a storage. | ||
| <4> Defines a profiling pipeline, including a configuration for forwarding the received profile data to an OTLP-compatible profiling backend such as Grafana Pyroscope. | ||
|
|
||
| [role="_additional-resources"] | ||
| .Additional resources | ||
| * link:https://opentelemetry.io/docs/specs/otel/profiles/[OpenTelemetry Profiles] | ||
| * link:https://opentelemetry.io/docs/specs/semconv/general/profiles/[Profiles attributes] | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,46 @@ | ||
| // Module included in the following assemblies: | ||
| // | ||
| // * observability/otel/otel-collector/otel-collector-exporters.adoc | ||
|
|
||
| :_mod-docs-content-type: REFERENCE | ||
| [id="otel-exporters-google-cloud-exporter_{context}"] | ||
| = Google Cloud Exporter | ||
|
|
||
| [role="_abstract"] | ||
| You can use the Google Cloud Exporter to export telemetry data to Google Cloud Operations Suite. Using the Google Cloud Exporter, you can export metrics to Google Cloud Monitoring, logs to Google Cloud Logging, and traces to Google Cloud Trace. | ||
|
|
||
| :FeatureName: The Google Cloud Exporter | ||
| include::snippets/technology-preview.adoc[] | ||
|
|
||
| .OpenTelemetry Collector custom resource with the enabled Google Cloud Exporter | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🤖 [error] AsciiDocDITA.BlockTitle: Block titles can only be assigned to examples, figures, and tables in DITA. |
||
| [source,yaml] | ||
| ---- | ||
| # ... | ||
| env: | ||
| - name: GOOGLE_APPLICATION_CREDENTIALS | ||
| value: /var/secrets/google/key.json # <1> | ||
| volumeMounts: | ||
| - name: google-application-credentials | ||
| mountPath: /var/secrets/google | ||
| readOnly: true | ||
| volumes: | ||
| - name: google-application-credentials | ||
| secret: | ||
| secretName: google-application-credentials | ||
| config: | ||
| exporters: | ||
| googlecloud: | ||
| project: # <2> | ||
| # ... | ||
| ---- | ||
| <1> The `GOOGLE_APPLICATION_CREDENTIALS` environment variable that points to the authentication `key.json` file. The `key.json` file is mounted as a secret volume to the OpenTelemetry Collector. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🤖 [error] AsciiDocDITA.CalloutList: Callouts are not supported in DITA. |
||
| <2> Optional. The project identifier. If not specified, the project is automatically determined from the credentials. | ||
| + | ||
| By default, the exporter sends telemetry data to the project specified in the `project` field of the exporter's configuration. You can have an override set up on a per-metric basis by using the `gcp.project.id` resource attribute. For example, if a metric has a label project, you can use the Group-by-Attributes Processor to promote it to a resource label, and then use the Resource Processor to rename the attribute from `project` to `gcp.project.id`. | ||
|
|
||
| [role="_additional-resources"] | ||
| .Additional resources | ||
| * link:https://cloud.google.com/monitoring[Google Cloud Monitoring] | ||
| * link:https://cloud.google.com/logging[Google Cloud Logging] | ||
| * link:https://cloud.google.com/trace[Google Cloud Trace] | ||
| * link:https://cloud.google.com/iam/docs/workload-identity-federation-with-kubernetes#deploy[Google Cloud Guides: Configure Workload Identity Federation with Kubernetes] | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| // Module included in the following assemblies: | ||
| // | ||
| // * observability/otel/otel-forwarding-telemetry-data.adoc | ||
|
|
||
| :_mod-docs-content-type: CONCEPT | ||
| [id="otel-forwarding-data-to-aws_{context}"] | ||
| = Forwarding telemetry data to AWS | ||
|
|
||
| [role="_abstract"] | ||
| You can have metrics, logs, and traces forwarded to the Amazon CloudWatch and AWS X-Ray services by using the following exporters of the OpenTelemetry Collector: AWS CloudWatch Logs Exporter, AWS EMF Exporter, and AWS X-Ray Exporter. | ||
|
|
||
| // Currently, this docs repository does not permit linking from here to the sections for AWS CloudWatch Logs Exporter, AWS EMF Exporter, and AWS X-Ray Exporter. See the xref to the "Exporters" page placed in observability/otel/otel-forwarding-telemetry-data.adoc. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| // Module included in the following assemblies: | ||
| // | ||
| // * observability/otel/otel-forwarding-telemetry-data.adoc | ||
|
|
||
| :_mod-docs-content-type: CONCEPT | ||
| [id="otel-forwarding-data-to-google-cloud_{context}"] | ||
| = Forwarding telemetry data to Google Cloud | ||
|
|
||
| [role="_abstract"] | ||
| You can have metrics, logs, and traces forwarded to Google Cloud Operations Suite by using the Google Cloud Exporter of the OpenTelemetry Collector. | ||
|
|
||
| // Currently, this docs repository does not permit linking from here to the Google Cloud Exporter section. See the xref to the "Exporters" page placed in observability/otel/otel-forwarding-telemetry-data.adoc. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -32,3 +32,48 @@ include::snippets/technology-preview.adoc[] | |
| ---- | ||
| <1> A list of file glob patterns that match the file paths to be read. | ||
| <2> An array of Operators. Each Operator performs a simple task such as parsing a timestamp or JSON. To process logs into a desired format, chain the Operators together. | ||
|
|
||
| To collect logs from application containers, you can use this receiver with sidecar injection. The {OTELOperator} allows injecting an OpenTelemetry Collector as a sidecar container into a application pod. This approach is useful when your application writes logs to files within the container filesystem. To access the generated files, both pods require a shared volume for the application container and the sidecar Collector. This receiver can then tail log files and apply Operators to parse and transform the logs. To use this receiver in sidecar mode to collect logs from application containers, you must configure volume mounts in the `OpenTelemetryCollector` custom resource. The Collector requires access to the log files through a shared volume, such as `emptyDir`, that is mounted in both the application container and the sidecar Collector container. The following is a complete example of this approach: | ||
|
|
||
| .OpenTelemetry Collector custom resource with the Filelog Receiver configured in sidecar mode | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🤖 [error] AsciiDocDITA.BlockTitle: Block titles can only be assigned to examples, figures, and tables in DITA. |
||
| [source,yaml] | ||
| ---- | ||
| apiVersion: opentelemetry.io/v1beta1 | ||
| kind: OpenTelemetryCollector | ||
| metadata: | ||
| name: filelog | ||
| namespace: otel-logging | ||
| spec: | ||
| mode: sidecar | ||
| volumeMounts: # <1> | ||
| - name: logs | ||
| mountPath: /var/log/app | ||
| config: | ||
| receivers: | ||
| filelog: | ||
| include: # <2> | ||
| - /var/log/app/*.log | ||
| operators: | ||
| - type: regex_parser | ||
| regex: '^(?P<timestamp>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(?P<level>\w+)\] (?P<message>.*)$' | ||
| timestamp: | ||
| parse_from: attributes.timestamp | ||
| layout: '%Y-%m-%d %H:%M:%S' | ||
| processors: {} | ||
| exporters: | ||
| debug: | ||
| verbosity: detailed | ||
| service: | ||
| pipelines: | ||
| logs: | ||
| receivers: [filelog] | ||
| processors: [] | ||
| exporters: [debug] | ||
| ---- | ||
| <1> Defines the volume mount that the sidecar Collector uses to access the target log files. This volume must match the volume name defined in the application deployment. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🤖 [error] AsciiDocDITA.CalloutList: Callouts are not supported in DITA. |
||
| <2> Specifies file glob patterns for matching the log files to tail. This receiver watches these paths for new log entries. | ||
| + | ||
| [IMPORTANT] | ||
| ==== | ||
| The `volumeMounts` field in the `OpenTelemetryCollector` custom resource is critical for the sidecar to access log files. The volume specified here must be defined in the application's `Deployment` or `Pod` specification. Both the application container and the sidecar Collector must mount the same volume. | ||
| ==== | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,55 @@ | ||
| // Module included in the following assemblies: | ||
| // | ||
| // * observability/otel/otel-collector/otel-collector-receivers.adoc | ||
|
|
||
| :_mod-docs-content-type: REFERENCE | ||
| [id="otel-receivers-prometheus-remote-write-receiver_{context}"] | ||
| = Prometheus Remote Write Receiver | ||
|
|
||
| [role="_abstract"] | ||
| The Prometheus Remote Write Receiver receives metrics from Prometheus via the Remote Write protocol and converts them to the OpenTelemetry format. This receiver supports only the Prometheus Remote Write v2 protocol. | ||
|
|
||
| :FeatureName: The Prometheus Remote Write Receiver | ||
| include::snippets/technology-preview.adoc[] | ||
|
|
||
| .OpenTelemetry Collector custom resource with the enabled Prometheus Remote Write Receiver | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🤖 [error] AsciiDocDITA.BlockTitle: Block titles can only be assigned to examples, figures, and tables in DITA. |
||
| [source,yaml] | ||
| ---- | ||
| # ... | ||
| config: | ||
| receivers: | ||
| prometheusremotewrite: | ||
| endpoint: 0.0.0.0:9009 # <1> | ||
| service: | ||
| pipelines: | ||
| metrics: | ||
| receivers: [prometheusremotewrite] | ||
| # ... | ||
| ---- | ||
| <1> The endpoint where the receiver listens for Prometheus Remote Write requests. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🤖 [error] AsciiDocDITA.CalloutList: Callouts are not supported in DITA. |
||
|
|
||
| The following are the prerequisites for using the Prometheus Remote Write Receiver with Prometheus: | ||
|
|
||
| * Prometheus is started with the metadata WAL records feature flag enabled: | ||
| + | ||
| [source,yaml] | ||
| ---- | ||
| ./prometheus --config.file config.yml --enable-feature=metadata-wal-records | ||
| ---- | ||
| * Prometheus Remote Write v2 Protocol is enabled in the Prometheus configuration file: | ||
| + | ||
| [source,yaml] | ||
| ---- | ||
| remote_write: | ||
| - url: "<your_chosen_prometheus_remote_write_receiver_endpoint>" | ||
| protobuf_message: io.prometheus.write.v2.Request | ||
| ---- | ||
| * Native histograms are enabled in Prometheus. For more information about enabling native histograms in Prometheus, see the Prometheus documentation. | ||
| [role="_additional-resources"] | ||
| .Additional resources | ||
| * link:https://prometheus.io/docs/prometheus/latest/feature_flags/#metadata-wal-records[Metadata WAL Records] | ||
| * link:https://prometheus.io/docs/specs/prw/remote_write_spec_2_0/[Prometheus Remote-Write 2.0 specification [EXPERIMENTAL]] | ||
| * link:https://prometheus.io/docs/specs/native_histograms/[Native Histograms] | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤖 [error] OpenShiftAsciiDoc.SuggestAttribute: Use the AsciiDoc attribute '{TempoName}' or '{TempoShortName}' rather than the plain text product term 'Tempo', unless your use case is an exception.