丨prometheus metricsserver与kubernetes监控体系你好我是今天和主题PrometheusMetri

Prometheus实际上，Prometheus项目是当年CNCF起家时的“第二把交椅”。而这个项目发展到今天，已经全面接管了Kubernetes项目的整套体系。比较有意思的是，Prometheus项目与Kubernetes项目一样，也来自于的体系，它的原型系统，叫作BorgMon，是一个几乎与Borg同时诞生的内部系统。而Prometheus项目的发起原因也跟Kubernetes很类似，都是希望通过对用户更友好的方式，将内部系统的设计理念，传递给用户和开发者。作为一个系统，Prometheus项目的作用和工作方式，其实可以用如下所示的一张官可以看到，Prometheus项目工作的，是使用Pull（抓取）的方式去搜集被对象的Metrics数据（指标数据），然后，再把这些数据保存在一个TSDB（时间序列数据库，比如OpenTSDB、InfluxDB等）当中，以便后续可以按照时间进行检索。有了这 机制，Prometheus剩下的组件就是用来配合这套机制的运行。比Pushgateway，可以允许被对象以Push的方式向Prometheus推送Metrics数据而Alertmanager，则可以根据Metrics信息灵活地设置。当然，Prometheus最受用户欢迎的功能，还是通过Grafana对外出的、可以灵活配置的数据可视化界PrometheusMetricsKubernetes第一种Metrics，是宿主机的数据。这部分数据的提供，需要借助一个由Prometheus的NodeExporter工具。一般来说，NodeExporter会以DaemonSet的方式运行在宿主机上。其实，所谓的Exporter，就是代替被对象来对Prometheus出可以被“抓取”的Metrics信息的一个辅助进程。而NodeExporter可以给Prometheus的Metrics数据，也不单单是节点的负载（Load）、CPU、内存、磁盘以及网络这样的常规信息，它的Metrics指标可以说第二种Metrics，是来自于Kubernetes的APIServer、kubelet等组件的/metricsAPI。除了常规的CPU、内存的信息外，这部分信息还主要包括了各个组件的指标。比如，对于APIServer来说，它就会在/metricsAPI里，出各个Controller的工作队列（WorkQueue）的长度、请求的QPS和延迟数据等等。这些信息，是检查Kubernetes本身工作情况的主要依据。第三种Metrics，是Kubernetes相关的数据。这部分数据，一般叫作Kubernetes数据（coremetrics）。这其中包括了Pod、Node、容器、Service等主要Kubernetes概念的Metrics。其中，容器相关的Metrics主要来自于kubelet内置的cAdvisor服务。在kubelet启动后，cAdvisor服务也随之启动，而它能够提供的信息，可以细化到每一个容器的CPU、需要注意的是，这里提到的Kubernetes数据，其实使用的是Kubernetes的一个非常重要的扩展能力，叫作MetricsServer。MetricsServerKubernetesHeapsterKubernetes项目发展的初期，Heapster是用户获取Kubernetes数据（比如PodNode的资源使用情况）的主要。而后面提出来的MetricsServer，则把这些信息，通过标准的KubernetesAPI了出来。这样，Metrics信息就跟Heapster完成了解耦，允许Heapster项目慢慢退出舞台。而有了MetricsServer之后，用户就可以通过标准的KubernetesAPI来到这些数据了。比如，下面这个URL：1<namespace-当你这个MetricsAPI时，它就会为你返回一个Pod的数据，而这些数据，其实是从kubelet的SummaryAPI（即<kubelet_ip>:<kubelet_port>/stats/summary）而来的。SummaryAPI返回的信息，既包括了cAdVisor的数据，也包括了kubelet本身汇总的信息。需要的是，MetricsServer并不是kube-apiserver的一部分，而是通过备注：出可以看到，当Kubernetes的APIServer开启了Aggregator模式之后，你再apis/metrics.k8s.io/v1beta1的时候，实际问到的是一个叫作kube-aggregator的。而kube-apiserver，正是这个的一个后端；而MetricsServer，则是另一个后而且，在这个机制下，你还可以添加的后端给这个kube-aggregator。所以kube-aggregator其实就是一个根据URL选择具体的API后端的服务器。通过这种方式，我们就可以很方便地扩展Kubernetes的API了。而Aggregator如果你是使用kubeadm或者的kube-up.sh部署Kubernetes集群的话DIYkube-apiserver--requestheader--ca-file=<pathtoaggregatorCA----cert-file=<pathtoaggregator----key-file=<pathtoaggregatorAggregatorKeyCert些文件的生成，就需要你自己手动完成了，具体流程请参考这篇文档。AggregatorMetricsServerYAML$git $cdmetrics-$kubectlcreate-fmetrics.k8s.io这个APIKubernetesAPI在理解了Prometheus关心的三种数据源，以及Kubernetes的Metrics之后，作为用户，你其实要做的就是将PrometheusOperator在Kubernetes集群里部署起在后续的文章中，我会为你进一步剖析Kubernetes体系以及自定义Metrics（自定在本篇文章中，我主要为你介绍了Kubernetes当前体系的设计，介绍了Prometheus项目在这套体系中的地位，讲解了以Prometheus为的系统的架构然后，我为你详细地解读了Kubernetes数据的来源，即：MetricsServer的具体工作原理，以及AggregatorAPIServer的设计思路。通过以上讲述，我希望你能够对Kubernetes的体系形成一个整体的认知，体会到Kubernetes社区在这个事情上，全面以Prometheus项目为进行建设的大方最后，在具体的指标规划上，我建议你遵循业界通用的USE原则和RED原则不难发现，USE原则主要关注的是“资源”，比如节点和容器的资源使用情况，而RED原则主要关注的是“服务”，比如kube-apiserver或者某个应用的工作情况。这两种指标，在我今天为你讲解的Kubernetes+Prometheus组成的体系中，都是可以完在体系中，对于数据，其实既有Prometheus这种Pull模式，也有Push模 售卖。页面已增加防盗追踪，将依法其下一 49|CustomMetrics:让AutoScaling不再“食之无味言言 12能否解析下prometheusserver配置文件中，jobs的写法，alertrule的写法？还有作者回复:篇幅所限，prometheus项目具体的不进行详细展开 pushhttpworker，5jobjobpushgateway取。push方式可以联想到APM。 2 李昊 1有一个问题，就是metricserver是怎么给metrics.k8s.io/v1beta1这个api的，或者说狮锅 1你好，为什么node_exporter要单独分为一类而不是算作core 我要收购腾 1prometheuspull模式搭配自己的kubernetesSDprometheus-operatorservicemonitor 老师我一直对Prometheus和SNMPserver有什么区别搞不明白。这俩是一个东西吗？他们有什么具体的区别？是不是可以理解为SNMPserver是Prometheus的一个子集？ 按照课里的方式，基于kubeadm部署了k8s集群，但是metricsserver总是没办法正常工作。unabletofetchnodemetricsfornode"node-hostname":no