这是一个创建于 150 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们这边每天都会落几十 GB 日志，埋点+调试都有。 想法比较简单：
- 日志最好能留够 1 年。
- 偶尔要查问题，用 SQL 能直接捞出来就行。
- 不想自己搭 ES/数仓，成本太高、维护也麻烦。
之前看过对象存储 + Presto(Trino) 这套，但有点懒得自己搭建和维护，感觉太折腾。 大家平时是怎么搞的？有没有省心点的办法？
 |
1
FlashEcho 2025 年 8 月 21 日  3
grafana 可视化+promtail 收集+loki 日志聚合+任意对象存储，k8s helm chart 一个 loki-stack 全搞定了，只要调调 yaml 配置，相当不折腾
|
 |
2
c00WKmdje2wZLrSI 2025 年 8 月 21 日
阿里云或者腾讯云的日志服务?
|
 |
4
Nitroethane 2025 年 8 月 21 日 via iPhone
试试阿里云 maxcompute ？内部叫 odps ，挺好用
|
 |
5
nm1st 2025 年 8 月 21 日 2
duckdb+s3
|
 |
6
Smileh 2025 年 8 月 21 日
买个 10T 硬盘
|
 |
7
linhrdom OP @c00WKmdje2wZLrSI 有点贵，1TB 一年 2700 左右。有点恐怖了
|
 |
8
COW 2025 年 8 月 21 日 via Android
presto 非常吃内存的，而且也不太推荐用于块存储查询，要不看看 ck ？
|
 |
10
Maboroshii 2025 年 8 月 21 日 2
没有银弹... 最简单就是存文件，grep 查
|
 |
11
bruce0 2025 年 8 月 21 日
我前几天刚搭了一套 ELK, filebeat 收集,logstash 分析处理,ES 存, kibana 展示. 除了 filebeat 都是 docker(podman) 跑的, 现在只收集程序运行 log.每天 2G 左右,保存 14 天,原始 log 永久保存(gov 规定的)
前几天想把玩家行为 log 也写入 ES,每天可能在 10G 左右,打算保存 1 年+, 算了一下,硬盘需求太大,还是用原来的吧(原来有一套程序+脚本能通过原始 log 文件查找分析玩家行为) 就没必要把行为 log 再写入 ES 了 |
 |
12
vincentWdp 2025 年 8 月 21 日
aws Athena? 虽然成本也不低
|
 |
13
Dragonish3600 2025 年 8 月 21 日 via iPhone
aws s3
|
 |
14
pingdog 2025 年 8 月 21 日 via Android
买冷存储块，3 天后就放入冷库，要查在捞出来
|
 |
15
DefoliationM 2025 年 8 月 21 日 via Android
quickwit+s3 ，完美符合你的要求，支持全文搜索。
|
 |
16
ETiV 2025 年 8 月 21 日 via iPhone
https://github.com/openobserve/openobserve
🚀 10x easier, 🚀 140x lower storage cost, 🚀 high performance, 🚀 petabyte scale - Elasticsearch/Splunk/Datadog alternative for 🚀 (logs, metrics, traces). OpenObserve (O2 for short) is a cloud-native observability platform built specifically for logs, metrics, traces, analytics, RUM (Real User Monitoring - Performance, Errors, Session Replay) designed to work at petabyte scale. |
 |
17
perfectlife 2025 年 8 月 21 日 via Android
云上直接用云平台的日志服务，想降低成本就设置把历史日志扔到归档存储里
|
 |
18
BlueSpace4512 2025 年 8 月 21 日 4
我有一技：
你去 steam 上买个 wallpaper engine 然后使用 SteamCMD 命令行向 wallpaper engine 创意工坊上传作品，在这个作品里把你的日志文件加密丢进去，然后随便整个图片包装下上传，描述或者标题就写你的日志备份日期 一次传十几个 G 的文件没太大问题，还能免费用到 steam 的 CDN 下载服务 而且完全可以自动化进行，因为 steam 有 SteamCMD 功能可以命令行运行，可以部署在 linux 或者 docker 上 |
 |
