vlambda博客
学习文章列表

Kibana 图形试玩 | 多突出各原因占比

小目标:2021-02-25 开始日拱三年七百篇 #72/720,迭代三疯白帽笔记,入门白帽。


1. 日拱学习

  • 地铁看书:「金庸作品集」6594/26907。

  • 技术学习:ES 核心技术与实战课程 13/100。



2. 日拱技术

日拱鸽了两天。周五去聚餐,想着周末补,结果周末除了踢球遛猫,都在王者峡谷度过了。昨天周一状态不好,又鸽了。


最近几天都在分析一个打点数据,完善了下打点协议和开关控制的设计。


ES 分析层面,在 Kibana 里动手调配了下 Visualize 和 Dashboard,整体上感觉这种可视化的分析还凑活。


有了图形,有些维度分析,就立马直观了。而且这种图形是可以保存的。当前问题分析期间一直受用,后续分析就很高效。


另外这几天也一直在用 ES 做查询分析,但总感觉 ES 查询的结果展现方式太呆板了,没有 MySQL 那种二维表看着方便。去找插件,也没找到这种格式化结果类型的插件。


ES 的 MySQL 基础版,用了下,其实也不太好用。发愁。


这几天了解到 ClickHouse,初步了解了下,这种 OLAP 的库,做了针对性优化,性能特表高,貌似兼容 MySQL 语法也不错。后续我们尝试下 ClickHouse。



3. 日拱唠嗑

跟人一起探讨分析一件事时,最好各自把自己对各种原因所占比例给说明一下。这样会更清晰。


观察到很多同学沟通时,只是各自说出觉得有哪些原因,而没说出各原因的比例。最终虽然对原因种类基本达成共识,但其实各自认为的原因配比,可能是天壤之别。


这也是沟通同步信息时,造成伪和谐的重要原因之一。


所以,我一般会说 A 原因占 30% 左右,B 原因 70% 左右。


后来看剧时也发现了,一些剧里高段位的也会这么沟通事情。不过大佬用的几成几成,例如 A 原因占三成,B 原因占七成。


哈哈,这个叫法更通俗易懂,接地气。