{"action":"reopened","issue":{"url":"https://api.github.com/repos/mwitkow/go-grpc-prometheus/issues/2","repository_url":"https://api.github.com/repos/mwitkow/go-grpc-prometheus","labels_url":"https://api.github.com/repos/mwitkow/go-grpc-prometheus/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/mwitkow/go-grpc-prometheus/issues/2/comments","events_url":"https://api.github.com/repos/mwitkow/go-grpc-prometheus/issues/2/events","html_url":"https://github.com/mwitkow/go-grpc-prometheus/issues/2","id":154856229,"number":2,"title":"Potential ways to improve metrics","user":{"login":"brian-brazil","id":7115638,"avatar_url":"https://avatars.githubusercontent.com/u/7115638?v=3","gravatar_id":"","url":"https://api.github.com/users/brian-brazil","html_url":"https://github.com/brian-brazil","followers_url":"https://api.github.com/users/brian-brazil/followers","following_url":"https://api.github.com/users/brian-brazil/following{/other_user}","gists_url":"https://api.github.com/users/brian-brazil/gists{/gist_id}","starred_url":"https://api.github.com/users/brian-brazil/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/brian-brazil/subscriptions","organizations_url":"https://api.github.com/users/brian-brazil/orgs","repos_url":"https://api.github.com/users/brian-brazil/repos","events_url":"https://api.github.com/users/brian-brazil/events{/privacy}","received_events_url":"https://api.github.com/users/brian-brazil/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":20,"created_at":"2016-05-14T14:20:21Z","updated_at":"2016-05-17T15:40:04Z","closed_at":null,"body":"There's a few ways these metrics can be improved in line with [best practices]( https://prometheus.io/docs/instrumenting/writing_exporters/)\r\n\r\n`service` is a common target label, so it is unwise to use it as an instrumentation label as it'll cause clashes for some users. I recommend `grpc_service` instead.\r\n\r\n`type` is a very generic label name, try to find something more specific. This is to avoid half the metrics exposed by a binary having a `type` label, each with different meanings.\r\n\r\n`grpc_server_rpc_handled_bucket` should include the seconds unit in the name\r\n\r\n`grpc_server_rpc_handled_bucket` should not include `code` as a label. There's two reasons. Firstly \"The list of all statuses is to long\", which combined with the other 4 labels in this metric threatens to make the metric cardinality too high. Secondly is it strongly recommend not to break out latency metrics by success/failure. Better would be a separate failures metric broken out by code, don't forget to initialise all possible label values to 0."}}