Get best of the week

集成服务器负载指标评估

在该国最大的银行之一工作时，我不得不处理评估约1.6万台服务器的资源使用效率的任务。该任务的制定非常简单-必须开发一种方法来评估一段时间内的服务器负载指标。理想情况下，应使用一个或几个（不超过8个）数字来估算每个时间段的服务器负载。

关于使用虚拟服务器的功能的几点说明


大型组织（尤其是银行）使用各种虚拟化技术将传统应用程序部署在不同的服务器上，杂乱无章。私有云是一种有前途的技术，但实际上，大型组织将长期使用各种虚拟化平台来部署各种应用程序。

随着虚拟化平台的发展，公司中没人会了解资源的使用效率。由于各种服务器使用情况，即使是最先进的监视工具也无法提供此问题的答案。例如，一个部门可能有一个报表服务器，它将仅在有限的时间段内完全加载。在月底说3-4个小时。在现实生活中，没有人为这些服务器动态分配资源-这在技术和组织上都是困难的。资源是专门为最大的周期性服务器负载分配的，尽管这种情况很少发生。

总之，在大型组织中，虚拟服务器场资源的使用效率极低。

下面，我提出一种方法，您可以通过这种方法轻松地证明分配给虚拟服务器的资源的增加和减少的理由，而不管情况如何。

方法


要评估资源负载，有必要收集各种计数器的统计信息；要评估资源负载，将使用各种度量。按照惯例，计数器可以分为两种类型（根据变化率）：“快速”和“慢速”。 “快速”计数器的一个很好的例子是处理器负载计数器（％CPU）。慢速计数器的一个示例是可用硬盘空间的百分比（％FreeSpace）。
慢速计数器的评估包括计算该期间指标的极值（最小值或最大值）。这种方法允许（例如，在评估磁盘可用空间时）估计可用资源，并在必要时分配其他卷或减少当前卷。

对于快速计数器，使用另一种方法。在这里很好地描述了使用简单的积分指标（平均值，最大值，最小值和中位数）来评估此类计数器的动态的缺点。常见的缺点包括缺乏有关增加的负载（中和峰值）的信息。如果我们将周期的最大值作为整数指标，那么异常值的存在（例如，程序启动时CPU的即时加载高达100％）将无法提供客观信息。

在文章中建议使用0.9分位数来估算快速度量（此值表示在90％的样本中观察到的值位于该水平以下的水平）。根据此指标，在服务器负载均匀的情况下，我们可以充分估计平均处理器负载。但是这种方法具有相同的缺点-缺乏有关增加的负载（中和峰值）的信息。

下面，以％CPU计数器的每周和每日图表为例。图表上的最大计数器值为100％。





该图显示，在指定的时间段内，负载突增，持续约3小时。对于此计数器，本周计算了各种指标。图2显示，中值（绿线，5％值），平均值（黄色，12％值）和0.9分位数（红色，27％值）过滤了负载变化，并且丢失了有关负载的信息。

作为分位数概念的发展，我想提出滑动分位数的概念。这类似于移动平均线。但分位数0.9用作窗口函数。此外，我们将使用2个滑动分位数来估算计数器的级别-短期（1小时）快速运行，而长期（24小时）缓慢运行。快速分位数将过滤掉瞬时排放并提供峰值负荷信息。缓慢的分位数将允许您估计平均负载。

从图中可以看出，移动的分位数为0.9是动态特征（棕色-快速，紫色-慢速）。为简单起见，评估计数器的状态作为建议使用的指标：

  • 1小时周期的最大分位数，显示该时间段内的最大连续服务器负载，
  • 24小时的平均分位数，显示该期间的平均服务器负载。

在图中，快速分位数的最大值是85％处的黑线，慢速分位数的平均值是30％处的粉红线。

因此，在分析服务器资源的负载（根据％CPU计数器）时，如果我们将月份的平均值（12％）作为度量标准，则会做出错误的决定以减少分配的资源。双快/慢移动分位数度量（分别为85％和30％）表明分配的资源足够，但是没有剩余。

决断


资源利用效率评估的实施已分解为三个任务：

  1. 数据采集
  2. 评估方法的发展
  3. 当前架构中的方法论实施

上面，我检查了此实现的任务2，下面我们将讨论第三个任务。

数据收集在ClickHouse数据库中。 DBMS专栏是存储时间序列数据的理想选择。在2019年9月5日的ClickHouse聚会中对此进行了详细讨论。可在此处找到ClickHouse与其他时间序列DBMS的比较。
由于数据收集的结果，我们形成了几个表，其中的数据是逐行组织的（每个计数器的值写在单独的行中）。当然，原始数据也存在问题。

第一个问题是计数器条目之间的间隔不均匀。例如，如果标准计数器记录时间为5分钟，则有时会出现间隙，下一条记录会比上一个记录多5分钟（最多20分钟）。

第二个问题是，有时计数器数据使用相同的时间戳出现两次或多次（具有不同的值）。

第三个问题-ClickHouse没有窗口功能。

要解决第一个问题，可以使用ASOF JOIN。这个想法很简单-每个服务器的每个计数器都以均匀填充的时间间隔均匀地创建一个表。使用ASOF JOIN允许使用原始数据表中最接近的值填充新表中的值（可以配置类似于ffill和bfill的填充选项）。

第二个问题的解决方案是在给定时间选择最大值进行聚合。

为了解决第三个问题，考虑了几种解决方案。首先，由于性能不足，Python脚本被拒绝。第二种解决方案-将原始数据复制到MSSQL数据库，计算指标并复制回-实施起来似乎太复杂了。MSSQL也具有窗口函数，但是不需要聚合函数。可能会感到困惑，并编写了自己的SQL CLR函数。但是由于过于复杂，该选项被拒绝了。

一个有效的解决方案可能是ClickHouse的SQL脚本。下面给出了此脚本的示例。为简单起见，我只查看了多个服务器的单个计数器的快速分位数。该解决方案看起来不是很简单，也不是很方便，但是可以工作。

结果，在PowerBI中创建了一个测试报告以演示该方法。





结论


最后，我想对解决方案的开发进行推测。如果从数据仓库的角度看解决方案，您会发现以这种方式解决了从原始数据层（暂存区）创建数据仓库（数据仓库）的任务。您可以讨论该体系结构，但对于ClickHouse作为列数据库而言，规范化并不重要（甚至可能有害）。

在创建具有不同生存期（TTL）的汇总表（日，周，月）时，可以看到存储库的进一步发展。这样可以避免存储过度膨胀。
下一步可能是将数据用于预测分析。

附注

：用于测试的代码和数据已发布在此处。

More articles:


All Articles