集群容量概述直到今年1月，我一直在使用企业级监控解决方案来监控Kubernetes集群，它也用于APM。使用起来感觉很自然，只需稍加调整就可以很容易地与Kubernetes集成，并且可以集成APM和基础架构指标。虽然此监控解决方案可以轻松收集和存储数据，但使用指标创建警报具有很大的查询限制。我们收到的警报通常与仪表板上显示的不同。更不用说我们有6个集群，收集和存储的指标数量巨大，在很大程度上增加了我们的经济成本。经过一番考虑，我们意识到继续使用这种监控解决方案弊大于利。是时候更换我们的监控解决方案了！但是使用什么产品或工具呢？Grafana是可视化工具的最佳选择，但是我们的“后端”需要具备弹性的可扩展性和高可用性。我们应该使用什么工具？使用OpenTSDB纯粹需要太多的工作和精力来安装；单机Prometheus不提供复制能力，需要配备多个数据库；TimeScaleDB看起来不错，但我不太擅长使用PostgreSQL。在尝试了上面的一些解决方案后，我查看了CNCF网站，终于找到了Thanos！它满足了我们所有的需求：数据长期保留、可复制、高可用、适用于微服务、拥有使用同一个数据库的所有集群的全局视图！架构我们的集群上没有可用的持久存储（所有服务都保持无状态），因此默认的Prometheus+Thanossidecar方法不可用，并且度量存储必须放在集群外部。此外，集群彼此隔离，不可能将Thanos组件绑定到一组特定的集群，并且必须从“外部”监控集群。综上所述，考虑到高可用和Thanos在虚拟机上运行的可能性，我们最终的架构如下：如图所示，我们有一个多数据中心的架构。这些中心中的每一个都有一组Grafana+查询服务器、一组存储服务器和三个接收服务器（集群数量的一半）。Grafana使用的数据库也有AWSRDS。这个数据库不必很大（以降低成本），我们的团队也不需要管理MySQL。在Thanos提供的所有组件中，我们实现了其中4个：接收：负责TSDB，还管理所有运行接收和TSBD块上传到S3的服务器之间的复制。查询：负责查询接收数据库。Store：读取S3以获取不再存储在receive中的长期指标。Compactor：管理存储在S3中的TSDB块的数据下采样和压缩。所有DataIngestion集群的数据摄取由集群内运行的专用PrometheusPod管理。它从控制板（API服务器、控制器和调度程序）、etcd集群和集群内的pod收集指标，其中包含与基础设施和Kubernetes本身相关的指标（Kube-proxy、Kubelet、NodeExporter、StateMetrics、MetricsServer、和其他带有抓取注释的Pod）。PrometheusPod然后将信息发送到其中一个接收服务器，该服务器使用远程存储配置管理TSDB。数据摄取所有数据都被发送到单个服务器，然后复制到其他服务器。Prometheus使用的DNS地址是一个DNSGSLB，它探测每个接收服务器并在健康服务器之间平衡DNS解析，在所有服务器之间分担负载，因为DNS解析只为每个DNS查询提供一个IP。应该强调的是，数据必须发送到单个接收实例并让它管理复制，发送相同的指标将导致复制失败和行为不端。在此级别，指标也会上传到S3存储桶以供长期保留。Receive每2小时（当每个TSDB块关闭时）上传一个块，这些指标可用于使用Store组件进行查询。您还可以设置本地数据的保留时间。在这种情况下，所有本地数据都会保留30天，以供日常使用和故障排除，从而加快查询速度。超过30天的数据仅在S3上可用，并且最多保留1年以供长期评估和比较。数据查询数据被收集并存储在接收器中以供查询。这部分也设置为在多个数据中心可用。对于每台运行Grafana和Query的服务器，如果其中一台（或两台）出现故障，我们可以更轻松地识别并将其从负载均衡器中移除。在Grafana中，数据源配置为localhost，所以总是使用本地Query来获取数据。对于查询配置，它必须知道存储指标的所有服务器（Receiver和Store）。查询组件知道哪些服务器在线并且可以从它们收集指标。数据查询它还管理重复数据删除，因为它查询所有服务器和配置的复制，所有指标都有多个副本。这可以使用分配给指标和查询参数的标签（--query.replica-label=QUERY.REPLICA-LABEL）来完成。通过这些配置，查询组件知道从Receiver和Store收集的指标是否重复并且仅使用一个数据点。长期数据如前所述，数据最多在本地保存30天，其他所有内容都存储在S3上。这减少了Receiver上所需的空间量并降低了成本，因为块存储比对象存储更昂贵。更不用说查询超过30天的数据并不是很常见，主要用于资源使用历史和预测。远程数据查询TheStore还为存储在S3存储桶上的每个TSDB块保留索引的本地副本，因此如果它需要查询超过30天的数据，它知道要下载哪些块并使用哪些块来提供数据。数据情况考虑了所有集群。本监控方案：监控6个Kubernetes集群；收集670个服务的指标；使用NodeExporter监控246台服务器；每分钟收集约27w个指标；每天摄取约7.3GB的数据，或每月摄取约226.3GB的数据；为Kubernetes组件创建了40个专用仪表板；在Grafana上创建了116个警报。对于月费，由于大部分组件在本地运行，成本降低了90.61%，从每月38,421.25美元降至3,608.99美元，其中包括AWS服务成本。总结配置和设置上述架构花了大约一个月左右的时间，包括测试一些其他解决方案、验证架构、实施、在集群上打开收集以及创建所有仪表板。在第一周，好处是显而易见的。监控集群变得更加容易，可以快速构建和自定义仪表板，收集指标几乎是即插即用的，大多数应用程序以Prometheus格式导出指标并根据注释自动收集。另外，通过集成Grafana的LDAP可以实现更细粒度的团队权限控制。开发人员和SRE可以访问大量仪表板，其中包含有关其命名空间、入口等的相关指标。
