记一次 kibana 二开经历
前言
这只是一次经历分享，大家当故事听听就行，知识密度不会那么高。
不是 kibana、elasticsearch 的技术教程，是一个以技术主题的职场故事。
这个任务给我的印象实在是深，是技能面和人力调度最广的一次。
几年前的事情了，有些细节可能有所偏差，错误之处还请指出。
背景
2021 年，我是工龄 2.5 年的前端开发，公司卖网络安全产品给其他公司客户。彼时已经是第二条产品线了，前端还是做后台管理 web (react+umi)。
基层研发团队完整，高级研发人员有：创始人（老板，架构师级别），技术总监 (公司技术天花板)，部门老大（团队负责人，网络安全专家）。
公司有自己维护的机房，使用 VMware vSphere 虚拟化技术灵活分配服务器系统资源，给整个研发团队使用，由运维同事管理。
至少 3 个项目环境：开发、测试、生产。
那天，PM (产品经理) 找我：我们要把 kibana 的界面，嵌入到我们的后台管理。
我：…（短暂的思考） 为啥？ 意义是什么？ 谁做的技术选型？
PM: 老板决定的，因为我们现在的产品数据读写性能太差了，数据库要换成 elasticsearch；然后老板也不希望前端再自己手动写界面，直接用 kibana 的界面就行了。
内心 os：从要解决的痛点分析，kibana 不一定是一个好的方案，但这是老板的决定，我似乎没办法拿出一个更好的方案。我可以做，但效益不一定有预期那么好。
起步
好的，任务明确，部门前端两个，我自己工龄不如同事高，他做事情比较稳，但我更喜欢研究折腾玩一些新玩意。我愿意做这个任务，跟同事简单讨论，他表示 ok。
开干呗，但我不知道啥是 kibana、elasticsearch，肯定得先查资料，看文档，先简单了解一下。
Kibana 是一个强大的数据分析和可视化工具，它允许用户通过 ES|QL 进行数据查询和分析，支持多种数据源和类型，提供了一系列的特性和工具来加速数据洞察、解决问题、监控系统、进行安全检查以及提升搜索引活性。 --- Elasticsearch 是一个开源的分布式 RESTful 搜索和分析引擎，它不仅是 Elastic Stack 的核心，而且是一个高性能数据存储和向量基数据库，能够满足各种使用场景的需求，包括 AI 搜索和分析。
emm… 要我自己讲，kibana 是运维日志面板工具，可以展示来自 Elasticsearch 的数据；Elasticsearch 是一个快速搜数据的引擎，类似数据库能存存储和查询数据。
叠甲：这是一个简单粗暴的理解，对于陌生的概念工具，这样理解可以快速上手。
预期实现效果：自家产品的后台管理 web，嵌入 kibana 页面，kibana 是连接了 Elasticsearch 实例。
方向也明确，嵌入可以用 html 的 iframe 技术；但 kibana 页面，需要其服务实例，我可以看文档资料，自己搭起来；
如何连接 Elasticsearch 实例，这需要跟后端要一下，但我也最好提供配置文件，需要啥值让后端直接告诉我，这样他们比较省事。
跟 PM，部门老大沟通了一下，这个任务没那么简单，我不好预估时间，而且这些都是新概念，我需要一些时间成本学习。而且个人认为，就算实现了老板的想法，效果不一定有老板预期那么理想。
但老板在公司有完全的决策权，我不会反驳他。还是会按照他的想法，去推动任务。你知道这个风险还有我的意见就行。
PM: 放心去做就行。
能行，开搞。
创建实例
我玩过服务器还有 docker，跑个 kibana 实例并不难。直接在产品的测试环境服务器（虚拟机）执行吧。预估我后面的操作，都是可以撤回且不影响产品的测试环境。
连接 Elasticsearch 实例，需要配置 ELASTICSEARCH_HOSTS 的值，直接带着文档资料， 找后端同事让其提供就行。
就这样顺利有了 kibana 实例，也连接了 Elasticsearch 实例。工作电脑能访问产品的测试环境。
歪头… 我搞这个实例，是需要搞页面，嵌入到自家产品的后台管理 web。
但我现在得到了一个管理平台。如果老板的选型没问题，我应该是可以借助管理平台，配置出页面。
老板既然这么提了，估计是已经看过实际案例，我不需要质疑他，继续往下推动就完事。
配置页面
继续翻文档，了解 kibana 的概念，得出我需要的” 零件”，组装成页面：
- 配置索引模式（Index Pattern）
- 使用 Discover 查看数据
- 创建可视化图表（Visualizations）
- 创建仪表板（Dashboard）
- 构建仪表盘（Dashboard）
所以，可视化图表（Visualizations）就是页面的组成元素，仪表盘（Dashboard）就是页面。
Dashboard 可以用链接的方式分享，这是这次任务需要的 kibana 页面。
我已经掌握配置 kibana 的页面了，现在需要回归需求文档，看看需要我配置出具体如何的 kibana 页面，展示什么数据。
然后用 iframe 引用 dashboard 的链接，嵌入到自家产品的后台管理 web 就行了。
（此处省略一些我了解 Elasticsearch 的细节，还有产品项目的具体的业务 index pattern。 也花费了不少时间，需要找后端了解我页面上的 xx 模块，这里的数据从哪个 index pattern 获取）
配置出页面后，iframe 嵌入也是小问题，没啥好讲的。隐约记得有跨域问题，我改过前端 nginx 的配置，为 kibana 配置了反向代理，当然请求了后端、运维同事的协助。他们在这块比较专业。
location /kibana { proxy_pass http://192.168.1.100:5601; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }
至此开发任务到这里收尾，找 PM 验收，然后上线就是把测试环境的东西，搬到生产环境，就完成上线了。
样式改造
PM（产品经理）：老板说，我们的 kibana 页面太丑了。
我：额… 那要怎么调整。
PM：ui 已经设计好了，你按照这个设计稿调整就行。
我：（打开设计稿链接，沉思了一小会…）
要改外部的 url 的样式，要么在自家产品页面，叠个样式层，直接覆盖；kibana 是开源的，要么在 kibana 的源码上改，然后重新打包。
内心 OS：前者技术成本小，但支持度可能有限，而且 kibana 在 iframe 中，自家产品的样式层，可能无法影响到 kibana 的样式；
后者技术成本大，但有了源码，我可以自由更改，做任何样式调整。
我：改吧。我想办法。
PM: 加油。😉
我更倾向用第一种方案，方便快速。但可能没办法完全还原设计稿。第二种方案，成本高，但样式肯定能还原。
优先用第一种方案，看老板的反馈，如果不行，就只能用第二种方案了。
花了两三天时间，改了自家产品的样式，但效果不理想，PM 反馈老板说还是丑。
二次开发
没办法了，只能去碰 kibana 的源码了。虽然我并不想这么做。还是跟 PM，部门老大讲我的技术方案，风险告知…
PM、部门老大：继续加油。😉
写到这里，才重头戏的开始，从这里开始各卡壳，上一个问题解决了，又一直出现新的问题。
拉 repo 源码，本地跑起来，改代码，打包，部署。
思路如此，开搞！
文档提供了：development-getting-started，拉代码的时候，我才意识到源码体积 2G+，第一次接触过这么大的 repo。
虽然一般项目是直接使用包管理器安装开发依赖，但文档让我用 yarn kbn bootstrap 的命令，简单翻阅了一下，是用 node 执行一些脚本，他们这样做肯定有原因，不去深入了解为什么，就这样跑吧。
kibana 的项目太大了，安装依赖也很久，中间也报过一些依赖版本问题，还有外网资源下载慢的问题，也通过代理解决了。
本地正常运行后，我不着急写代码。先第一时间编译、部署一下。之前吃过没第一时间部署的亏，代码也改了一大堆，没办法快速定位是自己改的代码问题，还是项目的起点时候的问题。
编译的时候，也让我发懵，当时的设备是 i7 的 u，性能并不低，但编译的时候，u 拉到 100% 了，整个设备完全卡死无法操作，等了 10 分钟才行。
看来，我需要一台性能更好的设备。
稍微思考后，vscode 支持 remote ssh 功能。vim 我也比较熟悉。
我可以用 x-shell、vscode 等工具，连接公司的服务器，在服务器直接写代码开发。果断找 CTO 反馈这个问题。
我：(简单说明了情况) 似乎我没办法在本地开发，是否建议在公司的服务器上直接开发？
CTO：行。
我：那我找运维同事帮我提供一个虚拟机系统。
CTO: 可以。
到这里，也就是说… 我二开的这个任务，前面的做的完全都白费了。还得在服务器上重新搞。
小插曲：偶然跟老板搭上话闲聊（毕竟大家工作时间都挺忙的，而且也不一定有心情聊天）
老板说：当时我以为 kibana 是后端搞的，没想到 CTO 说这个是前端的活。
我回了一个微笑：没事，我来搞定就行。
内心 OS：管他什么后端前端的，能解决问题就行。
继续在开发环境的服务器重复之前的步骤：
- 拉 repo 源码
- 本地跑起来
- 编译、部署
能正常部署后，我就可以开始写代码了。没时间、没心情去研究 kibana 的每个模块，简单扫了几眼大致结构和模块。
发现一个有意思的点：这项目同时用了 react、angular, 说实话同一个项目用两个框架，也没啥；如果这两个框架要数据流通交互，可能需要另一个的状态管理吧。
觉得挺有趣的，翻了下 kibana 的 first commit，似乎一开始是用 jsp 的。看来他们的技术栈一直在更新。
由于之前的样式改造，我使用的是叠加样式层，样式代码是写在自家产品上。
我现在需要把样式代码，迁移到 kibana 的源码中。写在哪个模块，模块的路径都得自己找。
只能通过反查样式的来源，找到对应的模块。之前的工作经历，多次对 ui 库进行样式定制化改造。
无论是改原来的样式还是叠加样式，再或者样式调试，这些对我来说都不难。
样式改造完整后，自然需要部署。但我也多次卡在项目的工程化上，每一次编译都跟赌博一样，不安且动荡。
而且服务器环境的编译。又跟本地的编译不一样，本地是 win10, 服务器是 ubuntu。
而且公司的是不允许本地出包的，所有的项目编译都是在 gitlab 的 ci 而且也全部 docker 化，也跟 jenkins 有集成。
我需要把 kibana 的源码，部署到 gitlab 的 ci 或者 jenkins 上，然后编译，出 docker 包。
到这里，陷入了巨大的困境。
小插曲：跟部门老大喝咖啡，我问：业内拉开源项目，二开这种类型的项目，很常见吗？
部门老大：不常见。
我：那二开开源项目呢？
部门老大：这就比较多了。
点了下头，表示理解。
搞不定，卡死，摇人。让 PM、部门老大了解情况，他们帮我摇了 CTO 协助我。
CTO 过了几天，给了我一份文档，完美的二开教程方案────从拉项目、到编译、到部署、到出 docker 包。文档精简但很全面。
值得一提的是，我当时是把源码 clone 到本地，然后再上传到部门的 gitlab 平台。
CTO 直接用了 gitlab 的 mirror 功能，把 kibana 的 repo 镜像到 gitlab 上。
专家级别的操作，果然高级！
有了 CTO 的文档，我任务推动得非常顺利，只是前期我自己摸索的… 就又废弃了。
再次在服务器上，拉取 CTO 创建的 kibana 镜像项目，检出新分支… 迁移代码。
但没想到，又在 CI 的环节出了点问题：CI 超时了，默认都是 10 分钟，跟后端大佬沟通（彼时运维已经离职了，后端大佬兼任运维），帮我调大了 CI 的 timeout 为 1h。
这是何等的巨无霸项目…
最后顺利上线了，测试同事测试页面的配置，页面效果符合需求。UI 设计师也验收了样式，老板也看了，表示满意。
后面也完全上线了，每次发布产品版本，kibana 都会作为产品的一个组件一起发布。我们使用的是增量部署，不变动 kibana，就不需要重复编译。
回顾过程
协作小结
思考
这个任务其实有很多可以优化的地方，我只是一个前端大头兵，当时任务只分配给我一个人。
其实在团队协同上，后端同事也不熟悉 kibana，Elasticsearch，提供给我的帮助也有限。
但其实我们是一家极客公司，让后端同事去学一下，也没那么难，只是都有自己的事情罢了。
所以开发同事都默认不关自己事，所以也在工作配合没那么顺利。
当然我也摇了部门老大，让他分析这种情况怎么处理。
就比如我 docker、nginx 其实并不熟悉，我跟老大沟通：我可以为 kibana 这个任务再去全面细细学一遍，但可能需要一些时间。
老大：别，不需要，部门设定了不同的岗位就是各司其职，我去协调就行。
上帝角度，理想情况：
- 老板：既然想介入技术选型，也行，跟 CTO、PM、部门大佬沟通，做一些技术调研
- 老大：任务总负责人，牵头整个团队推动整个事情，任务划分，kibana
- PM：需求分析，产品设计，功能验收
- CTO：总体技术方案设计，技术支持
- 后端同事：负责 Elasticsearch 层
- 运维同事：负责 docker、nginx 层
- 前端同事：负责 kibana 页面
这个任务当时磕磕绊绊两个月，只有我一个任务执行人，其他人都是我主动沟通，请求协助。
如果按照我理想的情况，应该 1 周内可以完成。
结尾
没啥好总结了的。只是这个任务的曲折，还有团队的协调实在让庞大，让我影响深刻。
最后附带一个朋友的阅读感想：
我觉得每个人的这个成长，就是在有突破的时候，就是在心理上有那个跨越的时候，他总会经历一段沉沉浮浮。而且呢，就像那个蘑菇一样。 蘑菇它其实上在生长出来之前，它是一直在黑暗的地方，在背面就是悄悄的有朝一日呢，这个太阳光洒过来的时候。这个蘑菇一下子就长大了，就有这种这种感觉。 它就像在成长的，就是还没有长出来的蘑菇一样，就是连绵的阴雨，黑暗、潮湿，然后没有任何人去在乎，没有任何人人去注意到。然后自己就在经历着这些阴雨连绵，然后还要就是虫害这些乱七八糟的东西，在长出来之前都是这样子的一个环境。然后突然阳光洒下来的时候，自己已经做足了准备，就可以绽放出来。 其实，你这个阶段分享你前一个阶段的故事，也是一种回顾，也是一种就是对自己的一种犒劳。就是每当有困难的时候，就是告诉自己，我自己是那么那么那么的棒。就是这个样子，我都过来了，就是只有我可以自己去肯定我自己，没有其他人能够去评价我，或者没有其他人能够去审判我，因为。我自己的路是我自己去走的，这其中的那种艰辛和心酸，没有任何人去代替。世界上没有感同身受，因为没有人能够完完整整的经历一遍你自己所经历的东西。 其实这种带有感性的分享，我觉得他既是对自己的一个总结，也是对自己的下一个阶段的开头，是一个等于说一个奠基石，就是给自己。长个精神，让自己有朝一日回过头来看到的时候，觉得哇，自己的曾经是那么的鲜活，那自己的未来和以后也要一直的去鲜活呀，而且在论坛上就是别的人看到了之后。就是其实上是会鼓励到下一代的这个人员的，就是我特别羡慕搞技术，像你这种搞技术的人的原因是就是特别纯粹，就是很纯粹由A到B，包括。就是你有什么就是冲突，你就是很纯粹。 你也很纯粹的去表达出来，然后并且你的这种纯粹就是贯穿了你整个人，就是在做技术上，因为不纯粹的人他干不了技术。 内心弯弯绕绕，太多内心不坚定、不纯粹的人，他搞不了任何的技术。 真的就是这种难度超大，把问题抛给你去解决，但是这个问题它不是你的问题，这个问题它是根本上的问题，但是我觉得超级新奇就是。自己要永远感激自己。