在这个版本的KubernetesLearnings系列（早期的博客，网站用云服务器，这里和这里）中，我们讨论了如何为Kubernetes集群配置可观测性，并使其与我们现有的可观测性设置共存。为了说明规模，在美国东部地区，对于一个应用程序（不包括其他从属服务），我们有：大约5000个集装箱，每月约2000亿个指标，基数约为500万，以及每天大约7.5 TB日志。我们的pre-Kubernetes基础设施（基于AWS OpsWorks）已经有了一个度量/日志记录设置：指标：InfluxDB+Telegrafa、 我们在所有的应用程序中都有特使sidecar，它以statsd格式发布所有的入口/出口指标b、 EC2+容器度量由Telegraf守护进程收集/发布c、 我们还从AWS CloudWatch中提取了一些指标d、 我们有Grafana仪表盘来可视化这些指标e、 警报是使用基于Tick脚本的设置完成的日志记录：使用ElasticSearch生成的自定义解决方案a、 已摄取所有应用程序和容器日志b、 所有EC2系统服务日志也通过同一管道摄取c、 我们为所有这些日志配置了日志轮换/保留（上传到s3bucket等）内部中央团队将度量和日志记录作为单个服务提供/管理。它是为多租户和高可用性而构建的。此外，手游返利折扣，所有这些都贴有适当的标签：蓝色/绿色用于跟踪部署/发布期间的错误/性能Shell，这是我们的基本原语，它可以最小化爆炸半径并提高可用性，这是一种基于单元的体系结构的东西。基于我们现有的观测能力，我们的观测能力已经很好地配置好了。当我们搬到Kubernetes时，我们很早就做出了一个重要的决定，即这个配置需要继续正常工作。给定的炮弹是由OpsWorks还是Kubernetes提供动力，这只是一个内部细节，不应该一直暴露给工程师。做出这个决定后，我们提出了以下高层次的要求：能够保留现有的Kubernetes之前的高级原语，而不管使用的底层基础设施如何必须支持多个Kubernetes集群当我们将流量从OpsWorks逐渐转移到Kubernetes时，能够观察指标/日志记录把库伯内特斯当作一等公民对待的能力：所有带有普罗米修斯注解的容器都应该自动报废其他Kubernetes指标，如Pods/Deployments、EKS CNI和CoreDNS必须收集和/或提醒所有指标必须有适当的标记（shell、蓝色/绿色、集群名称、区域、可用区域等）。1建筑在制定了需求之后，我们提出了以下高层配置：1.1指标我们运行三种度量收集代理（又称Telegraf）。1在群集级别作为一个带有一个复制副本的部署。这将收集以下指标：通过kube状态度量的Kubernetes对象度量Kubernetes API服务器指标Pod普罗米修斯度量，51返利，通过普罗米修斯注释自动发现/废弃Kubernetes控制平面指标（来自API服务器，贵阳大数据，由EKS管理）某些AWS CloudWatch指标EKS子网的AWS服务级别配额（ENI使用率/阈值等）和IP可用性（通过Telegaf exec插件完成）2在每个节点上作为守护进程。这将收集以下指标：Kubelet的指标EC2指标（CPU、磁盘、网络、内存等）Docker度量许多特定于节点的自定义度量，外汇返现，如conntrack错误，用于检测诸如this和OOM kills之类的问题。（这些也是通过Telegaf exec插件完成的）三。在吊舱内作为侧车。这将收集以下指标：特使的Statsd指标（尚未移动到使用特使普罗米修斯终结点！）来自应用程序的多个Prometheus度量（请注意，一旦我们通过Prometheus注释公开所有这些度量，就可以取消这个度量了）1.2测井我们运行两种日志收集代理（基于filebeat的代理）：1每个节点中有一个守护进程。这将管理以下日志：EC2系统日志库贝莱原木容器日志（包括通过stdout/stderr发送的应用程序日志）日志轮换、保留、S3上传等。2在吊舱内作为侧车。这将管理以下日志：非结构化应用程序日志。我们的一些应用程序生成大量日志。从我们的实验来看，将它们记录到stdout并通过docker日志驱动程序进行摄取会导致较高的CPU使用率。所以我们决定不这么做。我们可以使用hostPath，然后配置守护进程来从该目录收集日志，但是这样我们就丢失了重要的标记。所以我们决定用侧车。日志轮换、保留、S3上传等。2部署我们的监控部署完全由使用Kustomize的GitOps模型管理。（我们稍后将在本系列文章中介绍我们的GitOps模型。）它看起来像下面这样（省略了非度量/日志相关项）。我们定义了一个基本的监视/日志记录设置。这是在我们操作的所有AWS区域中全局使用的，只覆盖他们想要的部分（比如度量发布端点等）。这样我们就有了一个一致的，同质的全球设置。部署/├—基........│这是基本日志记录设置│││├—filebeat││││├—filebeat-配置yml││││├—filebeat-守护程序.yaml│ │ │ └── kustomization.yaml公司│││├—filebeat-环境yaml│ │ ├── kustomization.yaml公司│ │ ├── 命名空间.yaml│││——服务-帐户.yaml│–├—监控=================>这是基本指标设置│││├—kube状态指标│ │ │ └── kustomization.yaml公司│ │ ├── kustomization.yaml公司│││├—telegraf公司-环境yaml│││├—节点=================>这是守护程序TELEGRAF（每个EC2机器一个）││││├———康特克_度量.sh│ │ │ ├── kustomization.yaml公司││││├-—telegraf公司-守护程序.yaml│ │ │ └── 电话会议│││├—服务======>这是TELEGRAF服务（整个EKS群集一个）││││├—aws_定制_度量.rb│ │ │ ├── kustomization.yaml公司││││├-—telegraf公司-部署.yaml│ │ │ └── 电话会议│││——服务-帐户.yaml│–├—安全性│││├——守门员│ │ └── kustomization.yaml公司│—壳牌│–├—bg│–├—前景│ ├── kustomization.yaml公司│ └── 电话会议这是SIDECAR TELEGRAF........├—生产│–├—ap-south-1........││││├-—日志记录=================>此继承自日志记录基│││││├—filebeat-环境yaml│ │ │ │ └── kustomization.yaml公司││││├-—监控==============>此继承自监控库│实验室│添加│实验室│-确认.yaml│ │ │ │ ├── kustomization.yaml公司│││││├-—telegraf公司-环境yaml│││││——redis-实验室.conf........│–├—ap-东南-2........││││├-—日志记录=================>此继承自日志记录基│││││├—filebeat-环境yaml│ │ │ │ └── kustomization.yaml公司││││├-—监控==============>此继承自监控库│││││├-—添加redis实验室-确认.yaml│ │ │ │ ├── kustomization.yaml公司│││││├-—telegraf公司-环境yaml│││││——redis-实验室.conf........│–├—欧盟中央1区........││││├-—日志记录=================>此继承自日志记录基│││││├—filebeat-环境yaml│ │ │ │ └── kustomization.yaml公司││││├-—监控==============>此继承自监控库│││││├-—添加redis实验室-确认.yaml│ │ │ │ ├── kustomization.yaml公司│││││├-—telegraf公司-环境yaml│││││——redis-实验室.conf........│——美国东部-1........│││├—日志记录=================>此项继承自日志记录基││││├—filebeat-环境yaml│ │ │ └── kustomization.yaml公司│││├——监控││││├—添加redis实验室-确认.yaml│ │ │ ├── kustomization.yaml公司││││├-—telegraf公司-环境yaml││││——redis-实验室.conf........├—分期........│││├—日志记录=================>此项继承自日志记录基││││├—filebeat-环境yaml│ │ │ └── kustomization.yaml公司│││├-—监控==============>此继承自监控库│ │ │ ├── kustomization.yaml公司││││└—telegraf公司-环境yaml........查看原始监控_部署.md由GitHub托管以下是我们的一些仪表板（随机挑选）：节点仪表板总体CPU、内存使用情况、按Pods划分的细分，还显示了容器限制（如果有的话）（我们尝试bin-pack/over-commit，因此关注这个指标非常重要）。仪表板的其他部分不显示在下面，但显示了其他类似的指标（网络、磁盘、OOM终止、页面错误、上下文切换等）。我们使用EKS-CNI作为Kubernetes CNI插件。所以跟踪这些指标的一些重要部分（比如子网中有多少IP可用）。我们在从OpsWorks迁移到Kubernetes时使用了这个仪表板（如下）。下图显示了美国东部地区的一个此类应用程序迁移。展望未来根据度量的数量，我们是g