黑盒白盒测试及监控

一路向东_

已于 2023-11-01 11:11:53 修改

阅读量470

点赞数 1

分类专栏：知识科普 prometheus 文章标签： java docker kubernetes

于 2023-08-16 11:02:55 首次发布

本文链接：https://blog.csdn.net/lxd_max/article/details/132300279

版权

知识科普同时被 2 个专栏收录

13 篇文章 0 订阅

订阅专栏

prometheus

6 篇文章 0 订阅

订阅专栏

概念引入-黑盒白盒测试

一般按阶段有四个测试阶段：单元测试、集成测试、系统测试、确认测试。

白盒测试属于前两者，黑盒测试属于后两者。

单元测试（Unit Testing）

用于验证代码中最小的可测试单元（通常是函数或方法）的行为是否符合预期。单元测试通常由开发人员编写，并在开发过程中频繁运行，以确保代码的正确性和稳定性。
目标是隔离和测试代码的各个部分，以便快速发现和修复潜在的问题。

集成测试（Integration Testing）是单元测试之后进行的一种测试方法
用于验证多个组件或模块在集成后的行为是否正确。集成测试的目标是检查不同组件之间的交互和协作，以确保整个系统的功能和性能符合预期。
帮助发现在组件集成过程中可能出现的问题，如接口不匹配、数据传递错误等。

系统测试（System Testing）
用于验证整个系统的功能、性能和稳定性。系统测试的目标是模拟真实环境下的使用情况，对整个系统进行全面的测试，以确保系统在各种情况下都能正常运行。
可涵盖功能测试、性能测试、安全性测试等多个方面，以确保系统的质量和可靠性。

确认测试（Validation Testing）
用于验证软件是否满足用户的需求和预期。确认测试通常在开发完成后进行，以确保软件的功能和性能符合用户的期望。
关注软件是否满足用户需求、是否符合规范和标准，并且通常由用户或客户参与进行。

从单元级别到整个系统级别，逐步验证软件的正确性、稳定性和符合性。

白盒测试：关注内部结构和实现细节，测试人员具有对被测试软件的内部知识。
用于验证代码的逻辑正确性、路径覆盖和代码覆盖率等。测试人员可以查看代码、执行路径和数据流，以设计和执行测试用例。

黑盒测试：关注软件外部行为和功能，测试人员可对被测试软件的内部结构和实现细节一无所知。
通常在确认测试和系统测试阶段使用，用于验证软件是否符合用户需求、功能是否正常、界面是否友好等。测试人员根据需求和规格说明书设计和执行测试用例，关注输入和输出之间的关系。

黑盒白盒监控

类似黑白盒测试，黑盒监控和白盒监控是两种不同的系统监控方法，分别关注于系统的外部表现和内部实现。

（1）黑盒监控：

从系统的外部进行监控，而不关注系统的内部实现。黑盒监控主要关注系统的功能和性能，例如系统的响应时间、可用性、吞吐量等。黑盒监控通常通过模拟用户行为或者发送请求到系统，然后观察系统的响应来判断系统是否正常运行。

黑盒监控的优点：

不依赖于系统的内部实现，适用于各种类型的系统；
更接近用户的实际体验，可以发现用户在使用过程中可能遇到的问题；
相对来说，黑盒监控的实施成本较低。

黑盒监控的缺点：

无法深入到系统内部，难以定位具体；
对于一些隐藏的、不容易触发的问题，黑盒监控可能无法发现。

（2）白盒监控：

从系统的内部进行监控，关注系统的内部实现和组件。白盒监控通常通过收集系统的内部指标（如CPU使用率、内存使用情况、磁盘空间等）和应用程序的运行指标（如错误日志、事务处理时间等），来判断系统的健康状况。

白盒监控的优点：

能够深入到系统内部，帮助定位具体的问题；
可以发现一些隐藏的、不容易触发的问题；
有助于优化系统性能，提高系统稳定性。

白盒监控的缺点：

依赖于系统的内部实现，可能需要更多的开发和维护成本；
对于一些外部因素导致的问题，白盒监控可能无法发现。

总结：黑盒监控和白盒监控各有优缺点，实际应用中，常会结合使用这两种监控方法，以获得更全面、准确的系统监控结果。黑盒监控帮助我们从用户的角度发现问题，而白盒监控则让我们能够深入系统内部，找到问题的根源。

黑盒白盒监控事例

譬如在K8S中：（以下这段话参考自《Prometheus 中文文档》）

白盒监控层面，需关注：

基础设施层（Node）：为整个集群和应用提供运行时资源，需要通过各节点的kubelet获取节点的基本状态，同时通过在节点上部署Node Exporter获取节点的资源使用情况；
容器基础设施（Container）：为应用提供运行时环境，Kubelet内置了对cAdvisor的支持，用户可以直接通过Kubelet组件获取给节点上容器相关监控指标；
用户应用（Pod）：Pod中会包含一组容器，它们一起工作，并且对外提供一个（或者一组）功能。如果用户部署的应用程序内置了对Prometheus的支持，那么我们还应该采集这些Pod暴露的监控指标；
Kubernetes组件：获取并监控Kubernetes核心组件的运行状态，确保平台自身的稳定运行。

黑盒监控层面，则主要关注：

内部服务负载均衡（Service）：在集群内，通过Service在集群暴露应用功能，集群内应用和应用之间访问时提供内部的负载均衡。通过Balckbox Exporter探测Service的可用性，确保当Service不可用时能够快速得到告警通知；
外部访问入口（Ingress）：通过Ingress提供集群外的访问入口，从而可以使外部客户端能够访问到部署在Kubernetes集群内的服务。因此也需要通过Blackbox Exporter对Ingress的可用性进行探测，确保外部用户能够正常访问集群内的功能；

在 Kubernetes 中，可用 Prometheus 对集群进行白盒监控和黑盒监控。以下是一个简短的示例。（两个 ConfigMap，一个用于配置 Prometheus 的白盒监控，另一个用于配置黑盒监控。白盒监控通过 kubernetes-pods 作业收集 Kubernetes 集群中所有标记为 "prometheus.io/scrape: true" 的 Pod 的指标。黑盒监控则使用 Blackbox Exporter 对名为 "example-service" 的服务进行 HTTP 请求检查。）

白盒监控示例：

# prometheus-config-map.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
data:
  prometheus.yml: |
    scrape_configs:
    - job_name: 'kubernetes-pods'
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

2. 黑盒监控示例：

# blackbox-config-map.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: blackbox-config
data:
  config.yml: |
    modules:
      http_2xx:
        prober: http
        http:
          method: GET

# prometheus-config-map.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
data:
  prometheus.yml: |
    scrape_configs:
    - job_name: 'blackbox'
      metrics_path: /probe
      params:
        module: [http_2xx]
      static_configs:
        - targets:
          - http://example-service.default.svc.cluster.local
      relabel_configs:
        - source_labels: [__address__]
          target_label: __param_target
        - source_labels: [__param_target]
          target_label: instance
        - target_label: __address__
          replacement: blackbox-exporter.default.svc.cluster.local:9115