19
w568w 2025 年 8 月 21 日
看看 InfluxDB ？ https://www.influxdata.com/influxdb-pricing/
|
|
20
ETiV 2025 年 8 月 21 日 via iPhone 1
我也给我们项目写过
- 日志每天 gzip 上传到阿里云 oss 、AWS S3 这种地方，存储路径、文件名都有规律的 - 配置好归档冷存储策略 - 等需要搜索的时候，大批量开按量计费的虚拟机，然后用分布式、多进程、管道化的方式来 gunzip | grep 想要搜索的内容 * 机器都开在了同 region ，访问走内网域名，不会收取 egress 流量费 - 上面的工作是一个异步的任务，开跑了就可以挂着了 - 跑完会给企业微信群里发条消息，说最终 grep 匹配出来的结果放在了什么路径下。然后把跑任务的机器自动关机。 |
 |
21
lscho 2025 年 8 月 21 日 4
便宜
不折腾 能直接用（ SQL 能直接捞出来） 以上不可能三角 |
 |
23
wupher 2025 年 8 月 21 日
- 常用查询放 ELK ，一般双周或一月，视各项目重要情况。
- 归档日志存放于 Hadoop ，通过 API 进行检索。 |
 |
27
slowman 2025 年 8 月 21 日 1
每天上传几十 GB 日志,会不会被认定跑 PCDN 被限速?
|
 |
28
512357301 2025 年 8 月 21 日 via Android
用 duckdb 转成 parquet ，然后随便放哪里(本地或者 s3 ，甚至 http 文件服务器也行)，用 duckdb 读取，速度也很快。
|
|
29
512357301 2025 年 8 月 21 日 via Android
每天啊，那这量不算小，一般建议数仓了，可以先用 duckdb 试试，不行就上 ck 数仓
|
 |
30
dji38838c 2025 年 8 月 21 日 2
如果一年几万块，不值得出
那么大概率这数据也不值得放 |
 |
31
marquina 2025 年 8 月 21 日 via iPhone
@dji38838c #30 +1 ，用价格竞争最充分的对象存储来算，每月几十 g 的数据一年下来也得 5 位数了。如果这钱都不想出那说明这数据没那么值钱。
|
 |
32
billccn 2025 年 8 月 22 日
以前 AWS S3 还支持直接运行 SQL-like 查询呢： https://docs.aws.amazon.com/AmazonS3/latest/userguide/selecting-content-from-objects.html
当然这种好事已经结束了 |
 |
33
guo4224 2025 年 8 月 22 日 via iPhone
找个大善人给你出钱出精力维护
|
 |
34
xuanbg 2025 年 8 月 22 日
日志留够 1 年是你想多了，除非用于数据恢复。查问题的话，7 天足够了。一般也就 24 小时内的问题要查。
|
 |
35
bk201 2025 年 8 月 22 日
自己买 nas 存储设备存储最便宜。
|
 |
36
ExplodingDragon 2025 年 8 月 22 日
一楼的方案算是比较好的了，prometheus 也可以顺便用 grafana ，只不过每天落几十 GB 日志有点难崩，假如 30G/d, 一年就是 10T + 了
|
 |
37
jnliyan1 2025 年 8 月 22 日
啥问题需要一年后查..
|
 |
38
penisulaS 2025 年 8 月 22 日
既要低成本又要方便查询，我感觉需要建多层缓存
|
 |
39
opengps 2025 年 8 月 22 日
其实一块大容量的移动硬盘已经足够靠谱了
|
 |
40
spritecn 2025 年 8 月 22 日
年? 没审计需求的话,到月就可以了吧,我只存 10 天,方案是 OpenObserve 走 s3
|
|
41
spritecn 2025 年 8 月 22 日
OpenObserve 存储也是 parquet
|
 |
42
yudoo 2025 年 8 月 22 日
ilogtail+clickhouse 最简单的 单节点就行 压缩比 es 高 7 倍，硬盘 1T 差不多了
|
 |
43
guanyujia5444 2025 年 8 月 22 日
对象存储+分层存储，要不就降低保留时间，再便宜的方案可能可用性就受影响了
|
 |
44
i8086 2025 年 8 月 22 日
频繁查询都是 15 天内的，我这里 3 个月前的日志很少要查，平均下来 1 年查不到 2 次，那时候把日志导出为文本，直接用 winrar + 大字典压缩归档了，超级省空间，10G 日志压缩完不到 1G 。
完善后续恢复导入流程就可以了。 |
|
45
i8086 2025 年 8 月 22 日
按月归档。
|
 |
