InfluxDB Backend Listener: Limited error information and missing assertion failure details
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 50/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 技术栈
- java
调研方向
从 src/components/src/main/java/org/apache/jmeter/visualizers/backend/SamplerMetric.java 开始,重点关注 SamplerMetric.add() 及其当前的错误处理。使用一个故意失败的 Response Assertion 和 InfluxDB Backend Listener 重现该失败,然后验证 assertion 名称、失败消息和 HTTP 错误是否在报告的指标中分别表示。
由索引模型根据 Issue 内容生成。
描述
Expected behavior
When using the InfluxDB Backend Listener, error metrics should capture complete error information including:
- Detailed Assertion Failures: Each failed assertion should be reported with:
- Assertion name (e.g., "Response Assertion", "Duration Assertion")
- Specific failure message (e.g., "Expected to contain 'success' but found 'error'")
- Individual error count for each assertion type
- HTTP Response Failures: Non-assertion failures should report:
- HTTP response codes (e.g., "404", "500")
- Response messages (e.g., "Not Found", "Internal Server Error")
- Comprehensive Error Categorization: Errors should be properly categorized and distinguishable in InfluxDB/Grafana dashboards
Actual behavior
The InfluxDB Backend Listener currently provides limited error information:
- Missing Assertion Details: Assertion failures are completely ignored in error metrics
- No individual assertion failure reporting
- No distinction between different types of assertion failures
- Loss of valuable debugging information
- Incomplete Error Information: Only HTTP response code/message errors are captured
- Assertion failures are not reflected in error metrics
- No visibility into specific assertion failure reasons
- Difficult to debug test failures without detailed error context
- Poor Error Debugging: Users cannot identify:
- Which specific assertions are failing
- Why assertions are failing (missing expected text, duration exceeded, etc.)
- Patterns in assertion failures across different test scenarios
I have the potential solution to resolve this issue: The issue is in the SamplerMetric.add() method in src/components/src/main/java/org/apache/jmeter/visualizers/backend/SamplerMetric.java. The current implementation only creates ErrorMetric objects based on HTTP response codes, ignoring assertion failures entirely.
Required Changes:
- Enhance Error Processing: Modify the error handling logic to process both HTTP response failures and assertion failures
- Add Assertion Failure Support: Create ErrorMetric objects for each failed assertion with assertion name and failure message
- Improve Error Categorization: Distinguish between HTTP response errors and assertion errors in the metrics
Steps to reproduce the problem
- Create JMeter Test Plan:
- Add Thread Group
- Add HTTP Request sampler (configure valid URL)
- Add Response Assertion (configure to fail - e.g., check for text that doesn't exist)
- Add InfluxDB Backend Listener
- Configure Response Assertion:
- Set "Apply to" to "Main sample only"
- Add "Contains" pattern with text that won't be found in response Or add Duration Assertion with very low threshold (e.g., 1ms)
- Configure InfluxDB Backend Listener:
- Set InfluxDB URL
- Set database name
- Enable "summaryOnly" = false
- Set appropriate measurement name
- Run Test and observe in InfluxDB/Grafana:
- Expected: Error metrics showing all assertion name (in responseCode) and failure message (in responseMessage) per sample/ transaction
- Actual: No error metrics for assertion failures, only constant Error responseCode (Assertion Failed) and single assertion failed message per sample/ transaction are captured
- Verify Missing Information:
- Check InfluxDB for error metrics with assertion names
- Verify that assertion failure messages are not present
- Confirm that only HTTP response codes appear in error metrics
JMeter Version
5.6.3
Java Version
No response
OS Version
No response
- 主要语言
- Java
- 星标
- 9.6k
- 派生
- 2.3k
- 平均合并
- 20 小时 42 分钟
- 30 天内合并 PR
- 10
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
apache/jmeter 的其他 Issue
-
[Bug] Typo in assertion property name: "Asserion.test_strings" missing 't'可能已有人在做 @waterWang 于 59 天前认领。 未关闭defect to-triage
难度 1/5 1 小时以内 新手友好度 82/100
维护者通常 1 天内回复
-
enhancement to-triage
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
RandomDate ignores inclusive end date and throws when start == end可能已有人在做 @weillercarvalho 于 336 天前认领。 未关闭defect to-triage
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
documentation to-triage
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
invalid wontfix
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
相似的 Issue
-
ToolCallbackProvider AutoConfiguration does not preserve tool order可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭status: waiting-for-triage
难度 2/5 1-3 小时 新手友好度 79/100
spring-projects/spring-ai#7206 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 80/100
eclipse-dirigible/dirigible#7958 ·
维护者通常 1 天内回复
-
bug ci sev-6
难度 2/5 1-3 小时 新手友好度 73/100
-
area/cli
难度 2/5 半天 新手友好度 78/100
quarkusio/quarkus#57623 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
jhipster/prettier-java#1113 ·
维护者通常 2 天内回复