{"action":"created","issue":{"url":"https://api.github.com/repos/kubernetes/kube-state-metrics/issues/27","repository_url":"https://api.github.com/repos/kubernetes/kube-state-metrics","labels_url":"https://api.github.com/repos/kubernetes/kube-state-metrics/issues/27/labels{/name}","comments_url":"https://api.github.com/repos/kubernetes/kube-state-metrics/issues/27/comments","events_url":"https://api.github.com/repos/kubernetes/kube-state-metrics/issues/27/events","html_url":"https://github.com/kubernetes/kube-state-metrics/issues/27","id":178041249,"number":27,"title":"Feature request:  Add more labels to kube_pod_container_status_running","user":{"login":"somejfn","id":15197608,"avatar_url":"https://avatars.githubusercontent.com/u/15197608?v=3","gravatar_id":"","url":"https://api.github.com/users/somejfn","html_url":"https://github.com/somejfn","followers_url":"https://api.github.com/users/somejfn/followers","following_url":"https://api.github.com/users/somejfn/following{/other_user}","gists_url":"https://api.github.com/users/somejfn/gists{/gist_id}","starred_url":"https://api.github.com/users/somejfn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/somejfn/subscriptions","organizations_url":"https://api.github.com/users/somejfn/orgs","repos_url":"https://api.github.com/users/somejfn/repos","events_url":"https://api.github.com/users/somejfn/events{/privacy}","received_events_url":"https://api.github.com/users/somejfn/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2016-09-20T12:05:24Z","updated_at":"2016-09-20T13:55:02Z","closed_at":null,"body":"Thanks to this project I can create Prom alerts on the hosted deployment state.  Big +1 in filling this gap.\r\n\r\nNow Im attempting to create an alert based on a deployment's \"dispersion\" ratio.... that is,  should the Kube scheduler had little choice in picking nodes with resources (i.e. node outage),  that a given deployment's replicas are running on the same or too few Kubernetes node.   \r\n\r\nI think kube_pod_container_status_running would be the right place... but I'd need to have the deployment name and the node the pod is running on as labels. Then a Prom query would compute a ratio on POD running / unique nodes.  Does that make sense ?  \r\n"},"comment":{"url":"https://api.github.com/repos/kubernetes/kube-state-metrics/issues/comments/248308044","html_url":"https://github.com/kubernetes/kube-state-metrics/issues/27#issuecomment-248308044","issue_url":"https://api.github.com/repos/kubernetes/kube-state-metrics/issues/27","id":248308044,"user":{"login":"fabxc","id":4948210,"avatar_url":"https://avatars.githubusercontent.com/u/4948210?v=3","gravatar_id":"","url":"https://api.github.com/users/fabxc","html_url":"https://github.com/fabxc","followers_url":"https://api.github.com/users/fabxc/followers","following_url":"https://api.github.com/users/fabxc/following{/other_user}","gists_url":"https://api.github.com/users/fabxc/gists{/gist_id}","starred_url":"https://api.github.com/users/fabxc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fabxc/subscriptions","organizations_url":"https://api.github.com/users/fabxc/orgs","repos_url":"https://api.github.com/users/fabxc/repos","events_url":"https://api.github.com/users/fabxc/events{/privacy}","received_events_url":"https://api.github.com/users/fabxc/received_events","type":"User","site_admin":false},"created_at":"2016-09-20T13:55:01Z","updated_at":"2016-09-20T13:55:01Z","body":"You generally want to keep the number of 1:1 labels to a minimum. Otherwise, over time, you would basically enrich every metrics with all transitive and static label dimensions. If then something changes unexpectedly after all, you break all time series, as their identity is given by the full combination of all labels.\r\nGenerally speaking, you want your metrics to normalized.\r\n\r\nWhat we probably want here are metrics that express the relation from pod to deployment and pod to node. In your queries, you can then connect the time series along them.\r\n\r\nSo the node name could probably be attached to the `kube_pod_info` metric as a label: https://github.com/kubernetes/kube-state-metrics/blob/master/pod.go#L26-L30\r\n\r\nWe could have a metric on the `created-by` relation (currently living as a `SerializedRef` type in the `kubernetes.io/created-by` annotation. For example (`creator_namespace` would be redundant):\r\n\r\n`kube_pod_created_by{pod=\"my-app-aef242\",namespace=\"prod\",creator_kind=\"ReplicaSet\", creator_name=\"my-app-12341\"}    1` \r\n\r\nUnfortunately, relation from ReplicaSet to Deployment is not yet accessible in a similar way, but we can just use regex matching below to express it via ReplicaSets.\r\n\r\nYour PromQL query could then look like:\r\n\r\n```\r\ncount(\r\n  count by(node_name) (\r\n     kube_pod_info \r\n     and on(pod) kube_pod_status_phase{phase=\"Running\"}\r\n     and on(pod) kube_pod_created_by{creator_kind=\"ReplicaSet\", creator_name=~\"my-app-[0-9]+\"})\r\n  )\r\n)\r\n/ count(kube_node_info)\r\n```\r\n\r\nI know this is not a trivial but imagine that this is just one use case of many to incorporate relationships between components into your queries. So hard cording it into the exposed metrics does solve just a single use case of many.\r\n\r\n[Recording rules](https://prometheus.io/docs/querying/rules/#recording-rules) can help you here to break these parts out into separate metrics, which can be useful for other alerts and dashboards as well.\r\n\r\nI think a pull request for metric additions/changes as described above would be welcome."}}
{"actor":{"display_login":"fabxc"}}