高效日志管理与监控的优秀实践

译文
云计算
由于云原生系统具有海量的数据流和抽象的复杂性,因此我们必须建立强大的监控和日志记录,以管控各种不可预知的中断或宕机。本文将和您讨论在记录和监控云原生应用时,各种值得借鉴和遵循的优秀实践与标准。

【51CTO.com快译】有过云端运营经验的读者想必都知道:云原生应用具有分布与动态的特性,而所有此类应用通常都会用到容器和无服务器函数等临时技术(ephemeral technologies),来予以部署。而在管理这些云原生应用的时候,能够在任何给定的时间内,提供端到端的可视性显得尤为重要。

[[265226]]

与此同时,由于云原生系统具有海量的数据流和抽象的复杂性,因此我们必须建立强大的监控和日志记录,以管控各种不可预知的中断或宕机。本文将和您讨论在记录和监控云原生应用时,各种值得借鉴和遵循的优秀实践与标准。

1.使用托管日志记录解决方案,还是自建基础架构

首先,除了和本地部署的系统一样,日志记录需要能够反映出应用程序的运行状态之外,在云原生应用中,日志记录解决方案还应该遵循高可用性、分布式处理、以及智能故障转移等原则。而这恰恰就是现代云原生应用与传统整体式应用的区别所在。

能够实现此类目的的常见工具包括:Elasticsearch、Fluentd、Kibana(三者常被共称为EFK Stack)、以及其他工具。它们在架构上可以处理大规模的数据分析,并能够实时地显示处理的结果。它们不但能够协助用户对数据进行复杂性的搜索与查询,还能够支持基于API的开放性集成、以及与其他工具相集成。当然,尽管这些工具在业界十分常用,但是要成功地将它们集成到一起,以满足您的管控目的,则着实需要花费一些功夫。

与上述自行构建系统的方式相比,使用那些由供应商构建、并能够灵活扩展的托管型日志记录解决方案,则更为方便且实用。常见的有:Elastic Stack(请参见)。使用此类现成的集成方案,您只需要将云端的应用数据源和目标相连接,便可轻松地获取与分析各种应用日志。因此,您还可以将宝贵的时间分配到监控和记录其他重点应用之上,而不必花精力去研究如何自行构建日志记录的基础架构。

2.知晓哪些内容该监控、哪些不必记录

众所周知,我们监控的数据记录越多,我们就越难找到真正重要的数据。与此同时,更多的日志管理任务,也意味着更加复杂的日志存储与管理过程。

因此,我们需要认真考虑那些必须记录的内容。例如,在任何类型的生产环境中,那些具有合规性、和满足审计目的、以及至关重要的数据理应得到完整的记录。另外,对于那些能够帮助您解决性能和用户体验方面的问题、以及与安全事件相关的数据也需要被持续监控与记录。

那么,哪些数据类别不需要被记录呢?例如:来自测试环境的数据,由于它们不是软件交付管道(delivery pipeline)的重要组成部分,而且出于合规性或安全方面的考虑,我们对于此类数据不予记录。另外,如果用户启用了“禁止跟踪(do-not-track)”的设置,那么我们就不应记录与该用户关联的所有数据。同理,在确定自己的日志记录和存储过程已满足了该数据的安全要求之前,我们也要避免记录某些具有高敏感性的数据(如,信用卡号等)。

3.配套实施日志安全和保留策略

由于日志势必会接触到敏感数据,因此我们的日志安全策略应当包含检查诸如:客户端的个人数据、以及API内部访问密钥等敏感数据源的环节。同时,在将日志传送给任何第三方之前,我们应确保敏感数据被匿名化(或称脱敏)或加密。为了将日志数据安全地传输到日志管理服务器上,我们往往需要在客户端和服务器端之间启用、并设置TLS或HTTPS等端点加密的方式。

同时,不同来源的日志可能需要被分配不同的保留时间策略。例如:某些应用可能仅与几天之内的故障排除相关;而那些与安全相关的事务日志、或业务事务日志,则需要有更长的保留期限。因此,我们的留存策略应该对于日志源是灵活、且细粒度的。

