-
Notifications
You must be signed in to change notification settings - Fork 23
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
Migrate RHOAR QE coverage for MicroProfile OpenTracing #10
Comments
I've been waiting a while for the output #20 (review) using test-containers tooling proposal. For now it looks undefined so I had to migrate Docker helper classes too in order to get the migrated tests to work and tune them up. I had some difficulties with swarm @DefaultDeployment annotation eliminating. Deployments are OK now but Jaeger seems to be not grabbing logs from Tracer in deployed service - I will have to have a look on it next week once I am back in the office. Due to the above mentioned reasons the working branch is still in progress. |
@zhantemirov I can probably see the same thing. Jaeger logs just each 1000th request so it might look that it does not work. I suspect that configuration for Jaeger defined in microprofile-config.properties is not applied. My microprofile-config.properties looks like (taken from [1]):
[1] https://docs.thorntail.io/4.0.0-SNAPSHOT/#component-opentracing-jaeger |
Still having issues with discovering traces in Jagger UI. I've used your suggested configuration and it seems to be working, few interesting things are happening though. I decided to investigate the issue by starting a WildFly instance, deploying the same WAR archive (that I've been using in migrated tests) and starting a Jaeger (all steps manually). Here are the results: starting Jaeger -> starting WildFly + WAR deploy -> trace records are presented I don't know why the second option doesn't work. In my migrated tests the third option seems to not be working, giving it a little bit of time - but I need to do some work on RFE, so maybe filing an issue here would be a temporary option. |
+1 for issue, can you try it on WF 18 too ? OpenTracing is already integrated so we should file issue against WFLY project. I assume you hit the app endpoint at the time of last Is there a way to figure out Jaeger availability from management model ? |
@rsvoboda after some additional analysis and documentation reading I managed to identify the possible source of the issue. As mnovak has mentioned before, the reason why the entries are not presented at Jaeger database is that injected Jaeger tracer instance doesn't respect the META-INF/microprofile-config.properties configuration. As soon as I replace the injected tracer instance by my own that is manually configured by parameters from microprofile-config.properties - traced entries are shown up in Jaeger UI. So the question is: do we need to tweak migrated tests by this way? Own configured tracer instance logs the entries in a little another way - so the test checks have to be modified too. FYI the thorntail OpenTracing tests has a support of Swarm Jaeger tracer helper classes that set up all the necessary Jaeger configuration parameters as well. The problem is (as it is written above)
WDYT? |
Let me rephrase the question: Customer has deployment with META-INF/microprofile-config.properties entries for Jaeger configuration
|
An issue has been filed - https://issues.redhat.com/browse/WFLY-12842 |
@zhantemirov hi, can it be marked as done and closed? |
As it was written in the previous commentary, a JIRA [1] has been filed due to the issue [2] we hit. The original intent of this migration were additional OpenTracing tests (http path with wild cards, negative scenarios). These tests are already merged [3] in WildFly master. Closing the issue. [1] - https://issues.redhat.com/browse/WFLY-12842 |
@mnovak1 shouldn't this TS have opentracing module too ? At least just with README saying tests are in WF repo + link to the module with tests tbh I didn't expect everything will end up in WF TS and nothing here. |
Reopening - will prepare PR for the case when https://issues.redhat.com/browse/WFLY-12842 will be fixed. |
Migrate relevant test coverage from
The text was updated successfully, but these errors were encountered: