Update spec to reflect decision on context-root #108
Conversation
fixes eclipse#65 Signed-off-by: Mike Croft <backtotheoldhouse@gmail.com>
mikecroft
force-pushed
the
avoid-metric-collisions
branch
from
d2ab457
to
2670fbd
Compare
|
Can someone make sure what I've written clearly reflects the decision from #65 please? |
|
Hey Mike, in the Tuesday call, we decided to defer the whole context-root in the name change to 1.1. The reason was that it's a significant change and since we are so close to releasing this we didn't think we'd have time to make that work in our impl and test it properly before putting the spec out. |
| @@ -126,6 +126,7 @@ Details of this Java API are described in <<app-metrics-api>>. | |||
|
|
|||
| Application specific metrics are exposed under `/metrics/application`. | |||
|
|
|||
| The application context root must be prepended to all application metrics to prevent collisions where multiple applications are deployed to the same server. Where the implementation does not support multiple applications on the same server, or an application is deployed to the root context (`/`), it is not necessary to prepend anything to the metric name. | |||
There was a problem hiding this comment.
We should perhaps use a pseudo-root in cases only one application is provided and not omit that level in the hierarchy to make things uniform (?)
There was a problem hiding this comment.
I agree with @pilhuhn. If only one application is deployed, there should be metrics with both context root prefix and without it. That way it wouldn't break the behavior specified in v1.0.
What happens to the metrics without prefix if another app is deployed would be left unspecified - impls can choose to show the metrics from the app deployed first, last, combine conflicting metrics together or allow user to configure it. I expect that the metrics without a prefix would be only used when there's a single app deployed.
|
We will not implement it this way, but if at all via labels. See #362 |
fixes #65