Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The result shows all http req failed but Prometheus received data #24

Closed
Kirchen99 opened this issue Sep 12, 2022 · 2 comments · Fixed by #31
Closed

The result shows all http req failed but Prometheus received data #24

Kirchen99 opened this issue Sep 12, 2022 · 2 comments · Fixed by #31
Labels
good first issue Good for newcomers

Comments

@Kirchen99
Copy link

Prometheus Version: v2.37.0
xk6-client-prometheus-remote Version: build from resource according to the README.md
k6 Version: k6 v0.40.0 ((devel), go1.19.1, darwin/amd64)

In this example the status code is compared with 200, but Prometheus give 204 back.

'is status 200': (r) => r.status === 200,

What did you do?

try the example from this repo with a local prometheus: https://github.com/grafana/xk6-client-prometheus-remote/blob/main/examples/basic.js

What did you expect?

No error

What did you see instead?

Error messages such as:

http_req_failed: 100% and

✗ is status 200
      ↳  0% — ✓ 0 / ✗ 10

but the Prometheus received the data.

default ✓ [======================================] 1 VUs  10s

     ✗ is status 200
      ↳  0% — ✓ 0 / ✗ 10

     checks.....................: 0.00%   ✓ 0        ✗ 10 
     data_received..............: 640 B   62 B/s
     data_sent..................: 2.8 kB  274 B/s
     http_req_blocked...........: avg=155.09µs min=4µs     med=6.5µs   max=1.49ms  p(90)=156.09µs p(95)=827.04µs
     http_req_connecting........: avg=15.4µs   min=0s      med=0s      max=154µs   p(90)=15.39µs  p(95)=84.69µs 
     http_req_duration..........: avg=29.69ms  min=16.42ms med=24.23ms max=81.08ms p(90)=37.05ms  p(95)=59.06ms 
     http_req_failed............: 100.00% ✓ 10       ✗ 0  
     http_req_receiving.........: avg=61.69µs  min=38µs    med=58µs    max=127µs   p(90)=77.49µs  p(95)=102.24µs
     http_req_sending...........: avg=85.9µs   min=27µs    med=46.5µs  max=444µs   p(90)=127.19µs p(95)=285.59µs
     http_req_tls_handshaking...: avg=0s       min=0s      med=0s      max=0s      p(90)=0s       p(95)=0s      
     http_req_waiting...........: avg=29.54ms  min=16.35ms med=24.13ms max=80.51ms p(90)=36.9ms   p(95)=58.7ms  
     http_reqs..................: 10      0.969329/s
     iteration_duration.........: avg=1.03s    min=1.01s   med=1.02s   max=1.08s   p(90)=1.03s    p(95)=1.06s   
     iterations.................: 10      0.969329/s
     vus........................: 1       min=1      max=1
     vus_max....................: 1       min=1      max=1
{"remote_ip":"127.0.0.1","remote_port":9090,"url":"http://localhost:9090/api/v1/write","status":204,"status_text":"204 No Content","proto":"HTTP/1.1","headers":{"Date":"Mon, 12 Sep 2022 10:28:25 GMT"},"cookies":{},"body":"","timings":{"duration":22.487,"blocked":0.006,"looking_up":0,"connecting":0,"tls_handshaking":0,"sending":0.092,"waiting":22.327,"receiving":0.068},"tls_version":"","tls_cipher_suite":"","ocsp":{"produced_at":0,"this_update":0,"next_update":0,"revoked_at":0,"revocation_reason":"","status":""},"error":"","error_code":0,"request":{"method":"POST","url":"http://localhost:9090/api/v1/write","headers":{"Content-Encoding":["snappy"],"Content-Type":["application/x-protobuf"],"User-Agent":["k6-remote-write/0.0.2"],"X-Prometheus-Remote-Write-Version":["0.0.2"]},"body":"","cookies":{}}}
@mstoykov
Copy link
Contributor

Hi @Kirchen99, thanks for reporting that. This seems like a simple example mistake or behaviour change.

The test chekcs for 200 but prometheus returns 204 as you notice. I have no idea if that is normal though and if it has changed ... recently.

cc @replay any idea on this?

@replay
Copy link
Contributor

replay commented Jan 13, 2023

I believe to remember that it is normal for Prometheus to return 204 on successful ingestion. Instead of looking for 200 the check should look for a status code in the range [200, 300)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants