Prometheus监控部署以及问题解决

Prometheus作用：

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

---

部署流程：

本文采用Prometheus来监控k8s集群资源状态，并解决alertmanager 9093端口连接拒绝的问题

1.根据k8s集群版本下载对应矩阵的Prometheus版本

# 我的k8s集群版本为1.26.9，所以我下载0.13版本

wget https://mirror.ghproxy.com/https://github.com/prometheus-operator/kube-prometheus/archive/refs/tags/v0.13.0.zip


# 下载完成后解压即可使用

unzip v0.13.0.zip

2.进入解压出来的目录，自定义配置告警规则和邮件推送（看需求）

cd kube-prometheus-0.13.0/manifests/

# 该文件配置告警规则

vim prometheus-prometheusRule.yaml

# 该文件配置告警推送

vim alertmanager-secret.yaml

3.部署Prometheus监控和删除

kubectl apply --server-side -f manifests/setup -f manifests

# 移除Prometheus

kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup


# 以下为部署完成后正常的资源状态

# 如果没有部署ingress则需要更改以下几个svc配置文件，将svc类型改为NodePort才能对外访问

kubectl -n monitoring edit svc alertmanager-main

kubectl -n monitoring edit svc prometheus-k8s

kubectl -n monitoring edit svc grafana


# 删除对应的网络策略，它默认限制了出口和入口流量，即便使用了 NodePort 类型的 svc 或者 ingress 也无法直接访问

kubectl -n monitoring delete networkpolicy --all

4.接下来说一下我之前遇到的问题

# 在我部署Prometheus监控服务的时候，我的alertmanager一直无法正常启动，查看状态发现了报错信息

kubectl -n monitoring describe pod alertmanager-main-1

# dial tcp 10.244.135.151:9093 connection refused

# 最开始在github官网查看issue时，发现有人遇到了相同的问题，并且也有人给出了解决办法，我试着按照他的方法解决，没成功。他要修改sts里的文件内容，你改了就会发现不管你怎么改，它都不会生效，并且你还删不掉它的sts，该sts是由（crd）自定义资源alertmanager main所控制的，你只有修改这个或者删除这个资源才能停掉sts

kubectl -n monitoring edit alertmanager main

kubectl -n monitoring delete alertmanager main

# 起初想着可能是探针超时时间太短了导致它一直无法通过检测，就修改了alertmanager main的文件，更改超时时间为300s，但还是有问题。后面把探针给它注释掉，不让它检测发现还是有问题。最后是直接把容器的端口给注释掉了，让它通过域名查找，发现了真正的问题

kubectl -n monitoring get alertmanager main -o yaml > 
dump-modify.yaml


vim dump-modify.yaml

apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
  creationTimestamp: "2024-08-19T08:12:24Z"
  generation: 1
  labels:
    app.kubernetes.io/component: alert-router
    app.kubernetes.io/instance: main
    app.kubernetes.io/name: alertmanager
    app.kubernetes.io/part-of: kube-prometheus
    app.kubernetes.io/version: 0.26.0
  name: main
  namespace: monitoring
  resourceVersion: "510527"
  uid: ee407f56-bffa-4191-baa7-e458e7a1b9ff
