keyhole操作文档#功能概述Part3

Keyhole操作文档

Part3

在第 3 部分中，您将了解 Keyhole 新的全职诊断数据捕获 (FTDC) 评估面板以及 FTDC 评分的工作原理。

作者在另一个 GitHub 存储库 mongo-ftdc 中从 Keyhole 中分离了 FTDC 分析功能，以更好地支持选择跳过 Grafana 安装的人。正如您所料，Keyhole 导入了 mongo-ftdc 包。

Five Boldest Strokes

• 有许多软件选项可用于显示 MongoDB 指标。大多数侧重于在图表中反映服务器状态，但没有一个提供标记问题所需的附加信息。没有简单的答案，因为需要考虑许多因素，包括资源可用性和质量、事务率和配置细节。

How Scoring Works(评分的工作原理)

• 为了消除数据中的任何异常，仅评估第 5 个和第 95 个百分位数之间的数据点。一个指标的得分可以从 0 到 100，得分越高越好。颜色代码在 Grafana 配置中定义。默认情况下，低于 20 的分数以红色突出显示，高于 50 的以绿色突出显示。 20 到 50 之间的分数以橙色标记。下面是一个例子：

  

  确定指标得分的公式因该指标的性质而异。在这个新功能的初始版本中，公式是根据作者的经验定义的。作者愿意接受反馈，并将在我们进行时微调指标。与此同时，让我们通过单击指标的链接来讨论可用公式的一些细节。

Low and High Watermarks

• 所有公式都有低和高使用水平线。如果使用量低于低水平线，则给出 100 分。另一方面，如果使用量高于高水平线，则分配 0 分。例如，ticket_avail_read 的分数是用公式计算的：

  100 * (p5 of ticket_avail_read) / 128
  

  ，其中 p5 表示数据点的第五个百分位数。

  另一个例子是 cpu_iowait；在这种情况下，分数的界限如下：

  value := (p95 of cpu_iowait)
  if value < low_wm { 
       
    score = 100
  } else if value > high_wm { 
       
    score = 0
  } else { 
       
    score = 100 * (1 - (value - low_wm) / (high_wm - low_wm))
  }
  

  ，其中 p95 表示数据点的第 95 个百分位数。

Metrics with Known Behavior

• 对于具有已知行为的指标，我使用给定的阈值作为低水印和高水印来计算分数。例如，当 WiredTiger 缓存使用（wt_cache_used）超过 80% 时，它会使用后台线程触发驱逐。如果使用的缓存超过 95%，则使用应用程序线程进行主动驱逐。因此，计算得分时，Keyhole 使用 80% 作为低水印，95% 作为高水印。

Metrics Calculated with Derived Values

• 一些指标的分数取决于派生值，例如连接总数 (conn_current)。仅根据连接数提供分数并不理想。相反，我们通过计算所有连接使用了多少内存来评估它。每个连接将占用大约 1MB 的内存。 Keyhole 首先计算分配给连接的内存百分比，并使用 5% 作为低水印和 20% 作为高水印来计算其分数。

Bottleneck Patterns

• Bottleneck Patterns · simagix/keyhole Wiki (github.com)

Lost in Space

• 即使配置的内存足以包含工作集数据，您也没有从正确配置的资源中获得预期的性能结果。在此模式中，除大量扫描对象外，所有指标均处于健康状态。这可能是使用不正确甚至缺失索引的教科书案例。即使整个工作集都适合内存，如果没有适当的索引，可能会出现过多的对象扫描。想象一艘没有导航系统的宇宙飞船在太空中漫游；将有更多的空间来覆盖，从而导致查询响应慢得多。

Dream Weaver

• 另一个常见的性能不佳的读取操作是由不太理想的数据访问用例引起的。大多数与读取相关的指标都被标记，例如低 WiredTiger 可用读取票证、高 WiredTiger 缓存使用以及大量扫描对象。
• 架构师和开发人员因其现代和灵活的技术而被 MongoDB 所吸引。通过简单的转换，您可以快速将 XML 转换为 JSON 数据或将关系数据库表直接映射到 MongoDB 集合。这就像梦想成真，Dream Weavers 喜欢使用 $lookup 运算符并允许许多集合不经意地交织在一起。这样的实现不能有效地工作。使用 MongoDB 的一个重要原则是拥有合适的架构来支持您的用例。 MongoDB 不是“无模式”；相反，它允许存在多个并发模式。但是，需要适当地设计这些模式。

Vikings Attack

• 除了一小段工作时间外，大多数对数据库的操作都在白天进行。在此期间，集群在 I/O 等待、WiredTiger 脏数据率和磁盘 IOPS 方面的 CPU 使用率很高。资源供应应基于高峰时段的负载。许多企业必须在有限的时间内处理大量交易。因此，数据库操作像突然的维京人袭击一样突然爆发——乘着快速的龙船抵达，并在清晨的潮汐中涌入。维京人庞大而庞大，他们带着长剑、斧头和圆形木盾无畏地冲锋。在这种情况下，这些短暂的“攻击”袭击了村庄，烧毁了磁盘 IOPS，并在检索完成之前将 oplog 收集带到了地面。

New York, New York

• 许多人赶到纽约来消散小镇的忧郁，所以纽约市有时可以腾出一点喘息的空间。同样，在 MongoDB 集群中托管过多的集合和索引会在 WiredTiger 中产生额外的开销。我们经常在多租户实现中看到这一点。为支持 WiredTiger 中的集合和索引而维护的大量表导致 WiredTiger 数据句柄数量众多，这会导致检查点过长并阻塞所有正在运行的操作。

Angel Has Fallen

• 几乎所有的指标都表明资源都处于压力之下。排队操作的数量很高，集群正在不安地追赶。所有资源都可以简单地从许多显示高空飞行高原线的图表中标出。如果没有调整空间，请考虑扩展资源或分片。

如果本文对您的学习工作产生了帮助，请您点一个免费的赞，您的鼓励是我继续创作的动力！