Keith Kuchler 2018-10-04
本十年最重要的转变之一，是分布式系统中互联数据的兴起。这种爆炸式增长不仅促使人们重新思考云和全球 IT 战略，也颠覆了传统的开发、DevOps 和 ITOps 实践。这些变化正将对更高开发速度（以更快交付功能和产品）以及更快速响应支持请求的要求，施加于技术专业人员身上。这些新要求促使团队评估新的工具和敏捷流程，以支持现代企业在激烈竞争中的需求。
无论你所在团队的变化节奏如何，基础设施监控等基本功能对于运行生产应用程序都至关重要。在当今高速运转的商业环境中，“可观测性”（observability）这一概念变得尤为重要，它有助于实现更成功的部署，并减少对用户的干扰——不仅限于生产环境，也包括持续集成/持续交付（CI/CD）流水线的早期阶段。作为“左移”（shifting left）的一部分，在 CI/CD 流水线中实施日志和事件管理，使开发人员能够在将应用发布到生产环境之前就监控并观察其行为。尽管有人可能会认为这在开发环境中增加了额外的流程、时间、精力和尽职调查工作，但它实际上可以帮助组织演进其基础软件开发行为，同时减少因部署后才暴露的问题而造成的可预防故障。这种方式能够创造更顺畅、无缝的用户体验，并减少在应用上线并大规模运行后“救火”或重新架构解决方案的需求。
测试与开发阶段的设定
快速演变的技术格局，提高了在分布式系统和容器中对日志管理和可观测性的需求。应用和服务构建方式的变化、跨多个全球日志即服务（Logging-as-a-Service, LaaS）提供商部署应用的能力、容器的普及及其短暂生命周期，以及使用多种开发语言构建服务的能力，都进一步增加了跨互联系统的数据点收集、监控和追踪的需求——这些数据点直接为终端用户提供关键价值。
传统上，许多人认为日志管理是一项繁琐的任务，因为每当新增一台服务器实例时，都需要在该服务器本地的日志中运行搜索命令。当每个包含 20 台以上服务器的集群可以在几分钟内搭建完成，且每个应用都采用独立的日志格式时，这种方法显然无法扩展。在这种情况下，你需要在多个系统上分别执行 20 次独立搜索，并比较位于不同时区的服务器上的时间戳等等。随着容器和虚拟系统的成本不断降低、使用日益普及，典型组织内部运行的系统数量随着业务繁荣呈指数级增长。
除了虚拟系统和容器使用量的增加，独立的 Scrum 开发团队可以并行构建服务，选用最适合其所开发服务的技术，同时共享构建、预发布（staging）和生产环境。在这些分布式服务中，聚合日志系统能迅速定位应用程序错误、异常或性能瓶颈的根本原因。日志聚合系统可以减少因开发者使用不同技术栈和多样化日志格式而产生的“个性化”问题，还能通过过滤掉干扰信息来减少噪音，从而加快团队定位问题源头的速度。否则，当一名开发者需要理解另一名开发者非标准化但又共享的工作负载时，容易造成混乱或降低生产力。
虚拟环境和容器服务的成本降低、协作增强及普及程度提高，共同推动了虚拟环境和容器数量的激增，通常也导致测试和开发环境中需要生成更多日志，从而迫使组织进行变革，以实现对其基础设施的全面可观测性。
可观测性的三大支柱
企业正处于采纳这些原则——即可观测性的三大支柱——的转型过程中，并采用一种三管齐下的监控方法，从多个视角采集数据，以更准确、更易理解的方式呈现整体健康状况和稳定性：
- 外部监控（External Monitoring）：例如，对内部和外部应用程序及网站执行健康检查，以观察用户的“数字体验”。
- 指标与分布式追踪（Metrics and Distributed Tracing）：使你能够追踪跨系统/容器分布的应用程序之间的通信，快速识别应用程序中的错误和异常，并解决延迟问题。
- 事件与日志（Events and Logs）：提供关于事件的上下文信息，当与前两大支柱的数据结合时，有助于识别代码中的问题。
上述类型的信息对 DevOps 至关重要，可支持构建弹性且高可用的服务。将应用、系统和基础设施事件整合到日志中，并与外部监控和指标收集相结合，正迅速成为行业标准。借助强大的日志解析功能（例如可通过网页浏览器访问的实时尾部搜索（live-tail search）），以及将日志洞察与附加健康指标可视化配对的能力，日志数据的真正价值得以轻松显现。
站点可靠性工程（Site Reliability Engineering, SRE）是另一个发生显著演进的领域。ITOps 过去总是被动应对、疲于奔命。从 ITOps 到 DevOps 再到 SRE 的演进，正在推动不同类型的数据在 CI/CD 流水线的极早期就被整合使用，并使 SRE 团队能够在项目启动之初就参与架构讨论，而不是等到后期或发布阶段才介入。SRE 更深入地参与监控工作，理解用于开发应用服务的开发和架构原则，并从项目初期就内建自动化、高可用性以及断路器（circuit breaker）模式。
这种方法使团队能够主动响应而非被动反应。它赋予了我们团队（负责保障业务顺利运行并让客户喜爱我们的产品）专注于可扩展性、弹性和韧性的能力。我们不再需要在生产环境中排查系统故障，而是通过自动扩缩容和替换组件来最小化中断，并尽可能在线下调查事故。
最佳实践
鉴于支撑业务需求所需的应用开发速度不断提升、容器化应用和虚拟环境的广泛普及，以及由于成本降低和可靠性提升而催生的可观测性新学科，日志和事件管理已成为所有参与构建、支持甚至使用关键任务型应用的相关人员的关键环节。日志管理正朝着一个更加明确的方向发展：日志应被分隔管理，并定义访问控制策略：
- 日志分隔（Compartmentalizing Logs）：作为一项关键最佳实践，有助于区分开发、预发布和生产环境，并根据实际用途对日志进行分组。使用日志聚合服务可为你在所有环境中提供一致的体验和通用的功能集。
- 访问控制（Access Control）：另一项应更广泛实施的最佳实践。例如，如果开发人员约 95% 的工作发生在进入生产环境之前，那么他们就不需要访问全部生产日志。换句话说，尽管技术专家们正努力“打破日志管理的孤岛”，我们仍希望在访问控制层面保留“隔离”，并对可见性进行管理。这也有助于确保个人身份信息（PII）不会被不应接触的人员看到。
日志管理的未来展望
随着技术格局不断演进，最佳实践日益明确，我们可以预期传统场景中依赖基础/免费监控的策略将被更新升级，并带来更高的期望。随着可观测性三大支柱在 ITOps 和 DevOps 社区中被更广泛地采用，我们将能更高效地从面向终端用户的事件（例如，跨分布式系统追踪到的应用错误）直接切入日志，快速定位引发问题的具体错误。我们将看到日志与其他自定义指标之间更强的相关性，以及这些技术在生产环境之外更广泛的应用。
DevOps 团队需要一个直观的事件和日志管理系统，其本身也应像我们一样“去孤岛化”。日志管理系统不能再局限于单一的本地存储系统或某个虚拟环境；它们必须契合当今以及未来工作方式的真实现状。