Add release notes for metrics changes #548
Conversation
|
When I was doing release notes for MP FT 2.1, I didn't understand the difference either. I think we should just get rid of "functional changes". |
|
A new paragraph needs to be added to document the breaking changes. |
Azquelt
force-pushed
the
metrics-release-notes
branch
from
6146903
to
49e044d
Compare
|
@Emily-Jiang I've updated the release notes to include a section for backward incompatible changes with more detail of what's changed and what's needed to migrate. |
| The names of the metrics added automatically by MicroProfile Fault Tolerance have been updated to take advantage of support for metric tags which was added to MicroProfile Metrics in version 2.0. As a result, some information which was previously contained in the metric name is now instead included in tags. | ||
|
|
||
| In addition, metrics have moved from the `application:` scope to the `base:` scope for consistency with other MicroProfile specifications. | ||
|
|
There was a problem hiding this comment.
Previously you see the metrics under /metrics and /metrics/application. With this change, the metrics will be displayed under /metrics endpoint only.
There was a problem hiding this comment.
Not sure I want to add this information. In other parts of the spec, we only talk about how fault tolerance adds metrics through the Metrics API, we never discuss or test how MP Metrics exports that information (which indirectly insulates us from any changes they might make to the export format).
Additionally, if we do add it, then, as far as I'm aware, it makes the following changes:
- metrics are no longer exported from
/metrics/application - metrics are exported from
/metrics/base - in the JSON format, when metrics are retrieved from
/metricsthey appear in thebaseobject rather than theapplicationobject - in the OpenMetrics format, the names are prefixed with
base_instead ofapplication_
There was a problem hiding this comment.
The spec does not talk about the difference between the endpoints, but MP Metrics has the details. I would vote to add what you proposed above. It is crystal clear from an end user point of view.
There was a problem hiding this comment.
Well, I've added it, but I'm not sure if it means we devote too much space to talking about the scope change, when the change of metric names and the addition of tags is the bigger and more important part of the change.
I'm happy to leave it in or take it out again, let me know what you think.
Azquelt
force-pushed
the
metrics-release-notes
branch
2 times, most recently
from
1a7e658
to
126ea30
Compare
Signed-off-by: Andrew Rouse <anrouse@uk.ibm.com>
Azquelt
force-pushed
the
metrics-release-notes
branch
from
126ea30
to
b30d927
Compare
Add release notes for #401 and #499
I'm not exactly sure of the difference between functional changes and spec changes are, but we seem to list changes under everything they apply to.
I've copied the way that MP Metrics denote breaking changes as it seemed fairly sensible.