有堂课讲到了我们大学所在城市的特色食物凉粉，关于它的文化以及制作原料 — — 豌豆。

豌豆为什么要叫豌豆？为什么在川渝地区非常流行而其它地方很少见？安徒生童话中的豌豆公主、豌豆花与碗杂面、豌豆尖汤有什么关联？

我当时没有深究。但这些问题留在了脑子里，像一颗种子，等着某一天发芽。
豌豆为什么要叫豌豆？在那堂课上，老师提到了豌豆的「豌」指的是西域国家「大宛」。

大宛，古国名，在今中亚费尔干纳盆地，张骞出使西域时，带回了葡萄、苜蓿，也带回了豌豆。

从地理分布上来看，四川重庆地区吃豌豆比较多，而西方的故事中也有豌豆身影 — — 安徒生的《豌豆公主》，英国的豌豆泥。

安徒生写过两篇关于豌豆的童话。

一篇是《豌豆公主》。王子要找真正的公主，怎么也找不到。一个雨夜，一个女孩敲开了城门，说自己是公主。皇后在她的床上放了一颗豌豆，压了二十层床垫和二十层鸭绒被。第二天早上，女孩说她睡得不舒服，有什么东西硌着她了。于是所有人都相信，她是真正的公主 — — 因为只有真正的公主，皮肤才会那么敏感。

一篇是《五粒豌豆》。一个豆荚里有五粒豌豆，它们都想飞到远方去。前四粒豌豆各有各的愿望，但都被鸟吃掉了或者烂在沟里。只有最后一粒豌豆，飞到了一个贫苦病弱的小女孩窗前，生根发芽，开出紫红色的花朵。小女孩看着它，一天天好起来。

小时候读这些故事，只觉得有趣。现在想想，豌豆在安徒生笔下，好像总是和「敏感」有关。

豌豆公主敏感，因为她能感受到别人感受不到的东西。窗前的豌豆敏感，因为它能在一个病弱女孩的生命里，开出花来。

豌豆最主要的作用还是吃。

嫩豌豆是甜的。

小时候我会去菜地里摘下来吃，连皮带豆塞进嘴里，甜丝丝的。

作为川渝人，豌豆在我们的饭桌上出现频率很高。

人类饮食的一大特色，是对鲜味的追求。西方选择了奶基：牛奶、奶酪、黄油。东方选择了豆基：黄豆、酱油、豆腐、豆豉。

而作为丝绸之路的起点 — — 川渝地区，发展出了另一种鲜味：以豌豆为基的料理。

豌豆尖汤。冬天的时候，豌豆尖刚长出来，嫩得掐得出水。烫一下就捞出来，翠绿翠绿的，带着一股清甜。豌豆尖是最不需要厨艺的菜 — — 因为它本身就是最好的。

凉粉。黄豌豆磨成浆，沉淀，煮成糊，冷却凝固。切块，浇上红油辣椒、蒜水、醋，撒一把葱花。夏天的凉粉摊，总是围满了人。

锅盔夹凉粉。南充的特产。锅盔是酥的，凉粉是软的，咬一口，酥脆和绵软在嘴里交织。我大学时候的食堂，三块钱一个，每次排队都要等十分钟。

碗杂面。豌豆煮得软烂，和杂酱拌在一起。豌豆的甜和杂酱的咸，是绝配。

豆汤面。宜宾的早餐，一碗豆汤面，配一个叶儿粑。豆汤是金黄色的，豌豆煮到开花，汤浓而不腻。

为什么会想到豌豆？

这篇文章构思了很久。我也不知道为什么，只是我的大脑中有很多件与豌豆相关的事情，在某一瞬间突然关联起来。

最近都忙于做 AI 相关的东西，似乎已经脱离太多人文的东西。我想要我的记忆，我的经历留下来。

在某天买锅盔凉粉的时候，看着老板拿勺子刮过凉粉表面，我想起凉粉似乎是豌豆做的。于是问了老板凉粉是什么做的，果然是豌豆。

在这一瞬间，我大脑中关于豌豆的记忆被激活。

豌豆从西域来，在川渝落了脚。 豌豆在童话里，是敏感的象征。 豌豆在生物学里，是遗传定律的起点。 豌豆在我的饭桌上，是童年的甜、少年的粉、成年的鲜。

这些看起来毫不相关的事情，被一颗豌豆串在了一起。

最近过年假期，终于有时间把这些记下来。

大宛已经没有了。孟德尔已经不在了。安徒生已经写完了。我也已经从大学毕业了好多年。

我吃着它，想起这一切，记忆中的一件件往事慢慢浮现。

旧事已去，只可追忆，但豌豆还在。

那作为一个老二次元，JAWS Days 就拿着明日香玩偶去各个摊位打卡，与各个工作人员进行了深入的交流（其实互相都不怎么听得懂对方的英语)。在这里，我想向大家分享一下 JAWS Days 各个展台的情况

JAWS（大白鲨）是日本 AWS UG 的吉祥物，与明日香都是橙色系，这是日本 AWS UG 官方展台，左边的展示了各个支部，分为是42个地域支部与26个领域支部。

日本的活动一大特色就是展台上充斥着各种各样的萌物

吧唧（badge）也是一大特色，一个展台的小礼品

和阿尼亚 Coser 志愿者的合照

我们大中华/韩国展台的合影

在一个用 AI 来生成贴纸展台，我们大中华区 User Group 生成了自己的贴纸。

最后，很感激亚马逊云社区给了我们这一次机会，在 Jaws Days 上见识到日本的商业现状，以及与不同国家工程师、架构师、AI 从业者进行了沟通交流。对于「出海选 AWS」这句话有了更深的认知。

顺带一提，展位的小狗到了我的背包上

在推上我看到有些朋友在问如何注册域名，那么我分享一下。长话短说，

到 http://nic.md 进行注册，184.17元（450 摩尔多瓦列伊，26.69美元）一个域名/年，支持万事达和 Visa 支付。

.md 原本为摩尔多瓦和德涅斯特河沿岸的国家及地区顶级域的域名，而刚好跟 Markdown 的缩写重合。MD 格式天然适合 GenAI，无论是训练数据集，还是行业生态，都是 Markdown 格式。最近 Claudflare 更是推出在网站源头将内容转成 MD 的功能。所以未来写给 AI 的看的网址很有可能是以 md 结尾。

最后，我也购买力一批，比如我将 AI Agent SOUL.md 放到了 ASUKA.md。

又到了一年的春节，总结我个人过去的一年工作上经历很是坎坷。年初从 DevOps 转化角色到做内部业务的 AI 转型，再到后来公司发生变故无法继续推进 AI 项目，最后我看到前司衡量 AI 的单位居然是「工时」，毅然决定离开去开启一段更多机会接触 AI 的工作。

同样，在 AI 圈里也是发生在的翻天覆地。业界总在提「奇点」已来，过去的炒作更多，或者从我的角度看至少在有生之年不会看到。但是，自从 ChatGPT 发布后，这种感觉随着各个 AI 模型或工具的发布进一步加深了我的感觉。特别是在去年，整个时间都被加速了：

• 如果说 Claude Code 的出现改变了整个编程的方式，那么 OpenClaw 对于我来说已经是接近认知中的 AGI
• 如果说 Sora 对于传统的内容产出是巨大的打击，那么 Seeddance 制作的内容更是让人惊艳，比如 「新鸳鸯蝴蝶梦」无论是从画面音乐都无可挑剔
• 如果说「星际之门」计划只是一场资本的泡沫，那么 Minimax 和智谱的上市是让普通人也可以参与到这次 AI 的狂欢中，看到暴涨的股票我拍断腿后悔为啥不开港股

去年年初 DeepSeek 不仅仅只是改变了业界，对我来说，让我花更多的心思在 AI 上，年底的 OpenClaw 发布后更是颠覆整个我对 AI Agent 的认知。
我很庆幸，我拿到了 AI 的入场券，我也很焦虑，爆炸信息量不断涌入我的大脑。

但总的来说，我乐在其中，数不尽的新玩具冒出，可以供我挑选和玩耍，我喜欢新技术更享受把自己筹码 All in AI 的感觉。

来吧一起加入 AI 的狂欢。

借此，我们想聊一聊 重新审视一下 Amazon S3， 如何在这个很慢的服务上构建数据库。

什么是「无盘」？

首先需要澄清的是：

「无盘」并不是没有存储，而是跳过本地块设备，直接把数据写入对象存储（S3）。

在这种架构中，S3 不再只是备份层或归档层，而是主存储层。

作为对比，在传统架构中（例如 Prometheus + Thanos 的 sidecar 模式）：

• Prometheus 先将数据写入本地磁盘（WAL / head block）
• 定期压缩为 block
• 再由 Thanos Sidecar 上传到对象存储

这种模式本质上仍然是磁盘优先。

而我们今天讨论的这些系统，正在尝试反过来。

走向「无盘」的项目

ScopeDB

ScopeDB[3] 是一个面向可观测性数据的数据库。日志、指标、追踪数据天然是 append-only 的，查询也大多是时间范围扫描。

ScopeDB 通过精心设计的分片与索引结构，将写入和查询映射为 S3 上的对象操作，从而绕开了 S3 在低延迟随机 IO 场景下的短板。

Kafka

Kafka 的「无盘化」并不是完全取消本地存储，而是：

• 将历史数据与副本负担转移到 S3（或 S3 兼容对象存储）
• 让 broker 节点更接近无状态

Confluent 推动的 Tiered Storage，其核心思想正是：

热数据留在本地，冷数据卸载到对象存储。

这样一来，扩缩容、故障恢复都会显著简化。

Clickhouse Cloud

ClickHouse Cloud [4] 近几年逐步演进出一套 「无盘 / 无状态计算」 的架构，其目标在于：

• 计算节点不再依赖本地磁盘
• 节点可以快速启动和销毁
• 存储与计算彻底解耦

通过将数据和元数据统一放入共享存储系统，ClickHouse Cloud 实现了真正意义上的 stateless compute。

ScopeDB、Kafka、ClickHouse Cloud 虽然面向的场景完全不同，但它们正在走向同一个方向：让对象存储承担原本属于本地磁盘的职责。

为什么要「无盘」

我们在学习计算机体系过程中会了解到，计算机存储是分层的，从 CPU 缓存到内存，再到磁盘以及网络存储设备，速度从快到慢，同时价格由贵到便宜。

而在 AWS 上的存储服务，也对应有着不同的层级：

在 AWS 上，存储分层大致如下：

• EC2（计算实例内存）：速度最快，适合临时数据和高性能需求，但数据不持久。
• EBS（弹性块存储）：块级存储，适合数据库、持久化磁盘，支持快照和高可用，但成本较高。
• S3（对象存储）：高可用、低成本、弹性扩展，适合大规模数据、日志、备份、数据湖等场景。
• 此外，S3 还提供了多种存储类别（如S3 Glacier， S3 Standard-IA, S3 One Zone-IA 等）

我们知道，越接近计算的越贵，从 CPU 到硬盘是读写速度减慢同时价格逐渐变低的过程[1]。这个规律同样也适用于 AWS 上的存储服务

根据 S3 的特点，我们可以看到两个方面的推动因素。

1. 成本驱动：

而云上唯一可用的商品块设备只有 EBS 类型，这在存储 PB 级数据时非常昂贵。

• EBS ：$80,000 — $125,000/1 PB/月
• S3 ：$21,550/1 PB/月

即使是 1 PB 的 EBS 存储，每月的成本也为 80,000 至 125,000 美元，相比之下，在 S3 上存储 1 PB 的数据每月费用为 21,550 美元[1]。成本差距接近 4–6 倍。

2. 简化运维：

直接写入 S3 可以简化运维工作。无需管理和维护底层存储设备，减少了故障排查和数据恢复的复杂性。S3 提供了高可用性和持久性，用户可以专注于应用逻辑而非存储管理。

为什么可以直接写入到 S3

我们知道数据库由于有大量读写操作，使用块存储是更合适的方式。直接写入 S3 会由于时延不满足要求，以及大量读写操作造成高额请求开销。

那为什么 ScopeDB 和 Kafka 可以做到呢？

我们来回顾这两个项目，有一个共同的特点，那就是「顺序」：

• ScopeDB：应用于可观测数据，有大量的写入并且查询会有时间范围
• Kafka：采用队列的方式顺序写，而读的时候会顺序读

这类场景下，数据的写入和读取都可以批量、顺序地进行，极大地减少了对低延迟和高并发的需求，S3 的高吞吐和低成本优势就能被最大化利用。

S3 的对象存储模型决定了它非常适合 append-only、immutable 的数据模式。每个对象都可以看作是一个 chunk，写入时只需要追加新对象，读取时批量拉取对象即可。

S3 可能不太适合于需要频繁更新的场景，但对于日志、事件流、归档等场景，具有天然的优势。

深入剖析 S3

从何说起 S3 的天然优势？ 更进一步，我们想要分析 S3 的架构，来了解为什么可以这么做

1. 存储机制

S3 的底层构建于海量的 HDD，由于物理原因[2]，HDD 速度很慢，又容易物理的损坏。那 S3 是如何做到以下特性的？

• 高可用：11 个 9 的持久性（99.999999999%）
• 高扩展：可以存储几乎无限量的数据
• 低成本：远低于块存储的价格

而实现这些背后靠的是

• 分片：每个对象被拆分成多个数据块
• 纠删码（Reed-Solomon EC）：生成校验块，允许部分丢失后恢复
• 多副本冗余：数据块分布在不同的存储节点和机架上
• 自动自愈机制：系统持续自我检测和修复
• 规模化带来的平滑负载：海量节点分摊故障概率

每个对象会被拆分成多个数据块和校验块，分布在不同的存储节点和机架上，哪怕坏掉几个硬盘、甚至整个机架挂了，数据都能无损恢复。系统持续自我检测和修复，持久性是动态评估、持续保障的。

2. 架构分层

S3 架构分为三层[5]：

• API 层：负责接收请求、做负载均衡。
• 命名空间服务：负责对象元数据和一致性。
• 存储管理层：负责实际的数据存储、复制、分层和后台维护。

底层存储后端采用 LSM（Log-Structured Merge Tree）结构，顺序写入磁盘，充分利用 HDD 的吞吐能力。新数据块天然更「热」，老数据会自动冷却、迁移、均衡。

3. 为什么顺序写入很关键

底层存储后端采用 LSM（Log-Structured Merge Tree）结构，顺序写入磁盘，充分利用 HDD 的物理特性。新数据块天然更”热”，老数据会自动冷却、迁移、均衡。

S3 底层特性

• LSM 顺序写入
• 分层存储
• 前缀索引

无盘数据库的利用方式

• append-only 模式，只追加不修改
• 冷热分离，老数据自动降级
• 按时间分片，支持范围扫描

实践

我们用命令行工具来演示最简单的 S3 时间序列数据的写入和查询。

# 写入
echo '{"ts":"2025-12-15T10:30:00","value":"hello"}' | \
  aws s3 cp - s3://bucket/data/2025/12/15/103000_abc.json

# 查询某天所有数据
aws s3 cp s3://bucket/data/2025/12/15/ - --recursive | jq -s '.'

# 列出对象（前缀扫描）
aws s3 ls s3://bucket/data/2025/12/15/

从这里例子我们可以看到，我们只会通过追加的方式添加新的数据，并且按照查询语句可以按照时间顺序读取，最后根据前缀扫描接口做到批量列出数据。

# sh顺序写入数据
$ echo '{"ts":"2025-12-15T10:30:00","value":"hello"}' | \
    aws s3 cp - s3://bucket/data/2025/12/15/103000_abc.json

成功写入到 S3 中

执行根据前缀扫描命令

# 列出对象（前缀扫描）
$ aws s3api list-objects-v2 \
  --bucket s3-diskless-database-demo \
  --prefix data/2025/12/18/

{
    "Contents": [
        {
            "Key": "data/2025/12/18/103000_abc.json",
            "LastModified": "2025-12-17T17:46:36.000Z",
            "ETag": "\"3760ca4d8f2d4546910fc32b74b0db79\"",
            "ChecksumAlgorithm": [
                "CRC32"
            ],
            "ChecksumType": "FULL_OBJECT",
            "Size": 45,
            "StorageClass": "STANDARD"
        }
    ],
    "RequestCharged": null,
    "Prefix": "data/2025/12/18/"

在上面的 demo 中，我们实现了一个 shell 命令就实现了无盘顺序写入以及批量读。当然，这离真正的工程实现还有很远的距离，但我们可以由此窥见「无盘」架构设计的精妙之处，以及 S3 的强大。

总结

「无盘」不是一个噱头，而是一种在特定场景下非常务实的架构选择。实践证明，只要设计得当，S3 完全可以作为数据库的主存储层。

当然，「无盘」并非银弹。对于随机读写，频繁更新、高 QPS 点查的场景，本地块存储依然不可替代。

参考

[1] 岔路口：决定卡夫卡的无盘未来 — 杰克·范莱特利

[2]《深入理解计算机系统》（Computer Systems: A Programmer’s Perspective）

[3] ScopeDB

[4] No more disks: the architecture behind stateless compute in ClickHouse Cloud

[4]. How AWS S3 serves 1 petabyte per second on top of slow HDDs 5. Hard disk drive (HDD) — Physical Mechanism

[5]: https://en.wikipedia.org/wiki/Hard_disk_drive “Hard disk drive (HDD ) — Physical Mechanism”

P95 是什么？

假设有个班的学生，让他们按照身高从低往高排列，那么

• P0 = 最小值 → 最矮的同学
• P50 = 中位数 → 中间高度的同学
• P100 = 最大值 → 最高的同学

由此，P95 既是第 95 高位置的同学。

在 IT 系统的时间中，P95 通常用于衡量系统的时延。使用最大值来衡量的一个问题是，很容易被一些极端值所影响。我们在实际业务系统中，需要关注受时延影响最大的一批用户，而不是最大的一个用户。

P95 怎么算？

以时延来看看，我们该如何计算时延的 P95？

a. 排序

最容易想到的时候，把所有的数据进行排序，然后从低往高找第 95% 位置的数据。当然这个方案在真实业务是不可能用的，排序带来的开销很高，在实际应用没什么价值

b. 桶

以 Prometheus 为例，其 Histogram 通过桶的数据结构来实现。会设计不同时延的桶，

例如 [(0,1),(1,2),…..]，统计到的时延数据会被放到

c. 堆

在学习堆这个数据结构的时候，了解到其也可以用于排序，而且其可以做到部分排序，

那么不妨脑洞一下堆是否可以用于 P95 的计算。

当然可以！但前提是是知道所有的数据，才可以使用堆来计算，而流式的数据就无法做到。

d. CKMS

既然聊到了 Histogram，那么不得不提 Summary ，这两个的概念应该差不多吧，他们的实现也应该是同样的逻辑吧？然而当我问了一下我的 AI 助手，Amazing 呀！它们俩采用了完全不同的算法。

Summary 使用了叫 CKMS 的算法，总而言之就是把「相近的多个点用一个点来代表」。

还是回到最开始的例子，站了一排同学，几个差不多高的同学可以用一个来占位，比如 3 位同学身高相差不过 1 厘米，那就可以用一位同学来作为代表占位，另外两位同学就不用排队而去休息了

核心逻辑是：

1) 插入数据（Insert）

把数据插入到有序链表中。

2) 合并节点（Compress）

如果两个节点合并后误差仍可接受 → 把它们压缩成一个。

3) 误差限制（Invariant）

始终守住设置的最大错误率（如 0.01）

g + δ 决定了两个节点之间能代表多少真实数据。
扫描累加，达到 95% 的位置，就是 P95。

关键数字节点 = 满足 CKMS 误差不等式（g + δ ≤ 2εN）的有序节点集。

最终，扫描这些节点就能估算出 P95/P99 的值。

总结一下

总之，这几类算法的核心就在于「压缩」，只保存对理解数据最关键的部分，其他能压就压。都在大量数据中，只保留能代表整体的信息，
其余部分通过数学规则压缩掉。

其核心哲学是：

删不重要的点，保留最关键的点

概述

YACE（Yet-Another-Cloudwatch-Exporter) 是一个基于 Golang 编写，开源的 AWS CloudWatch 的指标（metrics）导出器（exporter）。其可以将 CloudWatch 的指标导出为 Prometheus 格式的指标，通过 Prometheus 抓取后可以通过 PromQL 来进行查询对应的指标，例如 aws_ec2_cpu_utilization。

本文将通过学习 yace 的代码，来了解如 AWS CloudWach 指标的 API 接口，以及熟悉 Metrics 的机制。我们将从两个部分进行解读：

• 配置读取与 CloudWatch 客户端初始化
• 从 AWS API 获取指标并转换为 Prometheus Exporter 的格式

由于篇幅有限，本文主要关注配置和 CloudWatch 的客户端逻辑。

配置读取

在开始主流程的解读前，我们将会关注如何配置文件从 AWS 获取指标，客户端

• 配置层
• 客户端层

配置层

YACE 通过读取 YAML 来进行配置，其配置文件示例如下：

apiVersion: v1alpha1
discovery:
  jobs:
    - type: AWS/EC2
      regions:
        - us-east-1
      period: 300
      length: 300
      metrics:
        - name: CPUUtilization
          statistics: [Average]

在上述的文件中， YACE 配置 discover 来抓取指标，discover 可以通过 tag 自动发现服务。

每个 job 控制着抓取不同 AWS 服务的指标，例如 EC2, Lambda, ECS。

• type： CloudWatch Metrics 的 namepsace
• region：从特定的 region 获取指标（注，部分指标只在特定的region，如cloudfront）
• period：进行数据聚合的间隔
• length：最久可获取到的时长
• metrics：要从该服务拉取的指标类型，可以通过在CloudWatch中的指标名字定位，同时可以指定聚合的类型。

对应着以上的配置文件，在 YACE 的代码中，将 config.yaml 中的配置读取：

上述代码摘抄于 config.go，该部分的代码定义了结构体以及从 YAML 文件读取配置和进行验证的方法。ScrapeConf 的 Load() 方法中实现了 YAML 读取并写入到结构体中的细节。

以 Metric 结构体为例，其可以定义了之前中配置文件中的 Name 和 Statistics ，还有一些之前没有列出的配置项，如 Delay、NilToZero、AddCloudwatchTimestamp等配置选项参数，关于这些配置的内容可以参考官方配置的文档：yet-another-cloudwatch-exporter/docs/configuration.md

另外，在 services.go 中，服务的名称和别名做了定义，也针对某些服务做了特殊处理，这些内容会被存放到 ServiceConfig 中

例如,「AWS/Usage」和「AWS/EC2」, 其中 Namspace 为「AWS/EC2」的做了一些特殊的处理，

• Namespace： 对应着 CloudWatch Metrics 的命名空间
• Alias：一些支持在配置文件中设置的别名，例如 AWS/EC2 namespace 的别名可以设置为 ec2
• ResourceFilters：这是一个字符串列表，用作 resourcegroupstaggingapi.GetResources 请求中的过滤器。它用于在资源组标记 API 请求中指定要过滤的资源类型在 AWS/EC2 中，ResourceFilters 被设置为 ec2:instance，这意味着过滤器将专门针对 EC2 实例进行。
• DimensionRegexps：可选的正则表达式列表，用于从资源 ARN 中提取维度名称。 AWS/EC2 的表达式regexp.MustCompile("instance/(?P<InstanceId>[^/]+)")将从 ARN 中提取 InstanceId 维度

上述的参数被定义在 ServiceConfig。我们来看一下 config 的定义部分，在 ServiceConfig 中。

而抓取的类型在 YACE 中被分成了三种：

