atop工具

背景

1、某次收到某个应用一台机器14:32:02挂掉的报警。

2、于是一顿操作猛如虎,然后一脸懵逼:究竟是什么导致了系统挂掉!

3、于是求助了公司ops热线,发现一个好用的工具。解决了这个疑惑。这个工具就是atop。

先上一张图来加深印象:

正是从上图,得知,是有同学在14:32:02秒执行了less命名导致了系统cpu飙升。(这里先不分析为什么less会导致cpu飙升,本文主要讲解atop工具)。

现在开始介绍atop工具。

简介

 atop是一款用于监控Linux系统资源与进程的工具,它以一定的频率记录系统的运行状态,所采集的数据包含系统资源(CPU、内存、磁盘和网络)使用情况和进程运行情况,并能以日志文件的方式保存在磁盘中,服务器出现问题后,我们可获取相应的atop日志文件进行分析,其比较强大的地方是其支持我们分析数据时进行排序、视图切换、正则匹配等处理。

监控字段的含义

ATOP列:该列显示了主机名、信息采样日期和时间点

PRC列:该列显示进程整体运行情况

  1. sys、usr字段分别指示进程在内核态和用户态的运行时间
  2. #proc字段指示进程总数
  3. #zombie字段指示僵死进程的数量
  4. #exit字段指示atop采样周期期间退出的进程数量

CPU列:该列显示CPU整体(即多核CPU作为一个整体CPU资源)的使用情况,我们知道CPU可被用于执行进程、处理中断,也可处于空闲状态(空闲状态分两种,一种是活动进程等待磁盘IO导致CPU空闲,另一种是完全空闲)

  1. sys、usr字段指示CPU被用于处理进程时,进程在内核态、用户态所占CPU的时间比例
  2. irq字段指示CPU被用于处理中断的时间比例
  3. idle字段指示CPU处在完全空闲状态的时间比例
  4. wait字段指示CPU处在“进程等待磁盘IO导致CPU空闲”状态的时间比例

CPU列各个字段指示值相加结果为N00%,其中N为cpu核数。

cpu列:该列显示某一核cpu的使用情况,各字段含义可参照CPU列,各字段值相加结果为100%

CPL列:该列显示CPU负载情况

  1. avg1、avg5和avg15字段:过去1分钟、5分钟和15分钟内运行队列中的平均进程数量
  2. csw字段指示上下文交换次数
  3. intr字段指示中断发生次数

MEM列:该列指示内存的使用情况

  1. tot字段指示物理内存总量
  2. free字段指示空闲内存的大小
  3. cache字段指示用于页缓存的内存大小
  4. buff字段指示用于文件缓存的内存大小
  5. slab字段指示系统内核占用的内存大小

SWP列:该列指示交换空间的使用情况

  1. tot字段指示交换区总量
  2. free字段指示空闲交换空间大小

PAG列:该列指示虚拟内存分页情况

swin、swout字段:换入和换出内存页数

DSK列:该列指示磁盘使用情况,每一个磁盘设备对应一列,如果有sdb设备,那么增多一列DSK信息

  1. sda字段:磁盘设备标识
  2. busy字段:磁盘忙时比例
  3. read、write字段:读、写请求数量

NET列:多列NET展示了网络状况,包括传输层(TCP和UDP)、IP层以及各活动的网口信息

  1. XXXi  字段指示各层或活动网口收包数目
  2. XXXo 字段指示各层或活动网口发包数目

视图模视

1、默认视图(Generic information)

进入atop信息界面,我们看到的就是进程信息的默认视图(上图下半部分),按g键可以从其他视图跳到默认视图。以简介里的截图为例,我们可以看到PID为31085的find进程在退出前在内核模式下占用了0.45秒CPU时间,在用户模式下占用了0.10秒CPU时间,相对10分钟采样周期,CPU时间占用比例为3%,ST列表示进程状态,N表示该进程是前一个采样周期新生成的进程,E表示该进程已退出,EXC列指示进程的退出码。从进程名在“<>”符号中,我们亦可知该进程已退出。

2、内存视图(Memory consumption)

内存视图展示了进程使用内存情况,按m键可进入内存视图。如下图:

上图下半部分展示了每个进程占用的虚拟内存空间(VSIZE)、内存空间(RSIZE)大小,以及在上一个采样周期中虚拟内存和物理内存增长大小(VGROW、RGROW),MEM列指示进程所占物理内存大小。从上图的PAG列的信息,我们可以知道此时系统内存负载较高,页交换比较频繁,而且可以看出物理内存几乎完全不可用,swap分区也比较繁忙,从进程视图中VGROW和RGROW列可看出 lekker 进程占用内存量大量增长,部分进程占用的内存减少(VGROW或RGROW字段为负值),为lekker进程腾出空间。

3、命令视图(Command line)

这个对于查看具体某个命令的详细参数,很容易通过该模式下查看到。比如,我们有多个java程序,普通视图下,可能看到的只显示为java ,但通过命令模式,我们可以方便的区分出,到底是哪个java程序占用资源比较高。如下图:

4、磁盘视图

通过按键d 可以进入磁盘视图,可以查看每个进程占用IO的情况。

快捷键汇总

进入atop目录: /var/log/atop

读取atop日志文件: atop  -r  XXX

读取atop日志文件(更具时间范围): atop -r atop_20190325 -b 14:34 -e 14:35

前进翻页: t

后退翻页: T

进程列表前进翻页: ctrl + f

进程列表后退翻页: ctrl + b

按时间跳转:

 b

 Enter new time (format hh:mm):

 按hh:mm格式输入时间

进程视图:

g   —— 默认输出

m  —— 内存相关输出

d   —— 磁盘相关输出

n   —— 网络相关输出

c   —— 命令行输出

u  查看对应的用户资源使用情况

p  显示所有每个进程的所有信息占用情况(disk、mem、io)

P(大写) 正则匹配,显示所有匹配到的进程

退出atop:q

更加详细的说明:https://www.361way.com/atop/5162.html

架构师设计大纲

哪些项目必须写设计文档

DEV工作量大于等于2PD的项目必须写设计文档,建议所有项目都根据设计大纲确认一下有没有问题。

设计的坏味道

线上频繁执行SQL来修复问题

有大量的JSP后门

机制和策略不分离,任何修改都牵一发而动全身

设计大纲

按照项目研发流程设计

需求解析

分析相关方、计算收益,定义评估方法

描述背景、要解决的问题

名词及术语定义

总体设计

技术选型:涉及技术选型,需要对比候选方案的优缺点,特别要关注一个技术方案的缺点自己是否可以接受。

确定边界:系统边界、代码边界、接口边界等

确定交互流程:

  • 交互流程划分:业务交互流程、系统交互流程、模块交互流程
  • 交互流程检查点:一致性、性能
  • 策略算法相关功能:需要画出流程图

结构设计:

  • 逻辑结构:数据模型、时序模型、状态机模型;
  • 物理结构:DB;
  • 部署结构:分析依赖关系,后续要根据以来关系来撰写上线步骤

详细设计

存储设计:

  • 抽象出业务实体
  • 画出实体之间的ER关系图
  • 定义表结构,写出MySQL scheme变化
  • 考虑数据如何初始化

接口设计:

  • 接口组成:存储层接口、模块间接口、系统间接口
  • 接口应该抽象一组能力,良好的设计应该做到“机制和策略分离”,而接口应该承担分离的职责
  • 接口变化需要检查是否有兼容性问题

类图:类描述业务实体,需要描述清楚类之间的关系;类图的设计可以参考各种设计模式,

测试设计

可测性:尽量减少对环境的依赖,确定自测方法;策略算法相关的功能,需要提前想好如何获取数据、如何度量好坏;

测试范围:写明项目的影响面、确定测试范围。测试范围评估不准,会影响自测质量,进而导致联调时间偏长、QA测试时间偏长、QA测试评估不充分导致质量偏低。

测试用例:包括单元测试用例、接口测试用例、系统测试用例、面向C端的用例等

发布流程

写上线步骤:包括上线步骤、回滚步骤(必须和上线步骤相反,每一步都需要有回滚方案)、线上检查方法、应急方案(回滚或者降级);要重点检查兼容性。

上线前评估:上线时间(上线要评估对业务的影响,进而决定可行的上线时间)

阿里技术三板斧:可灰度,可监控,可回滚。

按照系统层次结构设计

存储设计

  • 抽象出业务实体
  • 画出实体之间的ER关系图
  • 定义表结构,写出MySQL scheme变化
  • 考虑数据如何初始化

API设计

构成:API可以划分为存储API、模块间API、对外API

方法:建议使用OOA、DDD等设计方法;一个良好的接口应该描述一组能力,可以尝试使用一句话来描述接口的能力。

模块设计

根据API粒度,按照服务原则,规划模块及模块关系

流程设计

  • 交互流程划分:业务交互流程、系统交互流程、模块交互流程
  • 交互流程检查点:一致性、性能
  • 策略算法相关功能:需要画出流程图

系统结构设计

  • 逻辑结构:数据模型、时序模型、状态机模型;
  • 物理结构:DB;
  • 部署结构:分析依赖关系

关键检查点和设计组成

工作量拆分

性能:

  • 存储性能:选择DB、设计表结构、设计Cache机制
  • 接口性能
  • 吞吐量
  • 数据规模

一致性:

  • 数据一致性:事务处理是否正确,是否涉及分布式数据一致性,是否需要分布式事务
  • 并发处理:锁、幂等机制等

监控

附录:设计流水账

  1. 明确交互流程:系统之间、业务、模块
  2. 交互流程关键节点:一致性、性能
  3. 底层API(对外、存储)、DB数据库设计(实体关系、scheme-SQL)
  4. 对现有系统影响范围,评估、应对方案
  5. 详细设计:接口、前端接口、类图
  6. 发布流程:兼容性、上线步骤、历史刷数
  7. 数据:增加字段如何处理,如何刷数据
  8. 用例Case(C端)
  9. 上线前前评估:吞吐量、性能、时间、数据规模
  10. 涉及状态:状态机
  11. 测试要点:TestCase、单元测试Case、自测方法、测试范围(事后用联调、QA测试状况来评估)、可测性(免环境)
  12. 业务模型、模块、层次图
  13. 工作量拆分
  14. 背景,要解决的问题
  15. 采用的代码设计模式
  16. 监控
  17. 性能(核心API)
  18. 边界:系统、代码、接口
  19. 拆出来提测文档
  20. 需求解析
  21. 逻辑结构:数据模型、时序模型、状态机模型;物理结构:DB;部署结构:依赖=>上线步骤
  22. 线上检查方法
  23. 事务:特例考虑分布式事务
  24. 数据处理方式:DB、Cache;一致性处理
  25. 并发处理:锁、幂等操作
  26. 发布考虑:监控、灰度、应急方案(回滚、降级)
  27. 技术选型:对比优缺点
  28. 数据模型
  29. 策略算法:需要画流程图
  30. 名词定义、术语
  31. 相关方、利益(收益)
  32. 问题:代码与设计不符
  33. 线上问题度量:线上执行SQL刷数据次数、JSP后门执行次数、蜂利器任务提报问题数量
  34. API类别:存储、对外、模块间
  35. API设计之前:先一句话描述