0

我目前有一个正在使用的 Azure TSI 环境。

目前两种商店类型的环境GET请求

https://XXX.env.timeseries.azure.com/availability?api-version=2020-07-31&storeType=ColdStore
https://XXX.env.timeseries.azure.com/availability?api-version=2020-07-31&storeType=WarmStore

已开始恢复DateTime.MinValue其可用性range.from价值。在 Time Series Insights 用户界面和 Chrome 开发工具网络选项卡中可以观察到以下响应：

{
    "availability":{
        "intervalSize":"P3600D",
        "distribution":{
            "0001-01-01T00:00:00Z":371427749,
            "2020-04-15T00:00:00Z":1499591,
            ...
            "2011-09-21T00:00:00Z":137643193
        },
        "range":{
            "from":"0001-01-01T00:00:00Z",
            "to":"2021-07-03T07:05:49.182Z"
        }
    },
    "retention":"P7D"
}

这是一个错误吗？我可以通过选择分发中最旧的有效值来轻松解决这些问题。但是，我想知道分发响应DateTime.MinValue试图表达什么？

链接到 Microsoft 时序见解文档

编辑：

这似乎是我使用不正确的时间戳将数据发送到 TSI 的结果。其中时间戳相当于DateTime.MinValue. 因此，TSI 的反应是正确的。但是，似乎在这种特殊情况下warmstorage，TSI 的回应是：

availability?api-version=2020-07-31&storeType=WarmStore

{
  "availability": {
    "intervalSize": "P3600D",
    "distribution": {
      "2011-09-21T00:00:00Z": 132976370,
      "0001-01-01T00:00:00Z": 371393382
    },
    "range": {
      "from": "0001-01-01T00:00:00Z",
      "to": "2021-07-05T14:36:16.439Z"
    }
  },
  "retention": "P7D"
}

没有给我足够的数据来确定正确的warmstorage范围？

4

1 回答 1

1

时间戳为“0001-01-01T00:00:00Z”的摄取事件正在扭曲结果。上述可用性提供了基于摄取事件时间戳的范围。我们无法通过可用性 API 过滤事件。

您需要等到这些事件由于保留而从热存储中删除。TSI Gen2 暖存储保留期为 31 天。

于 2021-07-14T22:30:38.777 回答