• Job：通过 tag 自动发现服务资源，并自动抓取
• Static：手动配置要抓取的资源
• CustomerNamespace：自定义的指标，如 CloudWatch Agent 采集的指标，使用 SDK 上传的自定义指标

通过上面的代码即可将 YACE 的配置读取到 Golang 的结构体。带给我们的启发在于如何定义配置文件以对接 AWS 的 SDK 和 API，以获取所需的数据。

CloudWatch 客户端初始化

YACE 项目使用了 AWS 的 Golang SDK，其中涉及到 v1/v2 的 AWS Golang SDK。

而 AWS SDK 中会涉及到不同服务的客户端，yace 主要使用了 3 类客户端：

• Account Client 完成认证
• CloudWatch Client 负责获取数据
• Tagging Client 负责服务发现和过滤

1. 认证

我们首先先找到与AWS进行认证的逻辑，与 AWS 进行认证的部分在factory.go文件中，通过createStsOptions方法和awsConfigForRegion函数实现。这些方法设置了AWS STS（安全令牌服务）选项和区域配置。

func awsConfigForRegion(r model.Role, c *aws.Config, region awsRegion, stsOptions func(*sts.Options)) *aws.Config {
 regionalConfig := c.Copy()
 regionalConfig.Region = region

 if r == defaultRole {
  return &regionalConfig
 }

 // based on https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/credentials/stscreds#hdr-Assume_Role
 // found via https://github.com/aws/aws-sdk-go-v2/issues/1382
 regionalSts := sts.NewFromConfig(*c, stsOptions)
 credentials := stscreds.NewAssumeRoleProvider(regionalSts, r.RoleArn, func(options *stscreds.AssumeRoleOptions) {
  if r.ExternalID != "" {
   options.ExternalID = aws.String(r.ExternalID)
  }
 })
 regionalConfig.Credentials = aws.NewCredentialsCache(credentials)

 return &regionalConfig
}

• 创建基础 AWS 配置的区域副本。
• 如果角色是默认角色（AK/SK），直接返回区域配置。
• 对于非默认角色，使用 AWS STS 进行角色假设，并通过stscreds.NewAssumeRoleProvider设置配置中的凭证。

而这些认证 credentals 将会被存储到 cachedClients，

数据结构如下

type cachedClients struct {
 awsConfig *aws.Config

 onlyStatic bool
 cloudwatch cloudwatch_client.Client
 tagging    tagging.Client
 account    account.Client
}

其中，将会根据 role 和 region 来区分 client，并将其存放到 cache 中

cache := map[model.Role]map[awsRegion]*cachedClients{}
  // 按照job的类型进行区分，比如ec2,s3
 for _, discoveryJob := range jobsCfg.DiscoveryJobs {
  // 按照role区分，一般来说一个role对应着一个aws account
  for _, role := range discoveryJob.Roles {
   if _, ok := cache[role]; !ok {
    cache[role] = map[awsRegion]*cachedClients{}
   }
    // 按照 region 进行区分
   for _, region := range discoveryJob.Regions {
    // 获取区域的客户端和认证的逻辑
    regionConfig := awsConfigForRegion(role, &c, region, stsOptions)
    cache[role][region] = &cachedClients{
     awsConfig:  regionConfig,
     onlyStatic: false,
    }
   }
  }
 } 

我们从 README 找到了rolearn 配置文件的示例

apiVersion: v1alpha1
sts-region: eu-west-1
discovery:
  jobs:
    - type: AWS/ECS
      regions:
        - eu-north-1
      roles:
        - roleArn: "arn:aws:iam::1111111111111:role/prometheus" # newspaper
        - roleArn: "arn:aws:iam::2222222222222:role/prometheus" # radio
        - roleArn: "arn:aws:iam::3333333333333:role/prometheus" # television
      metrics:
        - name: MemoryReservation
          statistics:
            - Average
            - Minimum
            - Maximum
          period: 600
          length: 600

可以看到其分层关系 jobs -> regions -> roles 与 cache 的代码是对应的

yet-another-cloudwatch-exporter/pkg/clients/v2/factory.go

而 cachedClients 的作用，是为了生成要拉取数据所用 CloudWatch 客户端，

上述的代码会获取 CloudWatch、Tagging 和 Account 的客户端。

2. CloudWatch 客户端

对与 cachedClients 生成的三个我们接下来将重点理解 CloudWatch client的逻辑

yet-another-cloudwatch-exporter/pkg/clients/cloudwatch/client.go

中定义了一个接口，主要是 Client 的接口

type Client interface {
 // ListMetrics returns the list of metrics and dimensions for a given namespace
 // and metric name. Results pagination is handled automatically: the caller can
 // optionally pass a non-nil func in order to handle results pages.
 ListMetrics(ctx context.Context, namespace string, metric *model.MetricConfig, recentlyActiveOnly bool, fn func(page []*model.Metric)) error

 // GetMetricData returns the output of the GetMetricData CloudWatch API.
 // Results pagination is handled automatically.
 GetMetricData(ctx context.Context, getMetricData []*model.CloudwatchData, namespace string, startTime time.Time, endTime time.Time) []MetricDataResult

 // GetMetricStatistics returns the output of the GetMetricStatistics CloudWatch API.
 GetMetricStatistics(ctx context.Context, logger *slog.Logger, dimensions []model.Dimension, namespace string, metric *model.MetricConfig) []*model.Datapoint
}

其中，其实现了三个 CloudWatch 相关的接口，这三个为我们提供了获取指标的核心能力

• ListMetrics：查看当前的 CloudWatch 命名空间中有什么指标
• GetMetricData： 获取 CloudWatch 服务中的数据，并通过 MetricDataResult 的结构体存储
• GetMetricStatistics：返回统计后的数据，相比 GetMetricData 会有更少的开销

以上的数据以 MetricDataResult 存储

type MetricDataResult struct {
 ID string
 // A nil datapoint is a marker for no datapoint being found
 Datapoint *float64
 Timestamp time.Time
}

