输油管道问题测试数据_建立测试时要考虑的数据管道

输油管道问题测试数据

如果您已经建立了批处理数据管道，但不知道检查其运行状况或测试更改以进行潜在回归的最佳方法，那么本文适合您。

监视和测试批处理数据管道需要与监视和测试Web服务不同的方法。在Python中构建健壮的数据管道流程是一回事，但要找到工具并建立框架以提供对数据系统健康的信心，则是完全不同的挑战。为了真正地迭代和开发代码库，开发人员必须能够在开发过程中自信地进行测试并监视生产系统。本文提供了一些监视和配置数据管道警报的解决方案。

监视数据管道与Web服务

那么，监视数据管道与监视Web服务有何不同？监视任何系统的大多数核心原则都可以在数据管道和Web服务之间直接转移。 监视的方式开始有所不同，因为数据管道本质上具有不同的运行状况指示。下表概述了常见的运行状况指标，并比较了与批处理数据服务相比对Web服务的那些指标的监视。

	网络服务	数据管道
Health Check	拥有某种健康检查端点，并检查ping `/healthcheck`是否获得200状态码。	检查作业是否成功。
Integration Test	`POST`到一个端点，并期望从相应的`GET`端点获取正确的数据。	验证一些伪造数据是否已通过数据转换。（如果没有简单的方法将伪造的数据馈送到数据管道中，则很难复制。）
Latency	测量API的平均响应时间。	测量完成数据管道所需的时间。

监控工具

StatsD和Prometheus等开源工具通常用于收集指标和配置警报。除了不断收集指标之外，集成测试还可以在诸如Nagios之类的工具上运行，该工具主要检查成功的退出代码，并且我与其他使用Jenkins定期运行集成测试以检查构建仍通过的团队合作。可以推断所有这些工具以支持数据服务和Web服务。

时间序列数据

核心功能是：“一个多维数据模型，其中包含通过度量标准名称和键/值对标识的时间序列数据。”

普罗米修斯

我在Button的团队在我们的监视堆栈中充分利用了Prometheus，因此本博客中的示例将特定于Prometheus，但是可以将常规概念外推到具有时间序列指标的任何监视工具。用自己的话说：

“ Prometheus非常适合于记录任何纯数字时间序列。它既适合以机器为中心的监视，也适合监视高度动态的面向服务的体系结构。在微服务的世界中，它对多维数据收集和查询的支持尤其重要。强度。”

Prometheus服务器通过HTTP抓取数据，这意味着您的服务需要向Prometheus服务器公开一个HTTP端点才能启用数据收集。通过中间推送网关还支持推送时间序列数据。

时间序列指标

从时间序列指标的角度来看，测量Web服务和数据管道之间的差异是实时系统和批处理系统之间的差异。实时系统在处于“实时”状态并为流量提供服务或处理流量时始终会发出健康的信号，而批处理系统可能更零星，并且“停机时间”在两者中可能并不相同。如果批处理系统报告它“不可访问”，则不一定表示它无法运行。这可能意味着它没有任何数据要处理。

网页服务

您可以通过检查连续的成功状态代码来评估Web服务的运行状况，并通过寻找相对较短的响应时间来监视延迟。

要在Prometheus中执行此操作，您需要在代码中创建并抓取指标。例如，您可能想了解响应时间和总请求指标：

import prometheus_client

response_time = prometheus_client. Histogram ( 'http_response_time_seconds' , 'Histogram of requests processing time.' , [ 'method' , 'path' ] ) requests_total = prometheus_client. Counter ( 'http_requests_total' , 'Total count of requests' , [ 'method' , 'path' , 'code' ] )

计数器发送发出的总请求，因为计数器是Prometheus中的累积指标，随着发出更多请求而增加。在此示例中，Prometheus中的数据将显示对在标签中配置的url路径的请求的所有历史计数，以及在code标签中的相应响应状态代码。