4.日志存储

我们在规划日志存储的容量时,应充分考虑到高负载时的峰值流量。在系统平稳运行时,应用每天所产生的数据量几乎是不变的,而且主要取决于系统的利用率、以及服务每天的事务量。而系统在出现严重错误的情况下,我们通常会发现日志卷的猛增。

因此,如果日志存储达到分配空间的限制,而您又没有设置过“滑动窗体”策略的话,那么就可能无法再继续存入那些对于修复系统错误来说至关重要的日志。此处的滑动窗体是指:日志存储循环地在缓冲区上进行工作,以实现在应用数据达到存储空间的限制之前,自动将最早的数据删除掉,以保持日志的存入。

如果有人问:“什么是比系统宕机时间更糟糕的事情?”那么我的回答是:“缺乏相应的故障排除信息,以至于反过来延长了宕机时间。”可见,我们在设计日志存储时,要保持它的可扩展性和可靠性。

另外,日志存储应该配备有单独的安全策略,我们将各种日志实时地、集中性地传送到某台中央存储库上,如果不法分子有可能访问您的基础架构的话,则可以考虑将日志发送到异地(例如,使用专门提供日志服务的SaaS),以避免证据被篡改。

5.查看并持续维护您的日志

缺少对于日志数据的维护,可能会导致排障时间的延长、敏感数据的暴露、以及日志存储成本的走高。我们需要定期查看应用日志的输出,通过审查服务的可用性、可操作性、以及安全性等方面的内容,以及时按需调整系统。

创建有意义的日志信息

如果日志中只包含了局部且“神秘”的错误代码与信息,那么运营部门是需要花时间进行解读的。只有那些易读且实用的日志消息,才是快速进行排障的关键。因此,各类开发人员应当尽可能地通过提供有意义的日志信息,来节省诊断的宝贵时间。

使用结构化的日志格式

结构化的日志格式(例如:JSON或key/value格式)可以包含诸如:时间戳、严重性、进程ID、事务ID等与消息相关的数据字段。如果您尚未对所有应用采取统一的日志格式,那么请尽快规范化和标准化日志的产生,以便系统能够以结构化的方式,高效地进行日志的合并、解析与存储。

使得日志级别可配置

在现实系统中,我们时常会发现某些应用的日志过于冗长,而某些应用日志却没能涵括足够的服务信息。因此,我们需要通过可调整的日志级别(log levels),来配置各种日志的详略程度。另外,我们在日志审阅的过程中,也要注意通过以脱敏和加密的方式,在详细程度与不公开个人隐私数据、以及保护安全信息之间的建立平衡。

持续检查审计日志

安全问题的迅速解决,依赖于我们持续对于审计日志的检查。我们可以通过配置诸如auditd或OSSEC代理之类的安全工具,以实时日志分析的方式,生成各种指向潜在安全问题的警报日志。通过一些既定的警报日志级别,运营人员能够快速地获悉任何可疑的活动。您可以通过链接:https://sematext.com/blog/auditd-logs-auditbeat-elasticsearch-logsene/,来进一步了解auditd的使用,以及各种补充性的框架。

使用如下日志审阅检查表:

  1. 该日志消息对用户是否有意义?
  2. 该日志消息是否包含有利于排障的上下文?
  3. 该日志消息是否已被结构化,且包括:
  • 时间戳
  • 严重性/日志级别
  • 消息主体
  • 其他排障信息的特征字段
  1. 是否需要第三方日志解析与结构化服务(配置日志代理)?
  2. 日志级别是否可配置?
  3. 该日志消息是否包含了个人数据或与安全相关的数据?
  4. 是否具备检查审计日志和调整警报日志的规则?
  5. 是否已对警报日志进行了设置?

6.不要孤立地进行日志分析,请将所有数据源关联起来

日志记录应该被纳入到您的整体监控策略之中。也就是说,要想实现真正有效的监控,您需要使用其他类型的监控方法(如,基于事件、警报和跟踪的监控类型),来作为日志记录的补充,以便随时掌握系统中某个事情的“全貌”。虽然日志数据能够针对某个问题的局部,提供非常详尽信息,但是它却往往无法以相互关联的方式,给您提供全局维度的状态信息。我们需要通过各种聚合级别的指标和事件,来有效地从问题的开端“顺藤摸瓜”地查找问题。

