From dcf7bae439adc8eb54ed809f791c4aa7150c7120 Mon Sep 17 00:00:00 2001 From: RainbowMango Date: Mon, 9 Sep 2019 16:47:04 +0800 Subject: [PATCH] Update broken links from keps/sig-instrumentation --- .../20181106-kubernetes-metrics-overhaul.md | 4 ++-- .../20190404-kubernetes-control-plane-metrics-stability.md | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/keps/sig-instrumentation/20181106-kubernetes-metrics-overhaul.md b/keps/sig-instrumentation/20181106-kubernetes-metrics-overhaul.md index e7d0b1bdb19..6d5c19794eb 100644 --- a/keps/sig-instrumentation/20181106-kubernetes-metrics-overhaul.md +++ b/keps/sig-instrumentation/20181106-kubernetes-metrics-overhaul.md @@ -59,7 +59,7 @@ This KEP is targeted to land in Kubernetes 1.14. The aim is to get all changes i ## Motivation -A number of metrics that Kubernetes is instrumented with do not follow the [official Kubernetes instrumentation guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/instrumentation.md). This is for a number of reasons, such as the metrics having been created before the instrumentation guidelines were put in place (around two years ago), and just missing it in code reviews. Beyond the Kubernetes instrumentation guidelines, there are several violations of the [Prometheus instrumentation best practices](https://prometheus.io/docs/practices/instrumentation/). In order to have consistently named and high quality metrics, this effort aims to make working with metrics exposed by Kubernetes consistent with the rest of the ecosystem. In fact even metrics exposed by Kubernetes are inconsistent in themselves, making joining of metrics difficult. +A number of metrics that Kubernetes is instrumented with do not follow the [official Kubernetes instrumentation guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md). This is for a number of reasons, such as the metrics having been created before the instrumentation guidelines were put in place (around two years ago), and just missing it in code reviews. Beyond the Kubernetes instrumentation guidelines, there are several violations of the [Prometheus instrumentation best practices](https://prometheus.io/docs/practices/instrumentation/). In order to have consistently named and high quality metrics, this effort aims to make working with metrics exposed by Kubernetes consistent with the rest of the ecosystem. In fact even metrics exposed by Kubernetes are inconsistent in themselves, making joining of metrics difficult. Kubernetes also makes extensive use of a global metrics registry to register metrics to be exposed. Aside from general shortcomings of global variables, Kubernetes is seeing actual effects of this, causing a number of components to use `sync.Once` or other mechanisms to ensure to not panic, when registering metrics. Instead a metrics registry should be passed to each component in order to explicitly register metrics instead of through `init` methods or other global, non-obvious executions. Within the scope of this KEP, we want to explore other ways, however, it is not blocking for its success, as the primary goal is to make the metrics exposed themselves more consistent and stable. @@ -117,7 +117,7 @@ https://github.com/kubernetes/kubernetes/pull/63924 #### Prober metrics -Make prober metrics introduced in https://github.com/kubernetes/kubernetes/pull/61369 conform to the [Kubernetes instrumentation guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/instrumentation.md). +Make prober metrics introduced in https://github.com/kubernetes/kubernetes/pull/61369 conform to the [Kubernetes instrumentation guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md). ### Kube-scheduler metric changes diff --git a/keps/sig-instrumentation/20190404-kubernetes-control-plane-metrics-stability.md b/keps/sig-instrumentation/20190404-kubernetes-control-plane-metrics-stability.md index 30d4e27981a..e57b05f634a 100644 --- a/keps/sig-instrumentation/20190404-kubernetes-control-plane-metrics-stability.md +++ b/keps/sig-instrumentation/20190404-kubernetes-control-plane-metrics-stability.md @@ -64,7 +64,8 @@ Currently metrics emitted in the Kubernetes control-plane do not offer any stabi ## Motivation -Metrics stability has been an ongoing community concern. Oftentimes, cluster monitoring infrastructure assumes the stability of at least some control-plane metrics; thus, it would be prudent to offer some sort of guarantees around control-plane metrics, treating it more properly as an API. Since the [metrics overhaul](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/0031-kubernetes-metrics-overhaul.md) is nearing completion, there should be less reason to introduce breaking changes to metrics, making it an opportune time to introduce metric stability rules. Specifically, this KEP intends to address metric stability from an ingestion point of view. +Metrics stability has been an ongoing community concern. Oftentimes, cluster monitoring infrastructure assumes the stability of at least some control-plane metrics; thus, it would be prudent to offer some sort of guarantees around control-plane metrics, treating it more properly as an API. +Since the [metrics overhaul](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/20181106-kubernetes-metrics-overhaul.md) is nearing completion, there should be less reason to introduce breaking changes to metrics, making it an opportune time to introduce metric stability rules. Specifically, this KEP intends to address metric stability from an ingestion point of view. Guarantees around metrics have been [proposed previously](https://docs.google.com/document/d/1_CdNWIjPBqVDMvu82aJICQsSCbh2BR-y9a8uXjQm4TI/edit#) and there are [ongoing community discussions](https://groups.google.com/forum/#!topic/kubernetes-sig-instrumentation/XbElxDtww0Y) around this issue. Some suggested solutions include: