监控基础与指标收集全解析

### 监控基础与Prometheus指标采集方法解析 #### 1. 彩色图像下载 可通过链接 [https://www.packtpub.com/sites/default/files/downloads/9781789612349_ColorImages.pdf](https://www.packtpub.com/sites/default/files/downloads/9781789612349_ColorImages.pdf) 下载包含书中截图和图表彩色图像的PDF文件。 #### 2. 文本约定 - **CodeInText**：用于表示文本中的代码词汇、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟URL、用户输入和Twitter句柄。例如："Now, you can run vagrant status." - **代码块**：设置如下 ``` annotations: description: "Node exporter {{ .Labels.instance }} is down." link: "https://example.com" ``` - **突出显示代码**：当需要突出代码块的特定部分时，相关行或项会以粗体显示 ``` annotations: description: "Node exporter {{ .Labels.instance }} is down." link: "https://example.com" ``` - **命令行输入或输出**：写法如下 ``` vagrant up ``` - **粗体**：表示新术语、重要单词或屏幕上看到的单词。例如："You can find this page by going into Status | Rules on the top bar." #### 3. 联系我们 - **一般反馈**：若对任何方面有疑问，在邮件主题中提及相关内容，并发送至 [email protected]。 - **勘误**：若发现错误，请访问 [www.packt.com/submit-errata](www.packt.com/submit-errata)，选择相关内容，点击“Errata Submission Form”链接并输入详细信息。 - **盗版问题**：若在互联网上发现非法副本，请提供位置地址或网站名称，联系 [email protected] 并附上材料链接。 - **成为作者**：若在某主题有专业知识且有意写作或参与创作，请访问 authors.packtpub.com。 #### 4. 留下评价 阅读和使用相关内容后，建议在购买处留下评价，这有助于潜在读者决策，也能让相关方了解看法。 #### 5. 监控基础概述 监控基础部分涵盖以下几个关键方面： - **监控的定义** - 由于行业和工作特定背景不同，难以达成统一的监控定义。观点的多样性、监控系统的组成部分以及数据的收集和使用方式，都增加了明确定义的难度。 - 随着基础设施复杂度的增加，监控变得至关重要。它能跟踪基础设施组件的数据，用于警报、容量规划、事件调查等多种目的。 - **监控的价值** - 随着基础设施复杂度的增加，尤其是微服务架构的广泛应用，获取基础设施各组件的全局视图变得至关重要。手动验证每个实例、缓存服务、数据库或负载均衡器的健康状况是不现实的。 - 监控可以跟踪这些组件的数据，这些数据有多种形式，可用于不同目的。例如，警报是监控数据的常见用途，但还可以用于容量规划、事件调查等。 - **组织背景下的监控需求** | 角色 | 数据分辨率 | 数据延迟 | 数据多样性 | | ---- | ---- | ---- | ---- | | 系统管理员 | 高 | 低 | 高 | | 质量保证工程师 | 高 | 高 | 高 | | 专注于容量规划的SRE | 低 | 高 | 高 | | 产品所有者 | 低 | 高 | 低 | - **监控组件** - **指标**：以特定时间点的值展示系统资源、应用程序操作或业务特征，信息以聚合形式获取。 - **日志**：包含比指标更多的数据，表现为系统或应用程序的事件，包含事件产生的所有信息，未聚合且有完整上下文。 - **追踪**：日志的特殊情况，为请求分配唯一标识符，以便在整个生命周期内跨系统跟踪，但由于数据集随请求数量增加，建议使用样本而非跟踪所有请求。 - **警报**：持续验证指标或日志的阈值，超出阈值时触发操作或通知。 - **可视化**：以图形方式表示指标、日志或追踪。 #### 6. 白盒与黑盒监控 监控方式主要分为黑盒和白盒监控： - **黑盒监控**：从外部观察应用程序或主机，检查系统是否以已知方式响应探测，如主机是否响应ICMP回显请求、TCP端口是否开放、应用程序是否对特定HTTP请求做出正确响应、特定应用程序进程是否在主机上运行。 - **白盒监控**：被监控系统暴露其内部状态和关键部分的性能数据，可通过以下方式处理遥测数据： - **通过日志导出**：在仪表化库广泛使用之前，应用程序常用此方式暴露内部工作情况，如处理HTTP服务器的访问日志来监控请求速率、延迟和错误百分比。 - **作为结构化事件发出**：类似于日志，但数据直接发送到处理系统进行分析和聚合。 - **作为聚合信息保存在内存中**：数据可托管在端点或直接从命令行工具读取，如Prometheus指标的 /metrics、HAProxy的统计页面或varnishstats命令行工具。 #### 7. 指标收集方法 指标收集主要有推（Push）和拉（Pull）两种方法： - **推式监控系统**：发出的指标或事件直接从产生应用程序或本地代理发送到收集服务。适用于处理原始事件数据的系统，因为事件生成频率高，轮询数据不切实际且复杂。例如Riemann、StatsD、ELK堆栈等。 - **拉式监控系统**：直接从应用程序或代理进程收集指标。如Nagios及类似系统（Icinga、Zabbix、Zenoss和Sensu等），Prometheus也采用拉式方法。 ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px A(应用程序/本地代理):::process -->|推送指标| B(收集服务):::process C(监控系统):::process -->|拉取指标| D(应用程序/代理进程):::process ``` - **推与拉的比较** - **推式系统**：优点是无需事先了解新系统即可收集数据，但需将监控服务位置传播到所有目标，且存在数据陈旧问题，管理分布式主机和服务时，还可能面临过载和数据洪流风险。 - **拉式系统**：需要明确的监控目标列表，有中央真实源保证数据位置，但需维护和更新该列表。不过，集中配置在出现问题或配置错误时能更快响应。 - 多数缺点可通过巧妙设计和自动化减少或解决。选择监控工具时，还需考虑灵活性、自动化难易程度、可维护性以及对所用技术的广泛支持等因素。Prometheus虽为拉式系统，但也可通过网关将推式指标转换为拉式指标进行收集。 #### 8. 指标选择 规划指标收集时，需确定要观察的指标，可参考当前最佳实践和方法，以减少噪音并提高性能和可靠性的可见性。 ### 监控基础与Prometheus指标采集方法解析 #### 9. 监控需求的组织差异分析 不同组织角色对监控数据有着不同的需求，这主要体现在数据分辨率、数据延迟和数据多样性三个方面，具体如下： - **系统管理员**：他们需要高分辨率、低延迟和高多样性的数据。高分辨率的数据能让他们深入了解系统的具体状况，低延迟确保能及时发现问题，而高多样性的数据则有助于全面掌握基础设施的各个方面。例如，他们需要监控CPU的使用情况，以及HTTP请求的速率等，以便快速发现问题并确定根本原因。 - **质量保证工程师**：同样需要高分辨率和高多样性的数据，但对数据延迟的要求相对较低。他们更关注历史数据，用于比较软件版本之间的差异，以评估软件发布的质量。 - **专注于容量规划的SRE**：低分辨率、高延迟和高多样性的数据对他们更有价值。历史数据能帮助他们预测基础设施的增长需求，如节点数量、存储容量和网络带宽等。 - **产品所有者**：通常只需要低分辨率、高延迟和低多样性的数据，主要关注业务指标，以了解特定软件产品的趋势和评估软件发布对客户的影响。 | 角色 | 数据分辨率 | 数据延迟 | 数据多样性 | | ---- | ---- | ---- | ---- | | 系统管理员 | 高 | 低 | 高 | | 质量保证工程师 | 高 | 高 | 高 | | 专注于容量规划的SRE | 低 | 高 | 高 | | 产品所有者 | 低 | 高 | 低 | #### 10. 监控组件的详细作用 监控系统包含多个组件，每个组件都有其独特的作用： - **指标**：指标是对系统资源、应用程序操作或业务特征的量化表示，以特定时间点的值呈现。它以聚合形式提供信息，例如每秒处理的请求数量，但不包含单个请求的详细时间或ID。 - **日志**：日志记录了系统或应用程序中发生的事件，包含了事件的所有详细信息，且未经过聚合，具有完整的上下文。通过分析日志，可以深入了解系统的运行状态和问题。 - **追踪**：追踪是日志的一种特殊形式，为每个请求分配一个唯一的标识符，以便在整个系统中跟踪请求的生命周期。由于追踪会产生大量数据，通常采用抽样的方式进行。 - **警报**：警报机制会持续监控指标或日志，当它们超过预设的阈值时，会触发相应的操作或通知，以便及时处理问题。 - **可视化**：可视化组件将指标、日志或追踪数据以图形的方式展示出来，使监控数据更加直观易懂，帮助用户快速理解系统的状态。 #### 11. 白盒与黑盒监控的适用场景 白盒和黑盒监控各有其适用场景： - **黑盒监控**：适用于无法访问系统内部状态的情况，例如第三方应用程序或需要从客户端角度验证应用程序的情况。它通过外部探测来检查系统的可用性和响应能力。 - **适用场景**： - 验证第三方应用程序的可用性。 - 从客户端角度检查应用程序的响应情况。 - 作为最后的防线，在其他监控方法失效时使用。 - **白盒监控**：适用于需要深入了解系统内部状态和性能的情况。它通过系统内部的仪表化来暴露关键信息，帮助用户更好地理解系统的运行状况。 - **适用场景**： - 分析系统的性能瓶颈。 - 监控关键组件的健康状况。 - 进行详细的故障排查。 #### 12. 推式与拉式指标收集的操作流程 推式和拉式是两种常见的指标收集方法，它们的操作流程有所不同： - **推式指标收集**： 1. 应用程序或本地代理生成指标或事件。 2. 这些指标或事件被直接发送到收集服务。 3. 收集服务接收并处理这些数据。 ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px A(应用程序/本地代理):::process -->|生成指标/事件| B(发送指标/事件):::process B -->|推送到| C(收集服务):::process ``` - **拉式指标收集**： 1. 监控系统维护一个需要监控的主机和服务列表。 2. 监控系统定期从这些主机和服务中拉取指标。 3. 主机和服务将指标提供给监控系统。 ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px A(监控系统):::process -->|维护监控列表| B(拉取指标):::process B -->|从| C(主机/服务):::process C -->|提供指标| A ``` #### 13. 推式与拉式指标收集的优缺点对比 推式和拉式指标收集方法各有优缺点，在选择时需要综合考虑多个因素： | 指标收集方法 | 优点 | 缺点 | | ---- | ---- | ---- | | 推式 | 无需事先了解新系统，能及时收集数据 | 需要传播监控服务位置，存在数据陈旧问题，可能导致过载 | | 拉式 | 有中央真实源，便于管理和配置 | 需要维护监控列表，更新不及时可能导致数据缺失 | #### 14. Prometheus对不同指标收集方式的处理 Prometheus是一个基于拉式的监控系统，但也支持推式指标的收集： - **拉式收集**：Prometheus通过定期从目标端点拉取指标来收集数据。它会按照配置的时间间隔，向目标发送HTTP请求，获取指标数据。 - **推式指标处理**：对于推式指标，Prometheus提供了一个网关，将推式指标转换为拉式指标。具体操作步骤如下： 1. 配置Prometheus网关，指定网关的地址和端口。 2. 应用程序或代理将指标推送到Prometheus网关。 3. Prometheus从网关拉取指标数据。 #### 15. 指标选择的重要性及方法 在进行指标收集时，选择合适的指标至关重要。正确的指标选择可以减少噪音，提高性能和可靠性的可见性。以下是一些选择指标的方法： - **基于业务需求**：根据业务目标和关键绩效指标（KPI）来选择相关的指标。 - **参考最佳实践**：借鉴行业内的最佳实践和经验，选择被广泛认可的指标。 - **关注关键组件**：监控系统中的关键组件，如CPU、内存、磁盘和网络等。 - **进行实验和验证**：通过实验和验证，确定哪些指标对业务和系统的监控最有价值。 通过合理选择指标，可以确保监控系统提供有价值的信息，帮助用户更好地管理和优化系统。