如何获得讲师PPT：
扫码关注公众号，后台回复「1214」即可获得讲师PPT哟～
还能一键订阅后续精彩活动内容～
Q&A环节答疑：
1、（存储方案）为啥不选vm？
我们在测试时发现，使用VM也是可以的，它支持这种玩法。对于时序来说，我们的模型可以用任何支持读写协议的数据库。我们选择使用M3DB ，主要是因为它的压缩比比较高。
2、怎么解决prom的配置规模大了带来的配置问题？
配置过多可能导致问题，例如将需要抓取的IP写入配置，经常导致变更问题。如果能够实现自动的服务发现，配置基本上不需要更改。只有引入新的主线时才会修改。对于我们来说，我们引入了很多中间件，但基本上不会动，因为我们有自动的服务发现机制。
3、推模型自由度会不会太高了，如何保障业务指标的质量呢？
所谓的自由度与推模型和拉模型没有关系。我们的推模型并不是由业务在代码中推送的，而是由中间件SDK自动处理的。对于业务来说，它感受不到是推模型还是拉模型，它只需要上报指标。
为了确保业务指标的质量，我们所有的时序数据库都会面临高基数问题。一个指标可能有非常多的不可枚举的标签。在落地初期，我们也考虑到了这个问题。我们修改了P客户端，在客户端上限制了每个指标的标签数量。目前，每个指标最多只能有500个标签组合。这是从客户端角度来解决高基数问题的。
当然，有人可能会说在客户端上也可以绕过这个问题，但对于推模型来说，你也可以解决。你只需要在中间再加一层代理，就可以控制推模型的一些能力，对一些指标进行拦截等。对于我们来说，这个功能可有可无，目前还没有出现过其他问题，所以我们没有使用它。
4、限制的标签数量还是标签值的数量？
限制的是标签组合的数量，例如某个指标有55个标签，每个组合代表一个值。对于我们来说，每个指标最多只能有500个标签组合。
5、有没有考虑pushgateway ，业务直接推送？
非常有意思，刚接触时可能会掉进这样的坑。我看到有很多其他公司的同学也想将拉模型改为推模型，但是pushgateway模型中存在很多相关问题，即push OM问题。这是因为push模型会永久保留接收到的所有指标，除非重启。它需要保留这些指标供Prometheus持续采集。当你把全公司的所有指标都推到有限的几个节点上，pushgateway还不能分片，都需要固定推到一个节点上。某些指标固定的推到某个节点上，你不能说这个指标一会儿推到这个pushgateway，一会儿推到另一个pushgateway等等。这些问题会导致它根本不适合作为一个公司大规模级别的推送，就像官网上的架构图上有一个很明显的说明，它是一个短暂存活的服务采用。
6、如果把User_ID放在标签里的话，是不是会存在值发散的问题？
7、推模型是不是还需要up状态的告警？
推模型在Prometheus采集时，会对每一个采集的组件和实例都有一个up指标。在采集时，我们可以利用这个up指标进行告警。其实我们完全可以用另一个角度去解决告警问题，比如端口探测等。我们没有必要为了一个up指标而选择拉模型，因为推模型对我们来说更具吸引力。
8、推模型是不是还需要up状态的告警？
9、push的话会影响服务性能么?
我们改变的只是数据通讯的方向，从拉模式改为推模式。对于服务性能的影响并不源于数据通信的方向，无论是是不是Push，它源于你的指标的组合数量、指标占用的内存大小以及指标的上报量。我们也做了很多测试，没有发现任何影响。
10、告警事件是用prometheus原生的，还是自研服务计算的？
我们告警系统是自己研发的。原生的告警系统存在很多问题。首先，它需要自己编写PQL。对于我们来说，我们落地了一套全新的监控系统，公司的RD可能之前没有接触过这些，因此需要付出很多学习成本。另外，如果自己编写PQL，很难对一些第三方的指标进行高点，因为不了解其结构。此外，原生告警系统对很多场景的支持也不够完善。
11、这个分层分级，告警的参数值要怎么设定？来实现分级降噪
这个就是PPT里呈现的，越高等级的参数值，时间越低。越不太重要的，这个时间就会越高。当然，这个参数值我们会根据业务反馈逐渐调整。
12、老师好，针对大量三方服务对接，监控告警有没有一些经验分享一下？
是这样的，我们将拉模型改成了推模型，这使得客户端变得更加简化，它的依赖也减少了很多。对于我们来说，只需要在第三方服务中引入我们的包，如果有源码则更好，如果没有，这些都是白扯。必须要有源码，然后修改一下包，引入我们的客户端包，我们会在里面自动采集资源和其它监控信息，然后推送到服务器。如果想要在第三方代码中做一些定制化，那么直接使用这个客户端即可，这与自己研发的项目是一样的。另外，我们有很多类似的项目，不只是外包项目，只要引入我们的包就行，还有很多其他的类似需求。
13、老师好，请问告警的延迟和误报问题你们是怎么解决的？
所谓的延迟，对于我们来说，我们现在的告警是分层的。比如有一万个告警，我会分在每一秒钟去执行，会给他分层。这样的话去充分均匀这个告警查询的QPS，去减少货端存储的一个压力误报问题，我觉得是上一个问题导致的。你告警的查询，将后端的一个时序数据库查询的压力比较大，导致有很多指标查询，就会出现一些失败、超时，或者说其他的一些问题，就会产生一些误报警。
14、前面说的告警数据，和定位分析这块数据是怎么关联的？想了解下你们目前的实践情况，比如自动化分析这块有没有在做？
这块其实很有意思，我们正在规划去做。其实就是靠你的一个自动分析，这一块，其实对于可观测性来说的话，分为很多种，像我们现在做的这个监控twice-log。我们现在这三个系统的数据，大部分时候都是死数据，什么叫死数据？我不去看。这数据就没有任何价值。怎么能把这三个系统的数据给它串联、关联起来。比如说，当我发生报警的时候，我能自动的把影响告警产生的时候的trace可以关联能够带出来。在这个告警里面，我一点击我就能看见：产生告警的链路是什么？如果哪些链路是异常，哪些链路是正常的？包括我可以看到去联动日志系统，我根据日志系统上去联动查询出来对应的日志都有哪些？这些是目前是在规划来做这个东西，那具体怎么联动要看怎么把log一起联动，这个我们目前是借鉴了一个去哪儿网的一个方案，目前是这样的一个思路，就是在打点的时候。会把Mat label metrics label都去关联到注册到当前trace里面。这样就可以通过查询到它所对应的关联到log这个就比较简单。
15、报文异动这种可以配置化告警吗？现在这个项目。比如对接三方数据，约定的税务数据突然没了。
只要打点就行了。在服务中，只需在代码中遇到异常情况时进行打点，比如发现某个指标没了，打一个点就是一个异常，将其加一就是一个计数器，这样就可以进行报警。
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫 