-
Notifications
You must be signed in to change notification settings - Fork 591
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
MP70: Implement MicroProfile Telemetry 2.0 #27108
Comments
we need to add resource attribute labels to properly identify where our telemetry is coming from. I've opened #28608 for that, and added that to a checklist in the description of this epic. |
I added another requirement to this epic to ensure that we add required JVM metrics. See checklist in description of this epic. |
I added another requirement to this epic to be able to load customizers into the OTel SDK instance created by the runtime. See checklist in description of this epic. |
Review comments from Upcoming Feature Overview presentation:
|
@yasmin-aumeeruddy I'm really struggling to understand slides 19-21 as shown in the UFO. I spoke to @donbourne because it is late on a Friday for you as I'm reviewing it and he might be in a better position to explain my confusion. It isn't clear to me what the pictures are trying to show, the boxes are labeled host, but look like servers. On slide 21 it isn't clear what the lines between the two hosts mean, and it isn't clear to me how you get a runtime associated SDK vs an application associated one. |
Hi @NottyCode I have changed the reference from "Host" to server. If I have updated the diagrams in the UFO with the help of @donbourne |
On slide 36:
As I understand it, it's valid and may be desirable to configure MP Telemetry per application rather than per server? If so, I think this should be an info message, rather than a warning. Warnings are for things that are wrong that the user ought to correct. I think we've had users complain before about warnings that they can't correct. |
@OpenLiberty/demo-approvers Demo scheduled for EOI [24.17] |
OL: Serviceability Approval Comment - Please answer the following questions for serviceability approval:
|
Approving. David Mueller indicated that he has/will have the info that he needs to make the doc updates. |
@clarkek123 will be handling the serviceability approval for this epic. |
UFO -- does the UFO identify the most likely problems customers will see and identify how the feature will enable them to diagnose and solve those problems without resorting to raising a PMR? Have these issues been addressed in the implementation? Yes - Slide 36 shows the new warning messages that are emitted when enabling the feature if the user has any misconfiguration. The breaking changes to the configuration of the feature are explained in slides 19-21. Test and Demo -- As part of the serviceability process we're asking feature teams to test and analyze common problem paths for serviceability and demo those problem paths to someone not involved in the development of the feature (eg. IBM Support, test team, or another development team). Behaviour: Enabling the OpenTelemetry sdk by setting Outcome: A warning message is shown: Behaviour: Disabling the OpenTelemetry sdk by setting Outcome: A warning message is shown: b) Who did you demo to? The UK MicroProfile Development team - Including team members who were not involved in the development process: @abutch3r @jakub-pomykala @tevans78 @ryan-storey. @benjamin-confino was involved in the development process but reviewed as a level 3 support engineer. c) Do the people you demo'd to agree that the serviceability of the demonstrated problem scenarios is sufficient to avoid PMRs for any problems customers are likely to encounter, or that IBM Support should be able to quickly address those problems without need to engage SMEs?** Yes SVT -- SVT team is often the first team to try new features and often encounters problems setting up and using them. Note that we're not expecting SVT to do full serviceability testing -- just to sign-off on the serviceability of the problem paths they encountered. According to @hanczaryk: SVT agrees that the serviceability of any problem encountered was sufficient to avoid PMRs or L2 should be able to quickly address those problems without engaging L3. Which IBM Support / SME queues will handle PMRs for this feature? Ensure they are present in the contact reference file and in the queue contact summary, and that the respective IBM Support/SME teams know they are supporting it. Ask Don Bourne if you need links or more info. Yes, see was-l3-cdi Does this feature add any new metrics or emit any new JSON events? If yes, have you updated the JMX metrics reference list / Metrics reference list / JSON log events reference list in the Open Liberty docs? Yes- The link to documentation is here: |
I have added Serviceability approval based on the information provided above for Serviceability showing common error paths testing with demo with approval from Local team members with L3 support focus and others not working on development in addition to the SVT signoff on the paths included for serviceability. |
@OpenLiberty/ste-approvers I have added the slide deck to the box folder |
@yasmin-aumeeruddy : WASWIN is good with the STE slides. STE approved. |
Approved for GA without the FAT approval. In discussions with the test team it seems that the tests are timing out which means that sometimes it doesn't run on some platforms. When it runs it seems to pass. We obviously need the tests to be passing reliably, but the assessment is that the risk the timeout is hiding quality issues is low. Addressing the test reliability will need to be done post GA. |
Description
Adopt OpenTelemetry Metrics and/or Logging as well as Tracing.
Dependent epics:
Documents
When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.
Aha idea
Requested feature
Process Overview
General Instructions
The process steps occur roughly in the order as presented. Process steps occasionally overlap.
Each process step has a number of tasks which must be completed or must be marked as not applicable ("N/A").
Unless otherwise indicated, the tasks are the responsibility of the Feature Owner or a Delegate of the Feature Owner.
If you need assistance, reach out to the OpenLiberty/release-architect.
Important: Labels are used to trigger particular steps and must be added as indicated.
Prioritization (Complete Before Development Starts)
The (OpenLiberty/chief-architect) and area leads are responsible for prioritizing the features and determining which features are being actively worked on.
Prioritization
Design (Complete Before Development Starts)
Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID. Furthermore, each identified item places a blocking requirement on another team so it must be identified early in the process. The feature owner may check-off the item if they know it doesn't apply, but otherwise they should work with the focal point to determine what work, if any, will be necessary and make them aware of it.
Design Preliminaries
ID Required
, if non-trivial documentation needs to be created by the ID team.ID Required - Trivial
, if no design will be performed and only trivial ID updates are needed.Design
Design Review Request
Design Approval Request
Design Approved
No Design
No Design Approval Request
No Design Approved
Product Management Approval Request
and notifies OpenLiberty/product-managementProduct Management Approved
(OpenLiberty/product-management)FAT Documentation
Implementation
A feature must be prioritized before any implementation work may begin to be delivered (inaccessible/no-ship). However, a design focused approach should still be applied to features, and developers should think about the feature design prior to writing and delivering any code.
Besides being prioritized, a feature must also be socialized (or No Design Approved) before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it
kind=noship
or beta fencing it.Code may not GA until this feature has obtained the
Design Approved
orNo Design Approved
label, along with all other tasks outlined in the GA section.Feature Development Begins
In Progress
labelLegal and Translation
In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before Beta or GA is requested.
Legal (Complete before Feature Complete Date)
Innovation (Complete 1 week before Feature Complete Date)
Translation (Complete by Feature Complete Date)
Beta
In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.
Beta Code
kind=beta
,ibm:beta
,ProductInfo.getBetaEdition()
target:beta
and the appropriatetarget:YY00X-beta
(where YY00X is the targeted beta version).release:YY00X-beta
(where YY00X is the first beta version that included the functionality).Beta Blog (Complete by beta eGA)
GA
A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.
Feature Complete
Translation - Complete
orTranslation - Missing
labelrelease
branch, feature owner adds labelTranslation - Complete
.Translation - Missing
.Translation - Missing
label is replaced withTranslation - Complete
.Translation - Blocked
label.Translation - Blocked
may NOT proceed to GA until the label has been replaced with eitherTranslation - Missing
orTranslation - Complete
.target:ga
and the appropriatetarget:YY00X
(where YY00X is the targeted GA version).Focal Point Approvals (Complete by Feature Complete Date)
These occur only after GA of this feature is requested (by adding a
target:ga
label). GA of this feature may not occur until all approvals are obtained.All Features
focalApproved:externals
@OpenLiberty/demo-approvers Demo scheduled for EOI [Iteration Number]
to this issue.focalApproved:demo
.focalApproved:fat
.Design Approved Features
focalApproved:id
.focalApproved:instantOn
.focalApproved:performance
.focalApproved:sve
.focalApproved:ste
.focalApproved:svt
.Remove Beta Fencing (Complete by Feature Complete Date)
GA Blog (Complete by Friday after GM)
Post GM (Complete before GA)
Post GA
target:ga
andtarget:YY00X
labels, and add the appropriaterelease:YY00X
. (OpenLiberty/release-manager)Other Deliverables
The text was updated successfully, but these errors were encountered: