《监控运维实践:原则与策略》读书笔记

原文地址:https://www.lujun9972.win/blog/2022/03/17/《监控运维实践:原则与策略》读书笔记/index.html

目录

  • 书本信息
  • 监控实施的原则
    • 反模式
      • 以工具为中心而不是任务为中心
      • 监控岗位化
      • 监控系统无效、嘈杂且不值得信
      • 依赖监控规避故障
      • 自动化程度不足
    • 好的设计模式
      • 可组合监控
        • 数据采集组件
        • 数据存储组件
        • 可视化组件
        • 分析和报告
        • 告警
      • 从用户角度监控
      • 不要自己构建监控
      • 持续改善
    • 告警,值班与事件管理
      • 如何创建好的告警
        • 不同的告警通知渠道
        • 撰写运行手册
        • 慎用静态的阀值
        • 精简告警
        • 设定维护周期
        • 尝试故障自愈
      • 值班待命
      • 事件管理
      • 事后分析
  • 统计入门
    • 监控中常用的监控指标包括
    • 回顾数据的几个问题
  • 监控策略
    • 业务监控
      • 业务KPI
      • 将业务KPI与技术指标绑定
      • 应用程序中增加对应指标
    • 前端监控
      • 前端性能指标
        • Navigation Timing API
        • Speed Index
        • 日志
    • 应用程序监控
      • 关于应用程序性能监控(APM)工具的题外话
      • 监控构建和发布的指标
      • /health 检测
      • 应用程序日志
    • 服务器监控
      • 标准操作系统指标
      • SSL证书
      • SNMP
      • Web服务器 / 负载均衡器
      • 数据库服务器
      • 消息队列
      • 缓存
      • DNS
      • NTP
      • DHCP
      • SMTP
      • 定时任务
      • 日志
    • 网络监控
      • 网络性能
      • 接口
      • 配置
      • 路由
      • 机架
      • 流监控
    • 安全监控
  • 运行手册示例

书本信息

作者: [美]迈克•朱利安

出版社: 人民邮电出版社

图书封面

豆瓣地址:监控运维实践:原则与策略

监控实施的原则

反模式

以工具为中心而不是任务为中心
  • 监控不是一个单一问题,无法通过某一个工具来解决

    + 如果想在代码级别分析并监控应用程序,你可能需要 APM 工具,或者自行测量应用程序(例如,通过 StatsD)。
    + 如果需要监控云基础设施的性能,你需要寻找现代化的服务器监控解决方案。
    + 如果需要监控生成树拓扑结构的变化或路由变更,你需要寻找专注于网络的工具。
    
    1. 合并提供相同信息的工具
    2. 不要害怕引入专用工具

      团队希望使用能够解决问题的工具,而不是以“整合工具”之名被迫使用不能满足其需求的工具

  • 盲目崇拜更成功的团队以及公司的工具和程序

    团队需要花很多时间去理解为什么一个工具或程序是有效的。工具是工作方式、假设、文化和社会规范的表现。这些规范不太可能直接适用于你的团队。

监控岗位化

监控本身与被监控对象息息相关,不了解被监控对象就无法为其创建监控体系, 因此监控不是一份工作,而是一项技能,并且是团队中每位成员都需要在一定程度上掌握的技能

  在监控过程中,请坚持让每个人都对监控负责。DevOps 运动的一个核心宗旨就是让所有人而不只是运营团队对产品负责。
  网络工程师最了解应该监控网络中的哪个部分以及热点的分布。
  软件工程师比任何人都了解应用程序,所以应该将他们放在最合适的位置上,以便为应用程序设计最好的监控。
  • 确保监控的首要地位,只有部署好监控的产品才具备上线条件
  • 可以有专人创建监控工具,但监控本身不由其负责。
监控系统无效、嘈杂且不值得信
如何判断自己是否已经成为这种反模式的受害者呢?可以通过以下几种迹象来判断。

+ 虽然你记录系统负载、CPU 使用率和内存利用率这样的指标,但是服务还是在你不知道原因的情况下停止运行。
+ 你习惯性地忽略告警信息,因为它们多数时候是误报。
+ 你每隔 5 分钟或者更短的时间就要检查系统的指标。
+ 你没有存储历史指标数据(说的就是你,Nagios)。

这个反模式通常和上一个反模式(监控岗位化)一同出现。因为配置监控的人员没有完全理解系统的工作原理,所以他们经常只配置最简单和最容易的检查项

  • 弄清正常运行的真正含义
  • 系统资源类的告警不是很有用

        如果 MySQL 总是使用全部的 CPU,但是响 应时间在可接受范围内,那其实没有问题。
        这就是为什么与 CPU 和内存使用率这样的低级别指标相比,了解“正常运行”的含义要有用得多。
    
        当然,并不是说这些指标没有用。操作系统指标对于诊断和性能分析至关重要,因为它们能让你在可能影响性能的底层系统行为中发现波动和趋势。
        但在大多数情况下,它们并不意味着真正有问题
    
  • 增加收集指标数据的频率

        在一个复杂的系统(比如现在运行的这个)中,几分钟甚至几秒钟内就能发生很多事。
        考虑这样一个例子:假设不管什么原因ÿ

你可能感兴趣的:(无主之地,无主之地)