「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。

大家好，我是张晋涛。

由于上周在假期，所以没有推送新的文章。大家的假期过的如何呢？

我有一个托管在 Pipedream 上的 workflow ，该 workflow 订阅了我博客的 RSS，当有新文章发布后，会调用 Bitly 生成短网址，然后自动发推。正常情况下，它会保持 RSS 的处理状态，仅处理增量数据。

但是在两周前某天早上醒来，我收到一堆的告警和消息提醒，发现该 workflow 工作异常了，它将我的很多历史博客都推送了一遍。（事实上，幸好触发了 Bitly 的请求限制，否则它确实会把我的所有博客都推一遍）

经过与该司的 Co-founder 沟通，问题出现的原因是该平台出现了一些故障，导致 RSS 处理的状态数据丢失了。所以会将 RSS 的任务重新进行处理。

问题出现的原因和影响面这和我关系不大，知道在个结论已经足够了。简单说下如何避免后续再出现这种情况。

该平台提供了一个 Data Stores 的服务，用于进行一些持久化数据的存储。所以后续的处理办法就是选择了 guid 作为唯一值，存储在该服务中。该平台首选支持的语言是 NodeJS，所以也比较简单，如下配置即可。

export default defineComponent({
  props: {
    db: {
      type: "data_store",
      label: "RSS item keys",
    }
  },
  async run({ steps, $ }) {
    const { guid } = steps.trigger.event
    // Exit early if no GUID found
    if (!guid) return $.flow.exit("No GUID found")

    // Exit early if key is found
    const key = await this.db.get(guid)
    if (key) return $.flow.exit("GUID already found")

    // Else set and continue
    await this.db.set(guid, true)
  },
})

另外为了防止再重复推送，所以在恢复 workflow 运行前，我创建了一个新的 workflow，使用了 RSS 和上述的处理步骤，对数据做了下预热，确保已经都存储到了 Data Stores，并且能按预期工作。

既然 Data Stores 是一个持久化服务，这应该不至于再出问题了吧（笑

Prometheus v2.39 正式发布

Prometheus v2.39 近期正式发布了，这个版本中做了大量的资源优化和增加了一些新的特性。我聊一下我觉得比较关键的部分。

大幅度优化内存资源用量

在这个版本中 @bboreham 提交了一系列的 PR 来进行资源用量相关的优化，比如：

此外还有一些PR，我就不一一列举了。总结来说是改进了 relabeling 中的内存重用，优化了 WAL 重放处理，从 TSDB head series 中删除了不必要的内存使用，以及关闭了 head compaction 的事务隔离等。

尽管这些优化会根据不同的 Prometheus 使用情况造成不同的实际效果，但在 Grafana Labs 的一个大型 Prometheus 实例中可以看到，通过升级最新的版本，内存用量减少了一半左右。

prometheus memory usage

实验特性：增加对无序样本的支持

Add out-of-order sample support to the TSDB by jesusvazquez · Pull Request #11075 · prometheus/prometheus

这个特性确实可以多聊一点。我们知道对于 Prometheus 而言，它默认使用了自己的 TSDB，并且有两个主要的限制：

在给定的时间序列中，只能以基于时间戳的顺序附加样本，因此当相同 series 已有较新的样本时，不能摄取较旧的样本；
在整个 TSDB 中，最多只能追加比 TSDB 中最新样本早 1 小时的样本（这里假设默认是 2h 的 block 设置）；

虽然这通常适用于实时监控用例，但有时您可能有指标生产者需要摄取无序数据或超过一小时的数据。这可能是因为生产者并不总是连接到网络，需要在发送数据之前在更长的时间内聚合数据，或者类似的限制。在技术层面上，此类生产者可以以度量标准公开格式公开自定义客户端时间戳，或者使用 Prometheus 中的远程写入接收器来覆盖 Prometheus 自己的抓取时间戳。但是，Prometheus 的 TSDB 通常不会在这些样本出现故障或太旧时接受这些样本。

现在添加个这个实验特性是允许生产者发送无序数据，或者超 1 小时的数据（和上述假设一致）。可以通过 out_of_order_time_window 配置项进行配置。它接受的是一个时间周期的配置。比如可以进行如下配置：