其实大部分的操作前面都已经学习到了，综合篇的最后就是各种总结，总结各种之前学到的工具方法并进行分类。下面给出我的几个总结要点。

USE（utilization、saturation、errors）

这个给我们了一个指标思路，看系统是否存在问题，这三个大的指标往往预示这么我们该往哪个方向去走，不会迷路
相对应的，我们对应应该注意的就是：CPU、内存、IO、文件系统、网络这些的 use 指标如何

监控

有的问题，当我们去服务器上看可能已经晚了，有时候监控对于我们来说是有必要的。
根据学到的和了解到的我也总结了监控的相关：
https://www.jianshu.com/p/2316f72b4aa0

动态追踪

无论是 strace 还是 perf 还是 sysdig ，当我们出现问题需要定位的时候，往往动态追踪能像手术刀一样切开我们的程序，让我们知道程序这个时候到底在对我们的 linux 系统做什么操作，导致我们的 linux 系统出现了问题。

很多人会说，我们有日志系统，但是事实情况证明，有的时候日志并不完全靠谱。一方面程序员自己都知道我有的时候回忘记打印日志。另一方面线上往往日志级别不够暴露问题。还有就是日志过多无法精确筛选到当时出现问题的关键。有的时候还会出现日志不动，程序假死等奇怪问题，往往这些问题，动态追踪就能发挥它的作用。

第一次接触 strace 的时候我就觉得它真的太强大了，从底层就给你翻出你到底在干啥。

限制

当容器化普遍之后，容器的方便让人往往忘记了很多事情。限制就是其中一个。具体来说就是，目前我们线上跑的容器 CPU 和内存都是没有任何限制的，能吃多少全看应用自己。虽然现在为止没有问题，而大多数情况下也好像看似稳定，但是保不齐一颗毒瘤就在其中，可能导致整个集群影响。

总结

其实综合篇的最后总结了很多图，很多表格，告诉我们在什么情况下应该怎么做。但是个人觉得其实对我们来说表格其实用处真的不大。说白了线上出现问题之后，你对应着表格去找问题？
Linux 性能分析和优化往往代表着经验和能力。

  • 了解背后的运行原理和机制
  • 可能的原因
  • 定位和解决问题的思路

或许我认为这三点可能对我来说更加重要，也是我看下来学到最多的。
剩下的我建议和前人去请教一下线上曾经出现问题的经验更重要，他们会告诉你曾经出现过什么问题，如何定位和解决的，因为曾经出现，代表你以后大概率就会遇到。