OpsThoughts

前言：为什么自托管拨测boce.com 是国内老牌的商业拨测平台，HTTP / DNS / PING / TCPing / 劫持 / 被墙检测样样齐全，按波点计费。 问题在于： 平台 UI 是公版，告警格式没法定制，群里来一长串原始 JSON，10 条 URL 就是 6000+ 字符，眼睛都看花了 波点余额监控没有，经常到第三天发现「余额不足，已停止拨测」，业务告警全断 多项目隔离没有，一个公司一套配置，谁都能改别人的 URL 数据不能导出，历史曲线只能用它的图表看，没法和我们自己的 Grafana 拼起来 告警通道单一，只有邮件 / 钉钉，没有 TG / 飞书 于是就有了 boce-site —— 把 boce.com 的 API 包成自托管的小工具： Web 控制台，UI 自己写 Prometheus 抓取端点，直接并入现有监控体系 周期任务调度，APScheduler 跑 14 种检测类型 告警通道分发，TG + 飞书 webhook，自己定义紧凑格式 全部跑在一个 Docker 容器里，SQLite 存数据，没有 MySQL、没有 Redis、没有 worker ...

前言：为什么要自己拉三云账单每个月最后一周，财务扔过来一个问题： 「上个月咱们三朵云加起来花了多少钱？每个账号分别多少？哪些服务是大头？」 我们公司 AWS / 阿里云 / 腾讯云全在用，AWS 还有 3 个子账号、阿里云 2 个主账号、腾讯云 2 个国际站账号。光是把这些控制台挨个点开看本月合计，至少 15 分钟，而且： 看不到”过去 6 个月 EC2 在 AWS 的趋势”，控制台只有本月 Excel 想统一格式发给财务，但三家 API 返回结构完全不一样 半夜 12 点想看下今天累计账单，控制台没有”昨日累计”，得第二天才看得到 退款、调账这种负数行经常藏在明细里，月度概览看不到 于是就有了 multi-cloud-billing —— 一个本地跑的「三云账单聚合」小工具： AWS / 阿里云 / 腾讯云 各家账单拉下来，落到本地 SQLite 带图表的 Web 仪表盘 + Excel 文件下载 账号管理 UI（AK/SK Fernet 加密、添加账号自动拉 6 个月历史） 定位很明确：自托管的 FinOps 控制台——不替代云厂商控制台、不做预算告警，纯粹是把分...

前言：为什么做这个平台在我们用 Prometheus + Consul 做服务发现的监控体系里，每接一台新机器、新数据库、新网站，标准的”人工 SOP”是这样的： SSH 到目标机器 部署对应的 node_exporter / mysqld_exporter / redis_exporter … 手写 JSON 调 Consul API：PUT /v1/agent/service/register 填各种字段：service_id、tags、meta、健康检查 URL 错了再 deregister 重新来 一个项目几十台机器，每个都要敲一遍 Consul API；批量？得写脚本；共享？得传 API Token；审计？谁改了什么？查不到。 一个晚上批量起 50 台新服，靠人一个个注册，是真的会出事的。 Consul Register Manager 就是为了把这套流程做成一个 Web 平台，让注册变成”贴文本框 + 点按钮”，并且所有写操作可追溯。 系统在监控体系中的位置12345678910111213141516┌─────────────────────┐│ Pr...

概述在单负载均衡器（LB）绑定多端口的后端架构中，Cloudflare 的 Origin Rules（源站规则） 提供了灵活的 HTTP 请求重写能力。通过在 Cloudflare 边缘节点匹配特定请求条件（如主机名），动态修改发往源站的目标连接端口，实现了流量的精准分发与统一安全暴露。 工作原理 客户端请求：用户使用标准的 HTTP/HTTPS 端口（如 80 或 443）访问目标域名。 边缘节点匹配：流量到达 Cloudflare 边缘节点后，匹配预设的 Origin Rules 条件（例如 主机名 等于 example.com）。 端口动态重写：边缘节点将请求的目标端口动态更改为后端负载均衡器实际监听的自定义端口（例如 1031）。 回源与响应：Cloudflare 节点直接连接后端负载均衡器的指定端口，并将回源响应返回给客户端。 核心优势 隐藏真实端口与服务结构外部客户端始终只需访问标准的 80/443 端口，后端真实服务端口（如 1031、8080 等）完全隐藏在 Cloudflare 代理之后，显著降低被直接扫描和攻击的风险。 突破标准 CDN 代理限制Clou...

