装在笔记本里的私有云环境：监控篇

本篇是系列中的第二篇内容，我们继续聊聊如何把一个简化过的私有云环境部署在笔记本里，以满足低成本、低功耗、低延时的实验环境。

在上篇《准备篇》中，我们聊过了基础虚拟化相关的事情，在虚拟机环境准备就绪之后，在继续折腾容器集群之前，我们还需要做一些基础技术设施建设，监控就是其中比较重要的一个组成部分。

写在前面

说起监控，我相信许多时候，这是一个很容易被忽略或者被省略的部分。

尤其是在个人场景或者小公司或者团队，因为业务量小，不容易出问题，出了问题使出 “关机重启敲一敲” 的解决方案的也大有人在。在长久的工作过程中，我们都知道，没有监控最好的情况是无事发生，最糟糕的情况则是，问题发生了但是在早期没有被发现，随着时间推移，这个事情越来越严重，我们需要付出数倍的成本来解决问题。

Google SRE - Service Reliability Hierarchy

《Google SRE》 一书中提到的“服务可靠性金字塔”中的基石，同样也是监控。虽然我们很难达到 Google 业务的复杂度和量级，但是重视监控，以客观的数据事实来推动我们做相对正确的决策，还是值得每个人和团队去践行的。书中有一段比较形象的例子：

Without monitoring, you have no way to tell whether the service is even working; absent a thoughtfully designed monitoring infrastructure, you’re flying blind.

如果在搭建环境的早期，就规划设计了监控服务，那么在完善整体的过程中，便可以在有数据支撑的情况下，快速定位和判断哪些新增组件需要完善和调整，这样一来就避免了盲人摸象的状况发生。

监控选型

如果你的业务都“跑在云上”，那么监控选型的事情其实可以变的很简单。尤其是如果你没有定制需求，那么在你的预算之内，云平台提供什么，你用什么就是了。甚至如果我们只跑一两台“虚拟机/服务器”，预设的运行程序数量也比较少的话，使用云平台提供的“探针式”的监控也是可以的。

因为本文的初衷是搭建简化的云服务环境，并且希望能满足低成本、低功耗、低延时的实验环境， 故需要从开源产品中进行选型、部署和使用。

选型细节经验

在开始具体选择之前，先来分享一些之前折腾监控时的小经验：

• 如果你不能为所有的点都设置监控，以及设定合适的监控规则。那么至少要监控关键位置，形成你自己的监控网，而不是一个个监控散点。
• 监控设施的监控策略、监控指标要灵活变通，而不是从“创业”初期开始到中后期还一成不变，僵硬的监控规则会遗漏非常多重要的信息。
• 尽量不做“补作业”的事情，事后补监控的成本相比较事前做功课，只高不低（别忘记业务实际损失）
• 尽可能提高采样率，避免不准确的、“懒惰的”监控数据掩盖了发生的事情。
• 数据可视化和易观察有关联性，但是不一定是正相关。所以在选型上，不要追求酷炫，要时刻明确你的需要到底是什么。
• 根据自己的经济实力，去选择基础平台和，避免选择“大而全”的“银弹”（众所周知，没有银弹），除非你对这个方案的提供团队非常信任。
• 适当选择开源开放的平台，在有人同行的情况下，群策群力始终是有效的问题解决方式（你遇到的问题不会只有你一个人遇到）。

那么，比较通用的、适合从零到一阶段使用的监控系统，该选择谁呢？

开源监控产品：“普罗米修斯”

时值 2021 年末，考虑搭建监控平台，相对主流的选择都在 Prometheus 和 Zabbix 之间摇摆。前者从 CNCF 带着光环毕业，在许多场景下泛指 “Prom Stacks”，能够模块化灵活提供快速搭建整套监控体系的方案 ，而不单单只是作为对标 InfluxDB 而存在的时序数据库。而后者则单纯的多，或者说最在某些程度上能够代表上一世代的监控思路的产品：大而全。

至于日志落地存储，一般的选择有直接使用类似 Prometheus 的 “TSDB”的方案、也有类似 Zabbix 使用的 MySQL / PostgreSQL，有一些希望精细化搜索日志的场景，我们甚至会选择使用 ES 来作为落地方案。当然，如果你的数据量小的话，使用按日期归档的纯文本也不是不可以。

考虑到易于集成的需求，本文选择比较有代表性的 “Prom” 全家桶来搭建基础的监控服务，还不熟悉 Prometheus 的同学可以先看看它的光辉履历。

Prometheus 的履历

Prometheus 具备了许多用户喜欢的功能特点：

部署灵活，环境适应性强 。除了易于安装部署外，本身对于运行模式和存储模式也都比较宽容，可以多节点分布式运行，搭配分布式存储水平扩展，也可以多节点单一数据库，也可以单节点单一数据库模式运行。它既可以使用静态配置使用，也可以使用服务发现的方式来动态的汇聚需要监控的项目。

内置查询语言，数据查询灵活，还有大量现成模版，减少了定制软件本身的需要。如果使用 MySQL 或者其他数据库为后端的监控方案，还需要使用类似 ClickHouse 之类的方案进行查询加速，至于使用 ES 进行查询的方案嘛。众所周知，在资源性价比上，这个方案比较没有优势。

支持灵活的数据交互，数据监控依赖客户端和服务端的信息交换，而这个交换无非“推”、“拉”两个模式，多数监控采用拉模式定期收取数据。Prometheus 则支持使用网关插件集成的方式支持按需上报的“主动推送”模式。而且它的交互形式为容易调整的 HTTP 响应，如果需要调整和加工，直接在上报/拉取的过程中添加一个过程进行流程化修改也很方便。

语言支持、软件生态相对完善，Prom 覆盖了主流的开发语言，以及多数庞大用户量的软件的集成接入，能省不少功夫做集成。剩下的时间可以去做其他更有价值的事情。

报警定制灵活、简单，不论是报警规则策略管理，还是集成三方通知模块，在 Prom 里都只需要几行配置。只要你喜欢，也可以将它集成到各种 IM 里，比如 Slack、钉钉、企业微信、飞书、以及企业里自己定制开发的 IM里。或者通过云平台的短信和机器人电话进行告警通知。

可视化容易，这点应该是许多人选择的主要原因之一。不论是使用自带的 HTML 模版，还是搭配 Prom Stack 中的 Grafana 使用，都非常容易，甚至可以搭配公有云更酷炫的可视化产品一起使用。

聊了这么多，让我们使用容器来快速搭建一套适合本系列，或者说小团队使用的监控服务吧。

使用容器搭建一套最简单的监控

为了方便读者的使用，我将下面的配置上传到了 GitHub 上，可以自取。和基础篇中一样，为了省事，我在 DHCP 中配置了一条规则，给这台专门用于监控服务的虚拟机起了一个名字“monitor.lab.com”，方便后续调试和访问：

address=/monitor.lab.com/10.11.12.186

主应用及数据库：Prometheus

Prometheus 作为监控服务中数据落地存储的数据库，所以我们需要先配置它。

version: "3"

services:

  prometheus:
    image: prom/prometheus:v2.30.3
    container_