内容简介：读DevOps软件架构师行动指南02(6.6)
监控
随着DevOps的发展对监控提出了新的挑战，DevOps的持续交付，持续部署和强烈依赖自动化意味着更加频繁的系统变更，同时在使用微服务架构时也使得数据流的监控更具挑战。这里面实际的难点包括了多方面：
1. 持续变更增加了监控本身的复杂度，持续的变更和部署使整个环境处于一种不稳定状态。
2. 和云环境的集成增加了监控难道，特别是PaaS平台集成后底层资源往往处于不可见状态。
3. 监控已经从传统的网管类资源监控，转移到了应用和服务监控，如APM应用性能分析和服务监控。
4. 微服务架构下微服务模块和服务接口都成倍增加，即要监控部署包又要监控服务接口
5. 在大型分布式系统中，管理和分析日志成为一个大的挑战
对于DevOps的监控，我们一定要意识到一个大的变化点， 即从传统的网管应用对资源层的监控，转移到了对应用和服务本身的性能监控分析。 监控不再局限于传统的CPU和内存，数据库和中间件关键指标，而更多的变化为对应用本身的性能，服务性能，服务调用链的实时分析和监控。
无代理监控方案对应用和环境侵入最小，配置容易，但是可能需要开放更多端口，存在安全隐患。同时无代理方案本身监控的指标详细度往往也不足够。
监控的目的和用途，书里面主要列举了如下几个方面的内容：
1. 故障检测： 包括两种方式一种是完全外置，一种是需要内置代理到应用或服务器
2. 性能下降检测： 对于访问延迟，吞吐量，CPU和内存利用率等是常用的监控指标体系。
3. 容量规划： 长期容量规划需要人工进去，而短期完全借助PaaS平台本身的资源动态调配扩展能力。
4. 用户交互： 最好理解为对用户访问行为信息的数据采集和分析，包括访问时长等性能信息。
5. 入侵检测： 主要是通过设置的安全策略和网络流量监测来判断是否遭到入侵。
监控的核心是记录和分析运维时间序列数据。监控系统可以直接度量或收集存在的数据，统计，日志，然后转换为指标，这些指标的属性包括了时间和空间。然后使用预定义的协议将这些数据传输到存储库。
日志是事件的时间序列，日志在监控中起着非常重要的作用，尤其是在DevOps设置中。对于日志监控不再只是传统运维中的数据库和中间件日志，在DevOps中运维人员已经成为第一干系人，因此日志包括了应用和服务的关键日志信息，这些日志方便运维人员进行故障诊断和问题排查。
日志关键信息（机器ID，进程ID，类型，错误等级，时间，详细内容，关键标签等）
对于日志监控，现在常见的 ELK(ElasticSearch, Logstash, Kibana) 是一个完整的覆盖日子采集，分析和可视化展示的完整解决方案。而对于flume更多只是日志采集方案，当然也可以基于flume，storm，kafka等主流技术来自定义适合业务需求的日志采集和监控解决方案。
监控系统向运维人员提供重要的事件信息，这些信息以警报或警告的形式提供，其满足预设的触发条件的时候就被触发。在监控系统中，将包含大量覆盖系统很多方面的大量指标，意味着可能会产生大量的警报或警告信息，因此在预警或报警规则设置的时候需要折中处理，否则会告警疲劳。
对于监控的工具，可以分为三大类 工具 进行分析
例如Nagios, Zabbix等开源监控解决方案。
2. 基于日志采集和分析类工具： 例如前面谈到的ELK解决方案，Flume+Storm+Kafka解决方案等。
3. APM应用性能监控工具： 基于自上而下的监控和分析路线，从应用和服务入手再到资源层。
随着DevOps的发展，个人更看好APM应用性能监控和发展 ，即我们传统的对资源的监控，基于CPU和内存，进程等的由下而上的监控更多都是被动式的监控模式，更逐渐会被自上而下的监控，基于应用和服务驱动的监控替代，即一种主动第一时间发现问题，面向客户并提示客户满意度的模式。
在DevOps的实践中，需要考虑如下一些安全方面的活动和内容：
1. 安全审计： DevOps的全流程是否符合企业标准的安全策略，包括Dev和Ops基于安全的协作活动。
2. 部署流水线安全： 整个部署流水线作业是否会受到恶意攻击和侵入。
3. 微服务架构安全： 其中重点是保留的微服务接口服务本身的安全。
安全审计： DevOps中一个流行语即是，基础设施即代码，也就是说把脚本和DevOps过程规格说明视为代码，使用和代码相同的质量控制实践 。安全策略，监管规则和配置可以自然地内置在基础设施代码和自动化中以便于审计。自动化也可以帮助生成安全审计和合规性报告。
安全这章讲的不太好，实际上更多是云安全，应用安全，基础设施安全等方面内容的归纳总结，而实际我们真正关心是DevOps下的安全，即DevOps部署流水线和微服务架构下需要怎样的安全策略和技术配合支撑等。因此对于这部分内容看小结部分总结基本就够了，具体如下：
传统的Devs和Ops也分别形成了安全关注点的两个不同领域。开发者关注应用安全设计，而运维关注基础设施和运维环境安全。应用安全本身也依赖于运维安全。通过基础设施即代码，开发人员驱动的自动化和DevOps工具，DevOps正在把一些运维安全责任转移给开发人员和工具。
对于DevOps实践，从一开始就应该考虑安全验证和确认，并且通过DevOps流水线自动化的在不同阶段执行，包括安全检测也可以通过自动化工具在某一个阶段自动执行。但是在单元，集成和系统级别上执行合适的和半自动化的安全分析和测试不是一件简单的事情。
对于DevOps的安全，不仅仅是关于应用和运维安全的，而且也是关于流水线本身的安全，例如构建/测试服务器安全，微服务组件安全，环境安全和动态配置期间的安全等 。
其他非功能性需求
注意这里谈的非功能性需求不是软件本身的非功能性需求，而是DevOps流水线的非功能性需求。
首先DevOps流水线本身也是一个软件产品，这产品的最终用户是开发和运维；其次，DevOps流水线具有过程的属性，相对于产品质量和性能，这里提到的一些非功能性需求更多的与过程质量和性能相关。
对于DevOps流水线的非功能需求和质量关注点可以简单描述如下：
1. 可重复性： 重复相同操作的可能性程度。
2. 性能： 执行DevOps操作所需要的时间和资源。
3. 可靠性： 在一定时间周期，DevOps流水线和内部各软件保持服务状态的程度。
4. 可恢复性： 失败的DevOps操作恢复到希望状态的程度。
5. 互操作性： 特定环境下，不同的DevOps工具通过接口有效的交换信息的程度。
6. 可测试性： 通过测试，DevOps运维软件能够很容易的展示错误。
7. 可修改性： 修改DevOps软件，过程或应用运维环境所需要的工作量。
对于DevOps流水线来说，这里面最重要的仍然是可靠性，可重复性和性能，同时还包括在出现故障后的快速恢复能力，包括了整个流水线的全程可视化监控和管理能力。这些都是我们在进行流水线设计，流水线的每个阶段和活动工具和组件选择的关键要素。
这要求流水线中的每个活动涉及到的组件或工具，都具备暴露南向和北向接口服务的能力，提供供管理监控台进行状态监控和日志数据实时采集的能力。 这些都是必须工作，而不是简单的通过工具实现自动化就完事。
DevOps的目的是减少从向系统提交变更到这个变更被部署在正式生产环境所需要的时间，同时保证高质量。保证高质量意味着，在将最终的高质量系统提升到正式生产环境之前，可能进行多次问题检测和问题修复的迭代。减少问题检测和问题修复的时间也是重要的。
因此两个重要的度量是，从提交到初始生产环境的时间和问题检测到修复的时间。对于DevOps，这部分进一步从五个方面给出了实践指导：
1. 在开发系统时，让Dev把Ops作为首要干系人。
2. 让Dev更直接的参与到故障和问题处理过程中，包括对详细异常信息和日志的查看和分析。
3. 为了将软件变更部署到生产环境，强制执行一致性的过程。
4. 开发基础设施代码的时候采用与开发应用程序代码相同的实践。
5. 实施持续交付的流水线自动化作业能力。
持续部署流水线
持续部署流水线主要包括了5个阶段，即构建和测试，烧制，部署，发布，拆解。
1. 构建和测试： 版本管理工具，分支管理，自动化构建脚本和自动构建，自动化单元测试等。
2. 烧制： 即制作虚拟机镜像或轻量的 Docker 容器镜像。
3. 部署： 部署一个独立的应用程序栈，需要支持负载均衡，伸缩，监控，组网和数据库等能力。
4. 发布： 发布重点是DNS路由器的重新分配和迁移
5. 拆解： 一旦所有流量迁移到新栈后，拆解旧栈
标准化的应用程序生命周期在持续部署系统中作为一个计划实施。标准的镜像文件的部署也不仅仅是镜像启动，还涉及到服务的注册，负载均衡的挂接，环境变量和配置文件的修改等一系列工作。
以上所述就是小编给大家介绍的《读DevOps软件架构师行动指南02(6.6)》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
