前言

       与其他应用程序相比，云原生的应用程序对点对点可见性的需求更为迫切，这是因为云原生的应用程序具有分布式及动态特性，通常使用容器（Container）和无服务器（serverless）功能之类的临时技术进行部署。

        由于跨云原生系统的流量大且复杂程度高，因此使用强大的日志记录及监控来控制并管理不可避免的混乱时非常重要的。我们在这里对记录和监视云原生应用程序时应遵循的最佳实践和标准进行讨论。

        首先，日志记录应该反应应用程序的状况。在云原生应用程序的范畴中，日志记录解决方案应该与高实用性、进行分布式处理、智能故障切换等相同的原则建立，并以此为应用程序奠定自身基础。这也是将现代云原生应用程序与原有其他整体应用程序区分开来的原因。

        日志托管解决方案使用的工具有很多，它们用于处理大规模数据分析并实时提供结果。它们促进了对数据的复杂搜索与查询，同时，也使与其他基于开放API的工具集成成为可能。但是，尽管已经有可以使用的原材料，但将所有原材料整合在一起并确保达成目的，却是另外一项挑战。

        与其自行构建系统，不如使用由供应商构建和扩展的托管日志记录解决方案。使用现有的集成系统，组织所需要做的仅仅是连接源头与目标，就可以开始轻松分析应用程序日志。如此一来，就可以腾出更多时间来监控和记录应用程序，而不是用来进行基础架构。

        必须了解什么样的内容不需要记录。可以记录但并不意味着应该或必须去记录——记录太多的数据反而会增加查找真正重要数据的难度。我们可以管理更多日志，但也因此增加了日志存储和管理过程的复杂性。

        由此，我们必须仔细考虑实际需要记录的内容。对于合规性或审核目的至关重要的任何类型的生产环境数据都应该被记录。那些可以帮助解决性能问题、有关用户体验的数据、或监视与安全性相关事件的数据也应被记录。

        另一方面，有些类别的数据是不需要记录的，例如测试环境的数据，因为这些不是软件交付管道的重要组成部分。也有某些数据出于合规性或安全性原因不应该记录。例如，如果用户启用了“请勿跟踪”设置，则不应记录与该用户关联的数据。同样，除非确定日志记录和存储过程符合该数据所需要的安全性要求，否则应避免记录信用卡号等诸如此类的高度敏感数据。

        日志包含敏感数据。日志安全策略应查看敏感数据，例如客户端的个人数据或API的内部访问密钥。在将日志发送给任何第三方之前，需要确保对敏感数据进行匿名或加密。要将日志数据安全传输到日志管理服务器，需要在客户端和服务器端为TLS或HTTPS设置加密的终结点。

        不同来源的日志可能需要保留不同的时间。某些应用程序日志仅与几天的故障排除有关，但与安全相关的日志或业务日志需要更长的保留时间。因此，保留策略应该是灵活的，它取决于日志源的具体要求。

        规划日志存储容量时应考虑高负载峰值。当系统运行良好时，每天产生的数据量几乎是恒定的，且数量主要取决于系统利用率和每天的业务量。然而一旦出现严重的系统错误，日志量就会加速增长。这时，如果日志存储达到存储限制，就会丢失最新的日志，但这对于修复系统错误来说却至关重要。因此，日志存储必须充当循环缓冲区，在应用达到存储限制之前，该缓冲区首先删除最早的数据。

        设计日志存储时，必须考虑其具有延展性和可靠性——没有什么比没有系统停机和缺少故障排除信息更糟糕的情况了，因为这反过来又会延长停机时间。

        日志存储应具有单独的安全策略。每个攻击者都将尝试避免或删除其在日志文件中的踪迹。因此，我们应该将日志实时发送到中央日志存储。如果攻击者可以访问您的基础结构，则在异地发送日志（例如使用日志记录SaaS）将有助于保持证据不受篡改。

      未维护的日志数据可能导致需要更长的时间去排除故障，并伴有暴露敏感数据的风险或导致更高的日志存储成本。查看应用程序的日志输出，并根据需要进行调整。审查应涵盖可用性、运营和安全性方面。

        创建有意义的日志消息

        可读且有用的日志消息是加快故障排除速度的关键。如果日志仅包含一些错误代码或“神秘”错误消息，则会很难理解。作为开发人员，您可以通过提供有意义的日志消息来节省组织时间。

        使用结构化日志格式

        日志格式应结构化（例如JSON或键/值格式），并具有各种字段（如时间戳、严重性、消息以及任何其他相关数据字段，如进程ID、事务ID等）。如果不能使用统一的日志格式对应所有应用程序，请标准化发送器中的日志。随后对日志进行解析并以结构化格式存储日志。

        使日志级别可配置

        一些应用程序日志太冗长，而其他一些应用程序日志却没有提供足够的相关信息。可调日志级别是配置日志详细程度的关键。日志查看的另一个主题是在记录相关信息与不暴露个人数据或与安全相关的信息之间取得平衡的挑战。如果是这样，请确保可以匿名或加密这些消息。

        经常检查审核日志

        针对安全问题采取行动至关重要，因此，组织应始终关注日志审核。设置安全工具，例如审计或OSSEC代理。该工具执行实时日志分析并生成指向潜在安全问题的日志警报。在此类审核之上，再定义警报，以便在任何可疑活动发生时迅速得到通知。

        使用清单进行日志审查：