为了解决 AWS API 限流的问题，yace 对 CloudWatch的客户端包装成了limitedConcurrencyClient，其

由于 AWS Golang Client 存在着不同的版本，CloudWatch 客户端同样区分了 v1 和 v2 ，我们后续主要通过 v2 的代码进行解读

yet-another-cloudwatch-exporter/pkg/clients/cloudwatch/v2/client.go

a) ListMetrics 用于列出符合条件的 CloudWatch 指标，并支持分页获取数据

参数：

• namespace：AWS服务命名空间
• metric：指标配置
• recentlyActiveOnly：是否只获取最近活跃的指标
• 使用分页器逐页获取数据并通过回调函数处理结果

b) GetMetricData 可以批量获取指标数据

其支持：

• 多个指标同时查询
• 自定义时间范围
• 自定义统计周期和统计方法
• 使用分页器处理大量数据
• 包含性能计数和错误监控

c) GetMetricStatistics

• 更少的数据开销
• 获取单个指标的详细统计信息
• 支持多种维度的数据查询
• 提供错误处理和日志记录

在代码中提供了一些数据转换工具函数，主要目的是将 AWS 格式的数据统一为 Prometheus exporter 的数据格式

a) toModelMetric (74-85行)

• 将 AWS CloudWatch 的指标数据转换为内部模型格式

b) toModelDimensions (87-97行)

• 将 AWS 维度数据转换为内部模型格式

c) toMetricDataResult (149-160行)

• 将 API 响应转换为标准化的指标数据结果

d) toModelDatapoints (187-206行)

• 将 CloudWatch 数据点转换为内部模型格式
• 处理扩展统计信息

CloudWatch Client 初始化逻辑

a. 客户端被初始化入口，YACE 定义了一个 NewClient 函数：

// pkg/clients/cloudwatch/v2/client.go
func NewClient(logger *slog.Logger, cloudwatchAPI *cloudwatch.Client) cloudwatch_client.Client {
    return &client{
        logger:        logger,
        cloudwatchAPI: cloudwatchAPI,
    }
}

这个函数将一个已经按照 AWS SDK 配置好的 cloudwatch.Client 实例和日志器传入，封装成 YACE 内部使用的 cloudwatch_client.Client 接口类型。

b. 客户端创建过程：

在 pkg/clients/v2/factory.go 文件中，YACE 的工厂（CachingFactory）负责根据 AWS 区域（region）和角色（role）配置来创建基础的 cloudwatch.Client

// 创建基础的 CloudWatch 客户端
func (c *CachingFactory) createCloudwatchClient(regionConfig *aws.Config) *cloudwatch.Client {
    return cloudwatch.NewFromConfig(*regionConfig, func(options *cloudwatch.Options) {
        // 1. 设置日志级别
        if c.logger != nil && c.logger.Enabled(context.Background(), slog.LevelDebug) {
            options.ClientLogMode = aws.LogRequestWithBody | aws.LogResponseWithBody
        }
        
        // 2. 设置自定义端点（如果有）
        if c.endpointURLOverride != "" {
            options.BaseEndpoint = aws.String(c.endpointURLOverride)
        }

        // 3. 配置重试策略
        options.Retryer = retry.NewStandard(func(options *retry.StandardOptions) {
            options.MaxAttempts = 5
            options.MaxBackoff = 3 * time.Second
        })

        // 4. 配置 FIPS 端点（如果启用）
        if c.fipsEnabled {
            options.EndpointOptions.UseFIPSEndpoint = aws.FIPSEndpointStateEnabled
        }
    })
}

c. YACE 使用 CachingFactory 将每个（角色，region）组合对应的客户端存入缓存，以避免重复创建。其核心方法如下：

func (c *CachingFactory) GetCloudwatchClient(region string, role model.Role, concurrency cloudwatch_client.ConcurrencyConfig) cloudwatch_client.Client {
    // 1. 检查是否需要刷新
    if !c.refreshed {
        c.mu.Lock()
        defer c.mu.Unlock()
    }
    
    // 2. 检查缓存中是否存在客户端
    if client := c.clients[role][region].cloudwatch; client != nil {
        return cloudwatch_client.NewLimitedConcurrencyClient(client, concurrency.NewLimiter())
    }
    
    // 3. 创建新的客户端并缓存
    c.clients[role][region].cloudwatch = cloudwatch_v2.NewClient(
        c.logger, 
        c.createCloudwatchClient(c.clients[role][region].awsConfig)
    )
    
    // 4. 返回带并发限制的客户端
    return cloudwatch_client.NewLimitedConcurrencyClient(
        c.clients[role][region].cloudwatch, 
        concurrency.NewLimiter()
    )
}

工厂类将实例化的客户端放入到缓存中，由于客户端有时间限制，所以会定期的进行检查是否过期，如果过期需要进行刷新连接。同时在进行返回的时候为避免客户端请求 API 超过限流，在返回的其实是带并发限制的客户端。

总结

本文对 YACE 的源码进行了分析。主要借此来学习如何构造并使用适配 CloudWatch 指标（Metrics）的配置文件，以及探索 YACE 如何与 AWS API（如 CloudWatch、Tagging API）进行交互，实现指标拉取、资源发现与数据转换。

随着 LLM 应用变得广泛，各种 AI 应用和 Agent 迎来了大爆发。而 LLM 作为一个基于概率的模型，以及其是一个黑盒，我们很难搞清楚里面发生了什么。在实际开发中进行调试时，构建良好的可观测性体系变得尤为重要。

过去我们常说 「Talk is cheap show me the code」，而现在，在与 LLM 交互的场景下，更像是 「Code is cheap show me the talk」

虽然是句玩笑话，但在 LLM 应用中，记录上下文、输入输出、模型行为等信息，是实现可观测性的基础。‍

目前主流的 LLM 可观测性方案有 LangSmith 和 LangFuse，本篇文章将介绍如何基于 OpenTelemetry（OTel）与 GreptimeDB 构建一个简单的 LLM 可观测性系统。

下面我们将一步步实现这一过程。

操作步骤

