1. 记录日志

1.1. 传统的日志文件仍然是最可靠和最灵活的信息载体

1.2. 日志文件反映应用程序内部的活动，因此它们能揭示应用程序的即时行为

1.3. 没有比日志文件更松散的耦合方式了，而且每个框架或工具都可以抓取日志文件

2. 成功运用日志的关键事项

2.1. 日志的存放位置

2.1.1. 对物理机器来说，将它们保存在单独的驱动器上是个很好的做法

2.1.2. 实例在虚拟机中运行，将日志文件从应用程序代码中分离出来也是一个好主意

2.1.2.1. 需要锁定代码目录，并且写入权限要尽可能小，甚至没有

2.2. 日志级别

2.2.1. 大多数开发人员在编写日志时，仿佛自己是日志文件的主要消费者

2.2.2. 运维团队的系统管理员和运维工程师将花费更多的时间与这些日志文件打交道

2.2.3. 记录日志应该面向生产环境的运维人员，而非开发人员或测试人员

2.2.4. 任何级别为“错误”或“严重”的日志记录都需要交由运维人员来采取措施

2.2.4.1. 并非所有异常都需要记录为错误，如果仅仅因为用户输错了信用卡号码，造成验证组件抛出一个异常，就不需要运维团队处理

2.2.4.2. 用“错误”标记严重的系统问题，如断路器跳闸至“断开”

2.2.5. 在生产环境中调试日志

2.2.5.1. 构建过程中添加一个步骤，自动删除任何启用“调试”级别或“跟踪”级别的配置

2.3. 日志读者

2.3.1. 需要便于读者阅读，这一点高于一切

2.3.1.1. 对信息的误解会造成经济损失，影响声誉

2.3.2. 必须确保日志文件能向其读者传达清晰、准确和可操作的信息

2.3.3. 在格式上应尽可能地便于读取

2.3.3.1. 缺乏列对齐，且需要从左到右“扫描”来阅读的格式绝对不能采用

2.4. 巫毒运维

2.4.1. 对早期人类来说，那些能探知不存在的模式的人比不能探知真实模式的人更容易将基因传递下来

2.4.1.1. 前者在看到类似豹子身上明暗相间的花纹，便从灌木丛中逃跑

2.4.1.1.1. 假阳性错误（所探知的模式是不存在的）的代价很低

2.4.1.2. 后者甚至不能辨认丛林中的豹子

2.4.1.2.1. 假阳性错误（所探知的模式是不存在的）的代价很低

2.5. 日志信息应包含可用于跟踪事务步骤的标识符，这可能是用户ID、会话ID、事务ID，甚至是接受请求时分配的任意数字

3. 实例的健康度量指标

3.1. 实例是组成系统的基本构件

3.2. 实例本身并不能说明整个系统的健康状况

3.3. 可以发出一些度量指标，这些指标可被集中地收集、分析和可视化

3.3.1. 只需要定期在日志文件中插入一行统计信息，日志抓取工具越强大，这种做法的优势越明显

3.4. 健康状况检查是流量管理的重要组成部分

3.4.1. 解释度量指标是有难度的

3.4.2. 当新实例的健康状况检查结果从失败转移到通过时，就意味着该应用程序已完成启动

热门相关：流鱼无恙   回眸医笑，冷王的神秘嫡妃   民国之文豪崛起   重生野性时代   道君