现状 k8snode节点磁盘容量只有120G，3周-5周就会报一次磁盘告警 主要是容器内产生的数据、系统日志、异常状态的容器、迭代产生的旧镜像 在

现象为：执行 df -Th后，一直卡着 排查df卡在哪里 1 2 3 4 5 6 7 # strace df -Th ...... stat("/var/lib/kubelet/pods/6671b45b-c0ca-45a0-8c2e-aa89c412299e/volumes/kubernetes.io~projected/kube-api-access-cwvq5", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=140, ...}) = 0 stat("/run/containerd/io.containerd.grpc.v1.cri/sandboxes/c52c96add6c9817c6f5918272e4c6702a93a79eaecca0500ed08d97485f2658f/shm", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=40, ...}) = 0 stat("/run/netns/cni-c7a355ae-dd53-922a-281d-87f2c2453a21", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 stat("/run/containerd/io.containerd.runtime.v2.task/k8s.io/c52c96add6c9817c6f5918272e4c6702a93a79eaecca0500ed08d97485f2658f/rootfs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat("/var/lib/kubelet/pods/78f96947-b65c-4a7e-97ea-b563846d821b/volumes/kubernetes.io~nfs/nfs-subdir-external-provisioner-root", 表示在检测/var

排查过程比较恶心，感觉不会出问题的地方出了问题 按常理说，使用kubeadm安装的k8s，k8s组件容器无论怎么重启，怎么断电都不会让k8s集

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 apiVersion:v1kind:Servicemetadata:name:examplenamespace:monitoringlabels:app:examplespec:clusterIP:Noneports:- name:metricsport:9100targetPort:9100protocol:TCP---apiVersion:v1kind:Endpointsmetadata:name:examplenamespace:monitoringlabels:app:examplesubsets:- addresses:- ip:xxx.xxx.xxx.xxxports:- name:metricsport:9100---apiVersion:monitoring.coreos.com/v1kind:ServiceMonitormetadata:name:examplenamespace:monitoringlabels:app:examplespec:selector:matchLabels:app:examplenamespaceSelector:matchNames:- monitoringendpoints:- port:metricsinterval:30spath:/metricsscheme:http 俺不会

背景 根据上篇根据goreplay抓取到api的数据后，发现，在接入多个服务后，无法分辨各api是从哪个服务回放进来的，这时需要添加一个字段进

背景 公司让调研流量回放工具goreplay，实现部分能力，其中包括要统计线上业务还在使用的api(代码陈旧，俗称屎山，无法从代码层面去做)，

修改coreDNS的configmap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 hosts

在之前的文章中，基本完成了opentelemetry可观测中：日志、链路、告警以及周边的类似于存储、拓扑等额外小功能。最重要的监控指标却没有

在之前的文章中完成了alertmanager发日志相关的告警，今天这篇是关于发送Prometheus告警的，在上篇中，日志的告警规则比较简单

在之前的文章中，告警的架构如下 由于我们公司的监控相关内容均是使用的阿里云，包括ECS、RDS、REDIS、MQ，ACK等，所以在目前部署的这