DevOps软件架构师行动指南(五)

DevOps软件架构师行动指南(五),第1张

DevOps软件架构师行动指南(五)

DevOps: A Software Architect`s Perspective
  • PART 3 横切关注点
  • 7. 监控
    • 7.1 监控什么
      • 7.1.1 故障检测
      • 7.1.2 性能下降检测
      • 7.1.3 容量规划
      • 7.1.4 用户交互
      • 7.1.5 入侵检测
    • 7.2 如何监控
    • 7.3 何时变更监控配置
    • 7.4 解释监控数据
      • 7.4.1 日志
      • 7.4.2 日志展示
      • 7.4.3 警报和警告
    • 7.4.4 诊断和反应
    • 7.4.5 监控 DevOps过程

PART 3 横切关注点 7. 监控

定义:观察并记录系统状态变化和数据流的过程。状态变化可通过状态的直接度量或记录更新状态的影响部分的日志来表示;数据流可通过记录内部组件与外部系统之间的请求和响应来获取。支持这些功能的软件系统叫监控系统。

监控涉及的方面:

  • 识别故障和相关缺陷,包括执行时和故障发生前后;
  • 识别单一系统和一组交互系统的性能问题;
  • 为长期和短期容量规划和交付账目而描述工作负荷;
  • 度量 用户对接口和业务产品的各种反应;
  • 检测企图入侵系统的入侵者。

难点:

  • 持续变更下的监控。由于系统改变、持续部署实践和云d性而导致监控指标阈值频繁变化;
  • 为不同的云环境选择方法(自上而下 / 自下而上);
  • 微服务架构要求监控的重心放到 移动部分;多服务间通信日志数据;
  • 大型分布式系统中的海量数据管理。
7.1 监控什么

大部分被监控对象来自栈的不同级:

监控目标数据来源发现检测应用和基础设施性能降低检测应用和基础设施容量规划应用和基础设施针对业务的用户反映应用入侵检测应用和基础设施

被监控基本项包含 输入、资源和输出。资源可以是硬件资源(CPU, 内存,硬盘和网络)也可软件资源(队列、线程池和配置说明);输出包括交易和面向业务的活动。

7.1.1 故障检测

检测物理基础设施的故障由数据中心负责。

软件故障检测分为三种:

  • 监控软件从外部点对系统进行“健康检查”;
  • 系统内的特殊代理执行监控;
  • 系统自检并发出报告。
7.1.2 性能下降检测

性能:延迟、吞吐率和使用率。

延迟
延迟指从活动开始到结束的时间。
粗度量下:延迟指用户发送一个请求到处理完成的时间间隔;细度量下,延迟指一个消息在网络上发出一个消息到接收到的时间间隔。

吞吐量
吞吐量是单位时间内某个特定类型 *** 作的数量。一个常见指标:Transaction per second

延迟关注单个用户或客户端,吞吐量关注系统。

用户数量下降会影响吞吐量(下降)。

使用率
使用率是资源使用的相对量。

7.1.3 容量规划
  • 长期容量规划:人工完成(按天、周、月、年)
    输入过程包括:1. 从监控数据收集的当前工作负荷;2. 基于业务和当前工作负荷做出的未来负荷预测。

  • 短期容量规划:自动执行(按分钟)
    常用方法:基于基础设施收集的监控信息进行判断和分配。

7.1.4 用户交互

用户满意度依赖于四个可被监控的因素:

  • 用户请求的延迟。用户期待的响应时间快;
  • 与用户交互的系统可靠性;
  • 特定业务产品或用户界面修改带来的影响;
  • 组织的特定指标集。

通常两种类型的用户交互监控:

  • 真实用户监控 (Real User Monitoring, RUM)
  • 综合监控。
7.1.5 入侵检测

入侵检测器是一个软件,他通过查看异常来监控网络流量。这些异常起因可能是 未授权用户尝试破坏系统 或 违反了组织的安全策略的 *** 作。

通常的方法:将网络上的当前流量与预期的(来自组织的历史记录)和异常的(来自攻击历史)流量进行比较,以判断当前网络是否被攻击。

7.2 如何监控


系统主动提供无代理的被监控数据,入侵式监控,影响系统设计;反之。

简单网络管理协议 (Simple Network Management Protocol, SNMP) 是从服务器和网络设备收集指标的常用机制。

监控的核心是记录和分析时间序列数据。这些数据点通常以连续的时间间隔获取,显示状态和状态变化的部分。对于其分析,有三个挑战:

  • 按时间关联监控项:分布式系统中的时间戳可能是不一样的;一个集群中的不同结点的时钟可能有数毫秒的差别,不同集群的不同结点差别更大。如果两次相关测量的时间差间隔大于定义用于判断关联关系的时间间隔,则会产生误差;
  • 按上下文关联监控项:假设正在执行滚动升级并在每个升级中替换两个实力,不同的节点会生成关于该实例升级的日志,若无法判断这些日志对应的实例,将为诊断问题带来困难;
  • 监控数据的容量。

一种可行的时间序列数据库: 轮转数据库 (Round-Robin Database, RRD).

7.3 何时变更监控配置

监控基于 时间 或 事件。

可能会改变监控配置的因素有:

  • 警告;
  • 部署;包括 金丝雀部署(见第六章)、滚动升级、功能激活或失活;
  • 对任何基础设施软件的变更;
  • 对配置参数的变更。
7.4 解释监控数据 7.4.1 日志

一种日志产生于在开发活动中。程序员应熟悉应用日志,他们在应用中输出系统状态和动作以帮助其开发、测试和调试;另一种由运维工具输出的日志产生,记录使用升级工具升级系统、迁移、管理配置等 *** 作。

生成日志的一般规则:

  • 一致的格式;
  • 包含日志生成原因的解释;
  • 条目应包含上下文信息:上下文信息不止是 时间,还有:
    • 代码中日志条目和来源;
    • 生成日志条目时进程执行的 进程id;
    • 导致进程 执行该日志生成器的请求id;
    • 生成该日志的虚拟机的ID;
  • 日志应包含筛选信息;
7.4.2 日志展示

有必要采用不同方式进行可视化。如 Graphite, 可支持对大数据进行实时绘图。

7.4.3 警报和警告

典型问题:

  • 如何配置 以减少误报(无需响应的警报)和漏报(需要采取行动却没有提示);
  • 如何配置监控系统 以使警告提供更多诊断信息;

改善警报的通用规则:

  • 为警报引入背景信息;
  • 发生某件事情不仅需要出发警报,也要为其未发生但预期要发生的事情做警报;
  • 将可能指向相同的事件的不同警报汇聚一起;
  • 设置清晰的严重性和紧迫性等级;
7.4.4 诊断和反应

运维人员以特定的方式 尝试关联事件、探索细节、请求执行和检查日志。

7.4.5 监控 DevOps过程

需监控的几个重要事项:

  • 业务指标
  • 周期时间
  • 发现错误的平均时间
  • 报告错误的平均时间
  • 丢弃(重复工作)的数量

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5678813.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-17
下一篇 2022-12-17

发表评论

登录后才能评论

评论列表(0条)

保存