大厂的同事们，你们是怎么定位线上故障的？

纵坐标是啥，我们都是 SLS 查关键字

牛逼的用眼看，其余的 grep -i xxx.log |less

第一阶段： 看日志

@whoami9426 #40 这个是不是 javaagent 实现的？

@bli22ard 基于 aop 实现的, aop + git blame + webhook

代码注释 二分查找

@ala2008 我云服务公司也是这么查的。。。甚至有的容器日志没有映射，还得现查日志文件路径

总的来说就是可观测性那一套 Metrics+Log+tracing.

用得多的就是 Promethues 全家桶，ELK 那套日志， 加 APM.

往细节上，
除去系统性能指标那些，还加上了应用/业务指标的监控。
网关层面的状态码监控。
再加上数据库慢 SQL 之类的监控。
最后还有就是波测，SaaS 多地监控。

@whoami9426 #85 git blame 只有在编译阶段才有吧， 难道你们每次编译生成了一个代码行和 git blame 的对应关系，出现异常 ，用堆栈类+行号 取找 git blame 的信息，然后生成通知信息？

@bli22ard #89 是直接请求 git 平台的 git blame api , 根据仓库,分支 实时读取的最新的代码

@whoami9426 #90 厉害了。

@weilai99 量大 selfhosting 的 sentry 能搞死你，我折腾了俩月，才扛住 50W 日活的 app

@zcl0621 #92 大概需要多少服务器资源，我有个项目也想用用这玩意

完全用 SLS 来排查和运维

@lepig 最近学习的 grep "error" *.log -ni --color=always

@JoeDH kafka ，redis ，pg ，clickhouse 全部拆出去部署；需要修改 selfhosting 的脚本，compose 文件，还有几个 py 文件；以及手动去执行 kafka ，pg ，clickhouse 的初始化文件；其他那些组件都跑在一台 16c 还是 32c 的机器上(目前离职一段时间了，我不太记得了);还需要调整 container 的数量。总之 selfhosting 的坑贼多，文档也很少，只能自己摸索。

看来思路是类似的💪

https://blog.keepchen.com/a/talk-about-api-response-structure.html

我们公司是
try:
...
except:
pass

没有报错就没有 bug

@proxychains #73 加下 —no-pager😂

没人折腾这个吗？ LGTM

https://github.com/grafana/docker-otel-lgtm