背景
最近两年的时间，一半左右的时间在做架构运维相关的工作，负责部门内一个可以说是故障、问题最多的系统运维负责人 A 岗。对于运维过程中，监控体系的欠缺有一些思考，认为对监控体系的建设有有一定帮助，分享与大家。
这里可能会用到 Prometheus、spring boot actuator 等相关知识，专业术语不会过多补充，后续若有时间会修改备注，请谅解。
定位类监控
相比于领导层面期望的快速应急，并且恢复服务。作为一个“刨根问底”的开发人员，我还是希望第一时间能够先定位到我的问题，不仅仅是问题的范围、影响的范围，还想知道具体哪一行代码导致的。
定位类监控就是深埋于代码的字里行间，透彻的展示错误。就例如在 springboot actuator 框架中，会将 tomcat 的接口请求成功率相关的指标暴露出来，供监控收集。其后配置成监控页面、告警指标。这都是公开的方案了，想必有相关工作经验的都有了解。
分享一个曾经的接口超时故障案例。在Prometheus 监控上可以看到 A 接口在 3 分钟内发生了 2 次请求超时，然而在对应的日志中，只发现了执行 SQL 使用了 100 毫秒，其余均无日志，也无明显耗时代码，导致了定位问题成了难题。
在不懈的努力下，发现该 SQL 查询返回的行数实际为 100 万条，在 mybatis 框架将结果从数据库读取回来，并转为 java 对象中极为耗时。后续，就在代码中，针对 mybatis 框架的执行耗时，对象转换耗时进行了埋点。之后对于 SQL 导致的慢接口，排查起来就更加轻松了。
以上的监控埋点，是位于框架层面的，整体看来，与 http 接口请求成功率是一个类型的，不是针对某一项具体业务。不知道大家是否遇到过链路过长，接口异常时，并不清楚具体错误的环节在哪儿。可能有些系统接入了类似 skywalking 这样 trace 类的 apm 工具，但是它也有一定的局限性：它的埋点也是框架层面的。
apm 工具针对业务成功率相关的埋点，提供了类似于：“@Span”这样的注解，用于方便针对一条链路排查时直接定位范围，这是极好的，但是需要业务开发人员意识的：“此处需要埋点”。
不过 apm 工具有一个缺点，就是有“采样率”，一般难以全量存储，以及存储后深度分页查询性能不佳。主要是海量的存储有太多限制。这也导致了 apm 工具最终有些公司停用。
不过我们要学习的是它“业务埋点”的意识，方便定位。通过暴露监控指标，包含成功率、耗时、百分位耗时等等，使用 Prometheus 采集。这种“汇总”的时点指标，所需存储要求有大大降低。通过在 grafana 上配置各个业务步骤的 SLI 指标监控，我们会较快定位大量接口报错时，主要的错误范围。因为成功率会向漏斗一样，只有少部分能真正的成功，而漏洞猛然“收腰”，第一个出现错误率的步骤，往往就是病灶。
小结
时间有限，先码这么多，后面再补充……（未完待续）