• 日志消息对用户有意义吗？

• 日志消息中是否包含用于故障排除的上下文？

• 日志消息是否结构化并包括

            ＊时间戳记

            ＊ 严重性/日志级别

            ＊ 信息

            ＊其他故障排除信息在单独的字段中

• 是否解析和构造了第三方日志（配置日志发件人）？

• 日志级别可以配置吗？

• 日志消息中是否包含个人数据或与安全性相关的数据？

• 检查审核日志并调整日志警报规则

• 在日志上设置警报

        将端点连接起来。日志记录是整个监视策略的一部分。要实施真正有效的监视，还需要用其他类型的监视来补充日志记录，例如基于事件、警报、和跟踪的监视。这是完整了解任何时间点正在发生事件的唯一方法。日志可以提供相关问题的高清详细信息，但这仅仅在看到“森林”并准备好放大“树木”时才有用。将指标及事件汇总起来可能更有效，尤其是在开始进行故障排除的时候。

        不要仅仅只在封闭环境里查看日志，使用其他类型的监视工具（例如APM、网络监视、基础结构监视等）来进行补充。这意味着您需要使用足够全面的监视解决方案，以便在一处提供所有监视信息，或者足够灵活，可以轻松地与提供此信息的其他工具进行集成。如此，作为用户，您可以看到完整监控的单窗格视图。

        对于繁忙的DevOps团队，很容易会把日志记录看作是一个不错的工具，或者将其视为一个附加组件。一旦找到了自动化的CI / CD管道并进行频繁的发布，便可以使用它。但是，查看日志的另一种方法是将其视为DevOps和CI / CD的启动器。为了在开发流程的每个步骤中实现自动化，我们都需要可见性，以了解在何处发生了问题，以及这些问题的主要根源是什么——代码错误、依赖项问题、外部攻击，资源不足或其他原因。原因可能很多，但是日志记录提供了查找和解决这些问题所需的依据。

        目前，集成越来越多地开始启用GitOps，就更需要关注自动化和速度，但不能牺牲质量和安全认证。

        自动化测试和诸如无头测试之类的新方法可以在开发环境中获取每个代码更改的实时反馈，即使是在提交之前。随着测试向左移动，并且越来越关注管道的开端，日志记录对于获得可见性和启用GitOps至关重要。没有适当的测试和日志记录，您将被“遗弃”在失控的版本和部署“地狱”之中。

      日志记录有助于尽早发现问题，为团队节省宝贵的时间和精力。它还可以帮助找到自动化的机会。我们可以设置自定义警报，在发生问题时触发，甚至可以设置在触发这些警报时启动的自动操作。无论是通过Slack、自定义脚本还是Jenkins自动化插件，我们都可以使用日志在GitOps流程中推动自动化。也是因为这样，日志记录应该被视为GitOps的启动器和驱动程序，而不是附加组件。

      总之，日志记录是构建和管理云原生应用程序的重要组成部分。为了使日志记录成功，它应该反映应用程序的状态并能够随之扩展。永远不要在silo中记录日志，这也是为什么针对云原生应用程序的监视解决方案应考虑其他类型的监视和指标。日志记录通常被认为是事后的想法，但是希望使用GitOps的团队将日志记录视为可观察性的驱动力和推动力，也是必不可少的。