1。相关背景待在工作岗位上，总得做点事，想做点新鲜事。但不代表你想做就有机会做，并且做好。无论是单独做还是与他人一起做，最终的结果都是不同的。这是关于时机，以及是否每个人都能就动机达成一致。今年是降本增效的一年。许多公司都在裁员，减少配置，降低成本。因此，需要对整个在线服务的负载情况进行汇总，细化监控数据。为了符合规定，海外服务的结构是分区的，数据以去中心化的方式进行管理。过去很难想象数据可以中心化。但是这个需求现在有了解决方案。在一些内部系统中，目前的监控系统无法通过编程方式集成，无法通过规则拼接URL来展示监控相关数据。对于终端用户来说，监控可以匹配业务形态，可以快速找到业务相关的监控数据，给业务带来极大的便利。不管公司预期的背景还是自身的标准化需求，这都是一件水到渠成的事情，可以尝试推动。2.海外服务拓扑对于海外服务，我们需要根据业务发展战略选择区域部署服务。例如，如果你打算在欧洲开展业务，你需要选择该地区华为、AWS等云工厂提供的云服务作为你的基础设施。对于全球业务，需要在新加坡、日本、印度、美国西部等多个地区建立服务节点。由于各地区的数据保护规定，不允许将本地数据传输到其他地区，因此数据和服务只能本地化。每个region是一个独立的单元对外提供服务，有独立的数据存储、K8s集群、API网关等，这种分区的服务拓扑会给运维带来很大的挑战，需要在每个zone中一一更改.在面向全球的镜像分发网络[1]一文中，我描述了一个跨地域搭建的全球运维网络。如下图所示：基于公网，可以通过StrongVPN、WireGuard等软件搭建企业内网，实现一个中心区域对整个区域的控制。这个控制包括全区的应用发布、流量控制、镜像分发、监控告警等。在打通全区内网后，我们再从基础资源监控、Kubernetes监控、业务数据监控。其中基础资源和Kubernetes属于短期监控数据，业务数据属于长期监控数据。对于短期的监控数据，需要填写足够的标签，方便业务人员过滤查询，使用Prometheus进行监控。针对长周期监控数据，采用Thanos方案，避免Prometheus查询长周期数据时云主机宕机。3.基础监控每个区域只有一台Prometheus拉取所有基础资源的监控数据，包括云主机、Redis、MySQL等中间件。直接进入Prometheus的配置：cat/etc/prometheus/prometheus.yml-job_name:"node_exporter"file_sd_configs:-refresh_interval:1mfiles:-"/etc/prometheus/file_sd/node*.yml"-job_name:'mongo_exporter'file_sd_configs：-refresh_interval：1m文件：-“/etc/prometheus/file_sd/mongo*.yml”-job_name：'elasticsearch_exporter'file_sd_configs：-refresh_interval：1m文件：-“/etc/prometheus/file_sd/es*.yml"passedfile_sd_configs指定Prometheus自动发现服务的目录，通过refresh_interval指定Prometheus重新加载配置文件的周期。当有新的服务需要监控时，只需要修改该类型的资源列表即可。我们看一下资源列表的定义：cat/etc/prometheus/file_sd/node-prod.yml-labels:region:"region-a"team_id:123host_name:"a-b-c"host_ip:"0.0.0.0"targets:-0.0.0.0:9100如下图，每个zone一个Prometheus拉取监控数据，在中心区域通过ThanosQuery聚合所有监控数据，提供整个zone的监控数据查询能力。最后需要在Grafana上呈现两个面板，一个是资源摘要，一个是资源详情。下图为基础资源汇总面板：通过汇总面板，我们可以知道指定区域内有多少资源，以及每个资源的负载情况。通过ThanosQuery汇总数据源，可以了解整个小区的资源概况。4.Kubernetes监控对于Kubernetes监控，我们采用的部署策略是在每个集群中安装一个Prometheus，只存储3d数据，不做持久化。在每个区域部署一个ThanosQuery来聚合所有Kubernetes监控数据。下图为相关拓扑图：根据社区的PrometheusHelmChart包，我们添加了ThanosSidecar，重新打包，推送到内部Habor镜像仓库。添加新集群时，只需要两步：installPrometheusexportHELM_EXPERIMENTAL_OCI=1helmchartpullharbor.chenshaowen.com/monitor/prometheus:15.0.1helmchartexportharbor.chenshaowen.com/monitor/prometheus:15.0.1cdprometheuskubectlcreatensmonitorhelm-nmonitorinstallprom-k8s--setserver.global.external_labels.cluster=cluster-1--setserver.global.external_labels.region=region-1。这里需要注意的是，每个Kubernetes集群的名称都是唯一的。ThanosQuery中添加查询API，请参考之前的文档使用Thanos集中管理多个Prometheus实例的数据[2]。在Grafana面板上，我们提供了两个层次的视角：分区和整个区域的数据源，以及summary和detail面板。下图是其中一个汇总面板：5.业务数据监控业务数据主要是业务本身上报和关注的数据，比如用户登录、下单、支付等，这类数据是异构的，不能被统一管理。我们提供统一的解决方案和Grafana服务，业务可以自己画。这里使用的是Thanos方案，参考：Thanos高级用户指南[3]。下面是部署拓扑图：下面是长期数据的查询：6.小结本文主要介绍近期的一些工作。针对海外多区域场景，我们将监控分为三层，基础监控、Kubernetes监控、业务监控数据。其中，基础监控包括云主机、Redis中间件等，而Kubernetes主要面向应用，业务数据属于业务关系的上报数据。针对这三个层次的划分，提供了三种部署方案，以满足业务对监控和查询的需求。参考资料[1]全球图片分发网：https://www.chenshaowen.com/blog/a-global-images-distribution-network.html[2]使用Thanos集中管理多个Prometheus实例数据：https://www.chenshaowen.com/blog/manage-multiple-prometheus-using-thanos.html[3]Thanos高级用户指南：https://www.chenshaowen.com/blog/an-advanced-user-guide-about-thanos。网页格式