可见,我们不应该孤立地查看日志,而需要综合使用诸如:APM网络监控、以及基础架构监控等其他类型的监控工具,来补足日志的“短板”。通过灵活地将各类工具集成到一个窗体视图之上,我们能够一站式地轻松获取所有监控信息,甚至能得到一些趋势图表。

7.将查看日志记录作为GitOps的催化剂

随着持续集成越来越多地在CI/CD管道起点被触发,GitOps需要在不降低产品质量和安全认证质量的情况下,实现软件交付的自动化、并达到迭代速度。对于忙碌的DevOps团队而言,他们很容易将日志记录视为其自动化管道、以及频繁发布的一种工具,而欣然接受之。

当然,业界也有另一种观点认为:日志记录是DevOps和CI/CD的催化剂。总的说来,为了在开发管道的每一个步骤上都实现自动化,您需要可视化问题出现的位置,以及它们的主要原因,例如:错误代码、问题依赖性关系、资源不足、或者是其他方面。问题的原因可能不胜枚举,但是日志记录绝对能够为您提供查找和修复问题的参考维度。

8.获取有关任何事件类型的实时反馈

自动化测试、以及headless测试等新的方法,使得开发人员能够在研发环境中,对于每一行代码的更改,都能够在提交之时,甚至是提交之前就能够获取实时的效果反馈。因此,随着测试的左移(shifts left),以及对于管道起点的日益重视,日志记录对于获得可视性,以及GitOps的启动都是至关重要的。可以说,如果没有适当的测试和日志记录,您的版本发布与部署可能会完全失控。

9.使用日志记录来识别自动化的契机和趋势

同时,日志记录除了有助于我们在管道中尽早地发现问题,进而为自己的团队节省宝贵的时间与精力之外,它还可以帮助我们找到自动化的契机。您可以通过设置自定义的警报,以便在发生故障时被触发,并且可以预先设定好针对警报的各种自动化操作。无论是通过Slack的自定义脚本,还是Jenkins的自动化插件,您都可以使用不同的日志,在GitOps的流程中驱动自动化。

总结

总之,日志记录是构建和管理云原生应用的重要组成部分。成功的日志记录,不但能够反映应用程序的状态,而且能够与之共同扩展和迭代。同时,我们不应孤立地分析日志,而应当学会与其他云原生应用类型的监控解决方案相集成,共同实现监控与度量。另外,日志记录还能够通过驱动GitOps的自动化,以实现事件类型的实时反馈。

原文标题:Best Practices for Efficient Log Management and Monitoring,作者:Twain Taylor & Stefan Thies

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

 

责任编辑:未丽燕 来源: 51CTO.com
相关推荐

2022-03-01 18:27:18

云原生日志监控

2019-10-10 09:00:30

云端云迁移云计算

2021-03-11 14:33:28

Kubernetes开源容器

2023-07-03 12:09:38

云日志云服务

2021-11-26 13:43:01

服务器虚拟化数据中心

2021-10-18 13:26:15

大数据数据分析技术

2019-11-24 23:39:01

漏洞管理漏洞风险

2019-11-22 15:27:07

技术漏洞管理网络

2022-04-20 12:08:17

容器安全漏洞网络安全

2022-07-13 08:00:29

安全风险管理IT

2022-11-23 10:49:41

IT资产管理IT战略

2023-01-27 15:41:24

2009-08-24 14:04:22

机房监控运维管理摩卡

2019-07-15 10:39:04

云计算基础设施监控软件

2022-01-19 11:17:50

服务质量 QoS云服务网络流量

2023-03-16 08:18:11

数据中心

2019-04-26 07:56:40

容器秘密安全

2021-03-14 09:37:45

Git仓库管理代码

2012-02-16 09:22:11

2020-02-07 10:46:43

多云云计算混合云
点赞
收藏

51CTO技术栈公众号