程序猿的运维知识之三——度量与日志

传统的开发与运维分别组建团队容易造成职责边界不清晰的问题，从软件部署来看的确如此。

系统规模膨胀后，很难在测试环境模拟出较为真实的后台处理，用户行为，三方交互，导致系统往往在生产环境才第一次被测试。

另一方面，支撑业务的庞杂让运维无法深入了解公司产品与业务，不能从业务视角增加价值，运维就容易变成简单应用API，AWS 的 FaaS 可以轻易替换掉他们。

怎样做到连结呢？运维可视化是一种思路。通过监测系统的吞吐量，错误率与延迟，设定度量与聚合日志，有效监测系统运行健康度，高效支撑系统运行。这里通过两个例子加以说明，系统的可观测性设计不同于开发视角。

排队系统大量应用，就在于可以分解任务，并异步执行，达到分离关注点解耦系统的目的。它的核心是消息队列，度量无外乎消息发布，消息排队，消息消费，三者共同构成了系统的吞吐量。

对消息发布数量等时间间隔抽样取值可以得到消息发布速率，如果停止增长可能生产者端影响了系统的吞吐量，如果激增可能会产生积压，如果增长缓慢可能消费者端处理性能需要加强。之所以是可能，是需要结合其他队列度量结果综合评判。

消息排队最先考虑的是队列大小，因为了解何时接近容量上限对于设计响应至关重要，比如继续扩容，进入等待队列还是拒绝新消息。另一方面要关注队列延迟，在消息被队列接收到被处理之前的平均时间，从而确认是等待时间过长还是处理时间过长。

最后在消息处理阶段求得类似的消息处理速率，队列度量指标完成收集。未确认的消息数，队列吞吐量一目了然。这些度量指标也是 RabbitMQ，Kafka 等消息队列产品的基础功能了。

再来看日志，古老有用又经常被滥用的监控功能。

日志的五种级别定义，上下文打印内容，结构化表达是核心设计。重要的，日志由于度量的好处就是可以给出错误的更多细节，也就是 ERROR 日志打印时正在采取什么动作，预期结果是什么，实际结果是什么，有哪些补救措施，潜在后果是什么。如果无法还原错误现场以及给出指导意见，那将是令人崩溃的。一个节点 1％ 的请求错误和一半节点每个节点 1％ 的请求错误是截然不同的。

除此之外，日志聚合可以实时监控系统流量，比如相同订单号在经过发布环节，消费环节，支付环节后可以聚合为订单流程监控。这也是 ELK 大放异彩的地方。
展开
评论
相关推荐