VMSS中Auto Scale基本原理及诊断
在前面的介绍中，我们看到通过定义规则可以实现虚拟机扩展集的auto scale，那么在后台执行上VMSS的扩展依赖于哪些组件，出现问题（比如自动扩展没有发生的时候），我们在拨打400之前，如何快速的检查是否是配置问题？
本文简单介绍一下VMSS下auto scale的原理，以及出现问题如何快速的检查问题。下图展示了Azure的计算资源监控和数据收集机制，从数据源来讲，Azure的监控数据可以来自于应用程序，诊断日志，系统、自定义的指标数据，也包括审计和操作日志。
例如在我们VMSS例子中用于自动化扩展的度量数据，来自于Linux Diagnostic扩展，扩展载我们做ARM模版定义的时候必须正确配置才能获得数据：
通过在Guest OS获得的metric数据会被保存在Azure Storage的Table当中，也可以保存在EventHub当中进行日志收集处理，收集的数据会被用于告警或者自动扩展处理，对于这些日志数据的访问，你可以通过Azure的portal，或者Powershell，或者使用命令行，或者使用REST API提供给第三方的工具进行监控：
在VMSS的ARM模板中，我们已经预先定义了一自动扩展的规则，获取数据的时间窗口，周期，进行scale out或者scale in的规则，那么在运行的时候，自动扩展引擎会根据定义的规则，时间窗口和度量值检测是否满足触发条件，一旦满足，就会执行相应的操作，例如增减，减少虚拟机，邮件通知等等：
到此为止，我简单介绍了一下VMSS的auto scale的工作原理和机制，那么现在问题来了，你部署了一个VMSS包含多个虚拟机，当压力增加的时候，你发现自动扩展没有发生，应该从哪些地方入手？
- 当然是检查你的ARM模版，看看你的LinuxDiagnotics是否定义，autoscale是否设置，规则是否正确等等。
- 打开你的Powershell并用RM登录，VMSS的autoscale依赖于两个Resource Provider，一个是Microsoft.Insights, 一个是Microsoft.Compute, 要确保他们的状态都是"Registered"，否则需要使用命令Register-AzureRmResourceProvider手工注册这两个provider：
- 登录到新的Azure Portal，单击你的VMSS的资源组，你会看到上次部署的记录，检查部署日志，正常情况下，所有的部署操作都应该是成功的，如果有任何问题，查看详细日志，修复错误操作并重新部署：
- 检查你的自动扩展选项是否为打开状态：
- 根据我们之前对于VMSS自动扩展的机制的了解，metrics数据会被写到Azure Storage Account里面，如果上面的配置都没有问题，那么我们需要看一下VMSS里面创建的存储账号，其中一个存储账号是存放诊断数据的：
如果你看到WADMetrics*这样的表产生了，至少说明你的诊断的存储账号配置是正确的；如果你没有看到任何这样的如下的表产生，则说明你的存储账号和自动扩展配置是错误的
- 请下载相关的Azure存储管理工具，比如http://storageexplorer.com/，拷贝你的诊断存储账号的账户名和密码，进行连接，查看WAD*表中是否存在数据，WADMetricsPT1H*存放每小时汇总数据，WADMetricsPT1M*存放每分钟采集数据，如果你看到数据产生，则说明你的Linux Diag Agent工作正常：
- 到此为止，如果上述检查都通过，而你看到你的VMSS中的虚拟机你所希望的度量值的确达到了要求，那么你需要看看你在ARM模板中定义的度量值和采集到的值是否一样，因为就CPU而言，也有非常多的度量值，例如早本例中，我们使用的是"\\Processor\\PercentUserTime"：
那么在storage explorer中,选择Query，在查询条件中field选择CounterName，查询值选择"\Processor\PercentUserTime"，查询该值的大小：
在大部分的情况下，如果前面的设置没问题，你的auto scale还是不工作，一般都是你的度量值设置有问题，比如如果你使用的是\Processor\PercentIdleTime，但实际上你看到度量值中这个并不高，你需要检查并调整下你的自动扩展策略。
基本上绝大部分问题都可以在上述的诊断中解决，了解了VMSS的基本工作原理，可以帮助我们更好的使用这个强大的功能~
