关于prometheus:对远程http服务的拨测体验

62次阅读

共计 6128 个字符，预计需要花费 16 分钟才能阅读完成。

背景：

过程是这样的，须要与合作方数据进行交互（必定是不容许间接连对方数据源的），对方提供了两台 server，后端共事在 server 下面作了 proxy 搭建了桥接的利用（两台 server 没有公网 ip，通过一个超级难用的堡垒机明御进行治理）。两台 server 挂在在了负载平衡 slb 上对外提供 http 服务（环境为阿里云环境）。我的项目马上要上线了，而后就面临一个问题，如何监控这个桥接程序的衰弱状态呢？想到了几种形式：
1 . 云商的拨测服务：比方腾讯云的云拨测（Cloud Automated Testing，CAT）
2. 还搜到了开源的我的项目 Uptime Kuma。
3. 当然了还找到了能够与 prometheus 联合应用的 blackbox\_exporter(Prometheus 社区提供的官网黑盒监控解决方案)
集体的 prometheus 集群是 kube-prometheus, 搭建形式参照：Kubernetes 1.20.5 装置 Prometheus-Oprator。上面次要基于腾讯云的 云拨测 和blackbox\_exporter的形式实现一下对近程 web 服务的拨测：

对近程 http 服务的拨测体验

云拨测 CAT

配置以及体验

关上腾讯云可观测平台：https://console.cloud.tencent.com/monitor/overview2, 点击左侧边栏云拨测服务：

能够看到上方云拨测的利用场景：网络品质 页面性能 文件传输(上传 / 下载) 端口性能 音视频体验。我这里的场景次要应用了端口性能！

当然了点击云拨测的时候还呈现了这 404 的页面，疏忽这该死的体验感！

新建工作参照：新建自定义拨测，我这里应用了新建端口性能工作：

拨测的频率最低这里只能反对到五分钟 ……（试用版，传输类型，挪动端不反对一分钟粒度），拨测点配置试用版只反对 6 个拨测点，我这里顺手点了五个，而后创立了工作：
点击查看剖析

剖析页面初始是空白的须要期待一会能力呈现相干数据

大略期待五分钟左右（拨测粒度工夫）

然而吐槽一下 这里有默认的 502 也会显示失常 100%，因为这里没有做 statuscode 验证，点击工作，进行编辑增加验证形式：

这里简略批改了一下工作设置拨测参数配置，验证形式 验证 statusCode 200

恩这样就能够了，非 200 默认为失败，当然了这里失常应该依据理论需要来设置，我这里就是探测源站存活，没有针对 uri 进行更具体的探测！

接下来是报警：

很恶心连贯性很差 佛系设置了。这里吐槽一下正确率不应该设置默认的小于号吗？

另外这种的云拨测的 能弹性伸缩 …. 伸缩能够带来什么呢？告警模板能够依据本人需要创立：参照：
告警接管

短信报警大略就是这个样子：

对此产品的不满

价格问题

参照：https://cloud.tencent.com/document/product/280/79416。我想创立一个探测工作一个月须要 1299？如果我对一个网站做 网络品质 页面性能 文件传输 (上传 / 下载) 端口性能 音视频体验， 貌似须要1299*6（工作外面上传下载是离开的）？如果我对一个网站的 100 个接口进行拨测呢？那这是多少工作？怎么免费 ….. 对于我集体来说，我宁愿国内搭建七个节点的边缘集群，本人去做探测了 …….

页面的连贯，一致性

眼神好的应该看到下面截图的差异了，可观测平台外面的云拨测与云拨测这里的题目根本分类都有点不统一了？

另外对于拨测增加告警监控，在工作下面设置是不是更好？我做了工作了不能顺畅的创立监控告警，如果在观测平台须要跳转到告警治理这里配置 ….

告警模板

告警模板也很刺激 … 操作这里居然没有批改？要点击告警模板的链接进入能力批改告警策略？

另外集体用 cls 日志服务较多，日志服务中监控告警跟可观测平台没有交融在所有，且 cls 日志中监控告警的告诉渠道组是不是就是实践上告警治理这里的告诉模板呢？居然也没有买通 ….

齐全是孤岛 ……..

Blackbox 简略应用

对于 Blackbox

参照 github:https://github.com/prometheus/blackbox_exporter.The blackbox exporter allows blackbox probing of endpoints over HTTP, HTTPS, DNS, TCP, ICMP and gRPC(blackbox exporter 容许通过 HTTP、HTTPS、DNS、TCP、ICMP 和 gRPC 对端点进行黑盒探测)
这里的 blackbox exporter 曾经默认装置了：Kubernetes 1.20.5 装置 Prometheus-Oprator

 kubectl get pods -n monitoring

blackbox-exporter 为对应 pod 服务！这里演示只进行 简略的 http code 200 检测！

批改配置文件

想查看一下 monitoring 命名空间下的 configmap

kubectl get cm -n monitoring

通过名字能够看出 blackbox-exporter-configuration 为 blackbox-exporter 的配置文件，查看一下此配置文件内容：

kubectl get cm blackbox-exporter-configuration  -n monitoring -o yaml

略微批改了一下下http\_2xx：

kubectl edit cm blackbox-exporter-configuration  -n monitoring


      "http_2xx":
        "http":
          "valid_http_versions": ["HTTP/1.1", "HTTP/2"]
          "valid_status_codes": [200]
          "method": "GET"
          "preferred_ip_protocol": "ip4"
        "prober": "http"

而后重启 BlackBox 服务，删除 pod 根本是：

kubectl delete pods blackbox-exporter-84b6467dcb-9jzbm  -n monitoring

