Meepoljd的博客

在前面的文章持续调度参数在高负载大集群中的影响中有说过，为了防止持续调度锁导致的调度阻塞，我们集群关闭了持续调度开关，同时打开了多容器分配，这意味着，在一次心跳中将不会只分配一个container，而是分配多个containers到一个nodemanager节点，那么可预见的，对应的nm节点就有可能出现热点问题。该问题的发现也是经过不断的摸索发现的，在此记录。

这几年经历了我们大数据的Yarn集群的几次扩容，集群从原先的800多台增加到1300多台到现在的1600多台，在集群规模不断增加的过程中，有遇到一次扩容后调度性能不增反降的情况，经过排查确认到是和持续调度有关。本文记录了该问题的详细排查过程和解决手段。

随着业务量不断扩大，平台逐步发展成HDFS多联邦的架构，这个过程中，作为平台维护人员也会对参数进行不定期的优化以应对逐渐繁重的存算压力。最近一个重点保障业务的计算任务无法满足客户的数据时延要求，客户很生气，然后也是各种投诉，然后项目上的同事就拉着一起查了下问题，最终定位到是一个客户端参数在大体量集群下造成的，记录一下

今天分享一个最近在生产环境排查的空白分区的问题，在无法通过审计程序抓到罪魁祸首的情况下，如何借助抓包工具分析hdfs请求从而找到问题所在

个人电脑崩了，重新做了下环境

最近做一些软件测试和打包，需要频繁的装系统，索性用docker启Centos容器来做，基础镜像做好直接启就好，过程中遇到一个和字符集有关的问题，记录一下，方便遇到同样问题的小伙伴。

Bigtop 从0开始参考了上述的博文自己尝试了编译组件，过程还是遇到很多问题，一一记录，方便后人

之前一直有在用Prometheus的规则引擎配一些告警，感觉内容还是比较多，做一下整理，方便以后用的时候有的查，一些基础的点官方文档有写，这里就不做赘述，主要是记录一些实用技巧和避开一些坑。

最近发生的一个临时故障，情况是一个启了HA的HDFS集群，在2023年9月份因为两台NameNode同时启动产生一些问题，所以当时将一台节点停止，一直没有启动，具体为什么当时有问题这个不太清楚，这次是唯一活动的NameNode节点因为硬件问题突然挂死了，需要把当初一直停止的节点拉起来做保证集群的服务可用，

这个事情的背景是生产环境的数据采集流程时不时会出问题（这个也是不可避免的），目前的处理手段是：所有的数据接口服务器（也就是存放原始数据等待采集的服务器）都部署一模一样的2台，数据也传的一模一样，然后当采集程序采集当前节点的数据异常的时候，由运维人员去改配置手动的切换。这样操作面临的问题不用多说，首先就是时效性的问题，就算数据断了能够及时发出告警，等到运维人员处理完成那也是至少几十分钟后了，所以高可用的实现还是很有必要的。

但知行好事，莫要问前程，2023结束了，24年继续前进吧，以运维的身份

Pyppeteer是对Puppeteer的一个Python封装，常用在爬虫方面，最近使用它做网页巡检报告的截图，记录一下。

记录了一下最近使用Pyecharts做数据可视化的经历

Sentry 是一个开源的错误追踪（error tracking）平台。它主要用于监控和追踪应用程序中的错误、异常和崩溃。Sentry允许开发人员实时地收集和分析错误，并提供了强大的工具来排查和修复问题

问题不是大问题，不是什么代码级别的高深问题，也没有影响任务运行，纯粹因为人员粗心导致，记录一下排查的过程。

简单了解一下Ansible的ad-hoc命令执行ping模块的逻辑

打包Openssh9.3p2的RPM包并使用yum进行生产环境ssh版本升级

使用Gin实现了一个Kerberos环境下的部分组件控制台的web代理功能

大概意思是开发者并没有发现pprof会泄漏啥信息，issue提出者使用的是gosec工具做的静态安全扫描，可能产生很多编译期间的误报，然后社区达成一致的结论是和prometheus社区保持一致，转而使用codeql工具。如果实在要解决就按照本文章进行

最近在写一些运维小工具，比如批量进行ping包的工具，实现不困难，反正就是ping，统计，然后输出，不过我本着自己既是开发者又是使用者的理念，还是不喜欢输出特别难看的工具，就像这样：所以就去瞄了一眼，看看有没有啥适合的库能够把输出整的好看点的，于是找到了一个库，这是一个在命令行输出格式化表格的库，这里记录一下使用这个库进行一些格式化输出的过程。

记录一次生产环境sudo启动进程频繁被Kill且不报错的异常处理过程，如果遇到同样的问题只想要解决方案，直接跳到处理方案部分即可。

大概说下这个问题牵扯出来的背景，一个外场项目，选型用PG存业务数据，然后客户要求保存保留一年的数据，运行到现在服务器5个T的磁盘已经有点扛不住了，使用率接近90%：项目经理无能，跟客户沟通调整存储周期无果，就把压力转给运维运营团队，经过一堆坎坷，最后决定用datax把原pg的数据同步到另一个同配置的pg节点去，然后再把原始数据清理掉，这样等于是变相的进行了存储的冷热分割了。至于同步走的数据客户要的时候怎么办，那自然就是再同步回去了（甲方确实会想出这种刁难你的活路）

书接上会，这次记录一下我基于telegraf进行的hdfs监控组件的开发工作，这其中也包括了开发完成后如何进行打包等事项。我的应用场景是，依赖于telegraf去监控大数据组件，所以第一个开发的就是hdfs的采集插件。