前言如题， 主要记录一下之前搭建部署的一套日志收集系统。这里采用docker-compose的方式运行，还是那句话主要是思路。 方式: 一台服务器上面利用docker-compose运行三个ES节点跟Kibana,并启用SSL,再使用Filebeat来收集服务器上面的应用日志到ES， 最后Kibana来做展示 配置目录创建1234mkdir -p /data/{es/node-1/{data,certs,logs,config},plugins}mkdir -p /data/{es/node-2/{data,certs,logs,config},plugins}mkdir -p /data/{es/node-3/{data,certs,logs,config},plugins}mkdir -p /data/kibana/{certs,config} -p 部署文件12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596...

背景线上API服务出现了5xx的请求错误, 未能在第一时间发现导致用户主动向团队报告接口有异常， 由于API的接口比较多，也只是监控了部分，事后通过日志才发现的确用户侧在对某个接口访问时，频繁出现5xx告警，我这边也没有收到什么通知，目前先暂且不说出现5xx是什么造成的，而是在API接口响应状态的监控方面没有做到很到位， 所以需要对Nginx日志中的状态为5xx的请求监控告警，以便能快速响应，解决问题。 ElastAlert2ElastAlert 2是一个简单的框架，用于对来自 Elasticsearch 和 OpenSearch 的数据的异常、尖峰或其他感兴趣的模式发出警报。 官方文档：https://elastalert2.readthedocs.io/en/latest/ Github: https://github.com/jertel/elastalert2 配置部署当然还是选择容器化方式运行，官方也提供得有镜像： 1docker pull docker pull jertel/elastalert2 配置文件配置可参考 https://github.com/jert...

在日常巡检过程当中，不需要登录服务器去查看，通过调用k8s api的方式获取所有pod的状态 然后在每天9点执行本脚本即可。 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101from kubernetes import client, configfrom kubernetes.client.rest import ApiExceptionfrom datetime import datetime, timezoneimport requestsimport jsonimport sysimport pytz# 加载 Kubernetes 配置#默认会在master节点去读取 ~/.kube/config 文件config.load_kube_...

问题原因在k8s中使用nfs作为持久存储方式，根据不同环境对应不同名称空间的pod使用的存储类/存储卷 相对应，发现mysql8.0.23 在启动时挂载NFS会卡住的情况： 问题复现这里在某台宿主机上面创建了一个本地目录，然后按照默认方式： 1mount -t nfs 10.10.10.142:/data/bbb /tmp/cc 将nfs挂载到本地，然后映射到容器中去，所以这里跟k8s环境没多大联系，主要是nfs挂载问题： 初始化一直卡着，而且在挂载目录发现只有这个文件： 问题排查检查一下nfs挂载的参数情况： 12345mount -v | grep nfs10.10.10.137:/data/nfs_share_137 on /tmp/fans type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.10.137,mountvers=3,mo=udp,local_...

一、背景因公司历史遗留原因有个别环境暂时没有使用kubernets, 现在需要将这批服务器的监控系统从zabbix替换到Prometheus, 于是乎这边有个问题就是需要将所有服务器上面的所有的exporter mertics（即 target）地址写到Prometheus配置文件中，这样一来，维护一个文件，似乎还算可以，但是这里我采用Prometheus+Consul的方式来管理服务器上的所有exporter， 那么这样做的好处是我们能更清晰的通过Consul来管理上面的每个exporter url , 以及通过consul自带的自定义元数据，再结合Promethues无疑是个很灵活的方式。 二、架构 promtheus配置数据源为consu_sd_configs 地址指向一个consul客户端地址； 通过脚本调用consulapi的方式将宿主机上面的cadvisor-exporter,node-exporter metrics的地址注册到consul中； promtheus 检测到了新增服务后，会通过这个http://xxxxxx:xxx/metrics url 抓取采集数...