spec:
  image: quay.io/prometheus/alertmanager:v0.26.0
  nodeSelector:
    kubernetes.io/os: linux
  podMetadata:
    labels:
      app.kubernetes.io/component: alert-router
      app.kubernetes.io/instance: main
      app.kubernetes.io/name: alertmanager
      app.kubernetes.io/part-of: kube-prometheus
      app.kubernetes.io/version: 0.26.0
  portName: web
  replicas: 3
  logLevel: debug
  resources:
    limits:
      cpu: 100m
      memory: 100Mi
    requests:
      cpu: 4m
      memory: 100Mi
  retention: 120h
  securityContext:
    fsGroup: 2000
    runAsNonRoot: true
    runAsUser: 1000
  serviceAccountName: alertmanager-main
  version: 0.26.0
  containers:
  - args:
    - --config.file=/etc/alertmanager/config_out/alertmanager.env.yaml
    - --storage.path=/alertmanager
    - --data.retention=120h
    - --cluster.listen-address=[$(POD_IP)]:9094
    - --web.listen-address=:9093
    - --web.route-prefix=/
    - --cluster.peer=alertmanager-main-0.alertmanager-operated:9094
    - --cluster.peer=alertmanager-main-1.alertmanager-operated:9094
    - --cluster.peer=alertmanager-main-2.alertmanager-operated:9094
    - --cluster.reconnect-timeout=5m
    - --web.config.file=/etc/alertmanager/web_config/web-config.yaml
    env:
    - name: POD_IP
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: status.podIP
    image: quay.io/prometheus/alertmanager:v0.26.0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 10
      httpGet:
        path: /
        port: 443
        scheme: HTTPS
        host: example.com
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 3
    name: alertmanager
    # ports:
    # - containerPort: 9093
    #   name: web
    #   protocol: TCP
    # - containerPort: 9094
    #   name: mesh-tcp
    #   protocol: TCP
    # - containerPort: 9094
    #   name: mesh-udp
    #   protocol: UDP
    readinessProbe:
      failureThreshold: 10
      httpGet:
        path: /
        port: 443
        scheme: HTTPS
        host: example.com
      initialDelaySeconds: 3
      periodSeconds: 5
      successThreshold: 1
      timeoutSeconds: 3
    resources:
      limits:
        cpu: 100m
        memory: 100Mi
      requests:
        cpu: 4m
        memory: 100Mi
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      readOnlyRootFilesystem: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: FallbackToLogsOnError
    volumeMounts:
    - mountPath: /etc/alertmanager/config
      name: config-volume
    - mountPath: /etc/alertmanager/config_out
      name: config-out
      readOnly: true
    - mountPath: /etc/alertmanager/certs
      name: tls-assets
      readOnly: true
    - mountPath: /alertmanager
      name: alertmanager-main-db
    - mountPath: /etc/alertmanager/web_config/web-config.yaml
      name: web-config
      readOnly: true
      subPath: web-config.yaml
# status:
#   availableReplicas: 0
#   conditions:
#   - lastTransitionTime: "2024-08-19T08:12:28Z"
#     message: |-
#       pod alertmanager-main-1: containers with incomplete status: [init-config-reloader]
#       pod alertmanager-main-2: containers with incomplete status: [init-config-reloader]
#     observedGeneration: 1
#     reason: NoPodReady
#     status: "False"
#     type: Available
#   - lastTransitionTime: "2024-08-19T08:12:28Z"
#     observedGeneration: 1
#     status: "True"
#     type: Reconciled
#   paused: false
#   replicas: 3
#   unavailableReplicas: 3
#   updatedReplicas: 3


# 删除已有的main资源

kubectl -n monitoring delete alertmanager main

# 重新创建main资源

kubectl -n monitoring apply -f dump-modify.yaml

# 查看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网段的

kubectl -n monitoring logs sts alertmanager 

kubectl get pod -A -o wide

# 于是查看cni网络组件信息，看到所有节点都有这个cni0的网卡，这个网卡是安装了flannel网络组件才会提供的，问题就出在这里，calico网络组件提供的网卡是calic741a2df36d@if2的网卡名称，所以将原本的coredns删除掉后，网络就恢复正常了

# 此时再将整个Prometheus服务删除重新部署就恢复正常了


ls -l /etc/cni/net.d/


# 两个都要删

kubectl -n kube-system delete pod coredns-5bbd96d687-gtl9r


kubectl -n kube-system get pod -o wide

总结

# 不管部署一套什么服务，pod能跑起来，跨节点pod和pod之间能互相访问就不是网络问题，像这种个别pod有问题的，就查看报错，只要发现是端口拒绝之类的优先检查k8s组件coredns的问题，有奇效，当然还是得根据实际情况而论。

# 如果部署集群有问题的时候，给它改成单节点测试也是很好的排错方式。