容器云平台监控架构设计及优化.docx

1概述随着容器化的大力发展，容器云平台已经基本由Kubernetes作为统一的容器管理方案.当我们使用Kubernetes进行容器化管理时，传统监控工具如Zabbix无法对Kubernetes做到统一有效的全面监控,全面监控Kubernetes也就成为我们需要探索的问题.使用容器云监控，旨在全面监控Kubernetes集群、节点、服务、实例的统计数据，验证集群是否正常运行并创建相应告警.本文旨在于介绍容器云平台监控的架构设计及优化.2价值和意义监控是运维体系中是非常里要的组成部分，通过监控可以实时掌握系统运行状态.对故障提前预警.以及历史状态的回放，还可以通过监控数据为系统的容最规划提供辅助决策，为系统性能优化提供真实的用户行为和体验.为容器云提供良好的监控环境是保证容器服务的高可鸵性、高可用性和高性能的重要部分，通过对本文的学习，能够快速认识当前容器环境下都有哪些监控方案，并对主流的监控方案有一个系统的了解和认识.3监控方案选型3.1容器云监控方案有嘟些(1)ZabbixZabbix是由AlexeiVladishev开源的分布式监控系统，支持多种采集方式和采集客户端，同时支持SNMP、IPM1.JMX、Telnet,SSH等多种协议，它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告瞥.Zabbix核心组件主要是Agent和Server,其中Agent主要负责采集数据并通过主动或者被动的方式采集数据发送到ServerPro×y,除此之外，为了扩展监控项，Agent还支持执行自定义脚本.Server主要负责接收Agent发送的监控信息.并进行汇总存储，触发告瞥等。ZabbixSerVer将收集的监控数据存储到ZabbixDatabase中。ZabbiXDatabase支持常用的关系型数据座，如MySQ1.、P。StgreSQ1.、Orade等，默认是MySQ1.并提供ZabbixWeb页面（PHP编写）数据直询.Zabbix由于使用了关系型数据存储时序数据，所以在监控大规模集群时常常在数据存储方面捉襟见肘.所以从Zabbix4.2版本后开始支持TimescaIeDB时序数据库，不过目前成熟度还不高。(2)Open-FalconOpen-Falcon是小米开源的企业级监控工具，用Go语言开发而成，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可扩展并且高性能的监控方案，主要组件包括了：1 )Falcon-agent是用Go语言开发的Daemon程序，运行在每台1.inUX服务器上,用于采集主机上的各种指标数据，主要包括CPU、内存、碳盘、文件系统、内核参数、Socket连接等，目前已经支持200多项监控指标。并且,Agent支持用户自定义的监控脚本.2 )Hearthbeatserver简称HBS心跳服务，每个Agent都会周期性地通过RPC方式将自己的状态上报给HBS,主要包括主机名、主机IP、Agent版本和插件版本,Agent还会从HBS获取自己需要执行的采集任务和自定义插件.3 )Transfer负责接收Agent发送的监控数据,并对数据进行整理，在过混后通过一致性Hash算法发送到JUdge或者Graph.4 )Graph是基于RRD的数据上报、归档、存储组件。Graph在收到数据以后,会以rrdtool的数据归档方式来存储，同时提供RPC方式的监控查询接口.5 JJudge告警模块,Transfer祷发到Judge的数据会发用户设定的告警规则，如果满足，则会触发邮件、微佶或者回调接口。这里为了避免电宣告警引入了Redis哲存告警，从而完成告警的合并和抑制.6 )Dashboard是面向用户的监控数据直询和告警配署界面.(3)NagiosNagiosN名为NetSaint,由EthanGalstad开发并维护。Nagios是一个老牌监控工具，由C语言编写而成，主要针对主机监控(CPU、内存、磁盘等)和网络监控(SMTP、PoP3、HTTP和NNTP等)，当然也支持用户自定义的监控脚本.它还支持一种更加通用和安全的采集方式NREP(NagiosRemotePluginExecutor),它首先在远端启动一个NREP守护进程，用于在远端主机上面运行检测命令,在Nagios服务端用checknrep的plugin插件通过SS1.对接到NREP守护进程执行相应的监控行为.相比SSH远程执行命令的方式，这种方式更加安全.(4)PrometheusPrometheus是一个很受欢迎的开源监控和警报工具包，继Kubernetes之后成为第二个正式加入CNCF基金会的项目，2017年底发布了基于全新存储层的2.0版本，能更好地与容器云平台配合.能实现dockerstatus.CAdvisor的监控功能，并且Prometheus原生支持Kubernetes监控，具有Kubernetes对象服务发现能力，Kubernetes的核心组件也提供了Prometheus的采集接口.单个Prometheus可以每秒抓取10万的metrics,能满足一定规模下k8s集群的监控需求，并且具备良好的三11旬能力，提供数据声询语言PromQ1.,PromQ1.提供了大量的数据计凭函数，大部分情况下用户都可以直接通过PromQ1.从Prometheus里直询到需要的聚合数据.3.2方案对比并确定通过以下方面对上述监控方案进行对比：1 )从开发语言上看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经慢慢从C语言转移到G。.不得不说,Go凭借简洁的语法和优雅的并发/Java占据业务开发，C占领底层开发的情况下，准确定位中间件开发需求，在当前开源中间件产品中被广泛应用.2 )从系统成熟度上看，Zabbix和Nagios都是老牌的监控系统，系统功能比较稳定，成熟度较高.而Prometheus和OPen-FaICon都是最近几年才诞生的,虽然功能还在不断迭代更新，但站在巨人的肩膀之上，在架构设计上借鉴了很多老牌监控系统的经脸.3 ）从系统扩展性方面看,Zabbix和OPen-FalCon都可以自定义各种监控脚本，并且Zabbix不仅可以做到主动推送，还可以做到被动拉取,Prometheus则定义了一套监控数据规范，并通过各种exporter扩展系统采集能力.4 ）从数据存储方面来看，Zabbix采用关系数据库保存，这极大限制了Zabbix采集的性能，Nagios和OPen-FaICOn都采用RDD数据存储，OPen-FaICOn还加入了一致性hash算法分片数据，并且可以对接到OPenTSDB,而Prometheus自研一套高性能的时序数据库，在V3版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储.5 ）从配置复杂度上看，Prometheus只有一个核心server组件，一条命令便可以启动,相比而言,其他系统配置相对麻烦,尤其是OPen-FaIcon.6 ）从社区活跃度上看,目前Zabbix和Nagios的社区活跃度比蛟低，尤其是Nagios,Open-Falcon虽然也比较活跃，但基本都是国内的公司参与，Prometheus在这方面占据绝对优势社区活跃度最高,并且受到CNCF的支持，后期的发展值得期待.7 ）从容器支持角度看，由于ZabbiX和Nagi。S出现得比较早，当时容器还没有诞生，自然对容器的支持也比较差。Open-Falcon虽然提供了容器的监控，但支持力度有限.Prometheus的动态发现机制,不仅可以支持swarm原生集群，还支持KUberneteS容器集群的监控，是目前容器监控最好解决方案.Zabbix在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。而Nagi。S则在网络监控方面有广泛应用，伴RS若容器的发展，Prometheus开始成为主导及容器监控方面的标配，并且在未来可见的时间内被广泛应用。息体来说，对比各种监控系统的优劣，Prometheus可以说是目前监控领域最律利的“瑞士军刀”了.4基于prometheus的容器云平台监控架构设计4.1 prometheus介绍Prometheus是由SoundCIoud开发的开源监控报警系统和时序列数据库.于2016年加入CloudNativeComputingFoundation,作为继Kubernetes之后的第二个托管项目，具有强大的数据采集、数据存储、数据展示、告警等功能，天生完美支持kubernetes.主要特点：多维数据模型：通过度员名称和键值对标识的时间序列数据PromSQ1.:一种灵活的直询语言，可以利用多睚数据完成复杂的直询不依赖分布式存储，单个服务器节点可直接工作基于HTTP的pull方式采集时间序列数据推送时间序列数据通过PUShGateWay组件支持通过服务发现或饰态配置发现目标多种图形模式及仪表盘支持组件：Prometheus生态包括了很多组件，它们中的一些是可选的Prometheus主服务器，用于抓取和存储时间序列数据用于检测应用程序代码的客户端库用于支持短声明周期的push网关针对HAProxy,StatsD,Graphite,Snmp等服务的特定exporters警告管理器各种支持工具多数PrometheUS组件是Go语言写的，这使得这些组件很容易编译和部罟.4.2 架构设计(1)图片左侧是各种数据源主要是各种符合Prometheus数据格式的exporter,除此之外为了支持推动数据类型的Agent,可以通过Pushgateway组件旃Push转化为Pull.Prometheus甚至可以从其它的Prometheus获取数据，组建联邦集群。Prometheus的基本原理是通过HTTP周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控.(2)图片上侧是服务发现，Prometheus支持监控对象的自动发现机制，从而可以动态获取监控对象.(3)图片中间是PrometheusServer,Retrieval模块定时拉取数据，并通过Storage模块保存数据。PromQ1.为Prometheus提供的直询语法,PromQ1.模块通过解析语法树，调用Storage模块迨询接口获取监控数据.(4)图片右侧是告警和页面展现，Prometheus将告警推送到alertmanger,然后通过alertmanger对告警进行处理并执行相应动作.数据展现除了Prometheus自带的webui,还可以通过grafana等组件查询Prometheus监控数据.Prometheus支持使用联邦集群的方式，对Prometheus进行扩展。如图，在每个集群（数据中心）部海单独的Prometheus,用于采集当前集群（数据中心）监控数据，并由上层的PrOmetheUS负责聚合多个集群（数据中心）的监控数据.这里部署多个联邦节点是为了实现高可用.联邦集群的核心在于每一个Prometheus都包含一个用于获取当前实例中监控样本的接口/federate。对于联邦Prometheus而言，无论是从其他的Prometheus实例还是Exporter实例中获取数据实际上并没有任何差异.适用场景：Prometheus在记录纯数字时间序列方面表现非常好.既适用于面向服务器等硬件指标的监控，也适用于高动态的面向服务架构的监控。对于现流行的微服务，Prometheus的多维度数据收集和数据筛选迨询语言也是非常的强大.Prometheus是为服务的可靠性而设计的，当服务出现故障时，可以快速定位和诊断问题.搭建过程对硬件和服务没有很强的依赖关系.不适用场景：(1)如果需要100%的准确度(例如按请求计赛).Prometheus不是一个好的选择，因为收集的数据可能不够详细和完整.在这种情况下，最好使用其他系统来收集和分析数据以进行计斐,并使用PrometheUS进行其余监控.(2)PrometheUS只针对性能和可用性监控，默认并不具备日志监控等功能.(3)Prometheus认为只有最近的监控数据才有直询的需要，本地存储的设计初衷只是保持短期(一个月)的数据，并非针对大JS的历史数据的存储.如果需要报表之类的历史数据，则建议使用远端存储.(4)PrometheUS没有定义单位，需要使用者自己去区分或者事先定义好监控数据单位.4.3 监控点有哪些从容器云平台本身的业务需求分析来看，至少应该通过Prometheus获取到以下监控数据：性能指标：(1)容器相关的性能指标数据container.cp.utilization:容器的CPU使用率container.memory.utilization:容器的memory使用率(2)Pod相关的性能指标数据pod.cpu.utilization:pod的CPU使用率pod.memory.utilization:pod的memory使用率(3)主机Node节点相关的性能指标数据node.cpu.utilization:主机的CPU使用率node.memory.utilization:主机的memory使用率node.load.l:主机过去1分钟的负载node.load.5:主机过去5分钟的负载node.load.15:主机过去15分钟的负载node.resource.request.cpu.utilization:主机的kubernetescpuresource使用率node.resource.request.memory.utilization:主机的kubernetesmemoryresource使用率服务健康状态：(1)KUberneteS集群服务的健康状态ControlPlaneUP:G群健康状态(2)KUberneteS服务组件的健康状态APIServerUP:APIServer状态ControllerManagerUP:ControllerManager状态SchedulersUP:Schedulers状态KubeletUP:kubelet状态Kube-proxyUP:KUbe-PrOXy状态(3)主机Node节点的健康状态NodeUP:node节点的状态(4)docker服务进程的健康状态DockerUP:DOCker状态(5)DePIOyment相关的健康状态DeploymentReplicas:deployment副本数(6)Pod的健康状态PodReady:pod的状态下面选取以上指标中的部分进行举例：容器cpu使用率：COntaineJCPU_USeJSeCOndS_totalContaineJname=jenkins”,endpoint='https-metrics",instance="192.168.234.122:10250job='e×pose-kubelets-metrics',namespace="kube-os',node='nodel",pod-name='jenkins2-696b8fbdbb-hd9hmservice="expose-kubelets-metries'主机过去5分钟的负载:node-load5endpoint="metrics",host,ip="192.168.234.121",instance="192.168.234.121:9796",job="expose-node-metrics,namespace=,cattle-prometheus,node="master,pod="exporter-node-cluster-monitoring-b4m72*,service="e×pose-node-metrics,Deployment副本数：kube_deployment_spec_replicasdeployment="coredns",endpoint='http",host.ip="192.168.234.122,instance="192.169.1.2498080,1job='expose-kubernetes-metrics",namespace="kube-system',node="node,pod="exporter-kbe-state-cluster-monitoring-5c988dbc56-ckrz6,',service="e×pose-kubernetes-metrics*Pod的状态:kube_pod_status_readycondition="true",endpoint=*http',host_ip="192.168.234.122,1instance="192.169.1.249:8080",job='expose-kubernetes-metrics",namespace="default",node="nodel",pod="toolbox-f95b876-mrkxn",service="e×pose-kubernetes-metrics,)4.4重要组件介绍上图是Prometheus-Operator官方提供的架构图,其中OPeratOr是最核心的部分,作为一个控制器，它会去创建Prometheus.ServiceMonitor.AIertManager以及PrOmetheUSRUIe4个CRD资源对象，然后会一直监控并维持这4个资源对釜的状态.Prometheus:PrometheusDeployment定义ServiceMonitor:Prometheus监控对象的定义Alertmanager:AlertmanagerDeployment定义PrometheusRuIe:告警规则这样,我们在集群中监控数据就变成了亘接去操作KUberneteS集群的资源对象，方便很多了.一个ServiceMonitor可以通过IabeISeIector的方式去匹配一类Service,Prometheus也可以通过IabeISeIector去匹配多个ServiceMonitor.(2)PrometheusServerPrometheusServer是Prometheus组件中的核心部分，负责实现对监控数据的获取，存储以及查询.PrometheusServer可以通过静态配营管理监控目标，也可以配合使用ServiceDiscovery的方式动态管理监控目标，并从这些监控目标中获取数据.其次PrometheusServer需要对采集到的监控数据进行存储，其本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中.PrometheusServer对外提供了自定义的PromQ1.语言，实现对数据的查询以及分析.PrometheusServer内置的ExpressBrowserUI,通过这个Ul可以直接通过PromQ1.实现数据的直询以及可视化.PrometheusServer的联邦集群能力可以使其从其他的PrometheusServer实例中获取数据，因此在大规模监控的情况下,可以通过联邦集群以及功能分区的方式对PrometheusSerVer进行扩展.Prometheus支持两种类型的规则：记录规则和警报规则.要在Prometheus中包含规则，需要创建一个包含必要规则语句的文件，并让Prometheus通过Prometheus配置文件中的rule.fiIes字段加载规则文件.Recordingrules（记录规则）Recordingrules可以预先计算经常需要或计算量大的表达式，并将其结果保存为一组新的时间序列.这样，面询预先计算的结果通常比每次需要原始表达式查询要快得多.这对于dashboards特别有用,dashboards每次刷新时都需要里复音询相同的表达式.Alertingrules（告警规则）告警规则可以基于Prometheus表达式定义警报条件，并将有关触发告警的通知发送到外部服务。每当告警表达式在给定时间点生成一个或多个向量元素时，警报将计为这些元素的标签集的活动状态.并且Prometheus提供了多种服务发现方式：azure_sd_configsconsul_sd_configsdns_sd_configsec2_sd_configsopenstack_sd_configsfile_sd_configskubernetes_sd_configsmarathon_sd_configsnerve_sd_configsSerVerSet_Sd_ConfigStriton_sd_configs(3)PushGateway由于PrometheUS数据采集基于PUII模型进行设计，因此在网络环境的配首上必须要让PrometheUSSerVer能缪直接与EXPorter进行通信.当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中.而PrometheusServer则可以采用同样Pull的方式从PushGateway中获取到监控数据。(4)ExportersExporter将监控数据采集的端点通过HTTP服务的形式寒3S给PrometheusServer,PrometheusServer通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。一般来说可以将Exporter分为2类：亘接采集：这一类Exporter直接内苒了对Prometheus监控的支持，比如cAdvisor,Kubernetes,Etcd等，都宜接内置了用于向Prometheus易露监控数据的端点.间接采集：间接采集,原有监控目标并不再接支持Prometheus,因此我们需要通过Prometheus提供的Qient1.ibrary编写该监控目标的监控采集程序.例如:MysqlExporter,JMXExporter,BlackboxExporter等。（5）AIertManager在PrometheusServer中支持基于PromQ1.创建告警规则，如果满足PromQ1.定义的规则，则会产生一条告警，而告警的后续处理流程则由AIertManager进行管理.在AIertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式.AIertManager即Prometheus体系中的告警处理中心.主要处理流程： 接收到Alert,根据labels判断属于哪些Route（可存在多个Route,一个Route有多个Group,一个Group有多个Alert）. 将Alert分配到Group中，没有则新建Group. 新的Group等待group.wait指定的时间（等待时可能收到同一Group的Alert）,根据resolve,timeout判断Alert是否解决，然后发送通知. 已有的Group等待gropjnterval指定的时间，判断Alert是否解决,当上次发送通知到现在的间隔大于repeat-interval或者GroUP有更新时会发送通知.alert工作流程：一旦这些警报存储在Alertmanager,它们可能处于以下任何状态：inactive:表示当前报警信息既不是firing状态也不是pending状态.Pending:表示在设置的阈值时间范围内被激活了.firing:表示超过设置的阈值时间被激活了.AlrfIfnanaRte*t*12"SX）te1EXZ-.,ivtm*no4*atwMmMM.io.KMtF«no«*HedvO2*jctowfemc<we«11r*mt>X4av*9Cc4w*COm<7*MMrr9rIwuqvtorwtMaQDaWwrM.<MM*knMCf*a*M*U2MX>lB-n2S/Zf*'11l"WcFeQ"km*w、,Q.、,B,y¾*rEMr<FarX91«,G«aMa>*ftn<mj.4*0*m4MsI228-S6J01B-nJ/TMf*rMT<><rw>«（>9）*W-ff11<Efrw*CeUrKtMte*metW*U.KtevrwCMo.rt*njM*在这个页面中可以进行一些操作，比如过速*分组等等，里面还有两个新的概念：InhibitiOn（抑制）和SiIenCeS（静默）.Inhibition:如果某些其他警报已经触发了，则对于某些警报，Inhibition是一个抑制通知的概念.例如：一个警报已经触发，它正在通知整个集群是不可达的时，Alertmanager则可以配首成关心这个集群的其他警报无效.这可以防止与实际问题无关的数百或数千个触发警报的通知，Inhibition需要通过上面的配置文件进行配置.Silences:静默是一个非常简单的方法，可以在给定时间内简单地忽略所有警报.Silences基于matchers配置,类似路由树.来到的警告将会被枪直，判断它们是否和活跃的SiIenCeS相等或者正则表达式匹配.如果匹配成功，则不会将这些警报发送给接收者.4.5数据可视化(1)WebConsolePrometheus自带了WebConsole,安装成功后可以访问http:/localhost:9090/graph页面,用它可以进行任何PromQ1.查询和调试工作，非常方便，例如：alters可以查看当前报警的状态StatU$->rules可以查看配置的报警规则StatUS->targets可以查看配舌的job及状态通过上图不难发现，Prometheus自带的Web界面比较简单，因为它的目的是为了及时查询数据，方便PromeQl调试.(2)Grafanagrafana主要用于大规模指标数据的可视化展现，是网络架构和应用分析中最流行的时序数据展示工具，目前已经支持绝大部分常用的时序数据库.Grafana支持许多不同的数据源，每个数据源都有一个特定的直询编辑器，该编辑器定制的特性和功能是公开的特定数据来源,官方支持以下数据源：Graphite.Elasticsearch,InfIuxDB.Prometheus,Cloudwatch.MySQ1.lOpenTSDB等.进入到Grafana的界面中，默认情况下使用账户admin/admin进行登录.在Grafana首页中显示默认的使用向导包括安装、添加数据源、创建DaShboard、邀请成员、以及安装应用和插件等主要流程.这里将添加Prometheus作为默认的数据源，如下图所示，指定数据源类型为Prometheus并且设置Prometheus的访问地址即可，在配笆正确的情况下点击"Add"按钮，会提示连接成功的信息:AdddatasourceCcWDmhMMOtMmwFrom<hm0ut?Frc11we*e.HTTPsettingsU<C¢7XJihM1.W0AaBdkeOHnPAU5igQWW»CWMrWO在完成数据源的添加之后就可以在Grafana中创建我们可视化Dashboard了.Grafana提供了对PromQ1.的完整支持，如下所示，通过Grafana添加DaShboard并且为该DaShboard添加一个类型为"Graph”的面板.并在该面板的"Metrics"选项下通过PrOmQ1.查询需要可视化的数据：点击界面中的保存选项，就创建了我们的可视化Dashboard了.当然作为开源软件，Grafana社区鼓用户通过Dashboard,可以找到大量可直接使用的DaShboard:DashboardsOffkial&communitybuiltdahboardi1Note(Jom<fe<PiOMhMMDmMom4EiIQlbhVmiMUPDATE1102.IM.*F一二。二二二-1NoteEs*<motfoePtoMlhMnOmMom*fnqihUMwUPOATl1102«*AMmIMl1NotelonttfofPtomOwutgt4VmtenUPOATl1102CIr.-IBIr一.Q.一1Motfe*ProaeOmnDm1*oWCNgUiftMmtenUPOATt11020Il'"wr.Mmm-1m-*Grafana中所有的DaShboard通过JSON进行共享，下载并且导入这些JSON文件，就可以直接使用这些已经定义好的Dashboard.4.6高可用设计4.6.1 存储Prometheus内置了一个基于本地存储的时间序列数据库。在Prometheus设计上,使用本地存储可以降低Prometheus部署和管理的复杂度同时减少高可用(HA)带来的复杂性.在默认情况下，用户只需要部署多套Prometheus,采集相同的Targets即可实现基本的HA.同时由于Promethus高效的数据处理能力,单个PrometheusServer基本上能够应对大部分用户监控规模的需求.(1)本地存储通过Prometheus自带的tsdb(时序数据库)，将数据保存到本地磁盘，为了性能考虑,建议使用SSD.PrOmetheUS本地存储经过多年改进启Prometheus2.0后提供的V3版本tsdb性能已经非常高.本地存储也带来了一些不好的地方，首先就是数据持久化的问题，特别是在像KUbemeteS这样的动态集群环境下，如果Promthues的实例被函新调度，那所有历史监控数据都会丢失.其次本地存储也意味着Prometheus不适合保存大量历史数据(一股Prometheus推荐只保留几周或者几个月的数据).最后本地存储也导致Prometheus无法进行弹性扩展。为了适应这方面的需求，Prometheus提供了remote.Write和remote,ead的特性，支持将数据存储到远端和从远端读取数据,通过将监控与数据分离，Prometheus能够更好地进行弹性扩展.(2)远端存储Prometheus提供了remote_write和remote_read的特性，支持将数据存储到远端和从远端读取数据.通过将监控样本采集和数据存储分离，解决Prometheus的持久化问题，适用于大量历史监控数据的存储和查询。目前，远端存储主要包ISOpenTSDB,InfIuxDB,ElasticsearchxM3db等.RemoteWrite:用户可以在Prometheus配置文件中指定RemoteWrite(远程写)的UR1.地址，一旦设置了该配三项，Prometheus将采集到的样本数据通过HTTP的形式发送给适配器(AdaPtOr).而用户则可以在适配器中对接外部任意的服务。外部服务可以是真正的存储系统，公有云的存储服务，也可以是消息队列等任意形式.w11tampcustomprotocolPrtxnelheui.AdaptorRemoteRead:Promthues的RemoteRead(远程读)也通过了一个适配器实现。在远程读的流程当中，当用户发起直询请求后，Promthues将向remote.read中配首的UR1.发起查询请求(matchers,ranges),Adaptor根据请求条件从第三方存储服务中获取响应的数据.同时将数据转换为Promthues的原始样本数据返回给PrometheusServer.当获取到样本数据后，Promthues在本地使用PromQ1.对样本数据进行二次处理.(注意:启用远程读设者后，只在数据直询时有效对于规则文件的处理以及MetadataAPI的处理都只基于Prometheus本地存储完成.)r*QUMtmMcM.tmrangescustomprotocol-f.Prom<hAdaptor.R9pon:MhM.MmplM通过远端存储可以分离监控样本采集和数据存储，解决PrometheUS的持久化问题.4.6.2 Prometheus高可用(1)服务高可用Promtheus以pull方式设计，通过主动发起的方式采集监控Metrics.Prometheus内苣了一个基于本地存储机制的时间序列数据库TSDB,使用本地存储的方式降低了部署和管理Prometheus的红杂度。为了保证Promtheus服务的可用性，用户只需要部署多套PrometheusServer实例，先通过Ngin×HAProXy接收请求，然后通过Prometheus采集相同的Exporter目标，就可以实现基本的高可用.(2)数据一致性PUIl模式下，同一个服务至少需要两个Prometheus节点同时拉取监控数据.这种情况下，就需要解决多个PrometheusServer实例之间的数据一致性问题.解决方案：采用Prometheus的协助方案Thanos4同机部署ThanosSidecar与Prometheus,ThanosQuery调用三i询的载体SideCar,Sidecar与Prometheus进行交互，获取Metrics并去*,来保证数据一致性。Thanos是CNCF孵化项目,目前;欠有出稳定发行版,未来可能是Prometheus高可用官方解决方案，还需继续关注(3)水平可扩展当单台PromthuesSerVer无法处理大星的采集任务时，通过联邦集群的特性对PrOmetheUS采集任务按照功能分区，对Promthues进行扩展，以适应规模的变化.(4)数据持久化Prometheus的本地存储设计能够满足大部分监控规模的需求，但是本地存储无法存储大量历史数据，存在数据持久化问题.Prometheus允许用户通过接口将数据保存到第三方数据库中，这种方式在Promthues中称为远程存储。（一）基本HA基本HA可以保证服务的高可用，无法长期存储历史数据。监控系统关注一段时间某个监控指标是否达到告警状态，多个PrometheusSerVer之间监控指标数据细微的差别，为Promethues是否产生告警通知影响很小，所以基本HA架构可以满足一般的监控场空.（二）基本HA+远程存储在基本HA保证Promthues服务可用性的基础上，通过添加远程存储支持，确保了数据的持久化.基本HA和远程存储的方案适合要求