前言

博主本身并不是负责apm项目的，基本都是自发的行为，这是很好的一方面，打工人一定要培养自己的行业里面的独有经验，下面我聊两句。

纵观《资治通鉴》，它讲中国古时代的精英，以及帝王他们的处事方式，所以它被称为帝王之书，用于管理人员、事务处理，但是如果用于个人品行去学习可能有所偏差。比如说在这些人哪个不是权贵，所以他们的权利比普通人高的，其次处理的事情也不是我们日常的芝麻小事，当角色不同、地位不同处事方式也不能直接照搬～

另外，唐代宪宗里面有段有意思谈话，他跟宰相在聊，怎么样能做好一位君主，宰相参照以往的历史，认为人的精力有限的，应该制定好选人机制、kpi考核，这些那些事情交由他们来处理。这里面提到了选人机制、还有考核机制制定，对于一个治理国家的人来讲，有一套合理的机制处理日常各种事务非常重要的，其次在位的这些头头应该是要称职，就需要靠这套考核机制。

职场上真正能力

我聊聊职场上应该怎么做才是比较好，我认为一个领导者最重要是在某个领域有自己的见解，也就是你知道某个领域未来的规划，然后可能遇到问题的解决方案，比如说供应链，本质来讲我认为它是提高这个流程的作业效率，对整个流程情况有一个数据支撑，比如说整条链路耗时出在哪里，有哪些还是人工作业。然后你再参照其他公司，你会发现它是通过c端用户消费数据来促进供应商里面商品快速迭代，打法又不一样。这跟你b端供应链自己玩不是一个档次，比如说采购商买得多的料子就是爆款吗，也不一定，说不定人家用来批发的。

至于管理能力，我按能力强弱、执行力的强弱去安排就完事了，所以我认为职场里面的领导者不是说简单的管理人，而是在特定领域有自己建树，真知灼见才是王道，即使没有能够主动了解学习，不愧为智者。

apm 查询优化

现状

之前也有同学反馈说apm查询比较慢，就是那种跨很长的时间跨度那种，最近有空我就去看看，发现代码比较久远的，通过restclient 直接通过es语句去请求。

我们apm日志是按天来分片，如果说跨天就需要 get /xxx_20230907,xxx_20230906/_search 来执行查询功能，我们每天日志量大概在5kw左右，这么多个索引查出来肯定会慢，其次加上按时间排序。

思路

我们按响应结果来看，就是一个total+分页查询数据，total的话，我们可以通过count方法来查询，其次分页查询数据大概10～500行一页，这就意味着我当前的查询会落在一个到两个索引里面，不需要把索引都塞进去查，所以关键在于找到我当前查询页所在的索引分片是哪个，直接查询即可。

实现

1、如果是聚合语句，或者单个索引分片（查一天）直接查询

因为聚合它需要做统计功能，无法直接通过单个分片来进行，一天查询只会命中一个索引，这我们直接执行查询就可以了。

2、查总数

通过多个索引的count+查询条件，我们可以查出当前条件下的所有数量有多少，一次性查询出来

3、定位索引分片

因为我们是时间倒序，我们将时间索引也倒序的查，比如说9月7号先查总数，10个符合的，如果说我在第一页，一页有8个，那么我直接命中第一页查询即可，第二页的时候，会跨分片，我们统计9月6号符合的个数，如果说它大于等于2，也就是刚好满足第二页的内容，我们通过get 两个索引来查询。

这样避免说我把所有索引都引进来暴力的分页查询。

4、数据组装

我们需要将上面的分页数据跟total组装返回给前端

apm接口请求缓慢归因分析

之前在第二篇apm 请求 “异常”分析的时候出现这幅规划图，当我实际去实现的时候发现有一些细节问题。

细节

1、异常点算法问题

我之前看去哪儿网也有谈到类似的，采用lof模型去统计，你就会发现几个极端情况：第一一堆的请求很慢的接口，几个请求很快的接口，这些很快的接口变成异类了，我滴妈；第二 一堆20ms接口，一两个400ms接口，这也是异常点；

所以在我掂量下采用了方差法，就是你比平均数高3倍方差，你就是异常点，当然这也存在上面的第2种情况，需要进行降噪。

1.1、降噪

a、定时器接口处理

定时器如果作成同步接口，那么会非常的慢，因为如果压榨机器性能可能会垮掉，只能慢慢跑。我们可以通过异步线程的方式进行处理，这样就不影响我们统计慢请求了。

b、正常的“异常点”

比如说第2种情况，正常接口请求只需要在200-500ms之间即可，但是如果我们内网点情况会非常快，导致这些接口也变成异常点，所以我们通过判定接口的平均时间大于500ms，然后你当前的请求时间大于它3倍方差，那么这个就是整个应用的异常点。

by the way，我们统计是有个时间窗口，比如说10s进行统计，所以我们上次才讲平均时间去跟500ms比对。

2、归因分析

2.1、按接口响应时间变慢维度统计

这个我认为是不行的，一个可能存在数据集小，比如说a接口，半小时才请求一次，你怎么知道接口变慢了呢对吧，另外一个除非有新版本更新才能发现接口速度变化情况。

2.2、按照时间最长的top3统计，接口+mysql请求

比如说我应用很慢，这些请求时间很长的当然是罪魁祸首对吧，没毛病。这里也有一个细节，就是应该去除网关接口统计，因为网关是最外层了，你统计它的接口意义不大，而是应该链路里面的服务最慢的哪些接口，还有数据库请求sql统计起来。