pushgateway 数据缓存配置

咱们继续啊，然后咱们往后啊，咱们来看一下啊，这个铺式 ktv 的一些优缺点。咱们之前呢咱们呃介绍了啊，这个铺式 ktv 啊，写这个脚本的一个方法啊，总的来说呢，还是啊比较灵巧啊，比较简别比较简洁的啊。 那么之前呢，咱们跟大家说过啊，浦西 ktv 啊，这种自定义的采集方式啊，他的一个最大的优点就是快速灵活啊，而且不受什么约束啊。其实呢，说到这啊，我个人啊，还是啊比较呃倾向于啊使用这个浦西 ktv 来获取这个监控数据啊， 那么各类的 exporter 呢，虽然啊很多啊，而且呢默认呢都提供了很多的这个数据啊，足够使用 啊，但是一般情况下啊，我们在企业当中啊，尤其是中小型的企业，我们呢这个 export 啊，我们一般只要 no 的 sport 和 db 相关的 export 这两 两种啊，就足够用的。那么其他类型的监控数据啊，我个人倾向于啊推荐啊使用不是 ktv 的方式啊，进行采集啊， 呃布施黑特卫呢，虽然啊他灵活快速啊，但是呢相对的也存在着一些短板啊，咱们接下来呢来看一看啊，普尔米修斯的官方网站啊，是怎么说的啊，这块呢，就是截取了这个官网的，对于这个 promises 啊，对于这个普世黑特卫的一段啊，就是我们什么时候应该使用普世黑特卫啊，他的这个优点有什么啊？缺点是什么？ 这个英文啊，不拉不拉说一大堆啊，其实啊，总结起来啊，就基本上就两点啊，上面这一大段话，首先第一点呢啊，缺点啊，不是一个位啊，他 本身啊会形成一个单点平静，那么假如说啊，有很多个这个采集脚本啊， 这个服务器上面的这个铺式黑图柜的这个采集脚本，同时呢给一个啊铺式黑图柜的这个进程发送这个监控数据 啊，假如说呢，这个进程因为某些原因呢，就没了啊，关闭了啊，那么这个监控数据呢，也就猜不到了。那么这个呢，就是啊，上面啊提到的啊，这个第一个啊，使用 pose k， 使用 pose k 的位啊，存在的一个啊隐患。那么第二点呢，就是说 peca 的位， 呃，他本身啊自己并不能呢对发送过来的这个脚本采集的这些数据呢，进行一个比较智能的判断。那么假如说这个脚本啊，咱们在这个采集脚本当中啊出现问题了，这个对于这个 有问题的数据啊，或者说是本身就已经错了的这个数据啊，发送给铺式给的位，他呢一样的这个照单全收啊，全部都接收过来啊，发送给 permesis， 呃，关于这两点啊，官网提到的这个缺陷啊， 呃，实际上呢，通过我本人这两年多啊使用啊，对于第一条缺点呢，实际上啊， 咱们只要啊保证福气本身不当机啊，或者说操作系统本身不当机，那么基本上这个浦时 ktv 的运行还是啊很稳定的。那么就算呢，有很多的这个脚本啊，大量的同时往一个浦时 ktv 去发送， 那么实际上啊，最终呢，也只不过呢就是导致呢这个 pose ktv 它接收请求的这个速度呢啊会变慢，因为咱们之前也说过啊， pose ktv 呢，它是啊接收这种 http pose 的这个数据的这个形式，那么这个 pose 呢实际上是属于一种数据发送和数据更新啊这样的 机制，所以说呢他的这个速度啊肯定呢相比较这个 get 请求啊肯定会啊，就是同样这个数量集上面啊肯定会比 get 要慢一些，那么假如说大多很多的这个监控脚本啊同时往一个图事业的位上面发送啊，实际上呢这个经过这个实际的测试啊，也不过呢就是啊接受速度啊会变慢啊，可能会有一点延迟 啊丢数据的话呢，我确实没有遇到过啊，而且有的时候呢我甚至啊反反倒觉得呢这个不是贝多呀，比啊很多的这个 expoters 啊还要稳定。 我之前在啊这一两年的时间内啊使用这个各种 expoter 啊这个 expoter 实际上它的这个社区开发啊它的呃还虽然种类比较多，但是呢还是有点啊缺乏统一性啊，这个使用什么语言开发 expoter 的都有啊，这个水平呢应该也是参差不齐的啊，在一两年的这个实际使用中实实际使用当中啊 expoters 啊，有些 expoters 倒是有的时候 还真的啊就发生了这个档机或者丢失数据啊啊这个地方呢其实啊也是因为啊 expoters 本身的这个开发啊比这个不是黑社会这种脚本啊要复杂的多。这个 spoters 呢啊在这要说一下呢是什么呢？就是 啊他用咱们这种简单的脚本语言啊，是写不出来这个这个 xpotes 啊，或者说很难啊，用这种简单比如说拜式这种脚本啊去开发 expotes 啊，这个是啊是不太现实啊，所以说呢，往往啊越简单的东西往往越稳定啊， 这个呢就是针对啊，第一条啊，官网的缺陷啊，咱们给大家呢吃一个这个定心丸啊，那么对于第二条缺点啊，就是说 不是 ktv 啊，对于发送过来的数据没有一个比较智能的一个判断啊，那么假如说中间数据有问题，那么他们也一样啊，都都接收了啊，其实呢，呃，在这款啊，我们呢就是要求咱们的这个运维和运维开发啊，咱们在写这个数据采集脚本的时候啊，咱们尽量呢 细心一些啊，这个不要人为的出现一些错误啊，这个很多的这种低级的错误啊，那么所以说这块啊，也是为什么啊，我在上节课啊，推荐啊，咱们在写这个不是 ktv 的这个交代的时候啊，咱们能用拜师写啊，咱们尽量去拜师写，因为它简单啊，不容易出错 啊，你要是使用拍子写啊，各种啊调各种酷啊，然后去去发送连接，那么去去写这个这个，呃呃，脚本的话，我这块不敢打保票啊 啊，所以说啊，针对这两个缺陷啊，我觉得呢啊，咱们呢其实还是不需要太担心的啊，这个官网说的呢啊，其实也是有点，嗯，就是有有一点偏激啊，这块呢给大家吃个定心丸啊，咱们可以放心的使用啊，没有什么太大的问题啊， 好，那么最后啊，咱们在第十讲最后啊，给大家呢留一个小作业啊，咱们呢自己首先呢尝试啊，在一个机器上面搭建图饰 ktv， 并且呢咱们自行编写一个采集脚本啊，使用啊 脚本就 ok， 然后呢咱们自行尝试编写一个啊聘延迟的啊，聘的这个延迟和丢包率啊，咱们往后啊，咱们针对这块的这个实际生产上面这个脚本啊是什么样子啊？还会给大家继续做这个啊？讲解。好，那咱们到这啊，咱们第十讲的内容就全部结束啊，谢谢大家。