我们将会用到 OpenLLMetry 来收集链路追踪（Trace）和指标（Metric)[1]。

这是一个使用 OpenAI SDK 与 DeepSeek 接口进行调用的简单示例

import os
from openai import OpenAI

openai_client = OpenAI(api_key="sk-xxxxxxxxxxxxxxxxxxx", base_url="https://api.deepseek.com")
 
chat_completion = openai_client.chat.completions.create(
    messages=[
        {
          "role": "user",
          "content": "What is LLM Observability?",
        }
    ],
    model="deepseek-chat",
)
 
print(chat_completion)

只需在 LLM 应用中添加如下代码，即可自动采集链路数据：

from traceloop.sdk import Trpytaceloop

Traceloop.init(disable_batch=True,
               api_endpoint=OTEL_EXPORTER_OTLP_ENDPOINT,
               )

该代码会对 OpenAI sdk, langchain 进行自动埋点

完整的代码如下:

import os
from openai import OpenAI
from traceloop.sdk import Traceloop

OTEL_EXPORTER_OTLP_ENDPOINT = "http://127.0.0.1:4000/v1/otlp" 
Traceloop.init(disable_batch = True,
               api_endpoint = OTEL_EXPORTER_OTLP_ENDPOINT,
)
openai_client = OpenAI(api_key="sk-xxxxxxxxxxxxxxxxxxx", base_url="https://api.deepseek.com")
 
chat_completion = openai_client.chat.completions.create(
    messages=[
        {
          "role": "user",
          "content": "What is LLM Observability?",
        }
    ],
    model="deepseek-chat",
)
 
print(chat_completion.choices[0].message.content)‍

注意 OTEL_EXPORTER_OTLP_ENDPOINT 是 OTLP（OpenTelemetry Protocol） 的数据接收地址。
常见接收端包括 otel-collector、Vector、Grafana Alloy 等，这里为了简化流程，我们使用 GreptimeDB 来接收数据 [2]

运行项目

1. 在本地下载和安装 GreptimeDB，并且运行（standalone 模式）[3]

$ ./greptime standalone start

2. 随后运行自动埋点后的代码，即可将 OTEL 采集的数据写入到 GreptimeDB

可视化数据

我们可以使用 GreptimeDB Dashboard [4]查看

在 Gafana 中添加数据源

​也可以通过 Grafana 构建更完善的可观测性视图。在 Grafana 上创建两个连接，分别是 Prometheus 和 Jaeger

1. 新建 Prometheus 类型的连接，并填入 URL: http://localhost:4000/v1/prometheus/​

2. 新建 Jaeger 类型的连接，并填入 URL: http://localhost:4000/v1/jaeger​

添加成功后，即可在 Grafana 中查看链路追踪与指标信息：

你也可以导入这份导入示例 Dashboard [5] 来快速体验完整效果。‍

总结

本文基于 OpenTelemetry 与 GreptimeDB 搭建了一个简单的 LLM 可观测性系统：

• OpenLLMetry 提供了便捷的自动埋点能力；
• GreptimeDB 作为新一代可观测性数据库，简化了部署流程，支持多协议数据接入；
• Grafana 帮助我们实现全面的可视化展示。

这套方案兼具灵活性与低门槛，本文只是做了一个简单的尝试，以快速构建简单版本的 LLM 可观测性。‍

[1] https://www.traceloop.com/docs/openllmetry/getting-started-python
[2] https://docs.greptime.com/user-guide/ingest-data/for-observability/opentelemetry
[3] https://docs.greptime.com/getting-started/installation/greptimedb-standalone
[4] https://docs.greptime.com/getting-started/installation/greptimedb-dashboard/
[5] https://gist.github.com/JetSquirrel/d8fbc1a589aae7f62c117601262eb66c

‍

‍

AWS CloudTrail 用于记录 AWS 上的操作，例如创建资源、权限授予等。

本文将 AWS CloudTrail 的日志导入到 GreptimeDB 中，并使用 GreptimeDB MCP Server，让大模型对 CloudTrail 日志进行分析，发现云安全威胁和恶意操作。

以下是一个聊天的效果，我们查询到「155.63.17.217」这一个IP 地址的异常操作：

一、环境准备

GreptimeDB 下载和安装

a. 下载 GreptimeDB 二进制文件，解压后并进入对应的目录，使用以下的命令运行

./greptime standalone start

b. (可选) 使用 GreptimeDB Dashboard 查询数据

在连接到 GreptimeDB 兼容 MySQL 和 PostgrepSQL 可以用 Navicat、DBeaver 等工具连接，也可以使用 Greptime 提供的 GreptimeDB dashboard.

GreptimeDB MCP 服务器

GreptimeTeam/greptimedb-mcp-server 基于 Python 开发，可以

使用Git 克隆到本地：

git clone https://github.com/GreptimeTeam/greptimedb-mcp-server.git

确保本地已经安装 Python 的包 管理工具 uv，用于运行该项目，安装步骤可以查看这里。

MCP 客户端

使用 MCP 的客户端来连接MPC服务器，例如 Claude Desktop、Cline、Cherry Studio、ChatWise。

本文以 ChatWise 为例，将下面的 JSON 修改 MCP Server 的路径后，复制导入 MCP 客户端

{
  "mcpServers": {
    "greptimedb": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/greptimedb-mcp-server",
        "run",
        "-m",
        "greptimedb_mcp_server.server"
      ],
      "env": {
        "GREPTIMEDB_HOST": "localhost",
        "GREPTIMEDB_PORT": "4002",
        "GREPTIMEDB_USER": "root",
        "GREPTIMEDB_PASSWORD": "",
        "GREPTIMEDB_DATABASE": "public"
      }
    }
  }
}

在 ChatWise 中配置模型，

二、数据导入

下载数据集

从 这里 下载 CloudTrail 的数据集用来做测试。

关于此数据集可参考：

• Summit Route — 来自 flaws.cloud 的 Cloudtrail 日志的公共数据集
• Threat detection🕵️‍♂️ in AWS using Amazon Athena Service

