ToB企服应用市场:ToB评测及商务社交产业平台

标题: Prometheus部署以及问题解决 [打印本页]
作者: 天空闲话    时间: 2024-8-21 05:14
标题: Prometheus部署以及问题解决
Prometheus作用：

Prometheus监控（Prometheus Monitoring）是一种开源的体系监控和警报工具。它最初由SoundCloud开发并于2012年发布，并在2016年加入了云原生计算基金会（CNCF）。Prometheus监控旨在网络、存储和查询各种指标数据，以资助用户监督其应用步伐和体系的性能和运行状态。
部署流程：

本文采用Prometheus来监控k8s集群资源状态，并解决alertmanager 9093端口连接拒绝的问题
1.根据k8s集群版本下载对应矩阵的Prometheus版本
  1. # 我的k8s集群版本为1.26.9，所以我下载0.13版本
  3. wget https://mirror.ghproxy.com/https://github.com/prometheus-operator/kube-prometheus/archive/refs/tags/v0.13.0.zip
  6. # 下载完成后解压即可使用
  8. unzip v0.13.0.zip
复制代码


2.进入解压出来的目录，自定义配置告警规则和邮件推送（看需求）
  1. cd kube-prometheus-0.13.0/manifests/
  3. # 该文件配置告警规则
  5. vim prometheus-prometheusRule.yaml
  7. # 该文件配置告警推送
  9. vim alertmanager-secret.yaml
复制代码
3.部署Prometheus监控和删除
  1. kubectl apply --server-side -f manifests/setup -f manifests
  3. # 移除Prometheus
  5. kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup
  8. # 以下为部署完成后正常的资源状态
复制代码
  1. # 如果没有部署ingress则需要更改以下几个svc配置文件，将svc类型改为NodePort才能对外访问
  3. kubectl -n monitoring edit svc alertmanager-main
  5. kubectl -n monitoring edit svc prometheus-k8s
  7. kubectl -n monitoring edit svc grafana
  10. # 删除对应的网络策略，它默认限制了出口和入口流量，即便使用了 NodePort 类型的 svc 或者 ingress 也无法直接访问
  12. kubectl -n monitoring delete networkpolicy --all
复制代码


4.接下来说一下我之前碰到的问题
  1. # 在我部署Prometheus监控服务的时候，我的alertmanager一直无法正常启动，查看状态发现了报错信息
  3. kubectl -n monitoring describe pod alertmanager-main-1
  5. # dial tcp 10.244.135.151:9093 connection refused
复制代码

  1. # 最开始在github官网查看issue时，发现有人遇到了相同的问题，并且也有人给出了解决办法，我试着按照他的方法解决，没成功。他要修改sts里的文件内容，你改了就会发现不管你怎么改，它都不会生效，并且你还删不掉它的sts，该sts是由（crd）自定义资源alertmanager main所控制的，你只有修改这个或者删除这个资源才能停掉sts
  3. kubectl -n monitoring edit alertmanager main
  5. kubectl -n monitoring delete alertmanager main
