-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[jaeger-v2] add Badger storage backend integration test #5281
Conversation
@james-ryans, this test is not able to receive data. any idea, how to tackle this? 2024/03/18 12:02:01 Starting load generator at 1024 items/sec.
2024/03/18 12:02:03 | Sent: 539 traces (275/sec) | Received: 0 items (0/sec)
2024/03/18 12:02:06 | Sent: 1,533 traces (309/sec) | Received: 0 items (0/sec)
2024/03/18 12:02:08 Stopped generator. Sent: 1,533 traces (219/sec)
2024/03/18 12:02:09 | Sent: 1,533 traces (192/sec) | Received: 0 items (0/sec)
2024/03/18 12:02:12 | Sent: 1,533 traces (139/sec) | Received: 0 items (0/sec)
2024/03/18 12:02:15 | Sent: 1,533 traces (109/sec) | Received: 0 items (0/sec)
2024/03/18 12:02:18 | Sent: 1,533 traces (90/sec) | Received: 0 items (0/sec)
2024/03/18 12:02:18 Time out waiting for all data items received
test_case.go:289: Time out waiting for all data items received |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5281 +/- ##
==========================================
- Coverage 95.08% 95.00% -0.08%
==========================================
Files 340 340
Lines 16626 16626
==========================================
- Hits 15809 15796 -13
- Misses 628 642 +14
+ Partials 189 188 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
I've just learned that Badger is an embedded local storage. In Testbed, the collector and the data receiver are both running as separated instances. That being said the data receiver doesn't have access to anything inside the collector, that's why we can't test the memory storage backend. But from my perspective, it seems your Badger config writes and stores the spans in the Also, that means you probably don't need to have a script to run a remote storage. |
If you point two badger instances to the same file system they may run into synchronization issues. I don't think it's recommended. The way to test badger and memory is by using jaeger remote storage, a binary that can run one instance to which you connect as grpc storage. I believe our crossdock tests are using that. |
I think Yuri is right, I've just tried to run the Badger integration test with
Yes, in the previous PR for gRPC integration test, I actually used memory span storage type for the remote storage. You may also follow that configuration at |
Thanks for the suggestions. I am trying it out, I will update you soon. |
However, replicating this in docker using a script throws this error because user_uid is set to 1001(non_root) in remote-storage.
|
Signed-off-by: Pushkar Mishra <pushkarmishra029@gmail.com>
You don't want /go/bin as the data dir for badger. See #5282 about permissions |
Signed-off-by: Pushkar Mishra <pushkarmishra029@gmail.com>
Fixed this permission error, Still same :
Any other approach or fix @yashrsharma44 |
dbentries.txt |
@Pushkarm029 I doubt you can compare binary files like that, @james-ryans might have completely different binary representation because of timestamps. You can query db via jaeger-query/apiv3 JSON interface |
perhaps we can add logging to the data receiver that shows which query it is executing against the backend. Then try to run the same query manually - if it returns the data it means you likely have some connectivity issue rather than data issue. |
Yes, I'm trying to help figure out how to add logging similar to the OTEL collector's components log to the data receiver. I just finished debugging the issue, it was sourced from the artificial jaeger receiver. In Badger, the
I'll create a new PR to fix this issue and also add logging to the data receiver. Sorry for the inconvenience. |
Don't feel sorry; after all, we all are here to learn❤️ |
Signed-off-by: Pushkar Mishra <pushkarmishra029@gmail.com>
… function. (#5288) ## Which problem is this PR solving? - Fixes #5281 issue for not being able to consume traces ## Description of the changes - Added `StartTimeMin` and `StartTimeMax` query params with 1h lookback to `consumeTraces` function. - Added logging to the data receivers with the OTelCol codes below as the references. - https://github.com/open-telemetry/opentelemetry-collector/blob/main/otelcol/unmarshaler.go#L45 - https://github.com/open-telemetry/opentelemetry-collector/blob/main/service/telemetry/telemetry.go#L118 ## How was this change tested? - Tested manually. ## Checklist - [x] I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md - [x] I have signed all commits - [x] I have added unit tests for the new functionality - [x] I have run lint and test steps successfully - for `jaeger`: `make lint test` - for `jaeger-ui`: `yarn lint` and `yarn test` --------- Signed-off-by: James Ryans <james.ryans2012@gmail.com>
Why closed? |
Auto-closed because the other PR had the text |
Signed-off-by: Pushkar Mishra <pushkarmishra029@gmail.com>
@Pushkarm029 do we still need this PR or is it covered by #5355 ? |
Nope, I'm closing it now. |
Which problem is this PR solving?
Description of the changes
How was this change tested?
Checklist
jaeger
:make lint test
jaeger-ui
:yarn lint
andyarn test