【.com快译】有过云运维经验的读者一定知道，云原生应用是分布式动态的，这些应用通常都使用容器和无线临时技术，比如服务器功能，待部署。在管理这些云原生应用程序时，能够在任何给定时间提供端到端的可见性尤为重要。同时，由于云原生系统具有海量的数据流和抽象的复杂性，我们必须建立强大的监控和日志记录来管理各种不可预测的中断或停机。本文将与大家探讨在记录和监控云原生应用时值得学习和遵循的各种良好实践和标准。1.使用托管的日志解决方案或构建自己的基础架构首先，日志除了与本地部署的系统一样，还需要反映应用程序的运行状态。在云原生应用中，日志方案也应该遵循高可用、分布式处理、智能故障转移的原则。而这正是现代云原生应用程序与传统单体应用程序的区别所在。用于此目的的常用工具包括：Elasticsearch、Fluentd、Kibana（这三者通常统称为EFKStack）等。它们在架构上能够处理大规模数据分析，并可以实时显示处理结果。它们不仅可以辅助用户搜索和查询复杂的数据，还支持基于API的开放集成以及与其他工具的集成。当然，虽然这些工具在行业中很常用，但为了您的治理目的成功集成它们可能需要一些工作。与上述自建系统的方式相比，使用厂商自建的可灵活扩展的托管日志解决方案更加方便实用。常见的有：ElasticStack（参见）。使用这个现成的集成方案，你只需要在云端连接应用数据源和目标，就可以轻松获取和分析各种应用日志。因此，您还可以将宝贵的时间花在监视和记录其他关键应用程序上，而不是弄清楚如何构建自己的日志记录基础架构。2.知道什么应该监控，什么不应该记录。众所周知，我们监控的数据记录越多，我们就越难找到真正重要的数据。同时，更多的日志管理任务也意味着更复杂的日志存储和管理流程。因此，我们需要仔细考虑必须记录的内容。例如，在任何类型的生产环境中，对合规性和审计目的至关重要的数据都应完整记录。此外，那些可以帮助你解决性能和用户体验问题的数据，以及与安全事件相关的数据也需要被持续监控和记录。那么，哪些数据类别不需要记录呢？例如：来自测试环境的数据，因为它们不是软件交付管道（deliverypipeline）的重要组成部分，并且出于合规性或安全方面的考虑，我们不允许此类数据不被记录。此外，如果用户启用了“不跟踪”设置，那么我们不应记录与该用户相关的所有数据。同样，我们也应该避免记录某些高度敏感的数据（如信用卡号等），直到我们确定我们的日志记录和存储程序已经满足数据的安全要求。3.支持日志安全和保留政策的实施由于日志必然会接触到敏感数据，因此我们的日志安全政策应该包括检查敏感数据源的环节，例如客户个人数据和API内部访问密钥。同时，我们应确保在将日志传输给任何第三方之前对敏感数据进行匿名（或脱敏）或加密。为了将日志数据安全地传输到日志管理服务器，我们经常需要在客户端和服务器之间启用和设置端点加密方式，如TLS或HTTPS。同时，来自不同来源的日志可能需要分配不同的保留策略。例如：某些应用程序可能只与几天内的故障排除有关；而那些与安全事务日志或业务事务日志相关的日志则需要更长的保留期。因此，我们的保留策略对于日志源应该是灵活和细粒度的。4.日志存储在规划日志存储容量时，要充分考虑高负载时的峰值流量。当系统平稳运行时，应用每天产生的数据量几乎是恒定的，主要取决于系统的使用率和服务每天的交易量。在系统出现严重错误的情况下，我们通常会发现日志量急剧增加。因此，如果日志存储达到分配空间的限制，并且您没有“滑动窗口”策略，您可能无法再存储对修复系统错误至关重要的日志。这里的滑动窗口是指日志存储周期性地作用于buffer，在应用数据达到存储空间限制之前，自动删除最早的数据，以保持日志的存储。如果有人问：“什么比系统停机更糟糕？”那么我的回答是：“缺乏相应的故障排除信息，进而延长停机时间。”可以看出我们在设计日志存储，要保持它的可扩展性和可靠性。此外，日志存储应配备单独的安全策略。我们将各种日志实时集中传输到中央存储库。如果不法分子可能会访问您的基础设施，您可以考虑将日志发送到远程位置（例如，使用专门提供日志服务的SaaS）以防止证据被篡改。5.检查并维护您的日志。缺乏对日志数据的维护可能会导致故障排除时间延长、敏感数据暴露以及日志存储成本增加。我们需要定期检查应用日志的输出，并通过审查服务的可用性、可操作性和安全性来根据需要调整系统。创建有意义的日志信息如果日志仅包含部分和“含糊”的错误代码和消息，运营部门将需要时间来解读它们。只有那些可读且有用的日志消息才是快速排除故障的关键。因此，各类开发人员应尽可能提供有意义的日志信息，从而节省宝贵的诊断时间。使用结构化日志格式结构化日志格式（例如：JSON或key/value格式）可以包含消息相关的数据字段，例如：时间戳、严重性、进程ID、事务ID等。如果您没有采用统一的日志所有应用程序的格式，请尽快规范和规范日志生成，以便系统能够以结构化的方式高效地合并、解析和存储日志。使日志级别可配置在实际系统中，我们经常会发现一些应用日志太长，而一些应用日志没有包含足够的服务信息。因此，我们需要通过可调整的日志级别来配置各种日志的详细程度。此外，在日志审核过程中，还要注意在详细程度和不泄露个人隐私数据之间建立平衡，并通过脱敏和加密等方式保护安全信息。审计日志的持续检查安全问题的快速解决依赖于我们对审计日志的持续检查。我们可以通过配置auditd或OSSEC代理等安全工具，在实时日志分析中生成各种指向潜在安全问题的告警日志。通过一些定义的警报日志级别，可以快速通知操作人员任何可疑活动。您可以使用链接：https://sematext.com/blog/auditd-logs-auditbeat-elasticsearch-logsene/了解有关auditd和各种补充框架的使用的更多信息。使用以下日志审查清单：日志消息对用户有意义吗？日志消息是否包含对故障排除有用的上下文？日志消息是否结构化，包括：时间戳Severity/日志级别消息体其他故障信息特征字段是否需要第三方日志解析和结构化服务（配置日志代理）？日志级别是否可配置？日志消息是否包含个人数据或安全相关数据？是否可以检查审计日志并调整警报日志记录规则？是否设置了警报日志记录？6.不要孤立地进行日志分析，关联所有数据源日志记录应该是您整体监控策略的一部分。也就是说，要使监视真正有效，您需要用其他类型的监视（例如基于事件、警报和跟踪的类型）来补充日志记录，以跟踪系统中发生的事情。“全貌”。尽管日志数据可以为特定问题提供非常详细的信息，但它通常无法以关联的方式为您提供全局状态信息。我们需要各个聚合层级的指标和事件，才能有效地“循树而行”，从源头上发现问题。由此可见，我们不应孤立地看待日志，而需要综合运用APM、网络监控、基础设施监控等其他类型的监控工具来弥补日志的“短板”。通过灵活地将各种工具集成到一个表单视图中，我们可以轻松地一站式获取所有监控信息，甚至可以得到一些趋势图。7.使用ViewLogging作为GitOps催化剂随着持续集成越来越多地在CI/CD管道开始时触发，GitOps需要自动化软件交付，并实现迭代速度。繁忙的DevOps团队很容易将日志记录作为其自动化管道和频繁发布的工具。当然，业内还有另一种观点，认为日志记录是DevOps和CI/CD的催化剂。总之，为了自动化开发流水线的每一步，您需要可视化出现问题的位置，以及它们的主要原因，例如：错误代码、问题依赖、资源不足或其他方面。问题的原因可能是多方面的，但是日志记录绝对可以给你一个发现和修复问题的参考维度。8.获得任何类型事件的实时反馈自动化测试和无头测试等新方法使开发人员能够在提交时甚至提交前更改研发环境中的每一行代码。获得实时性能反馈。因此，随着测试向左移动并且对管道起源的重视程度越来越高，日志记录对于获得可见性和启用GitOps至关重要。可以这么说，如果没有适当的测试和日志记录，您的发布和部署可能会完全失控。9.使用日志记录来识别自动化的机会和趋势同时，除了帮助我们及早发现管道中的问题并为我们的团队节省宝贵的时间和精力，日志记录还可以帮助我们发现自动化的机会和趋势。机会。您可以设置发生故障时触发的自定义警报，并且可以预设警报的各种自动操作。无论是通过Slack中的自定义脚本还是Jenkins中的自动化插件，您都可以使用不同的日志来推动GitOps流程的自动化。总之，日志记录是构建和管理云原生应用程序的重要组成部分。成功的日志记录不仅反映了应用程序的状态，还可以随其扩展和迭代。同时，我们不应该孤立地分析日志，而应该学会与其他云原生应用监控方案结合，共同实现监控和测量。此外，日志记录还可以驱动GitOps自动化，以实现对事件类型的实时反馈。原标题：BestPracticesforEfficientLogManagementandMonitoring，作者：TwainTaylor&StefanThies
