[ English | English (United Kingdom) | Deutsch | Indonesia | 中文 (简体, 中国) | español (México) | 한국어 (대한민국) ]

使用Elastic Recheck

注解

本部分假设您已完成 检查Zuul中的状态

允许您:

  • 增强社区对提交给gerrit的每个补丁所做的自动测试

  • 报告重复出现的错误,是的您无需手动’重新检查’

如果测试作业失败该怎么办

当您向gerrit提交补丁时,zuul返回其运行的测试结果,有时其中一项测试失败。 在大多数情况下,这表明您建议的更改存在问题,并且测试正在找出问题。 有时,测试运行可能会因OpenStack中潜在的预先存在的错误而跳闸。 此外,有时运行测试的基础设施可能会出现故障。 为了弄清楚这一点,您始终需要查看失败作业的日志以了解发生了什么。

什么是elastic-recheck

elastic-recheck是用于跟踪测试作业中的失败的工具。 它保留了已知错误“指纹”的仓库,这些“指纹”存储着正在影响门控工作的已知错误。 然后,它既可以用来跟踪发现这些错误的速率,也可以在发现故障的已知错误“指纹”时在gerrit和IRC中留下注释。

elastic-recheck建立在ELK之上( Elastic Search, Logstash, Kibana ),我们使用Logstash将CI作业中的所有日志存储在Elastic Search集群中。 我们还托管了一个 Kibana dashboard ,可用于在集群上运行查询并与数据进行交互。 elastic-recheck在弹性搜索集群中查询“指纹”。

您可以在以下位置查看通过elastic recheck跟踪的错误的当前状态: Elastic Recheck

../_images/er_status.png

每个图都显示在过去10天内针对被搜索“指纹”找到了多少个匹配项。 它还提供了指向该错误的launchpad页面链接和针对该“指纹”的基础elastic-search查询的kibana bashboard链接。

elastic-recheck也有一个页面来显示遇到了多少个没有匹配“指纹”的故障。 通常,未分类的故障越多,则门控(以及整个OpenStack)越不稳定。

你可以在下面找到这些页面:

Unclassified failed integrated gate jobsUnclassified failed jobs

取决于哪些作业是你感兴趣的。

../_images/er_uncategorized.png

如果您对Elastic Recheck项目背后的更多理论和历史感兴趣,那么Juno OpenStack峰会的演讲将提供很好的概述: Elastic Recheck - Tools for Finding Race Conditions in OpenStack

在elastic-recheck中跟踪一个新错误

当您遇到无法通过elastic-recheck进行跟踪的故障,并且查看了日志以确定该故障不是由建议的更改引起的并且正在影响其他更改时,可以提出新的elastic-recheck“指纹”。

本指南将不涉及跟踪运行日志和查找良好“指纹”的详细信息,因为这会根据您要查找的工作涉及很多,并且已经在一些地方进行了记录,包括:

当在日志中识别出可用于“指纹”鉴定的消息后,您将需要将其转换为弹性搜索查询。 您可以使用任何现有的“指纹”作为示例: opendev/elastic-recheck

您还应该在以下位置使用kibana检查所有弹性搜索查询: Logstash Search

当构建了查询并将其检入Elastic-Search之后,您应该在elastic-recheck git repo的查询目录中创建一个yaml文件。 文件名是该错误的launchpad错误号码,内容是弹性搜索查询。