云原生应用在商业领域使用率逐渐升高，现在不仅仅是Netflix、Amazon和Gilt这样的公司在打造高扩展性和动态应用架构，每隔一两个星期我就听说一些传统领域的公司（像金融和保险）在将他们的技术架构逐渐更新为云原生架构。云原生应用的逐渐增多深刻的影响了应用的监控手段，简单来看你可能以为这不过是一类新的被监控对象，然而深入分析后你会发现这不仅仅是一系列新技术，而是围绕应用构建、管理和运维的一系列改变，过去五年的最佳监控实践变成了反面教材。
一些反面教材和对应的最佳实践如下：
- 严格按照计划进行产品发布是保障软件质量的最佳实践，然而现在的公司为了或得更好的灵活性，会在一天之内进行多次产品部署升级
- 容量管理是一项重要的战略规划，试图预测未来，然而现在容量管理变为了一项特定的流程，会根据实时数据及时调整系统容量，进而节省成本
在我们深入了解这种新的监控方式带来的影响之前，让我们定义一下什么是云原生应用。
什么是云原生应用？
与云原生应用的名字不同，云原生应用不仅仅是关于“云”。事实上，这里的“云”代表了一系列应用构建和管理的方式，我们可以将其细分为几个关键环节：
- 可编程基础设施 云原生应用可以简单的通过一个API实现基础设施资源（像计算资源和网络资源）的编排，而不需要实际操作物理设备（像插接网线）。云计算供应商现在甚至提供像数据库这种完整的应用服务，它们已近通过网络访问的方式进行了分发和共享。
- 微服务 微服务架构已经成为新的应用构建标准，根本的原因在于其支持的局部业务模块简易部署大大加快了整个业务系统的部署速度，同时它给予了研发团队在技术选型上更多的自由。研发团队可以根据需求特点选择不同的技术，类似于在后端使用Java、在API使用Node.js、在一些后台任务使用Python。
- 持续交付 持续集成和交付（CI/CD）是云原生应用的核心，虽然云计算并不要求CI/CD，但是云原生架构需要全自动（理论上）的交付流水线来支持研发人员快速发布代码至生产环境。
云原生应用监控为什么不同于传统方式？
围绕应用交付如此多的变化对监控方式产生了哪些影响？我们是否还可以继续使用原来的好的监控手段？云原生应用带来了哪些变化和不同？从10000英尺高空的视角来看并没有太多的概念，我们仍在监控基础设施和应用。但是细节是魔鬼，通过对已经采用云原生应用架构公司的调研，我们发现了如下的内容。
你的监控手段需要改变吗？
取决于你所在团队的成熟程度，你的监控手段可能已经足够成熟。基础设施监控满足了对主机和网络的监控，应用监控满足了应用服务级别的监控（像错误率和响应时间），真实用户监控满足了终端用户响应时间和错误率，用户行为监控和日志监控也已经进行了很长时间，这一切构成了一个混合监控平台。这些监控数据对于云原生应用同样也很重要。
所以从整体角度来看监控手段并不需要改变，需要改变的地方藏在细节的地方。如果你的监控手段还没有覆盖上面提到的各个环节，仍有一些缺失，你需要完善整个运维监控体系。对于传统数据中心，由于基础设施的维护是运维团队的责任，研发团队完全不需要关心基础设施状态。然而，在云原生的场景下，研发团队需要端到端的承担围绕应用各个环节的责任，包括健康运转的基础设施。
多语言开发需要多语言监控
多语言开发代表研发团队可以根据需求使用多种类型的编程语言和数据库。传统的手段，公司会要求整个公司使用共同的技术体系，Java EE是其中最典型的代表。数据库也类似，一个公司很少同时使用多种类型的数据库。在现代话的环境下，这种标准被研发团队内部自治取代，如果一个团队认为Node.js比Java更适合来实现API，他们就会做出这个决定。这种趋势增加了监控环境的复杂度，以往我们很容易学习应用管理的专业知识，现在在云原生的场景下，这些专业知识分散在了很多不同专业领域的团队中，比如搜索团队、支付团队、优惠计算团队和用户管理团队。
这种情况就需要能够覆盖更多技术场景的监控手段，同时也需要标准化的方式来描述和管理监控数据，StatsD就是一种可选的方案。
网络规模IT（web-scale）越来越常见
网络规模IT（web-scale）已经成为Facebook、Google等公司等独特标记，事实上，我们很少会真正打造Twitter和Facebook这样级别的应用，然而微服务架构的出现导致更小体量的应用同样表现出类似的复杂性。过去的三级架构应用现在可能会变成超过100个彼此调用的服务模块，这些服务模块会同时存在多个版本而且以一种“混沌”的模式升级。
这样的复杂性就需要监控手段及工具更加自动化，并且能够以可视化的方式呈现包含大量应用实体的业务系统的整体健康状态。
所有人都需要关注监控
所有人都需要能够查看监控数据，尤其是那些采用DevOps模式的团队。然而在很多团队中，运维工作仍旧仅仅被分配给一些专门的人员，他们使用高度定制化的仪表盘来满足需求。在云原生环境下，每一个业务团队都需要能够以自定义化的方式查看监控数据。类似于响应时间、错误率、负载和日志文件这样简单的监控指标通常很容易实现这些目标，然而监控指标应当不仅仅局限于这些，技术团队往往还需要一些信息来了解A/B测试对产品功能的影响或者数据缓存策略对技术选型的影响。
监控界面需要更加直观，监控工具需要预置好各种各样监控配置，因为人们普遍缺乏配置监控工具的技能和时间。
持续交付提高了异常检测的凤霞
异常检测现在是运维领域一个很火的话题，这是有原因的。因为交付变得越来越频繁，同时掌握系统变化变得越来越困难，系统部件越来越多，甚至整个系统的具体表现也变得不好理解。
异常检测之所以被重视，正是因为它提供了一种自动分析系统运行状态的手段，同时它还会自动评估系统变更带来的影响。
基础设施生命周期变得短暂
“健康的灵魂或在健康的身体中”，很长一段时间这对于运维监控也是正确的，如果基础设施不健康，应用系统也会受到影响。虽然现在这仍是正确的，但是系统在处理异常基础设施时会采用完全不同的方式—异常节点在系统运行过程中会被直接替换掉，这使得系统具备了一定的弹性。云原生应用通过定期监控CPU或访问健康状态接口来自动监控节点健康状态，如果监控发现异常，类似于自动伸缩集群和Mesos这样的集群管理平台会自动替换异常节点。
监控策略需要适应这种弹性，以基础设施为中心的监控工具难以适配这种场景，监控所关注的中心需要由基础设施变化为应用本身。CPU和内存指标与应用健康之间的关联变得很小，系统资源不足时自动扩展策略会自动添加新的节点。
更重要的监控指标是应用及应用内每个独立服务的响应时间及错误率，这些指标代表了这些服务是否真正在提供它们所需要提供的服务。APM工具天生就是用来提供这些信息的，因为它们的首要关注对象正是应用本身。
然而，这并不代表基础设施监控指标完全失去了它们的重要性，它们在故障根因诊断和容量规划方面发挥重要的作用，应用健康状态最好还是通过与应用直接相关的指标来衡量。
容量规划变得实时化
以往容量规划往往需要在一开始就做好，添加新的硬件需要花费很长时间，然而通过云计算，现在只需要一次简单的API调用，这有助于实现按需扩容和缩容，同时也对监控工具提出了新的要求。
过去监控工具通常被用来分析是否有太多计算资源被使用，现在它们需要报告何时容量过于冗余。由于云计算是按需付费的，及时关闭资源有助于节省费用。CIO们已经不再仅仅关注服务的SLA质量，同时也开始关心容量使用情况，以便尽可能节省资金。
编排平台也是软件，也有可能出错
基础设施平台需要自动化，类似于Marathon、Mesos、Kubernetes之类的应用编排平台使用越来越普及。我们发现很多人使用这些平台，却忘记了监控它们，然而当它们出现问题时，平台将失去自动化运行能力，而需要非常困难的手动管理。
所以监控工具同样需要监控这些应用编排平台，虽然这些平台后面有强大的开发社区，它们仍是年轻的软件并且人们普遍缺乏管理经验。
基础设施可能会实时变化
我的业务系统是什么样子的，我能把它画在白板上吗？这是运维大型系统时的关键问题。配置管理平台（CMDB）通过提供统一可信的配置和部署信息来解决此类问题，然而事实上这从来不是一种可行的方式。关键障碍在于这些信息需要手动从不同的来源录入CMDB，由于维护困难，CMDB中的信息总是会出现延迟，分析管理复杂业务系统的需求还是没有得以解决。当也需系统模块化后搜集相关配置数据变得更加困难，基础设施和网络随时都在改变，很有可能你永远都没有办法保持配置管理信息实时更新。
监控工具通常包含很多配置相关信息，他们在操作系统层面运行并且具备应用级别洞察能力。由于监控数据是实时的，它们可以自动实时维护应用基础设施配置关系，通过在监控工具中添加类似于CMDB的功能，手动数据维护工作可以消失了。通过监控工具和CMDB的结合，数据得以实时更新，配置管理的意义变得更高，因为它可以提供一些很有价值的信息，类似于“哪个服务正在访问数据库，从上次部署发生了哪些变化”。
重新思考你的监控策略
以上这些对监控意味着什么？绝大多数情况下你并不需要完全放弃已经构建的监控体系，你需要开始思考在采用云原生架构后监控策略如何演进，监控绝对不能成为事后才考虑的事情。
翻译自 https://www.oreilly.com/ideas/monitoring-cloud-native-applications
网友评论