在进行服务器接口机资源梳理的时候，发现奇怪的write和read差异过大的现象，基于此，对这个问题进行了分析，并且最终确定是缓存机制导致了这个现象

以长期使用Prometheus和各种exporter的经验来说，大量的exporter会占用物理机的端口资源，虽说这不是特别严重的问题，但是从安全和优雅程度来说，这不太好，经过多方的考察，感觉使用telegraf的插件进行指标采集是当前解决这个问题的一个比较好的办法，不过之前没进行过telegraf插件的开发，只能参考以下官方的文档整一下，本篇先记录一下telegraf插件开发的一些知识要点；本文仅对telegraf的插件开发做了一个简单介绍，下次会基于自己的插件从开发到部署做一个记录。

弄了个clickhouse连接查询测试的工具，然后把工具放到生产环境一测试，查询都正常，这下开发哥们要继续查他的程序问题了，😃，运维甩锅成功🎉🎉🎉。

使用go必然会使用到协程以及其他的并发操作，初期学习的时候，经常在启动协程时操作变量出现问题，要么就是变量没更新，要么就是各种崩溃，或者vscode报告警之类的，于是浅看了一下Go的内存模型，也了解到Happens Before的概念，这里记录一下

最近在使用Gin+Gorm进行运维集中化后端的开发，期间遇到一些问题，这里进行记录总结，希望也能帮到遇到同样问题的朋友。

本文记录了在HDP3.1.5下，对接Atlas2.2.0的相关操作步骤和注意事项。

最近业务方有Clickhouse的使用需求，在测试环境做了一下集群的部署，在此记录

在生产环境中，无论遇到什么问题，只要和存储相关，不要轻易使用格式化类的命令，网上很多DN启动失败的教程就是直接让你format整个HDFS，然后跟你说生产环境亲测，很坑，最后！不要format！不要format！不要format！

在规模比较大的HDFS集群里，每天最容易出现的问题便是磁盘问题，我们的大集群1700+的DataNode节点，基本上每天都有磁盘损坏（虽然我也不知道是不是和磁盘的质量有关），有时候是磁盘直接读写错误，有时候是磁盘直接报废，无论怎样，这种情况都需要人工介入处理，如果某几天维护人员都很忙，或者碰到那种恶心的客户天天逮着你做他们的事情，这种坏盘的处理就有可能被搁置。

书接上回，前两天刚找到删文件性能比较OK的方式后，测试没啥问题就在生产环境开始操练了， 虽然文件是在持续删除着，但是跑了一段时间以后，执勤同事找我说IO满了，问我是不是做了啥，我上去一看还真是，然后让我先停了：但是文件也不能不删，脚本还是要跑，基于这个问题，看看怎么样控制IO又能够持续做文件清理。虽然通过脚本的方式控制了文件清理对IO的占用，但是这算是没办法的办法，若是能够对Linux的IO调度策略再熟悉些，也许我能找到更好的办法吧，学无止境~

公司现在在31省（不包括港澳台）都有搭建一个Hadoop的集群，目前是通过分开的Ambari管理的，也就是说，运维人员每天会登录到所有Ambari上面去查看，总共有2000多台物理服务器，每天的工作量还是比较大的，基于此建立IAAS层的基础监控体系

在操作系统的日常运维中，我们经常会做文件的创建、删除、修改操作，尤其是删除，无论是定期清理日志文件，还是做完一个操作以后删除临时文件，这都是非常常见的操作，如果你运维的服务器是非常小型的，而且业务量并不多，那也许你永远不会遇到在文件删除时产生的性能问题；但是如果你需要运维临时文件产生巨多或者日志产生巨多或者其他会产生大量文件的服务器，你也许会遇到删除文件时的瓶颈问题，其中最常见的就是；相信很快你就会遇到上述的问题，从这个问题出发，我们聊聊删除文件的这些破事。

这周成都可算是复工了，上周居家办公的时候，配合其他同事线上对各个集群的Ambari元数据库做了迁移工作，因为这个迁移不涉及组件的变更，所以当时做完没有去做所有集群的服务组件启停的测试，只是做了抽查，毕竟30多个集群，大部分的集群只是观察了一会主机的监控和agent上报就没管了。昨天下午，突然接到同事的会议邀请，说是有个集群服务启停不正常，Spark Worker重启都失败了，于是就上去和他们一起看了下，其实问题也是人为疏忽导致的，这里做了一下记录。

使用pg_dump做pg库备份的时候，发现导出的数据量大小远小于统计出来的占用空间大小，进行测试并记录

问题记录问题1：信号没有按预期触发描述编写了信号函数后，并没有如预期一般在必要时候触发，函数如下：@receiver(signals.post_save, sender=Prometheus)def monitor_prometheus_update(instance, **kwargs): # 当发生修改时，更新控制台url web_url = "http://{ip}:{port}/{route}".format(ip=instance.ip, port=i

近日在生产环境我们要进行调度服务迁移，几天的夜间工作中，多次遇到一个业务逻辑导致的问题：在调度重启的过程中，会通过Yarn的资源接口获取正在运行的任务进行Kill操作，这个操作本身是为了防止调度重启期间有计算任务被遗漏，索性从重启那一刻起，所有状态为运行中、失败的任务都会在随后重启完成后进行提交，因此，在Yarn上要把之前提交的任务都干掉，防止重复；基于此，调度服务会在这个步骤卡住非常长的时间，影响业务。...

某年某月某日开始，测试环境的NameNode开始频繁宕机，基本上是每天都会稳定触发此问题；第一次查的时候看到和JN通信发生超时，然后就宕机了，但是当时JN服务又是正常的，遂没太上心，重启完事，结果后面又继续出此问题，所以还是进行排查顺便记录一下...