46
TaiShang 2025 年 8 月 22 日
victorialog
|
 |
47
tomatocici2333 2025 年 8 月 22 日
 百度云自动备份就行了 就一个会员钱 |
 |
48
Sezxy 2025 年 8 月 22 日
日志我们最多只存 30 天
|
 |
49
RedisMasterNode 2025 年 8 月 22 日
一年 2700 的成本都不愿意..吗 这不对吧
|
 |
50
dode 2025 年 8 月 22 日
试试 clickhouse ，带压缩功能
|
 |
51
evan1 PRO @RedisMasterNode #49 这是 1t 的价格。op 一天就产生几十 g 的日志。一年下来也要几万块钱了。
|
|
52
RedisMasterNode 2025 年 8 月 22 日
@evan1 按 30G 一年只有 10T 左右，现在日志存储压缩率极高，轻松可以有 10x 以上的压缩率把存储开销保持在 2T 内。
See: https://victoriametrics.com/products/victorialogs/ |
 |
53
joyoyao 2025 年 8 月 22 日
clickhouse 上手简单。支持到期日志自动删除，压缩算法也给力。也支持 sql 。搞个大一点的机械硬盘就行了。
|
 |
54
guxingke 2025 年 8 月 22 日
doris ，MySQL 协议兼容，支持分层存储(冷数据丢到 OSS)
|
 |
55
duanxianze 2025 年 8 月 22 日
买两块硬盘不就好了，互为备份就行了，五年内还是稳的
|
 |
56
fengfisher3 2025 年 8 月 22 日
日志最好能留够 1 年。
偶尔要查问题，用 SQL 能直接捞出来就行。 不想自己搭 ES/数仓，成本太高、维护也麻烦 ------------------------------------------------------- 大量长时间存储，还要方便能直接使用，又不想麻烦的，真的如 @lscho 所说，不可能三角。 每天 几十 GB 日志，这个量，光存储的钱都不少，还不想麻烦，真的不可能，换方案吧。 |
 |
57
luzihang 2025 年 8 月 22 日
年初遇到个需求，金融机构上面来检查，按照订单号，要查 5 年内的日志：请求和响应 2 条。后面写个脚本，读按照日期归类的日志压缩文件。
|
 |
58
salmon5 2025 年 8 月 22 日
@duanxianze #53 的方案可以了，买 2 块大硬盘足够了
|
 |
59
laminux29 2025 年 8 月 22 日
你既要方便地能直接 SQL 查询，又懒得搭建和维护。
这边建议您花钱找人帮您搭建。 |
 |
61
la2la 2025 年 8 月 22 日
假设 1 天 100 GB 数据，1 年 大概 36.6 TB 左右的数据
这点数据可以考虑一下云厂商的 OSS 服务，在加上冷热模式，用不了几个钱。 不过你要支持可查，那么用数据湖格式，存储落到 OSS 上，使用 Doris 或者 Spark 挂个外表就能查了。 |
 |
63
JoeDH 2025 年 8 月 22 日
一年有没有必要？如果接受不了云服务的价钱，那还是自己买存储搭一套吧
|
 |
64
Moatkon 2025 年 8 月 22 日
找一个压缩算法，规划好分片维度。后面业务如果需要找到指定分片解压
|
 |
65
zhangxiangperson 2025 年 8 月 22 日 1
如果不想自己拼组件，可以考虑全托管的湖仓，（对象存储 + 表格式 + SQL 引擎一体化）。例如把日志直接落到云器 Lakehouse ，一年存储免费的 “资源包”，1TB 存储免费，存储+SQL 即席查询的诉求能一次到位：
https://www.yunqi.tech/product/one-year-package |
|
66
linhrdom OP @vincentWdp AWS Athena 我简单算了一下，可能要 4000 多美金，更恐怖了。
|
|
67
linhrdom OP @DefoliationM 可以，但不是 SQL
|
|
68
linhrdom OP @fengfisher3 感谢分析
|
|
69
linhrdom OP @zhangxiangperson 这个好，试试
|
 |
70
wineejam 2025 年 8 月 22 日
直接上 SLS
|
 |
71
tooroot 2025 年 8 月 22 日
Doris 存算分离模式 + OSS 冷备
|
 |