一、搭建架构● 3个或3个以上Nacos节点才能构成集群；● Nacos Nginx Proxy用于代理转发； 二、准备工作Nacos2.0版本相比1.X新增了gRPC的通信方式，因此需要增加2个端口。新增端口是在配置的主端口(server.port)基础上，进行一定偏移量自动生成。 端口 与主端口的偏移量 描述 8848 0 Nacos程序主配置端口 9848 +1000 客户端gRPC请求服务端端口，用于客户端向服务端发起连接和请求 9849 +1001 服务端gRPC请求服务端端口，用于服务间同步等 7848 -1000 Nacos 集群通信端口，用于Nacos 集群间进行选举，检测等 使用VIP/nginx请求时，需要配置成TCP转发，不能配置http2转发，否则连接会被nginx断开 按照上述官方的端口分配要求 ，此处部署的使用三台服务器上面创建的Nacos集群端口分配如下： 节点 IP 端口（所需暴露） 备注 版本 当前线下环境部署文件路径 Nacos_1 192168.18.73 宿主机：8858，9858，9859，785...

一、为什么要进行巡检 当前平台架构复杂，中间件繁多，组件之间耦合度高，微服务还未达到故障自愈水平，所以需要通过告警或巡检等手段发现问题来保障平台持续稳定运行。 当前有客户对平台及上层应用使用频率低，例如三四天登录查看一次数据，但是设备是正常运转的，一旦平台出现问题，刚好客户发现问题，运维 才去解决就为时已晚。 定期巡检方案是模拟人工登录各业务页面，而非接口调用，更能真实地发现问题，并通过截图真实保留平台运行状态。 Prometheus平台的监控报警功能还未覆盖到整个业务系统，部分问题还未能实时监控到，导致平台出现异常后而无法感知。 当前并不能保证客户环境的Prometheus平台本身不存在问题，针对这种不确定性，定期巡检是一个保障平台稳定性的方案，实现平台双保障。 部分客户环境不能够连接外网，Prometheus的监控告警信息无法同步到微信、飞书等，但可以通过定期巡检方案来保障平台稳定运行。 由于以上原因，为了保证SLA，必须进行定期巡检。 二、巡检检查项2.1 服务器基础信息 cpu 利用率 磁盘利用率 内存利用率 服务器时间同步 日常数据备份文件检查 2.2 ...

序 APSCheduler 简介在平常的工作中有些工作都需要定时任务来推动，例如项目中有一个定时刷新排行榜的程序脚本、定时爬出网站的URL程序、定时检测钓鱼网站的程序等等，都涉及到了关于定时任务的问题；虽然这些定时任务在服务器上面都能通过crontab来做；其次想到的是利用time模块的time.sleep()方法使程序休眠来达到定时任务的目的，虽然前两者也可以，但是总觉得不是那么的专业，😁所以就找到了python的定时任务模块APScheduler; APScheduler基于Quartz的一个Python定时任务框架，实现了Quartz的所有功能，使用起来十分方便。提供了基于日期、固定时间间隔以及crontab类型的任务，并且可以持久化任务。基于这些功能，我们可以很方便的实现一个python定时任务系统。 同时APScheduler还提供了Flask的扩展Flask-Apscheduler, 那正好就可以拿来做一个集成定时任务平台; APScheduler有四个组成部分 触发器(trigger)包含调度逻辑，每一个作业有它自己的触发器，用于决定接下来哪一个作业会运行。...

基于harbor搭建企业docker镜像仓库背景docker中要使用镜像，一般会从本地、docker Hup公共仓库和其它第三方公共仓库中下载镜像，一般出于安全和外网(墙)资源下载速率的原因考虑企业级上不会轻易使用。那么有没有一种办法可以存储自己的镜像又有安全认证的仓库呢? —-> 企业级环境中基于Harbor搭建自己的安全认证仓库。 Harbor是VMware公司最近开源的企业级Docker Registry项目, 其目标是帮助用户迅速搭建一个企业级的Docker registry服务。 安装Harborharbor需要安装docker和docker-compose才能使用，安装docker步骤省略， 安装docker-domposedocker-dompose安装步骤如下： 下载最新版的docker-compose文件 1$ curl -L https://github.com/docker/compose/releases/download/1.23.2/docker-compose-$(uname -s)-$(uname -m) -o /usr/l...

