loki + grafana 日志方案,比 ELK 轻多了
之前用 ELK,Elasticsearch 又吃内存又吃磁盘,小团队根本养不起。换成 Grafana Loki 后清爽多了。 Loki 的思路是不索引日志内容,只索引 label,存的是压缩的日志流。资源占用低一个数量级。 配合 Grafana 看日志,跟 metrics / t
这里聚合 CodeNodeX AI 社区中与 DevOps 相关的技术文章和讨论,覆盖概念解释、工具对比、工程实践、常见问题和独立开发经验。
如果你正在研究 DevOps,建议先阅读高质量长文,再参与帖子讨论,形成从理解到实践的完整路径。
之前用 ELK,Elasticsearch 又吃内存又吃磁盘,小团队根本养不起。换成 Grafana Loki 后清爽多了。 Loki 的思路是不索引日志内容,只索引 label,存的是压缩的日志流。资源占用低一个数量级。 配合 Grafana 看日志,跟 metrics / t
搭了 Postgres 流复制,主从架构,读走从库。但偶尔出现 "写完立刻读不到" 的问题,应该是复制延迟。 排查: pg stat replication 看 replay lag ,确实有 100ms 2s 抖动。 大事务会导致延迟突增。 从库 IO/CPU 慢也会拖后腿。
Docker 跑服务,默认 bridge 网络,但有时为了性能或方便(不想映射端口)会切 host 模式。两种模式一直没完全搞清楚取舍。 简单总结: bridge:隔离性好,端口要 p 映射,性能略损(NAT)。 host:直接用宿主网络,性能最好,但端口冲突、隔离差。 macv
K8s 集群用 ingress nginx 暴露 HTTP 服务,配置过几轮后总结了一些常用 snippet。 基础 ingress: 常用 annotation:限流(limit rps)、CORS、basic auth、canary。证书走 cert manager 自动签发
不想给云厂商交对象存储的钱,自建了一套 MinIO 存用户上传图片,S3 兼容 API,配 Next.js 的 image loader 很顺。 部署很简单,docker compose 一把梭,挂个挂载点就行。配合 mc 客户端做 bucket 管理和生命周期策略。 踩过的坑:
pnpm 项目在 CI 里跑 install 慢,缓存总是配不好。试了几种方案,记录下正确的姿势。 GitHub Actions: 关键点: 必须用 frozen lockfile ,否则可能改 lockfile。 cache key 用 pnpm lock.yaml 的 has
团队在选部署策略,蓝绿 vs 滚动 vs 金丝雀,每种都说自己好。说说我的理解。 蓝绿:两套环境,切流量瞬间完成,回滚秒级。资源占用翻倍。 滚动:渐进替换,资源省,但回滚慢,滚动期间混合版本。 金丝雀:先放一小撮流量观察,最稳,但配置最复杂。 我们的选择: 数据库 migrati
有些定时任务和数据处理 Job,想用云上的 Serverless 容器(阿里云 ECI / 腾讯云 EKS)跑,按量付费。但担心费用失控。 算过一笔账: ECI 按秒计费,单价高于自建 ECS,但不用常驻。 短时、突发、低频任务 → ECI 更省。 高频长跑任务 → 自建便宜。
应用要暴露 liveness / readiness 两个 health endpoint,但 "应该查什么" 一直没统一。说说我们的实践。 liveness(是否该重启我):只查进程活着、event loop 不卡。 不要 查依赖。 readiness(是否该给我流量):查关键
Nginx 限流 ( limit req ) 一直配不好,要么限不住,要么误伤正常用户。 基础配置: rate=10r/s 是平均速率, burst=20 允许瞬时 20 个排队, nodelay 让排队的不延迟直接放行。 调参心得: 看接口真实容量,留 30% 余量。 区分接口
Postgres 跑久了,表越来越大、查询越来越慢,往往是 autovacuum 没跟上,dead tuples 堆积。 排查: VACUUM (VERBOSE) mytable; 看 dead tuple 比例。 pg stat user tables 看 last vacuu
Redis 持久化方案纠结很久:RDB 简单恢复快,AOF 数据安全。生产该用哪个? 简单对比: RDB:定时快照,文件小恢复快,但故障可能丢几分钟数据。 AOF:记录每个写命令,最多丢 1 秒,但文件大、恢复慢。 生产推荐:两者都开(RDB 做快照兜底,AOF 做实时持久化)。