如何为已安装的Nginx动态添加模块？
|
另外，如果系统的监控体系并不完备的话，还需要将问题发生时，操作系统、各第三方组件自带的监控数据快速地通过截图保存下来。 保存监控数据的时候要特别留意一下网络相关的数据。如果发现网络相关的数据有异常，那么再把当下的网络连接情况通过命令保存下来。因为相对来说，网络出现问题的概率远远大于硬件，不管是程序导致的还是其他原因。规模越大的系统，越是如此。 /02 恢复/ 恢复系统访问有很多方法。首先不得不提到一个适用于80%情况的神技了——重启。没错，根据多年的经验来看这招的确在大多数情况下很有效。 也正因为屡试不爽，所以很多人习惯性地会在第一时间去重启，导致现场忘记保存并受到破坏。 重启也分两种，强制重启和自然重启。当然优先考虑自然重启，这样能避免产生一些意料之外的脏数据。但是如果是系统出现资源耗用异常的话，就不要傻傻地等自然重启了，只能强制重启(kill掉进程)。 第二种常见的方法是「回滚」。当然它的前提条件是你判断下来问题的出现是由于最近一次发布。否则盲目的回滚不但起不到作用，还会越弄越乱，特别在分布式系统中。因为在分布式系统中，一旦上下游耦合的地方出现对接不上，轻则报错，重则出现大量的异常数据，够你后续折腾好久的。 第三种方法是「降级」。暂停出问题的模块，停止服务。当然，这个动作需要和业务方做好沟通，是否单独降级某个模块会导致业务不完整之类的问题。 第四种方法是「限流」或者「扩容」。如果你发现是系统扛不住突增的流量，如果有条件的话可以快速扩容几台机器和程序。如果没法扩容的话可以选择限流，将一定百分比的请求直接拒绝服务。毕竟所有无法提供服务和部分无法提供服务相比，肯定还是后者划算。 还有一些比较小众的方法是「切到备机」、「故障隔离」等，这里就不展开了。它们对环境、条件的要求更多一些。 有时候可能系统并未恢复到完全正常的状态，比如，读取数据是OK了，但是某些操作写入数据到时候还是有问题。在这样的情况下，不要着急定位问题，还是先尽最大努力恢复到最大程度的可用状态再进行下一步的动作，毕竟用户第一嘛。 /03 定位/ 关于定位问题，如果有dump文件的话最方便了，通过dump文件分析工具来分析dump文件就可以快速定位到出问题的代码行，特别是程序阻塞、内存溢出、cpu100%之类明显是程序本身的问题。 不同的语言有不同的dump分析工具，可以自行网上搜一下教程。最终目的就是定位到异常点的堆栈信息，有了它就相当于直接把问题代码出现在哪里都给定位到了。 如果说分析dump文件是跳过抽丝剥茧的步骤，直击要害的话。通过监控数据、日志层层分析是个慢活。但是如果缺失dump文件或者从dump文件从未能分析出问题的情况下，也只能选择后者。 我们在看日志、监控数据的时候一定要有关联起来看的意识，而不能仅仅在单个维度上看。因为有时候你在单个维度上看到的数据像是正常的，但是你关联起来看就不一定了。比如，tcp连接数降低了一半，但是内存反而涨了100%，为什么?这里面可能就藏着故障的线索。 /04 解决/ 定位到了问题，解决起来就很简单了。该改代码的改代码，该改配置的改配置文件。这里就不多说了，毕竟情况太多，大家遇到的可能都不太一样。 /05 复盘/ 大家都知道复盘的好处，但是真正做复盘的人真不多。如果你不知道从何下手来做复盘的话，不妨从以下几个问题入手，
如果你能回答这些问题，我觉得这个复盘就很到位了，剩下的就是执行。 当然了，不管如何优秀的处理故障，最理想的还是不要发生故障。所以我们需要在前期做更多的准备。 /01 了解你的程序/ 我们很多人了解自己负责的程序只有通过coding这一种途径。除非该程序是个单体应用，否则这样的方式是远远不够的。 我建议你按照以下清单去了解你的程序：
 （编辑：漯河站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