72
gzldc 2025 年 8 月 22 日
公司出钱 让公司买现成的 没钱就不留呗
|
 |
73
yidinghe 2025 年 8 月 22 日 via Android
几十 TB 一年的存储费用可不少，任何云服务都不便宜。一个方案是用 btrfs 文件系统存储原始日志文件，挂载时加上压缩参数，能压缩 80%左右，35TB 原始文本可压缩成 7TB ，一个硬盘就能装下，查询日志用 grep 即可。
|
 |
74
vopsoft 2025 年 8 月 22 日
"我们这边每天都会落几十 GB 日志，埋点+调试都有。 想法比较简单" 最后这个句改成 "想法太天真"吧
需求能实现 也是野路子或者薅羊毛 感觉就是给 2 毛钱预算 让你做核弹 ...唉 |
 |
75
js2854 2025 年 8 月 22 日
腾讯云 CLS 低频版，关闭全文索引，添加需要的键值索引，成本还比较低
|
 |
76
Gilfoyle26 2025 年 8 月 22 日
百度云盘
 |
 |
77
howencilx 2025 年 8 月 22 日
重要就会花钱，舍不得花钱那还是不太重要
|
 |
78
wangtian2020 2025 年 8 月 22 日
|
 |
79
quicksandznzn 2025 年 8 月 22 日
我们是 es 保留近几天 其它的云服务深度归档（便宜） 需要的时候在恢复
|
 |
80
BlueSkyXN 2025 年 8 月 22 日
网盘+压缩
|
 |
81
DLOG 2025 年 8 月 22 日
filebeat -> kafka -> (ck -> S3)
才几十个 G ，随便玩 |
 |
83
maximdx 2025 年 8 月 22 日
这得上数仓吧，我们公司用 pinot 或者 clickhouse
|
 |
84
HappyAndSmile 2025 年 8 月 22 日
ClickHouse 按天分区，简单，不用那么折腾
|
 |
85
luciankaltz 2025 年 8 月 22 日
可以考虑 GreptimeDB ，和常见的日志存储在官网都有对比文章。写了一大堆 v2 不让我发，麻了
利益相关 |
 |
86
yingqi1 2025 年 8 月 22 日
我也推荐 duckdb+云存储方案， 文件压缩率也是第一梯队，duckdb 也可以， 然后 duckdb 安装极其简单，使用也简单，查询速度丝毫不弱。
|
 |
87
deplives 2025 年 8 月 22 日
@linhrdom #7 一天几十 G 一年就差不多得 17T 日志，又想冷数据大容量存储存储，又想热数据随时调用，又想不花钱，又想不麻烦。讲真，寿命这个数据不重要，你们干脆自己买个几块企业硬盘吧。够用了。
|
 |
88
qweruiop 2025 年 8 月 22 日
楼上的各位佬，最近有个内部文档，看介绍 duckdb 可以直接挂在 cloudflare r2/s3 来实现全文搜索？不知道，是否有简单的例子，或者 demo 。。。
|
 |
89
tudou1514 2025 年 8 月 22 日
直接物理存，买硬盘，做好报警，满了就换
|
 |
90
pinylin 2025 年 8 月 22 日
vector -> clickhouse -> S3
vector -> quickwit-> S3 我觉得 都行 |
|
91
Maboroshii 2025 年 8 月 22 日
补充一下我之前说的文件方案：
保存到支持透明压缩的文件系统里，比如 btrfs ，不仅支持快照，也支持方便的备份 然后文件是可以天然支持根据日期分区的 最后，直接用 warp 等 ai 终端帮你查找想要的内容，都不用自己拼 grep 或写脚本分析了 |
 |
92
guyueyiren 2025 年 8 月 22 日
@ETiV #20 感觉是邪修，从未想过如此办法，哈哈
|
 |
93
lichon 2025 年 8 月 23 日
signoz clickhouse 存储 支持 S3 fallback
|
 |
94
RicardoY 2025 年 8 月 23 日
没有审计需求留一年干嘛，一个月足够了（大多数是 7 天）
|
 |
95
nicoljiang PRO @linhrdom #69 兄弟是会做推广的。
|
 |
96
z12cryoto 2025 年 8 月 24 日
可以试试 web3.storage
|
Select Language