复制代码
  1. # 起初想着可能是探针超时时间太短了导致它一直无法通过检测，就修改了alertmanager main的文件，更改超时时间为300s，但还是有问题。后面把探针给它注释掉，不让它检测发现还是有问题。最后是直接把容器的端口给注释掉了，让它通过域名查找，发现了真正的问题
  3. kubectl -n monitoring get alertmanager main -o yaml >
  4. dump-modify.yaml
  7. vim dump-modify.yaml
  9. apiVersion: monitoring.coreos.com/v1
  10. kind: Alertmanager
  11. metadata:
  12.   creationTimestamp: "2024-08-19T08:12:24Z"
  13.   generation: 1
  14.   labels:
  15.     app.kubernetes.io/component: alert-router
  16.     app.kubernetes.io/instance: main
  17.     app.kubernetes.io/name: alertmanager
  18.     app.kubernetes.io/part-of: kube-prometheus
  19.     app.kubernetes.io/version: 0.26.0
  20.   name: main
  21.   namespace: monitoring
  22.   resourceVersion: "510527"
  23.   uid: ee407f56-bffa-4191-baa7-e458e7a1b9ff
  24. spec:
  25.   image: quay.io/prometheus/alertmanager:v0.26.0
  26.   nodeSelector:
  27.     kubernetes.io/os: linux
  28.   podMetadata:
  29.     labels:
  30.       app.kubernetes.io/component: alert-router
  31.       app.kubernetes.io/instance: main
  32.       app.kubernetes.io/name: alertmanager
  33.       app.kubernetes.io/part-of: kube-prometheus
  34.       app.kubernetes.io/version: 0.26.0
  35.   portName: web
  36.   replicas: 3
  37.   logLevel: debug
  38.   resources:
  39.     limits:
  40.       cpu: 100m
  41.       memory: 100Mi
  42.     requests:
  43.       cpu: 4m
  44.       memory: 100Mi
  45.   retention: 120h
  46.   securityContext:
  47.     fsGroup: 2000
  48.     runAsNonRoot: true
  49.     runAsUser: 1000
  50.   serviceAccountName: alertmanager-main
  51.   version: 0.26.0
  52.   containers:
  53.   - args:
  54.     - --config.file=/etc/alertmanager/config_out/alertmanager.env.yaml
  55.     - --storage.path=/alertmanager
  56.     - --data.retention=120h
  57.     - --cluster.listen-address=[$(POD_IP)]:9094
  58.     - --web.listen-address=:9093
  59.     - --web.route-prefix=/
  60.     - --cluster.peer=alertmanager-main-0.alertmanager-operated:9094
  61.     - --cluster.peer=alertmanager-main-1.alertmanager-operated:9094
  62.     - --cluster.peer=alertmanager-main-2.alertmanager-operated:9094
  63.     - --cluster.reconnect-timeout=5m
  64.     - --web.config.file=/etc/alertmanager/web_config/web-config.yaml
  65.     env:
  66.     - name: POD_IP
  67.       valueFrom:
  68.         fieldRef:
  69.           apiVersion: v1
  70.           fieldPath: status.podIP
  71.     image: quay.io/prometheus/alertmanager:v0.26.0
  72.     imagePullPolicy: IfNotPresent
  73.     livenessProbe:
  74.       failureThreshold: 10
  75.       httpGet:
  76.         path: /
  77.         port: 443
  78.         scheme: HTTPS
  79.         host: example.com
  80.       periodSeconds: 10
  81.       successThreshold: 1
  82.       timeoutSeconds: 3
  83.     name: alertmanager
  84.     # ports:
  85.     # - containerPort: 9093
  86.     #   name: web
  87.     #   protocol: TCP
  88.     # - containerPort: 9094
  89.     #   name: mesh-tcp
  90.     #   protocol: TCP
  91.     # - containerPort: 9094
  92.     #   name: mesh-udp
  93.     #   protocol: UDP
  94.     readinessProbe:
  95.       failureThreshold: 10
  96.       httpGet:
  97.         path: /
  98.         port: 443
  99.         scheme: HTTPS
  100.         host: example.com
  101.       initialDelaySeconds: 3
  102.       periodSeconds: 5
  103.       successThreshold: 1
  104.       timeoutSeconds: 3
  105.     resources:
  106.       limits:
  107.         cpu: 100m
  108.         memory: 100Mi
  109.       requests:
  110.         cpu: 4m
  111.         memory: 100Mi
  112.     securityContext:
  113.       allowPrivilegeEscalation: false
  114.       capabilities:
  115.         drop:
  116.         - ALL
  117.       readOnlyRootFilesystem: true
  118.     terminationMessagePath: /dev/termination-log
  119.     terminationMessagePolicy: FallbackToLogsOnError
  120.     volumeMounts:
  121.     - mountPath: /etc/alertmanager/config
  122.       name: config-volume
  123.     - mountPath: /etc/alertmanager/config_out
  124.       name: config-out
  125.       readOnly: true
  126.     - mountPath: /etc/alertmanager/certs
  127.       name: tls-assets
  128.       readOnly: true
  129.     - mountPath: /alertmanager
  130.       name: alertmanager-main-db
  131.     - mountPath: /etc/alertmanager/web_config/web-config.yaml
  132.       name: web-config
  133.       readOnly: true
  134.       subPath: web-config.yaml
  135. # status:
  136. #   availableReplicas: 0
  137. #   conditions:
  138. #   - lastTransitionTime: "2024-08-19T08:12:28Z"
  139. #     message: |-
  140. #       pod alertmanager-main-1: containers with incomplete status: [init-config-reloader]
  141. #       pod alertmanager-main-2: containers with incomplete status: [init-config-reloader]
  142. #     observedGeneration: 1
  143. #     reason: NoPodReady
  144. #     status: "False"
  145. #     type: Available
  146. #   - lastTransitionTime: "2024-08-19T08:12:28Z"
  147. #     observedGeneration: 1
  148. #     status: "True"
  149. #     type: Reconciled
  150. #   paused: false
  151. #   replicas: 3
  152. #   unavailableReplicas: 3
  153. #   updatedReplicas: 3
  156. # 删除已有的main资源
  158. kubectl -n monitoring delete alertmanager main
  160. # 重新创建main资源
  162. kubectl -n monitoring apply -f dump-modify.yaml
复制代码
  1. # 查看sts的日志发现报错信息提示说dns解析有问题，于是就去查看k8s组件coredns的信息，发现了问题所在，我的k8s集群采用的高可用部署方案，网络插件为calico，集群地址为10.10.40.100-105，service网段为10.96.0.0/16，pod网段为10.244.0.0/16，而这个coredns网段却是10.88.0.0/16网段的
  3. kubectl -n monitoring logs sts alertmanager
  5. kubectl get pod -A -o wide
复制代码

  1. # 于是查看cni网络组件信息，看到所有节点都有这个cni0的网卡，这个网卡是安装了flannel网络组件才会提供的，问题就出在这里，calico网络组件提供的网卡是calic741a2df36d@if2的网卡名称，所以将原本的coredns删除掉后，网络就恢复正常了
  3. # 此时再将整个Prometheus服务删除重新部署就恢复正常了
  6. ls -l /etc/cni/net.d/
  9. # 两个都要删
  11. kubectl -n kube-system delete pod coredns-5bbd96d687-gtl9r
  14. kubectl -n kube-system get pod -o wide
复制代码


总结
  1. # 不管部署一套什么服务，pod能跑起来，跨节点pod和pod之间能互相访问就不是网络问题，像这种个别pod有问题的，就查看报错，只要发现是端口拒绝之类的优先检查k8s组件coredns的问题，有奇效，当然还是得根据实际情况而论。
  3. # 如果部署集群有问题的时候，给它改成单节点测试也是很好的排错方式。
复制代码
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4