
近期公司要求降低服务器成本,然后砍掉了 Prometheus 、grafana 、skywalking 只留下了 elk
回忆了一下待过的几家公司,确实大部分情况只看日志,指标监控方面服务器与 k8s 由云厂商提供,应用实例方面有使用 spring boot admin 的也有 Prometheus 的,基本没人看
链路监控有简单的日志内嵌 traceId 的也有搭 skywalking 的,我个人觉得 traceId 够用,skywalking 没玩明白
个人待过中小团队,参与最大项目也就低粘性日活百万,思考了一下比较适合中小团队轻量监控体系,日志系统用 Loki ,logback appender 直接 push 过去,链路追踪靠 traceId ,服务实例监控用 Prometheus ,grafana 展示
日志采集需要经 Kafka 缓冲再存储的我还算不出来要多大的体量才需要,个人觉得以上方案应该可以适用大部分团队了,欢迎大家指正,顺便想了解下大家的项目量级与监控体系
1 guxingke 2024-01-31 15:34:27 +08:00 grafana 全家桶 |
2 yidinghe 2024-01-31 15:41:47 +08:00 小公司没必要付那么高的基础设施成本。如果你们公司主要都是些负载不高的服务,那么 grafana 之类的确实可有可无。如果出了问题,重启一下服务就好。关于日志,只要抛出异常的时候多带点信息,大部分的错误光看包含堆栈的这一条日志就能定位问题,无需链路。 |
3 arloor 2024-01-31 17:31:44 +08:00 我觉得小公司应该为可观测付出的成本应该不超过: 1. 一个人或者半个人维护可观测的服务( prometheus 、grafana 等等 2. 大部分人不需要学习 promql 等等使用 第一点是成本考虑,第二点是出于人性懒惰的考虑 |
4 ikas 2024-01-31 20:43:26 +08:00 目前可观测性的框架都可开始整合日志,链路,指标 .比如 OpenTelemetry,还有最新的 springboot3 基于 springboot3 的最新可观测 api,然后根据项目规模选择自己喜欢的可视化与存储后端即可 |
5 Aresxue 2024-02-01 10:39:57 +08:00 可观测性比较适用于大型成熟系统,小项目基础设施搞得再好如果只有零星几个开发那也没多少收益。可观测性目前主要分为几大块,log (日志)、trace(链路)、metrics (监控)、alarm (告警),对于小项目来说要有取舍,比如题中提到的 skywalking 我司目前也是用的这个并做了二开但是这是建立在核心系统有超过 60 个应用,上千个 pod 的基础之上的,小项目哪怕使用微服务应用数也很有限,链路本身就不复杂,所以链路的优先级远远低于日志(日志中有 tid 其实可以脑补串联起链路),剩下的监控和告警常常是一起的,Prometheus 几乎是事实意义上的标准了,只有告警成本较高收益不明显,资源告警和业务告警搞起来不要太复杂。所以小项目资源紧张的情况下优先保障日志(日志规范其实也很有讲究有很多技术手段可以做),其次有空余资源就把监控( jvm 内存、进程内存、gc 、cpu 、磁盘 io 、网络 io )搞起来,链路和告警可以在项目有更大的发展之后再逐步引入。 |
6 ychost 2024-02-01 16:42:07 +08:00 自己搭建还是复杂,直接用阿里云的 SLS 就行了(如果允许把日志上传到云),配套还是很完善 |
7 hancai 2024-02-01 17:15:02 +08:00 没有专业的运维就别搞太复杂了, 有运维就大力搞一下,对于运维来说监控非常重要。 不出问题大家都高兴,出了问题监控不完善,运维还得背锅。 |
8 hrzpaul02020 2024-02-01 17:39:56 +08:00 Loki 代替 elk 存日志 没啥问题 至少比上服务器看文件好. 调用链用阿里云免费的三天也够 . 几个人的小团队 |