直方图将请求持续时间放入存储桶中，并在特定时间段内基于响应时间（第90个百分位数）发出警报。

在API的中间件中，您希望在收到请求时记录这些指标。

def record_status_code ( self , request , status_code ) :

        if hasattr ( request , '_start_time' ) :

        requests_total. labels (

        request. method ,

        resolve ( request. path_info ) . url_name ,

        str ( status_code )

        ) . inc ( )

def record_time ( self , request ) : if hasattr ( request , '_start_time' ) : seconds = ( time . time ( ) - request._start_time ) response_time. labels ( request. method , resolve ( request. path_info ) . url_name , ) . observe ( seconds )

为了评估（并接收有关）系统运行状况的警报，您需要了解在特定时期内带有成功状态标签的请求计数器的变化率是否为0，这表示没有任何请求在此期间状态码为200。

rate ( http_requests_total { code = "200" } [ 1m ] ) == 0

或者，您也可以在非200码的变化率不为0时发出警报。

rate ( http_requests_total { code != "200" } [ 1m ] ) != 0

您还可以根据API请求的延迟触发警报。以下Prometheus查询将计算前一分钟的请求持续时间的90％。

histogram_quantile ( 0.90 , rate ( http_response_time_seconds [ 1m ] ) )

如果结果超过一定阈值，则可能会发出警报。

`数据管道`

数据流水线使用的度量标准略有不同。与其测量响应时间和响应状态代码，不如测量数据管道何时运行以及花费了多长时间或处理了多少数据。为此，我们将使用量规来测量上次批处理作业成功的时间。我们还可以使用摘要来衡量成功完成数据管道所需的时间-这等效于批处理数据管道的延迟。

发送指标：

job_last_success_unixtime = prometheus_client. Gauge ( 'job_last_success_unixtime' ,

        'Time of last successful batch job' )

        job_duration_seconds = prometheus_client. Summary ( 'job_duration_seconds' ,

        'Duration of batch job run in seconds' )

在流水线的末尾按以下方式计算指标：

with job_duration_seconds. time ( ) :

        run_pipeline ( )

        time_now = int ( time . time ( ) )

        job_last_success_unixtime. set ( time_now )

提醒批处理作业运行状况的明确方法是，检查上一次作业成功的时间是否在预期的时间间隔内。例如，如果您希望作业每小时运行五分钟，那么如果上一次成功完成的时间早于三小时前，则可能表明该系统运行不正常。 Prometheus中的警报如下所示：

Alert IF time ( ) - job_last_success_unixtime > ( 3 * 60 * 60 )

        for 5min

请注意，此方法仅适用于长时间运行的批处理作业，这些作业暴露了要刮除的端口。对于短暂的作业（例如定期的cron作业），Prometheus具有一个推送网关，用于将指标推送到Prometheus服务器，因为它们无法被刮取。

`回归测试和统计`

除了评估系统的运行状况之外，最好让数据管道输出一些有关其结果的核心统计信息。假设您的基本数据管道仅运行了csv转储，并生成了数值的总计数，平均值和标准偏差。您还应该能够输出诸如数据验证检查之类的信息，例如，由于无效数据而被拒绝的记录数，两个标准差以外的数据点，读取的记录总数，已处理的记录总数等。

这些基本统计信息还可用于回归测试中，以通过针对相同的基准数据运行不同的代码库来验证代码更改并未彻底改变系统。

设置阈值：建立基准

就像在Web服务中一样，所谓的“健康流量模式”可能会根据应用程序而有所不同，健康数据管道的概念可能会根据管道的目的而有所不同。您可能需要对特定管道的细微差别有一点经验，才能识别任何给定的信号是警报信号还是正常信号。

要了解更多信息，请在PyCon Cleveland 2018上参加刘佳琪的演讲，构建考虑测试的数据管道。

翻译自: https://opensource.com/article/18/5/building-data-pipeline-testing-mind

输油管道问题测试数据