![]()
上周一篇LinkedIn技术帖突然爆了。作者搭了一套Prometheus+Grafana的EKS监控栈,评论区却出奇一致地指向同一个缺口——"把Loki加上"。
这条建议价值连城。metrics告诉你"坏了",logs告诉你"哪坏了"。两者分家时,工程师得在kubectl logs和Grafana之间来回切,手动对时间戳。这不是工作流,是考古现场。
三文件部署:ArgoCD的"一键三连"
作者用ArgoCD把Loki和Promtail并入了现有Prometheus栈。整个改动就三个文件:一个ArgoCD应用定义、一个Grafana数据源ConfigMap、一个日志面板ConfigMap。push到main分支,ArgoCD自动同步,收工。
这种"基础设施即代码"的部署方式,把原本可能折腾半天的配置工作压缩到了版本控制的一次提交里。
最终成品是个七面板四行的统一仪表盘,作者直言"早该这么搭"。
面板的秘密:时间同步才是杀招
第一行放metrics:API请求率和错误率,来自Prometheus。看流量模式,抓异常点。
第二行是API日志:Loki实时拉取的gitops-api容器日志。上面metrics刚冒出尖峰,往下滚两屏就是同一秒产生的日志。
第三行基础设施日志:左边PostgreSQL,右边Redis。数据库checkpoint警告、连接事件、缓存操作,不用跨多个pod跑kubectl logs。
第四行错误日志:过滤后的视图,只显示含error、fail、panic、crash、exception的行。这是"出事了,给我看现场"的应急面板。
第五行日志量:每秒每容器的行数。日志量突然飙升,往往是某个服务在疯狂抛错。
核心设计是时间同步面板。在metrics图上拖拽选个时间范围,下方所有日志面板自动切到同一窗口。看到尖峰→框选时间→读日志。两分钟定位根因,作者把这叫做"metric-to-log关联工作流"。
LogQL上手:PromQL用户零门槛
熟悉PromQL的人,LogQL几乎无缝衔接。流选择器用大括号,跟Prometheus的标签匹配器一个套路。
拉取three-tier命名空间全部日志:
{namespace="three-tier"}
只看API容器:
{namespace="three-tier", container="gitops-api"}
用管道过滤错误:
{namespace="three-tier"} |~ "(?i)(error|fail|panic|crash|exception)"
把日志量变成指标(给时序图用):
sum(rate({namespace="three-tier"}[5m])) by (container)
最后这条有意思:对日志流用rate(),得到每秒行数,可以像Prometheus指标一样画图。用来发现"错误风暴"特别管用。
资源瓶颈:t3.medium的硬天花板
部署时卡了一手。Loki调度失败,两台t3.medium节点已经塞满了应用、Prometheus、Grafana、Alertmanager、Node Exporter。作者没展开怎么解决的,但留下了这个细节——小集群玩全栈监控,资源规划是隐形门槛。
这套方案最狠的地方在于"上下文折叠"。过去排查故障要开五个窗口:Grafana看metrics、终端跑kubectl logs、可能还要进AWS Console查CloudWatch。现在一个仪表盘,上下滚动就能完成"现象→定位→根因"的闭环。
作者最后放了个对比:加Loki之前,同样的排查流程平均15分钟;现在压到2分钟以内。这13分钟的差距,在凌晨三点的on-call场景里,是睡觉和通宵的分水岭。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.