OpsThoughts

前言：为什么要自己拉三云账单每个月最后一周，财务扔过来一个问题： 「上个月咱们三朵云加起来花了多少钱？每个账号分别多少？哪些服务是大头？」 我们公司 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 控制台——不替代云厂商控制台、不做预算告警，纯粹是把分...

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

前言：为什么做这个平台在我们用 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...

前言如题， 主要记录一下之前搭建部署的一套日志收集系统。这里采用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...

概述当你使用kuberentes的时候，有没有遇到过Pod在启动后一会就挂掉然后又重新启动这样的恶性循环？你有没有想过kubernetes是如何检测pod是否还存活？虽然容器已经启动，但是kubernetes如何知道容器的进程是否准备好对外提供服务了呢？ 本博文主要记录实践如何配置容器的存活和就绪探针。 liveness probe（存活探针）用于判断容器是否存活，即Pod是否为running状态，如果LivenessProbe探针探测到容器不健康，则kubelet将kill掉容器，并根据容器的重启策略是否重启，如果一个容器不包含LivenessProbe探针，则Kubelet认为容器的LivenessProbe探针的返回值永远成功。 readiness probe（就绪探针）用于判断容器是否启动完成，即容器的Ready是否为True，可以接收请求，如果ReadinessProbe探测失败，则容器的Ready将为False，控制器将此Pod的Endpoint从对应的service的Endpoint列表中移除，从此不再将任何请求调度此Pod上，直到下次探测成功。 每类探针都支持三种...