用于 DevOps 的 Python

第 7 章 监控和日志 监控和日志记录

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

诺亚在旧金山的创业公司工作时，利用午休时间锻炼身体。他会打篮球，跑到科伊特塔，或者练习巴西柔术。诺亚工作过的大多数初创公司都会提供丰盛的午餐。

吃完午饭回来，他发现了一个非常不寻常的规律。从来没有什么不健康的东西可以吃。吃剩的往往是沙拉、水果、蔬菜或健康的瘦肉。在他锻炼身体的时候，成群结队的初创公司员工吃光了所有不健康的食物，让他没有吃坏东西的诱惑。不随大流是有道理的。

同样，在开发机器学习模型、移动应用程序和网络应用时，忽略运算也是一条捷径。忽视运维是非常典型的做法，就像在餐饮午餐中吃薯片、苏打水和冰淇淋一样。不过，正常并不一定是首选。本章将介绍 "沙拉和瘦肉 "的软件开发方法。

构建可靠系统的关键概念

在创建公司的过程中，我发现在软件工程方面，哪些做法是行之有效的，哪些做法是行不通的。最好的反模式之一就是 "相信我"。任何理智的 DevOps 专业人士都不会相信人类。人是有缺陷的，会犯感情用事的错误，还可能一时兴起毁掉整个公司。尤其是如果他们是公司的创始人。

要建立可靠的系统，更好的办法是逐块建立，而不是基于完全无稽之谈的层次结构。此外，在创建平台时，应定期预测失败。唯一会影响这一真理的是，如果有一个有权势的人参与构建架构。在这种情况下，这一真理就会成倍增加。

你可能听说过 Netflix 的混乱猴子，但何必呢？倒不如让公司创始人、首席技术官或工程副总裁来进行逐一编码，并对架构和代码库进行二次评估。人类的混乱猴子会比 Netflix 跑得更快。更妙的是，让他们在生产中断时编译 jar 文件，并通过 SSH 将其逐个放到节点上，同时大喊："这样就可以了！"这样，就能达到混乱与自我的和谐统一。

一个理智的 DevOps 专业人员的行动项目是什么？自动化大于等级制度。解决初创企业混乱局面的唯一办法就是自动化、怀疑主义、谦逊和永恒不变的 DevOps 原则。

不可改变的 DevOps 原则

很难想象，要建立一个可靠的系统，还有比这一永恒不变的原则更好的起点。如果首席技术官正在用笔记本电脑构建 Java.jar 文件来修复生产中的火灾，那你还是辞职算了。没有什么能拯救你的公司。我们应该知道，我们曾经经历过！

无论一个人多么聪明/强大/有魅力/有创造力/富有，如果他们在危机中手动对软件平台进行重要更改，你就已经死了。只是你还不知道而已。自动化是这种畸形存在的替代选择。

人类无法长期参与软件部署。这是软件行业存在的第一大弊端。它实质上是为流氓在你的平台上肆虐开了一扇后门。相反，部署软件、测试软件和构建软件需要 100% 的自动化。

建立持续集成和持续交付是对公司最重要的初始影响。相比之下，其他一切都显得微不足道。

集中登录

日志记录的重要性紧随自动化之后。在大规模分布式系统中，日志记录并非可有可无。必须特别注意应用程序和环境层面的日志记录。

例如，异常情况应始终发送到集中日志系统。另一方面，在开发软件时，创建调试日志而不是打印语句往往是个好主意。为什么要这样做呢？为了调试源代码，我们需要花费大量时间开发启发式方法。为什么不捕获这些信息，以便在生产中再次出现问题时开启呢？

这里的诀窍在于日志级别。通过创建只出现在非生产环境中的调试日志级别，可以将调试逻辑保留在源代码中。同样，在生产环境中不会出现过于冗长的日志，也不会造成混乱，而是可以对它们进行开关切换。

Ceph就是大规模分布式系统中日志记录的一个例子：守护进程最多可以有 ...