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