对远程http服务的拨测体验

对你无可奈何2008

已于 2023-05-30 20:27:25 修改

阅读量599

点赞数 2

分类专栏： linux工具 prometheus 监控文章标签：腾讯云运维云计算 kubernetes

于 2023-05-30 20:17:50 首次发布

本文链接：https://blog.csdn.net/saynaihe/article/details/130956316

版权

linux工具同时被 3 个专栏收录

29 篇文章 0 订阅

订阅专栏

prometheus

9 篇文章 0 订阅

订阅专栏

监控

2 篇文章 0 订阅

订阅专栏

背景：

过程是这样的，需要与合作方数据进行交互（肯定是不允许直接连对方数据源的），对方提供了两台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服务，重启服务两种方式：

暴力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 正常使用！

后面准备做的

想搭建一个kubernetes 边缘集群(多地域的)？就跑blackbox。做一下完整的HTTP、HTTPS、DNS、TCP、ICMP 和 gRPC 的测试？
整理一下**PrometheusRule crd .**自定义完善一下role(现在都是默认的)
grafana 图表自定义生成一下自己想要的模板？ prometheus 查询语句研究一下

对你无可奈何2008

关注

2
点赞
踩
4

收藏

觉得还不错? 一键收藏
打赏
0
评论
对远程http服务的拨测体验

过程是这样的，需要与合作方数据进行交互（肯定是不允许直接连对方数据源的），对方提供了两台server，后端同事在server上面作了proxy搭建了桥接的应用（两台server没有公网ip，通过一个超级难用的堡垒机明御进行管理）。两台server挂在在了负载均衡slb上对外提供http服务（环境为阿里云环境）。项目马上要上线了，然后就面临一个问题，如何监控这个桥接程序的健康状态呢？想到了几种方式：1 .云商的拨测服务：比如腾讯云的云拨测（2.还搜到了开源的项目。
复制链接

扫一扫