yunson_Liu-CSDN博客

原创第一个PowerShell Update脚本update-sign.ps1

#war包下载url$DownloadUrl="http://192.168.0.117:81/sign_sys/ROOT.war"#war包存放路径$DownPath = "C:\sign_down\ROOT.war"#tomcat服务项目路径$TomcatDirectory='C:\apache-tomcat-8.5.41\webapps\'#jdbc配置文件路径$sign_webapps_conf=$TomcatDirectory + 'ROOT\WEB-INF\classes\.

2021-01-13 20:14:16 602

原创记一次公司服务器遭受CC攻击防御的应急记录

事件背景：公司服务部署框架因redis瓶颈，cc攻击导致资源全部被占用，APP几乎打不开处理过程一、因亚马逊服务就开启了cloudfront服务，结果因cloudfront是国外的CDN服务在国内不兼用，结果打开翻墙才能用，否则不行二、在nginx上配置http { limit_req_zone $binary_remote_addr zone=one:10m rat...

2019-02-18 11:44:48 9812 1

原创 AWS EKS创建EFS存储类

如果角色虽然挂载了，但里面是空的或者权限不足，就会报错。如果角色虽然挂载了，但里面是空的或者权限不足，就会报错。在 IAM 控制台找到 EKS_EFS_CSI_Driver 角色，点击 Trust relationships（信任关系）页签。确认 JSON 中的 Federated 字段里的 ID 与你上面查到的 ID 完全一致。即使角色有权限，如果它“不信任”你的 EKS 集群，AWS 也会拒绝授权。创建efs对已经的pvc的时候要注意指定sc、开启sc的安全组2049端口。

2026-04-25 00:38:37 237

原创记一次logrotate.service处理过程

报错告警内容解决过程1、查看硬盘空间是否充足2、查看logrotate日志3、手动运行以捕获即时错误通过手动运行 logrotate 的调试模式，你可以直接在终端看到详细的错误输出：Bash4、手动释放锁文件如果杀掉进程后依然报错，说明锁文件没有被正常清理。如果有正在运行的进程（且不是你刚刚启动的），尝试正常终止它；如果不行，强制杀掉：#杀掉所有残留的 logrotate 进程5、手动释放锁文件如果杀掉进程后依然报错，说明锁文件没有被正常清理。你可以检查该文件：Bash。

2026-04-15 21:54:28 43

原创 prometheus添加es监控模块

2、编写ServiceMonitor yaml文件并部署。1、helm部署es-exporter。3、编写rules yaml文件。4、导入grafana id。

2026-04-03 16:43:20 92

原创 grafana限制普通view角色用户查看默认的Dashboard

Shared with me” 部分通常不是因为手动分享了某个 Dashboard，而是因为这些 Dashboard 属于 “由插件或 Provisioning（配置文件部署）生成的默认资源。4、我们需要手动将dashboard中Devops的权限中的Editor和view全部去掉。默认的dashboard是所有的用户都可以看得到，如下。3、如果整个是Helm部署，则需要我们更改。下面,而且普通用户也看不到我们的默认配置。去掉如下显示，只留下了Admin的权限。至此我们的默认dashboard都存在。

2025-12-25 16:31:15 361

原创彻底删除逻辑卷lvs

1、停止运行在lvs存储上面的应用，并确认是否还有占用对应存储的线程2、卸载目录路径3、查看现有硬盘及挂载情况4、删除lvs5、删除vg6、删除pv。

2025-12-23 12:02:09 268

原创分别从横向和纵向两种方法扩充lvs空间

空间(将组成lvs的所有的pv都扩充同等的大小5G)1）查看现有pv的大小，并创建一块同等大小的硬盘。4）查看现有lvs挂载的空间大小，并刷新盘符大小。3）将vg所有free的大小都扩展到lv。空间(在新增一块同等大小的硬盘15G)3）将新创建的pv扩展到需要扩展的vg。2）将新增硬盘创建新的pv。ext4格式的刷新命令。

2025-12-23 11:48:18 285

原创 EC2创建逻辑卷lvs

1、创建三块硬盘，并创建物理卷。格式化逻辑卷并查看逻辑卷。

2025-12-23 11:25:35 279

原创单块硬盘创建的逻辑卷扩盘

1、给控制台物理卷增加空间。3、将所有空间扩展到lvs。

2025-12-17 10:36:44 216

原创 kube-prometheus-stack基础上部署domain-exporter监控域名注册过期时间

包括domain注册过期时间以及ssl证书过期时间。

2025-12-16 18:07:43 352

原创 kube-prometheus-stack基础上部署balckbox-exporter监控域名ssl证书过期时间

部署ServiceMonitor。

2025-12-16 17:47:36 115

原创 github实现同代码不同仓库地址数据同步

【代码】github实现同代码不同仓库地址数据同步。

2025-12-09 18:15:53 309

原创 grafana限制folder普通用户访问

1、选择需要限制普通用户访问的folder,在右上角点击编辑permission。我们需要将直接放在dashboard下的资源放到新的folder，然后再给。3、将dashboard下的资源重新整理。2、将Editor和Viewer都叉掉。权限则之前限制的folder都没法操作。需要将garafana的配置文件下的。文件进行更改配置，例如。然后重启grafana。

2025-12-09 14:23:58 374

原创 Elasticsearch 二次cpu负载过高处理

影响：当这些查询作用于高基数（High Cardinality，即唯一值很多）的字段时，Lucene 需要遍历倒排索引中的大量 Term，将其重写为成千上万个简单的匹配查询，这非常消耗 CPU。2）高基数 (High Cardinality)： uri（统一资源标识符）通常是一个高基数字段，意味着它有成千上万甚至上亿个不重复的唯一值（每个 URL 都不一样）。您的集群正在遭受无效的全表扫描攻击。4）数据量大：您的时间范围是 now-0d-365d（过去一年），数据量很大，进一步放大了遍历的开销。

2025-12-04 11:27:34 102

原创 prometheus + elasticsearch-exporter监控elasticsearch集群指标

此时prometheus通过CRD方式读取到我们的rules。6、导入grafana Dashboard json。5、查看prometheus/targets。在控制台上查看我们创建的rules。其中将cpu负载算法改下。

2025-12-03 15:33:21 104

原创 helm部署Elasticsearch集群

将charts库pull到本地自定义安装部署elasticsearch查看部署情况通过阿里云的创建的持续化存储查看的运行状态

2025-12-03 14:52:07 87

原创记一次Elasticsearch cpu负载过高解决全过程

结论：这是典型的“雪崩效应”。根源是 Node C 的磁盘 I/O 几乎完全卡死，导致整个集群的写入队列堵塞，并引发了其他节点的连锁高负载。

2025-12-02 12:40:34 278

原创 helm在kube-prometheus-stack基础上部署loki

自定义 values配置。

2025-12-01 12:07:57 248

原创 git 远程操作

【代码】git 删除远程分支。

2025-11-20 10:37:46 152

原创 prometheus通过aliyun-exporter监控aliyun资源

3、查看/metrics接口数据以及prometheus下targets的情况。创建secret、configmap、aliyun-exporter。1、创建aliyun-exporter。2、创建serviceMonitor。secret yaml文件。创建configmap。4、配置监控告警指标。

2025-11-19 16:59:53 266

原创 prometheus + mysqld_exporter 搜集mysql的metrics数据

查看prometheus的选择器selector。5、查看prometheus的targets列表。的yaml文件,并且配置selector为。3、创建serviceMonitor。4、创建mysql-exporter。2、创建登录数据库的secret。创建serviceMonitor。创建mysql-exporter。编写service包含标签为。6、导入id: 17320。创建secret命令。

2025-11-18 14:01:17 333

原创 prometheus监控kong，搜集metrics来统计不同路由的访问情况

即prometheus通过该标签找到serviceMonitor。,即serviceMonitor通过改标签找到kong。2、编写kong的grafana dashboard。1、创建serviceMonitor。创建serviceMonitor。

2025-11-17 22:30:40 272

原创 grafana+alertmanager配置sendgrid发送邮箱提示

2）配置send_authentication,这个时候要自己定一个发件人，比如monitor@asfewfsd.com。1）自行注册一个sendgrid域名账号，按照操作一步一步到完成。3、获取sendgrid passward的办法。B、要按提示添加域名的cname和txt记录。1、在grafana中添加smtp配置。2、配置alertmanager配置。3）创建一个apikey。

2025-11-17 15:03:17 334

原创解决阿里云ACK采用essd存储类创建的存储申明在重启pod是出现的冲突问题

因为老的插件存在bug，一般1.34以上不会存在这个问题。

2025-11-14 16:47:06 144

原创 helm持久化部署prometheus

Grafana 配置grafana:admin:# --- Grafana 邮件配置 ---smtp:#password: xxxxxxxxxxxxxxxx # 用刚才生成的App Passwordserver:envFromSecret: "grafana-secrets" # ⚠️ 这里必须是字符串，不是列表storageClassName: alicloud-disk-essd # 使用阿里云 ESSD 存储类size: 20Gitype: pvc。

2025-11-13 13:53:47 227

原创 python统计日志IP归属地，分文件存储

【代码】python统计日志IP归属地，分文件存储。

2025-11-10 11:40:07 381

原创 gitlab-ci中cicd+helm实现devops自动化部署到k8s

2、创建成功后可以看到创建客户端的时候需要的gitlab域名和token。3、等gitlab初始化完毕后通过日志获取gitlab初始密码。2、build-deploy.yaml文件。3、在gitlab上面启动Runners。3、手动触发deploy-to-k8s。3、看到创建好的服务端Runners。1、选择项目切换到Runners。1、build-binary日志。2、push-image日志信息。4、命令行验证helm部署情况。2、查看创建好的配置文件内容。2、启动gitlab。4、整体创建过程如下。

2025-10-31 12:13:40 455

原创手动配置ingress讲服务端获取客户端的真实用户IP

这样 kube-proxy 会直接把请求转发到本地的 Pod，不会再做 SNAT，从而保留客户端 IP。2、更改ingress-controller的。1、更改configmap。3、重启ingress即可。

2025-10-28 14:18:57 105

原创 helm一键安装etcd集群

2、加载helm仓库。

2025-10-21 16:09:25 321

原创阿里云将redis标准主从架构变更为集群架构

最后我们可以看到集群的各个分片，这个过程可能在实例显示正常运行的时候还要再等一会。2、将原来的标准版该选择集群版，根据自己需求选择分片数以及实例规格。1、点击实例id进入实例–>点击右上角规格调整的规格升配。

2025-10-13 14:24:55 224

原创 Aliyun 采用DTS将Redis数据迁移到新的实例的过程

8、最后就是购买，如果不是长期同步则可以只够买按量，不用的时候就要删除，如果要长期同步则建议包年包月购买。在目标数据库中将100.104.233.162添加到白名单中。1、创建新实例，根据自己的需求创建新的实例。5、选择要迁移和同步的库，这边全选。2、添加自行原数据库和目的数据库。其中的警告内容如下，可以忽略。2、创建DTS数据同步实例。至此我们的数据迁移完成了。然后点击下一步高级配置。6、一律默认选项，不改。7、数据校验–全量校验。1、选择创建数据同步。4、出现连接不通报错。

2025-10-13 14:12:34 424

原创 Redis CPU以及带宽瓶颈分析

场景是否建议升级“流量”监控显示 output 带宽接近上限✅ 强烈建议升级CPU 单核打满（>90%）且 Redis 5.0⚠️ 升级流量帮助有限，建议升级版本Pub/Sub 消息非常多🚫 不建议仅靠流量解决，应优化架构内存充裕但响应变慢✅ 升级 CPU/流量均有助益。

2025-10-11 20:45:01 930

原创 Redis CPU高负载案例分析

AOF 缓冲区占用较大（mem_aof_buffer ~386MB），说明存在一定写入压力。Pub/Sub 占比高（output kbps大），I/O 压力集中在推送；ERR: 1,208,188 次（一般是命令格式错误或 key 不存在操作）建议对订阅连接做空闲超时清理（ cmd=subscribe 连接）。订阅连接数量偏多，需关注是否有大量空闲订阅（可能浪费资源）；1.2M 的 ERR 有点偏高（可能客户端脚本逻辑问题）。说明性能瓶颈更可能在 CPU 或网络带宽，而不是内存。

2025-10-11 20:33:05 1051