-
Notifications
You must be signed in to change notification settings - Fork 144
OTel working branch targeting OTel feature branch #4894
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: janan07/otel-feature-branch
Are you sure you want to change the base?
OTel working branch targeting OTel feature branch #4894
Conversation
Signed-off-by: Andrew Jandacek <[email protected]>
|
😺 Thank you for creating this PR! To publish your content to Zowe Docs, follow these required steps.
Need help? Contact the Doc Squad in the #zowe-doc Slack channel. |
|
📁 The PR description is missing the file name(s) for the updated content. List all the files included in this PR so this information displays in our Zowe Docs GitHub Slack channel. If you have addressed this issue already, refresh this page in your browser to remove this comment. |
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
balhar-jakub
left a comment
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.
From the skeleton point of view, these are the only changes that would make the usage of the skeleton easier.
Let me know once the general explanation is available and I will review this part.
docs/user-guide/api-mediation/observability/observability-outline.md
Outdated
Show resolved
Hide resolved
docs/user-guide/api-mediation/observability/observability-outline.md
Outdated
Show resolved
Hide resolved
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
| Groups services into logical sets. Use this property value to distinguish between different installations, such as sysplex-a vs. sysplex-b, or north-datacenter vs. south-datacenter. `service.name` is expected to be unique within the same `namespace`. | ||
|
|
||
| * **service.instance.id** (The Unique Instance) | ||
| Identifies the specific running process or Address Space. Must be unique for each instance of `service.name` and `service.namespace` pair. On z/OS, this property is typically mapped to the Job Name or a unique UUID. |
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.
Not true with jobname. Instance id must be globally unique. All instances on different lpars may have the same job name.
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.
Is this better?
- service.instance.id (The Unique Instance)
Identifies a specific running process or Address Space. This value must be globally unique for every instance. As multiple z/OS systems can run identical Job Names, ensure that you combine the Job Name with a unique identifier (such as the LPAR name or a UUID) to ensure the instance can be isolated during troubleshooting.
| resource: | ||
| attributes: | ||
| service.name: "zowe-apiml" | ||
| service.namespace: "production-plex" |
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.
I suggest we put only examples of complete configuration instead of partial ones to specific attribute groups. For instance, here I would expect the 'production' to be set as deployment attribute
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.
Are you suggesting then that we remove all configuration examples in this article or replace them with the complete configuration? If the latter, can you provide me with the complete configuration?
docs/user-guide/api-mediation/observability/configuring-otel-zos-attributes.md
Outdated
Show resolved
Hide resolved
docs/user-guide/api-mediation/observability/configuring-otel-zos-attributes.md
Outdated
Show resolved
Hide resolved
docs/user-guide/api-mediation/observability/configuring-otel-zos-attributes.md
Show resolved
Hide resolved
| * **resource.attributes** | ||
| A collection of key-value pairs used to identify the telemetry source. See the following sub-properties of `resource.attributes`: | ||
|
|
||
| * **service.name** |
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.
Here we duplicate the explanation of service attributes that we have in a separate md file just for them. Similarly for the deployment. It will be difficult to keep them in sync over time.
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.
If you think it's sufficient, I can link to the specific attribute article for these three resources. It just seems that if we have an article for enablement, the user should have an easy reference to what parms are being configured...
docs/user-guide/api-mediation/observability/enabling-observability-in-zowe-yaml.md
Outdated
Show resolved
Hide resolved
docs/user-guide/api-mediation/observability/enabling-observability-in-zowe-yaml.md
Outdated
Show resolved
Hide resolved
docs/user-guide/api-mediation/observability/enabling-observability-in-zowe-yaml.md
Outdated
Show resolved
Hide resolved
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
Signed-off-by: Andrew Jandacek <[email protected]>
iansergeant42
left a comment
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.
Looking pretty good. Just a few things to address.
| @@ -0,0 +1,96 @@ | |||
| # Configure OpenTelemetry Service Attributes | |||
|
|
|||
| Services are identified via the service.name, service.namespace, and service.instance.id properties. Together, these attributes create a unique identity for API ML instances across your enterprise. | |||
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.
service.name, service.namespace, and service.instance.id? Trying to be consistent...
|
|
||
| ## z/OS Attribute Reference | ||
|
|
||
| The following attributes are captured during system discovery to describe the mainframe environment: |
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.
A couple of things:
- Can we describe what 'system discovery' means here? What actually populates the attributes? Our junior sys prog won't understand it.
- Given Richard's statement on process.pid not being configured by system discovery, does this move to another section?
| * **exporter.otlp.protocol** | ||
| The protocol is either `grpc` or `http/protobuf`. | ||
| **Default:** `grcp` |
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.
To note here that if we do reinstate, we have a typo with grpc and grcp mentioned.
| exporter: | ||
| otlp: | ||
| endpoint: "http://otel-collector.your.domain:4317" | ||
| protocol: "grpc" |
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.
To be removed as per Richard above
| @@ -0,0 +1,22 @@ | |||
| # Using Your API ML OpenTelemetry Metrics | |||
|
|
|||
| ## Examples of Useability of Telemetry data in API ML | |||
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.
Typo. Usability.
Signed-off-by: Andrew Jandacek <[email protected]>
Describe your pull request here: This is the working branch for dev use that targets the OTel feature branch
List the file(s) included in this PR:
After creating the PR, follow the instructions in the comments.