# Metrics Insights 问题排查
<a name="cloudwatch-metrics-insights-troubleshooting"></a>

## 结果包括“其他”，但未将其作为维度
<a name="cloudwatch-metrics-insights-troubleshooting-other"></a>

这意味着查询包含 **GROUP BY** 子句，该子句指定查询返回的某些指标中未使用的标签键。在这种情况下，会返回名为 `Other` 的空组。不包含该标签键的指标可能是聚合指标，这些指标返回该标签键的所有值之间聚合的值。

 例如，假设我们有以下查询：

```
SELECT AVG(Faults) 
FROM MyCustomNamespace 
GROUP BY Operation, ServiceName
```

如果某些返回的指标不作为维度包括 `ServiceName`，则这些指标将显示为将 `Other` 作为 `ServiceName` 的值。

要防止在结果中看到“其他”，请在您的 **FROM** 子句中使用 **SCHEMA**，如以下示例所示：

```
SELECT AVG(Faults) 
FROM SCHEMA(MyCustomNamespace, Operation)
GROUP BY Operation, ServiceName
```

这将返回的结果限制为同时具有 `Operation` 和 `ServiceName` 维度的指标。

## 我的图表中最早的时间戳的指标值比其他时间戳的指标值低
<a name="cloudwatch-metrics-insights-troubleshooting-oldest"></a>

CloudWatch Metrics Insights 支持长达两周的历史数据。当您使用大于 1 分钟的时间段绘制图表时，可能会出现最早的数据点与预期值不同的情况。这是因为 CloudWatch Metrics Insights 查询仅返回两周保留期内的数据。在这种情况下，查询中最早的数据点仅会返回两周界限内测得的观察值，而不会返回该数据点时间段内的所有观察值。

## 使用基于标签的查询时，不同时间段的指标值不一致
<a name="cloudwatch-metrics-insights-troubleshooting-tag-mutations"></a>

在 CloudWatch Metrics Insights 查询中使用带有标签的 `WHERE` 或 `GROUP BY` 子句时，根据所选的时间段，可能会看到不同的指标值。例如，6 小时的时段可能显示峰值 20，而 1 小时的时段在同一时间窗口内仅显示峰值 2。

出现这种情况是因为标签时间戳以二级分辨率存储，而指标数据点则与时段边界（例如，每分钟或每小时的开始）对齐。为了确定哪些数据点与标签时间范围匹配，CloudWatch 通过减去一个时段来调整该范围的起始点。对于较长的时段，此调整会在标签时间戳和最早包含的数据点之间造成更大的间隔，这可能会导致范围起始点附近的数据点被排除在外。

以下示例说明了这会如何影响查询结果。一个指标有两个标签值：`env=beta`（从 00:00 至 01:30）和 `env=gamma`（从 01:30 至 03:00）。每个标签覆盖 90 分钟的数据，总和为 270。

![\[两张 CloudWatch 指标图表，将基于标签的查询结果与 1 分钟和 3 小时的时段进行了比较。\]](http://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/images/metrics-insights-tag-alignment.png)



| **env=beta，时段为 1 分钟** | Statistic | 预期 | 返回值 | 区别 | 
| --- | --- | --- | --- | --- | 
| SUM | 270 | 271 | \$11 | 
| AVG | 3.0 | 3.0 | 0 | 
| MIN | 1 | 1 | 0 | 
| MAX | 5 | 5 | 0 | 
| SAMPLE\$1COUNT | 90 | 91 | \$11 | 


| **env=gamma，时段为 1 分钟** | Statistic | 预期 | 返回值 | 区别 | 
| --- | --- | --- | --- | --- | 
| SUM | 270 | 275 | 5\$1 | 
| AVG | 3.0 | 3.0 | 0 | 
| MIN | 1 | 1 | 0 | 
| MAX | 5 | 5 | 0 | 
| SAMPLE\$1COUNT | 90 | 91 | \$11 | 

对于 1 分钟的时段，对齐调整很小（1 分钟），因此每个标签只包含 1 个额外的数据点。对于 3 小时的时段，调整跨越了整个查询范围：


| **env=beta，时段为 3 小时** | Statistic | 预期 | 返回值 | 区别 | 
| --- | --- | --- | --- | --- | 
| SUM | 270 | 540 | \$1270 | 
| AVG | 3.0 | 3.0 | 0 | 
| MIN | 1 | 1 | 0 | 
| MAX | 5 | 5 | 0 | 
| SAMPLE\$1COUNT | 90 | 180 | \$190 | 


| **env=gamma，时段为 3 小时** | Statistic | 预期 | 返回值 | 区别 | 
| --- | --- | --- | --- | --- | 
| SUM | 270 | 540 | \$1270 | 
| AVG | 3.0 | 3.0 | 0 | 
| MIN | 1 | 1 | 0 | 
| MAX | 5 | 5 | 0 | 
| SAMPLE\$1COUNT | 90 | 180 | \$190 | 

对于 3 小时的时段，两个标签都会返回整个数据集（SUM=540，SAMPLE\$1COUNT=180），因为单个聚合数据点的时间戳在两个调整后的范围内。标签边界已被有效擦除。

要减少此行为的影响，请尝试以下方法：
+ **使用较短的聚合时段。**较短的时段（例如 1 分钟或 5 分钟）更贴近地匹配标签时间戳的二级分辨率，这样可以最大限度地减少对齐间隔，并且更有可能包含所有相关数据点。
+ **使用基于维度的筛选而不是标签。**如果使用案例允许，请按维度而不是标签进行筛选。基于维度的查询不受此行为的影响。例如，使用 `WHERE InstanceId = 'i-1234567890abcdef0'` 而不是 `WHERE tag."my-tag" = 'my-value'`。
+ **以一致的粒度进行查询。**比较不同时间窗口的指标数据时，请使用相同的时段，以避免因对齐调整导致的意外差异。