这是一个创建于 297 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们这边每天都会落几十 GB 日志，埋点+调试都有。 想法比较简单：
之前看过对象存储 + Presto(Trino) 这套，但有点懒得自己搭建和维护，感觉太折腾。 大家平时是怎么搞的？有没有省心点的办法？
 |
1 FlashEcho 2025 年 8 月 21 日 3
grafana 可视化+promtail 收集+loki 日志聚合+任意对象存储，k8s helm chart 一个 loki-stack 全搞定了，只要调调 yaml 配置，相当不折腾 |
 |
4 Nitroethane 2025 年 8 月 21 日 via iPhone试试阿里云 maxcompute ？内部叫 odps ，挺好用 |
 |
5 nm1st 2025 年 8 月 21 日 2
duckdb+s3 |
 |
6 Smileh 2025 年 8 月 21 日买个 10T 硬盘 |
 |
8 COW 2025 年 8 月 21 日 via Androidpresto 非常吃内存的，而且也不太推荐用于块存储查询，要不看看 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? 虽然成本也不低 |
 |
14 pingdog 2025 年 8 月 21 日 via Android买冷存储块，3 天后就放入冷库，要查在捞出来 |
 |
15 DefoliationM 2025 年 8 月 21 日 via Androidquickwit+s3 ，完美符合你的要求，支持全文搜索。 |
 |
16 ETiV 2025 年 8 月 21 日 via iPhonehttps://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
我有一技： |
|
20 ETiV 2025 年 8 月 21 日 via iPhone 1
我也给我们项目写过 - 日志每天 gzip 上传到阿里云 oss 、AWS S3 这种地方，存储路径、文件名都有规律的 |
 |
21 lscho 2025 年 8 月 21 日 4
便宜 以上不可能三角 |
 |
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 位数了。如果这钱都不想出那说明这数据没那么值钱。 |
 |
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 |
 |
48 Sezxy 2025 年 8 月 22 日日志我们最多只存 30 天 |
 |
50 dode 2025 年 8 月 22 日试试 clickhouse ，带压缩功能 |
 |
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 年。 |
 |
57 luzihang 2025 年 8 月 22 日年初遇到个需求，金融机构上面来检查，按照订单号，要查 5 年内的日志：请求和响应 2 条。后面写个脚本，读按照日期归类的日志压缩文件。 |
 |
59 laminux29 2025 年 8 月 22 日你既要方便地能直接 SQL 查询，又懒得搭建和维护。 这边建议您花钱找人帮您搭建。 |
 |
61 la2la 2025 年 8 月 22 日假设 1 天 100 GB 数据，1 年 大概 36.6 TB 左右的数据 |
 |
63 JoeDH 2025 年 8 月 22 日一年有没有必要？如果接受不了云服务的价钱，那还是自己买存储搭一套吧 |
 |
64 Moatkon 2025 年 8 月 22 日找一个压缩算法，规划好分片维度。后面业务如果需要找到指定分片解压 |
 |
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 日志，埋点+调试都有。 想法比较简单" 最后这个句改成 "想法太天真"吧 |
 |
75 js2854 2025 年 8 月 22 日腾讯云 CLS 低频版，关闭全文索引，添加需要的键值索引，成本还比较低 |
 |
77 howencilx 2025 年 8 月 22 日重要就会花钱，舍不得花钱那还是不太重要 |
 |
79 quicksandznzn 2025 年 8 月 22 日我们是 es 保留近几天 其它的云服务深度归档（便宜） 需要的时候在恢复 |
 |
81 DLOG 2025 年 8 月 22 日filebeat -> kafka -> (ck -> S3) |
 |
83 maximdx 2025 年 8 月 22 日这得上数仓吧，我们公司用 pinot 或者 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 我觉得 都行 |
|
91 Maboroshii 2025 年 8 月 22 日补充一下我之前说的文件方案： |
 |
93 lichon 2025 年 8 月 23 日signoz clickhouse 存储 支持 S3 fallback |
 |
94 RicardoY 2025 年 8 月 23 日没有审计需求留一年干嘛，一个月足够了（大多数是 7 天） |
 |
96 z12cryoto 2025 年 8 月 24 日可以试试 web3.storage |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