下载到本地后，对文此件进行解压，如果是 Windows 可以采用 7z 进行解压，如果是 Unix/Linux 系统可以使用以下命令

find . -type f -exec gunzip {} \;

导入数据到 GreptimDB

我们利用 Python 脚本将 JSON 格式的 CloudTrail 日志导入到 GreptimeDB，将该脚本存于下载数据集的同一目录下并运行

上述代码的作用是：

• 创建 CloudTrail 的表
• 导入原始的 JSON 数据到 GreptimeDB 中

在 GreptimeDB Dashboard 上查询数据，验证是否导入成功：

三、大模型问答

参考 Promtp

Promtp:
# 监控指标分析模板
你是一安全日志分析助手，致力于帮助用户查询和分析 GreptimeDB 中的数据。您的任务是分析用户的数据需求，并提供 SQL 查询语句，从 GreptimeDB 中提取相关信息。


## 1. 概述
GreptimeDB 是一个统一指标、日志和事件的时间序列数据库。
1. 提示：此服务器提供提示，帮助您构建与 GreptimeDB 的交互。
2. 资源：您可以在资源中找到格式为"greptime://<table_name>/data"的表。
3. 工具：
- "execute_sql"：执行 SQL 命令（MySQL 语法）。

## 2. 指导原则
1. 时间范围至关重要 - 请务必在查询中指定时间范围。
2. 要探索可用数据，请使用 SQL 命令，例如 (`DESCRIBE`、`SELECT`、`SHOW TABLES`)
3. 遵循 SQL 最佳实践：
- 使用适当的筛选条件来限制结果集
- 考虑对时间序列数据使用聚合函数
- 利用 GreptimeDB 的内置时间函数
4. 服务器将阻止危险操作。除非需要修改数据，否则请专注于读取操作
5. 使用简洁的 Markdown 格式，并添加适当的标题和项目符号。

## 3. 示例用例和查询
- 尝试通过特定用户 ARN 启动 EC2 实例
- 谁可以通过控制台访问
- 搜寻 AWS 控制台的登录失败
- 通过 AWS 管理控制台调查创建的事件（IAM、S3 和 EC2）资源。
- 通过 AWS 管理控制台、AWS CLI、SDK 或直接 API 调用调查创建的事件（IAM、S3 和 EC2）资源
- 搜寻 CloudTrail 中断
- 搜寻未经授权的呼叫
- 寻找 “whoami” 身份
- 通过创建 IAM 用户来入侵账户的努力
- 在 Secrets Manager 中搜寻访问密钥
- 搜寻 xlarge EC2 实例
- 搜寻 S3 存储桶暴力破解尝试
- 搜寻可疑用户代理（Kali、Parrot、PowerShell）
- 搜寻永久密钥创建
- 创建公有 S3 存储桶
- 暴力破解尝试代入角色
- 尝试对账户执行对帐作

```sql
-- 获取表结构
DESCRIBE ${table};
-- 获取近期数据样本
SELECT * FROM ${table}
${sample_queries} ORDER BY ${time_column} DESC LIMIT 100

-- 尝试启动 EC2实例由特定用户 ARN
SELECT 
  eventname, 
  count(*) AS eventcount 
FROM cloudtrail_logs WHERE 
  user_identity.arn = '${arn}' 
  AND source_ip='${ip}'
GROUP BY eventname ORDER BY eventcount DESC;

-- 日志配置变更的高风险操作
SELECT event_time, error_message, user_identity, source_ip, event_name, user_agent, aws_region FROM cloudtrail_events WHERE event_name IN ('StopLogging', 'DeleteTrail', 'UpdateTrail') AND event_time BETWEEN TIMESTAMP '2018-01-01T00:00:00Z' AND TIMESTAMP '2020-12-31T23:59:59Z' ORDER BY event_time DESC LIMIT 100
```

## 4. 补充说明
1. 如果您不知道如何回答特定问题，建议先探索模式以了解可用的数据结构。
2. 以清晰、翔实的方式解释查询结果。
3. 帮助他们有效地分析云安全日志数据。

例1： 分析 cloudtrail_events 表中在2018年4月存在的高危操作，注意这个表很大，请谨慎使用SQL

例2：分析 AKIA01U43UX3RBRDXF4Q 用户的操作是否存在高危，注意这个表很大，请谨慎使用SQL

对上述的内容进行验证，确实是存在恶意的操作。goodycy3’s gists 的博客中分享了对这个数据集的分析，可以多尝试一下更多的 case。

ADHD 儿童很难适应坐在教室里的方式学习，上课不会专心听讲，而且还可能会打扰到其他同学，甚至被老师打 上「坏学生」和「笨小孩」。

而成人面临着更严峻的挑战，随着现代社会工业化和信息化的发展，社会结构化、流程化、成瘾物质泛滥和运动空间缩小，这些问题会在 ADHD 的身上放大，最终又会成为 ADHD 身上糟糕的标签：懒、蠢、缺乏自控。

近年 ADHD 慢慢的被大众所了解，也有许多人确诊了 ADHD。

当然不少人为了维持日常的生活、工作和学习，选择了吃药。我也正在吃药，这确实让我日常生活和工作更有条理，也解决了我拖延、注意力不集中和冲动的问题。

当然，若不是生活所迫，我也不想通过吃药来维持正常的工作和生活。

另一方面，ADHD 天生就是要去追求新鲜的事情，天生就充满好奇，大脑中时刻都有火花在闪耀。而恰恰工业化和信息化的社会给 ADHD 提供了非常多的舞台，交通工具的发展使我们能到世界每一个角落，信息化能让我们在几秒内将自己的想法传达出去。我们能到更多的地方，见更多的人，做更多的事。

ADHD 的人蠢、无礼、鲁莽、冲动吗？我想我们身上确实会多多少少有这些问题，这是我们特质带来的影响。另一方面 ADHD 有着充沛的激情、生命力和好奇心，会驱动着我们去追求感兴趣的事情。

我给不出什么 ADHD 该如何生活的建议，因为我还在寻找。

我正在做的，写作，也许对我们是一种救赎。