黑盒监控与白盒监控

序言

谈到监控，有各种各样的监控软件，有各种各样的存储数据的格式，最流行的莫过于将相关的监控数据存储在mysql中，建一个表，然后按照时间来进行监控，这种方式最大的缺点就是不能灵活的按照各种维度来统计数据。

强大的监控，一眼看过去，就能知道是啥出了问题；强大的监控，易于使用，不用到处找啊找，躲猫猫了解一下。。。

黑白双煞

有一种监控方式，分为黑盒监控和白盒监控，看起来和测试好像。。。所谓的黑盒测试和白盒测试。。。想起来我养的两只狗，称之为黑白双煞。。。

黑盒监控，主要关注的现象，一般都是正在发生的东西，例如出现一个告警，某文件系统不可写入，那么这种监控就是站在用户的角度能看到的监控，重点在于能对正在发生的故障进行告警。

白盒监控，主要关注的是原因，也就是系统内部暴露的一些指标，例如redis的info中显示redis slave down，这个就是redis info显示的一个内部的指标，重点在于原因，可能是在黑盒监控中看到redis down，而查看内部信息的时候，显示redis port is refused connection。

什么是因？什么是果？种果得果，种因得因。。。

白盒监控，有很多种，有中间件，有存储，有web服务器例如redis可以使用info暴露内部的指标信息；例如mysql可以使用show variables暴露内部指标信息；例如httpd可以使用mod_status来暴露内部信息。。。

白盒监控，对于应用系统来说，就称之为应用的埋点。。。纠结了好久，什么叫埋点，埋葬一个葬花人么。。。简单可以理解为，通过编程的方式，来收集相关的数据，例如请求的成功率，请求的失败率，将相关的数据收集之后，统一发给监控系统，如果符合报警规则，则进行报警。。。

嗬，埋点。。。在应用系统中，增加metric的时候，主要根据监控系统的client sdk来进行设置。。。听起来感觉好酷，实际了解了一下，其实。。。也就那样，一点都不好玩。。。

一个监控系统的构建，如果没事就发出来告警，这种狗屎监控，留着有何用？？？信噪比如此之高，怎么玩。。。适当降低心理期望？一不小心就是一个故障，一不小心就是一个锅。。。

降低SLO来改进服务，优化服务质量，或者。。。全名运维，自己拉的屎自己吃，让开发自己来运维吧。。。运维，或许也只是一个擦屁股的玩意儿。。。

探针？prober。。。在很多时候，我们需要探针来检测一些东西，例如进程在不在呀，例如磁盘分区是否可写呀。。。

探针？断了怎么办。。。

上次碰到一个告警，某某主机的文件系统不可写，整体流程如下：prober是一个进程，在需要测试的分区上写入一个文件，成功之后，删除文件。。。

收到告警，那就处理呗，上去这个主机，找到这个分区，写入一个文件。。。嗬，可以写入。。。查看测试文件，发现还在。。。流程没走完？这属于误报。。。

好吧，既然是误报，那就重启一下prober，重新进行探测一次。。。嗬，居然没成功。。。这。。。触碰到了知识盲区。。。

查看一下检测的进程，发现还在。。。最后发现有一个子进程，其实也就是touch文件的进程变成了僵尸进程。。。所以，无论怎么重启都是不能解决的。。

查看一下僵尸进程的父进程，还好还好，不是pid为1的进程，杀掉僵尸进程的父进程，一切OK。。。

探针。。。断了怎么办，万万没想到。。。居然变成了僵尸进程

长尾效应。。。在监控中，经常需要查看各种监控指标的rate，可以是流量，可以是各种请求的数量，那么在统计这种数据的时候，需要注意长尾效应，毕竟如果百分之九九的请求响应速度为1ms，剩下的百分之一的请求为5s，看看平均值，嗬。。。相差的太多了。。。从而在一些监控系统中，需要统计百分之五请求的成功率，百分之五十的成功率，百分之九十的成功率。。。当然，把请求分为成功率和失败率是一种更好的做法。。。毕竟慢慢的失败比很快的失败要好的多咯？？？

监控，怎么和开发人员配合？

把开发人员拉到一边说。。。兄弟，你加班加点开发的BUG看看一天告警一百个。。。你来运维试试？

把开发人员拉到一边说。。。兄弟，你开发的系统性能很高啊，你看看这CPU，这内存使用量，这文件系统，这吞吐量。。。但是这个前台界面的响应时间不高啊，从web页面到nginx这个响应时间还行，但是从nginx得到请求和响应的时间有点长哇，是不是数据库的性能不足了？是因为数据库里面的数据太多了么？要分库分表嘛。。。我有分库分表的方法，但是应用方面要进行改造。。。我可以给你增加一个redis cache。。。要不要试一把~

监控，怎么和产品配合？

把产品拉到开发旁边，指着dashboard说，看看这个日活量，看看这个活动的增长用户说，看看这个点赞数。。。你们的需求是根据屁股决定么？关门放程序员。。。

风言风语

某人被提升为管理者，从此我们失去了一个优秀的运维人员，增加了一个傻逼的管理者。。。Emmm。。。这个话很有道理。。。

have you tell Prometheus which Alertmanager

it will be talking to. You will need to expand your prometheus

随时随地进行功能测试的时候，是否在这个功能测试中需要加入重试机制？？？功能测试本身故障怎么办？网络抖动怎么办？。。。某些service test还是需要的。。。