{"id":35878494,"url":"https://github.com/thought-machine/prometheus-adapter","last_synced_at":"2026-01-23T06:29:23.390Z","repository":{"id":332416703,"uuid":"1130411875","full_name":"thought-machine/prometheus-adapter","owner":"thought-machine","description":"An implementation of the custom.metrics.k8s.io API using Prometheus","archived":false,"fork":false,"pushed_at":"2026-01-08T15:32:23.000Z","size":16303,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"master","last_synced_at":"2026-01-13T20:40:25.294Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/thought-machine.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"code-of-conduct.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":"NOTICE","maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-01-08T13:21:26.000Z","updated_at":"2026-01-08T14:59:02.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/thought-machine/prometheus-adapter","commit_stats":null,"previous_names":["thought-machine/prometheus-adapter"],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/thought-machine/prometheus-adapter","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/thought-machine%2Fprometheus-adapter","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/thought-machine%2Fprometheus-adapter/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/thought-machine%2Fprometheus-adapter/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/thought-machine%2Fprometheus-adapter/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/thought-machine","download_url":"https://codeload.github.com/thought-machine/prometheus-adapter/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/thought-machine%2Fprometheus-adapter/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28682259,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-23T05:48:07.525Z","status":"ssl_error","status_checked_at":"2026-01-23T05:48:07.129Z","response_time":59,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-08T17:21:49.585Z","updated_at":"2026-01-23T06:29:23.383Z","avatar_url":"https://github.com/thought-machine.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Prometheus Adapter for Kubernetes Metrics APIs\n\nThis repository contains an implementation of the Kubernetes Custom, Resource and External\n[Metric APIs](https://github.com/kubernetes/metrics).\n\nThis adapter is therefore suitable for use with the autoscaling/v2 Horizontal Pod Autoscaler in Kubernetes 1.6+.  \nIt can also replace the [metrics server](https://github.com/kubernetes-incubator/metrics-server) on clusters that already run Prometheus and collect the appropriate metrics.\n\nQuick Links\n-----------\n\n- [Config walkthrough](docs/config-walkthrough.md) and [config reference](docs/config.md).\n- [End-to-end walkthrough](docs/walkthrough.md)\n- [Deployment info and files](deploy/README.md)\n\nInstallation\n-------------\nIf you're a helm user, a helm chart is listed on prometheus-community repository as [prometheus-community/prometheus-adapter](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus-adapter).\n\nTo install it with the release name `my-release`, run this Helm command:\n\nFor Helm2\n```console\n$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts\n$ helm repo update\n$ helm install --name my-release prometheus-community/prometheus-adapter\n```\nFor Helm3 ( as name is mandatory )\n```console\n$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts\n$ helm repo update\n$ helm install my-release prometheus-community/prometheus-adapter\n```\n\nOfficial images\n---\nAll official images for releases after v0.8.4 are available in `registry.k8s.io/prometheus-adapter/prometheus-adapter:$VERSION`. The project also maintains a [staging registry](https://console.cloud.google.com/gcr/images/k8s-staging-prometheus-adapter/GLOBAL/) where images for each commit from the master branch are published. You can use this registry if you need to test a version from a specific commit, or if you need to deploy a patch while waiting for a new release.\n\nImages for versions v0.8.4 and prior are only available in unofficial registries:\n* https://quay.io/repository/coreos/k8s-prometheus-adapter-amd64\n* https://hub.docker.com/r/directxman12/k8s-prometheus-adapter/\n\nConfiguration\n-------------\n\nThe adapter takes the standard Kubernetes generic API server arguments\n(including those for authentication and authorization).  By default, it\nwill attempt to using [Kubernetes in-cluster\nconfig](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod)\nto connect to the cluster.\n\nIt takes the following additional arguments specific to configuring how the\nadapter talks to Prometheus and the main Kubernetes cluster:\n\n- `--lister-kubeconfig=\u003cpath-to-kubeconfig\u003e`: This configures\n  how the adapter talks to a Kubernetes API server in order to list\n  objects when operating with label selectors.  By default, it will use\n  in-cluster config.\n\n- `--metrics-relist-interval=\u003cduration\u003e`: This is the interval at which to\n  update the cache of available metrics from Prometheus. By default, this\n  value is set to 10 minutes.\n\n- `--metrics-max-age=\u003cduration\u003e`: This is the max age of the metrics to be\n  loaded from Prometheus. For example, when set to `10m`, it will query\n  Prometheus for metrics since 10m ago, and only those that has datapoints\n  within the time period will appear in the adapter. Therefore, the metrics-max-age\n  should be equal to or larger than your Prometheus' scrape interval,\n  or your metrics will occaisonally disappear from the adapter.\n  By default, this is set to be the same as metrics-relist-interval to avoid\n  some confusing behavior (See this [PR](https://github.com/kubernetes-sigs/prometheus-adapter/pull/230)).\n\n  Note: We recommend setting this only if you understand what is happening.\n  For example, this setting could be useful in cases where the scrape duration is\n  over a network call, e.g. pulling metrics from AWS CloudWatch, or Google Monitoring,\n  more specifically, Google Monitoring sometimes have delays on when data will show\n  up in their system after being sampled. This means that even if you scraped data\n  frequently, they might not show up soon. If you configured the relist interval to\n  a short period but without configuring this, you might not be able to see your\n  metrics in the adapter in certain scenarios.\n\n- `--prometheus-url=\u003curl\u003e`: This is the URL used to connect to Prometheus.\n  It will eventually contain query parameters to configure the connection.\n\n- `--config=\u003cyaml-file\u003e` (`-c`): This configures how the adapter discovers available\n  Prometheus metrics and the associated Kubernetes resources, and how it presents those\n  metrics in the custom metrics API.  More information about this file can be found in\n  [docs/config.md](docs/config.md).\n\nPresentation\n------------\n\nThe adapter gathers the names of available metrics from Prometheus\nat a regular interval (see [Configuration](#configuration) above), and then\nonly exposes metrics that follow specific forms.\n\nThe rules governing this discovery are specified in a [configuration file](docs/config.md).\nIf you were relying on the implicit rules from the previous version of the adapter,\nyou can use the included `config-gen` tool to generate a configuration that matches\nthe old implicit ruleset:\n\n```shell\n$ go run cmd/config-gen/main.go [--rate-interval=\u003cduration\u003e] [--label-prefix=\u003cprefix\u003e]\n```\n\nExample\n-------\n\nA brief walkthrough exists in [docs/walkthrough.md](docs/walkthrough.md).\n\nAdditionally, [@luxas](https://github.com/luxas) has an excellent example\ndeployment of Prometheus, this adapter, and a demo pod which serves\na metric `http_requests_total`, which becomes the custom metrics API\nmetric `pods/http_requests`.  It also autoscales on that metric using the\n`autoscaling/v2beta1` HorizontalPodAutoscaler.  Note that @luxas's tutorial\nuses a slightly older version of the adapter.\n\nIt can be found at https://github.com/luxas/kubeadm-workshop.  Pay special\nattention to:\n\n- [Deploying the Prometheus\n  Operator](https://github.com/luxas/kubeadm-workshop#deploying-the-prometheus-operator-for-monitoring-services-in-the-cluster)\n- [Setting up the custom metrics adapter and sample\n  app](https://github.com/luxas/kubeadm-workshop#deploying-a-custom-metrics-api-server-and-a-sample-app)\n\nFAQs\n----\n\n### Why do my metrics keep jumping between a normal value and a very large number?\n\nYou're probably switching between whole numbers (e.g. `10`) and milli-quantities (e.g. `10500m`).\nWorry not!  This is just how Kubernetes represents fractional values.  See the\n[Quantity Values](/docs/walkthrough.md#quantity-values) section of the walkthrough for a bit more\ninformation.\n\n### Why isn't my metric showing up?\n\nFirst, check your configuration.  Does it select your metric?  You can\nfind the [default configuration](/deploy/manifests/custom-metrics-config-map.yaml)\nin the deploy directory, and more information about configuring the\nadapter in the [docs](/docs/config.md).\n\nNext, check if the discovery information looks right.  You should see the\nmetrics showing up as associated with the resources you expect at\n`/apis/custom.metrics.k8s.io/v1beta1/` (you can use `kubectl get --raw\n/apis/custom.metrics.k8s.io/v1beta1` to check, and can pipe to `jq` to\npretty-print the results, if you have it installed). If not, make sure\nyour series are labeled correctly.  Consumers of the custom metrics API\n(especially the HPA) don't do any special logic to associate a particular\nresource to a particular series, so you have to make sure that the adapter\ndoes it instead.\n\nFor example, if you want a series `foo` to be associated with deployment\n`bar` in namespace `somens`, make sure there's some label that represents\ndeployment name, and that the adapter is configured to use it.  With the\ndefault config, that means you'd need the query\n`foo{namespace=\"somens\",deployment=\"bar\"}` to return some results in\nPrometheus.\n\nNext, try using the `--v=6` flag on the adapter to see the exact queries\nbeing made by the adapter.  Try url-decoding the query and pasting it into\nthe Prometheus web console to see if the query looks wrong.\n\n### My query contains multiple metrics, how do I make that work?\n\nIt's actually fairly straightforward, if a bit non-obvious.  Simply choose one\nmetric to act as the \"discovery\" and \"naming\" metric, and use that to configure\nthe \"discovery\" and \"naming\" parts of the configuration.  Then, you can write\nwhichever metrics you want in the `metricsQuery`!  The series query can contain\nwhichever metrics you want, as long as they have the right set of labels.\n\nFor example, suppose you have two metrics `foo_total` and `foo_count`,\nboth with the label `system_name`, which represents the `node` resource.\nThen, you might write\n\n```yaml\nrules:\n- seriesQuery: 'foo_total'\n  resources: {overrides: {system_name: {resource: \"node\"}}}\n  name:\n    matches: 'foo_total'\n    as: 'foo'\n  metricsQuery: 'sum(foo_total{\u003c\u003c.LabelMatchers\u003e\u003e}) by (\u003c\u003c.GroupBy\u003e\u003e) / sum(foo_count{\u003c\u003c.LabelMatchers\u003e\u003e}) by (\u003c\u003c.GroupBy\u003e\u003e)'\n```\n\n### I get errors about SubjectAccessReviews/system:anonymous/TLS/Certificates/RequestHeader!\n\nIt's important to understand the role of TLS in the Kubernetes cluster.  There's a high-level\noverview here: https://github.com/kubernetes-incubator/apiserver-builder/blob/master/docs/concepts/auth.md.\n\nAll of the above errors generally boil down to misconfigured certificates.\nSpecifically, you'll need to make sure your cluster's aggregation layer is\nproperly configured, with requestheader certificates set up properly.\n\nErrors about SubjectAccessReviews failing for system:anonymous generally mean\nthat your cluster's given requestheader CA doesn't trust the proxy certificates\nfrom the API server aggregator.\n\nOn the other hand, if you get an error from the aggregator about invalid certificates,\nit's probably because the CA specified in the `caBundle` field of your APIService\nobject doesn't trust the serving certificates for the adapter.\n\nIf you're seeing SubjectAccessReviews failures for non-anonymous users, check your\nRBAC rules -- you probably haven't given users permission to operate on resources in\nthe `custom.metrics.k8s.io` API group.\n\n### My metrics appear and disappear\n\nYou probably have a Prometheus collection interval or computation interval\nthat's larger than your adapter's discovery interval.  If the metrics\nappear in discovery but occaisionally return not-found, those intervals\nare probably larger than one of the rate windows used in one of your\nqueries.  The adapter only considers metrics with datapoints in the window\n`[now-discoveryInterval, now]` (in order to only capture metrics that are\nstill present), so make sure that your discovery interval is at least as\nlarge as your collection interval.\n\n### I get errors when query namespace prefixed metrics?\n\nI have namespace prefixed metrics like `{ \"name\": \"namespaces/node_memory_PageTables_bytes\", \"singularName\": \"\", \"namespaced\": false, \"kind\": \"MetricValueList\", \"verbs\": [ \"get\" ] }`, but I get error `Error from server (InternalError): Internal error occurred: unable to list matching resources` when access with `kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/*/node_memory_PageTables_bytes` .\n\nActually namespace prefixed metrics are special, we should access them with `kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/*/metrics/node_memory_PageTables_bytes`.\n\n## Community, discussion, contribution, and support\n\nLearn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).\n\nYou can reach the maintainers of this project at:\n\n- [Slack](http://slack.k8s.io/)\n- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-dev)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthought-machine%2Fprometheus-adapter","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fthought-machine%2Fprometheus-adapter","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthought-machine%2Fprometheus-adapter/lists"}