my experience with cka exam preparation What is CKA?CKA全称就是Certified Kubernetes Adminsitrator，是由CNCF(Cloud Native Computing Foundation 云原生计算基金会)提供的认证项目，考试费用为300美金，必须要双币行用卡，考试过程为3个小时。我办理的是招行的MasterCard，给了20块加急；缴考试费到考完整个流程方面还是非常简单的。  如果考试第一次考试不通过，账号内会生成一个`Free Retake`，在一年之内有一次免费重考的机会。 Why should obtain certification很有幸在春节前(2019/01/06)完成了2018下半年既定的目标，将CKA顺利拿下。很巧合的是在6年前也就是2013年1月5号我通过了RHCE认证考试(虽然我的RHCE认证早已过期，但是我更想说的是: 万变不离其宗 ) 当K8S已经进入到各行各业，那么一套公正权威的管理员测评体系必然就...

一、概述本文主要记录一下搭建一个kubelet搭建到加入集群到手动、自动(证书轮换的)证书认证过程, 那么我的环境是用的v1.12.4版本，有一台master,除了master上面的一些组件已经搭建完毕，主要重点是在kubelet上面，所以现在就是master已经工作正常的情况下，加入新的kubelet(worker节点)需要做一些什么样的操作。然后需要实现的是: 通过bootstrap token以及boostrap.kubeconfig来引导worker节点申请证书 如果第一步申请发出去之后，在手动在master端进行手动批准证书申请，然后发放kubelet证书 实现kubelet证书的自动批准 实现kubelet证书的自动轮换操作 简单理一下TLS Bootstrapping的一个引导过程 master端创建API Server和Kubelet Client通信凭证即生成 apiserver.pem/apiserver-key.pem/apiserver.csr; 在集群内创建特定的 Bootstrap Token Secret，该 Secret 将替代以前的 tok...

概述etcd是CoreOS团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法，etcd基于Go语言实现。 etcd作为服务发现系统，有以下的特点： 简单：安装配置简单，而且提供了HTTP API进行交互，使用也很简单安全：支持SSL证书验证快速：根据官方提供的benchmark数据，单实例支持每秒2k+读操作可靠：采用raft算法，实现分布式系统数据的可用性和一致性 etcd项目地址：https://github.com/coreos/etcd/ kubernetes中的使用目前etcd是作为kubernetes集群当中的存储后端 在kuernetes中etcd涉及到的安全相关的主要有: etcd支持备份恢复机制，防止数据被误删导致数据丢失 用户的敏感信息建议放在secret类型的资源中，该类型资源是加密存储在etcd中的 etcd支持https, kube-apiserver访问etcd使用https协议 在kubernetes中的配置: Client -> Server1...

概述今儿是冬至，尽管如此，学习的脚步还是不能停下，今天学习实践一下kubernetes中的静态pod是什么？ 我们知道在前面Pod的声明周期管理都是通过像DaemonSet、StatefulSet、Deployment这种方式创建管理的，而官方文档介绍了一种特殊的pod就是静态Pod， 什么是静态Pod静态Pod是由kubelet进行管理，仅存在于特定Node上的Pod。它们不能通过API Server进行管理，无法与ReplicationController、Deployment或DaemonSet进行关联，并且kubelet也无法对其健康检查。 静态Pod的创建:静态pod可以通过两种方式创建：使用配置文件或HTTP。 通过配置文件创建配置文件只是特定目录中json或yaml格式的标准pod定义。他通过在kubelet守护进程中添加配置参数--pod-manifest-path=<the directory> 来运行静态Pod，kubelet经常会它定期扫描目录； 例如，如何将一个简单web服务作为静态pod启动 选择运行静态pod的节点服务器不一定是node节点...

概述Secret对象与ConfigMap对象类似，但它主要用于存储以下敏感信息，例如密码，OAuth token和SSH key等等。将这些信息存储在secret中，和直接存储在Pod的定义中，或Docker镜像定义中相比，更加安全和灵活。 kuberntes中内置了三种secret类型: Opaque：使用base64编码存储信息，可以通过base64 –decode解码获得原始数据，因此安全性弱。 kubernetes.io/dockerconfigjson：用于存储docker registry的认证信息。 kubernetes.io/service-account-token：用于被 serviceaccount 引用。serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。Pod 如果使用了 serviceaccount，对应的 secret 会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中。(前面博文记录过实践后的食用方法) Opaque SecretOpaque...