vsphere 故障排除

根据定义 ，故障排除被认为是对问题来源进行逻辑，系统的搜索以解决问题的方法。 现在，如果您还记得上次必须对生产系统中发生的特定问题进行故障排除的话，您会称之为逻辑和系统的吗？ 或者，您是否同意诸如忙碌和猜测驱动之类的词更有可能描述您所经历的过程？

如果您倾向于对后一个问题回答“是”，那么您最终会浪费大量时间来寻找答案。 更糟糕的是，由于该过程是完全不可预测的，因此会在团队内部造成压力，并且可能会开始指责：

在这篇文章中，我将分析导致这种情况的不同方面。 文章的第一部分重点介绍发生故障诊断的环境中内置的基本问题。 文章的第二部分将描述该领域中的工具和与人相关的问题。 在结束部分，我将显示隧道尽头仍然有一些光线。

生产中的故障排除

对生产中的特定问题进行故障排除时，往往会发生一系列特定的问题。 现在，许多不同方面都可能使该过程陷入困境：

首先，您面临着“ 让我们重新启动实例以恢复正常 ”的压力。 用最快的方法摆脱对最终用户的影响的愿望是很自然的。 不幸的是，重启也可能破坏有关实际根本原因的任何证据。 如果重新启动实例，您将无法再获取实际发生的证据。 即使重新启动解决了手头的问题，根本原因本身仍然存在，只是在等待再次发生。

接下来是与安全性相关的不同方面，这些方面往往会将工程与生产环境隔离开来 。 如果您自己无权访问环境，则将被迫进行远程故障排除，并涉及所有与之相关的问题：现在要执行的每项操作都需要多人参与，这不仅增加了执行每个操作所需的时间，而且一路上可能会丢失信息。

当您将“让我们希望这可行”补丁发布到生产环境时，情况越来越糟。 测试和应用补丁通常需要数小时甚至数天 ，从而进一步增加了实际解决当前问题所需的时间。 如果需要多个“让我们希望”补丁，则解决方案将延迟数周。

最后但并非最不重要的一点是要自己使用的工具。 您想要部署的某些工具可能会使最终用户的情况更加糟糕 。 就像例子：

• 从JVM进行堆转储将使JVM停止数十秒钟。
• 日志记录中详细程度的增加可能会引入其他并发问题。
• 附加的探查器的庞大开销可能使已经很慢的应用程序彻底瘫痪。

因此，很可能您最终会花费数天甚至数周的时间来传递另一个遥测收集脚本或另一个“希望它能起作用”的生产补丁：

考虑到在生产中进行故障排除时面临的问题，很自然地，在许多情况下，故障排除活动都是在不同的环境中进行的。

测试/开发中的故障排除

在其他环境中进行故障排除时，您可以避免在生产中困扰您的威胁。 但是，您现在面临的是一个完全不同的问题，最终可能会变得更糟：即重现生产中发生的性能问题的挑战。 有许多不同的方面使复制过程陷入困境：

• 测试环境未使用与生产相同的数据源。 这意味着由数据量触发的问题可能不会在测试环境中重现。
• 揭示某些问题的使用模式不容易重新创建。 试想一下仅在2月29日发生的问题，该问题要求Windows ME上的两个用户同时访问特定功能，从而触发特定的并发问题。
• 应用程序本身是不一样的。 生产部署可能具有明显不同的配置。 差异可能包括不同的操作系统，群集功能，启动参数甚至不同的内部版本。

这些困难导致臭名昭著的“在我的机器上工作”的报价被引入讨论中：

可以看出，与手边的环境无关，当您必须对某事进行故障排除时，手边的环境的性质会阻碍您的前进。

除了特定于环境的约束之外，还有其他方面也导致故障排除过程的不可预测性。 这将在下一节中介绍。

工具和经验丰富的人来救援？

如果使用的工具和故障排除准则已经成熟，那么环境约束将不是真正的卖座。 实际上，它远非如此-负责解决问题的工程师通常没有预定义的过程来解决问题。 老实说，您是否按照以下在shell中执行的操作顺序认识自己：

my-precious:~ me$ sar
sar: failed to open input file [-1][/var/log/sa/sa06]
/usr/bin/sar [-Adgpu] [-n { DEV | EDEV | PPP }] [-e time] [-f filename] [-i sec] [-s time]my-precious:~ me$ man sarmy-precious:~ me$ sar 1
15:29:02  %usr  %nice   %sys   %idle
15:29:03    1      0      2     97
Average:      1      0      2     97   my-precious:~ me$ sar 1 1000
15:29:06  %usr  %nice   %sys   %idle
15:29:07    2      0      2     97
15:29:08    1      0      2     97
^CAverage:      1      0      1     97my-precious:~ me$ man sar
my-precious:~ me$ sar -G 1 3
sar: illegal option -- G
/usr/bin/sar [-Adgpu] [-n { DEV | EDEV | PPP }] [-e time] [-f filename] [-i sec] [-s time]my-precious:~ me$ asdöäaskdasäl;
-bash: asdöäaskdasäl: command not foundmy-precious:~ me$