接着在 Prometheus 的配置文件中退出对 BlackBox 的抓取设置，咱们的 prometheus 配置文件是写入 secret 中的，参照：

kubectl get secret  -n monitoring


kubectl get secret additional-configs -n monitoring -o yaml

base64 加密后的数据这是，能够 delete secret 而后用上面的文件 apply 从新生成 secret：
cat prometheus-additional.yaml

- job_name: 'kubernetes-endpoints'
  kubernetes_sd_configs:
  - role: endpoints
  relabel_configs:
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
    action: keep
    regex: true
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
    action: replace
    target_label: __scheme__
    regex: (https?)
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
    action: replace
    target_label: __metrics_path__
    regex: (.+)
  - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
    action: replace
    target_label: __address__
    regex: ([^:]+)(?::\d+)?;(\d+)
    replacement: $1:$2
  - action: labelmap
    regex: __meta_kubernetes_service_label_(.+)
  - source_labels: [__meta_kubernetes_namespace]
    action: replace
    target_label: kubernetes_namespace
  - source_labels: [__meta_kubernetes_service_name]
    action: replace
    target_label: kubernetes_name
  - source_labels: [__meta_kubernetes_pod_name]
    action: replace
    target_label: kubernetes_pod_name
- job_name: 'blackbox'
  metrics_path: /probe
  params:
    module: [http_2xx]
  static_configs:
    - targets:
      - http://baidu.com
      - https://baidu.com
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: 172.22.255.22:9115

当然也能够将配置文件 base64 加密替换 secret 中 prometheus-additional.yaml 的 base64 内容：https://base64.us/

kubectl edit secret additional-configs -n monitoring

而后重启 prometheus 服务，重启服务两种形式：

  1. 暴力 delete pod
curl -X POST "http://xxxxx:9090/-/reload"  # promethues pod ip

我是间接暴力删除了 pod!
期待 prometheus pod running(我是有两个 prometheus 正本，要两个都重启了), 关上 Prometheus 的 Target 页面，就会看到 下面定义的 blackbox 工作了然而都是 down：

kubectl get svc -n monitoring

不求甚解间接将

      replacement: 172.22.255.22:9115

批改为：

      replacement: 172.22.255.22:19115

版本问题了晚期的貌似 9115 然而 9115 前面貌似是 https 的端口了：

这里就应用 19115 端口了，从新 apply prometheus-additional.yaml. 而后 targets 状态就失常了：

prometheus graph 这里，除了百度外我自定义的域名状态居然是 0：

probe_success{job="blackbox"}

but 自定义检测的域名状态为什么是 0 呢？看了一眼 Pod 日志：

 kubectl logs -f blackbox-exporter-84b6467dcb-6rzv8 blackbox-exporter -n monitoring

看了一眼 http2=false？狐疑为开启 http2 造成的？

curl -GET "http://172.22.255.22:19115/probe?module=http_2xx&target=https%3A%2F%2xxx.xxx.com"

测试了一下 baidu 都没有问题, 正文掉了 configmap blackbox-exporter-configuration 中 **”valid\_http\_versions”: [“HTTP/1.1”, “HTTP/2”]**，删除 blackbox-exporter, 期待 running:

目测失常了还不能确定是否是这个起因！

grafana 增加模板：

grafana 控制台左侧边栏 -create -import 13659 load

import

baidu http 的也会 down?
7587 模板倒入：

还有很多相似的模板，能够找一个适合的倒入，后续有工夫的钻研一下 grafana 的图表生成！

prometheus 报警

监控实现了，而后有必要搞一下报警，集体感觉应该去批改 configmap?：

kubectl get cm -n monitoring
kubectl edit cm prometheus-k8s-rulefiles-0 -n monitoring

依照集体教训批改 configmap，but! 批改了 cm 不失效的 …., 参照：
prometheus-k8s-rulefiles-0 无奈批改问题, 创立了一个 PrometheusRule crd 文件:
cat prometheus-blackbox-rule.yaml

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    prometheus: k8s
    role: alert-rules
  name: prometheus-blackbox-rule
  namespace: monitoring
spec:
  groups:
  - name: http_status
    rules:
    - alert: probe_http_status_code
      expr: probe_http_status_code == 200
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "{{$labels.job}}"
        description: "{{$labels.instance}} 域名 http 测试 code 非 200, 请尽快检测"
        value: "{{$value}}"

留神：以上仅供参考 probe\_http\_status\_code == 200 应该替换成 probe\_http\_status\_code != 200 . 下面这样是为了确认收到测试信息！

期待 pod 中 rule 同步过去！能够进入容器查看 /etc/prometheus/rules/prometheus-k8s-rulefiles-0 目录下 role 文件生成！

这里的报警是微信报警形式：

当然了 alertmanager 相干页面也能够查问到报警信息：

微信收到相干报警信息！当然了具体内容能够自定义！，将下面创立的 role 条件批改回去probe\_http\_status\_code != 200 .apply 失常应用！

前面筹备做的

  1. 想搭建一个 kubernetes 边缘集群(多地区的)？就跑 blackbox。做一下残缺的 HTTP、HTTPS、DNS、TCP、ICMP 和 gRPC 的测试？
  2. 整顿一下 **PrometheusRule crd .** 自定义欠缺一下 role(当初都是默认的)
  3. grafana 图表自定义生成一下本人想要的模板？prometheus 查问语句钻研一下

正文完
prometheus
发表至： prometheus
2023-05-30
 0
关于prometheus:prometheusadapter源码分析
关于prometheus:gozero-dockercompose-搭建课件服务七prometheusgrafana服务监控
关于prometheus:prometheus-告警判定与告警发送alertManager
关于prometheus:prometheus-rate与irate分析与源码