如果您发现上述内容太熟悉了，不要害怕，您并不孤单。 远非如此，大多数工程师缺乏在该领域的深入经验，因此无法根据公认的熟悉模式来取得进步。 这并不令人感到羞耻–除非您是Brendan Gregg或Peter Lawrey ，否则您就没有10,000小时的故障排除能力，无法让您成为该领域的专家。

缺乏经验往往会导致针对当前问题使用不同的证据收集工具，包括但不限于：

• 收集不同的指标（CPU，内存，IO，网络等）。
• 分析应用程序日志
• 分析GC日志
• 捕获和分析线程转储
• 捕获和分析堆转储

您可以使用的此类工具数量几乎是无限的。 如果您不满意，请在此处和此处查看列表。 随机试用不同工具的方法导致选择和试用工具所花费的时间比实际解决当前问题要花费更多的时间。

解决疑难解答的噩梦

除了累积将近10,000小时的分钟数（这将使您成为该领域的专家）之外，还有更快速的解决方案来减轻故障排除所带来的痛苦。

分析开发

为了清楚起见，该文章不是关于将剖析作为一种技巧。 对代码进行概要分析没有错，尤其是在将代码交付生产之前。 相反，了解应用程序各个部分的热点和内存消耗将首先防止某些问题在生产中影响最终用户。

但是，数据，使用模式和环境的差异最终只会暴露您最终将在生产中面临的部分问题。 可以很好地用作先发制人的措施的技术只能在追溯解决问题时极有帮助。

质量检查中的测试

投资质量保证，尤其是如果投资导致流程自动化是您可以构建的下一个防御之道。 如果进行周到和彻底的应用，测试将进一步减少生产中的事件数量。

但是，通常很难证明对质量检查的投资是合理的。 一切标有“性能测试”或“验收测试”的产品最终都将与清晰，可衡量的业务目标驱动的新功能竞争。 现在，当开发人员推动“执行某项性能”任务的唯一条件是某些缩写词时，此类任务将永远不会使其积压下来：

为了证明这种投资的合理性，您需要将投资的回报与活动联系起来。 将生产中的P1性能事件减少3倍可与其美元价值相关联，在这种情况下，它有机会与销售团队推动的下一个功能相抵触。

生产监控

您需要接受的第一件事是在生产部署中会出现问题。 即使是NASA也会不时地炸毁他们的飞行器，因此您最好为生产中发生的问题做好准备。 无论您的配置如何好或测试的透彻程度如何，错误仍然会漏掉。

因此，您无法避免对生产问题进行故障排除。 为了更好地完成手头的任务，您应该对生产环境保持透明。 每当出现问题时，理想情况下，您已经拥有解决该问题所需的所有证据。 如果您拥有所需的所有信息，则可以有效地跳过有问题的复制和证据收集步骤。

不幸的是，监视世界的最新技术无法提供任何灵丹妙药来揭示您在不同情况下所需的所有信息。 为典型的基于Web的应用程序部署的工具集应至少包括以下内容：

• 日志监控。 应该汇总来自生产堆栈各个节点的日志，以便工程团队可以快速搜索信息，可视化日志并注册异常警报。 最常用的解决方案之一是ELK堆栈，其中的日志存储在Elasticsearch中 ，在Logstash中进行分析，并使用Kibana进行可视化。
• 系统监控。 在基础架构中聚合和可视化系统级指标既有益又易于设置。 密切关注CPU，内存，网络和磁盘使用情况，可以发现系统级问题并注册异常警报。
• 应用程序性能监视/用户体验监视。 密切关注单个用户的交互将揭示影响最终用户的性能和可用性问题。 至少，您会知道您的应用程序提供的特定服务何时发生故障。 充其量，使用Plumbr时，您还可以放大源代码中的实际根本原因。

带走

故障排除是必不可少的。 您无法避免，因此您知道相关问题是公平的。 您无法绕过不同环境所带来的约束，也无法在一夜之间成为专家。

确保在发布之前在开发中应用性能分析并测试代码，从而减少了生产中故障排除的频率。 对生产部署具有透明性，每当两个安全网出现故障时，您都可以更快地以可预测的方式做出响应。

翻译自: https://www.javacodegeeks.com/2016/09/why-is-troubleshooting-so-hard.html

vsphere 故障排除