-
Notifications
You must be signed in to change notification settings - Fork 573
Adding Prometheus Support #534
Conversation
@pearj there were some CI errors, I'll double check locally and see if their are real. |
If this is creating problems with travis, maybe merge #527 onto a protected branch as well, and see how that one goes. There is more value with that change anyway. |
Fixes nginx redirect issue with #533
Switch redirect to use lua plugin so that it's relative
Codecov Report
@@ Coverage Diff @@
## master #534 +/- ##
============================================
- Coverage 80.95% 79.83% -1.13%
+ Complexity 585 582 -3
============================================
Files 32 33 +1
Lines 2688 2742 +54
Branches 233 234 +1
============================================
+ Hits 2176 2189 +13
- Misses 372 409 +37
- Partials 140 144 +4 |
Wierd that it fails browserstack. It works on my pc™️ on browserstack. |
all the logging is broken when running the tests since the move to logback I think:
Running locally I had to do:
So I guess that needs to be added into maven somehow when the tests run. |
Add logback logging into integration tests
@diemol looks like I shouldn’t have added the extra |
I'll check it |
Remove clean, as it breaks the tests
Somehow the BrowserStack test are failing, I also reproduced it locally. I am not sure what the reason is, I guess when the response comes back from BrowserStack something in nginx doesn't get processed properly. Just by running this test |
docker/nginx.conf
Outdated
@@ -26,27 +26,27 @@ http { | |||
|
|||
location / { | |||
proxy_pass http://127.0.0.1:4445; | |||
proxy_set_header Host $host; | |||
proxy_set_header X-Real-IP $remote_addr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I remove lines 29 and 30, BrowserStack works again.
The dashboard redirect also works.
Is there a reason to include them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I deleted other parts of nginx config that had included them originally. I presumed it would be safe. But I guess it isn’t! I wonder why the tests didn’t fail for me locally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I'll remove them and push again.
Also, the little icons for cloud providers are not being rendered anymore. The console tries to find them at http://localhost:4444/grid/admin/ZaleniumResourceServlet/images/browserstack.png |
Ahh whoops. I couldn’t find the usage of the resource servlet. My bad. |
@@ -81,7 +81,7 @@ privileged public aspect HubAspect { | |||
handler.addServlet(LivePreviewServlet.class, "/grid/admin/live"); | |||
handler.addServlet(ZaleniumConsoleServlet.class, "/grid/console"); | |||
// We want resources to be at least 3 levels deep so that the prometheus servlet filter doesn't pick up all the individual resources | |||
handler.addServlet(ZaleniumResourceServlet.class, "/grid/console/resources"); | |||
handler.addServlet(ZaleniumResourceServlet.class, "/grid/resources"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should move the resources out of /grid
so that it doesn’t appear in /metrics
at all.
@@ -87,13 +87,13 @@ private String getSingleSlotHtml(TestSlot s) { | |||
TestSession session = s.getSession(); | |||
String icon = ""; | |||
if (proxy instanceof TestingBotRemoteProxy) { | |||
icon = "/grid/admin/ZaleniumResourceServlet/images/testingbot.png"; | |||
icon = "/grid/resources/images/testingbot.png"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just straight /resources
pretty sure the hub doesn’t use it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe let’s just merge and when we add zalenium Prometheus metrics. I’ll move the resources somewhere else now that I know what uses them.
👍 |
* Update cloud icon locations
@@ -115,7 +115,7 @@ private WebDriver getWebDriver() { | |||
public void checkIframeLinksForLivePreview(String browserType, Platform platform) { | |||
|
|||
// Go to the homepage | |||
getWebDriver().get(String.format("http://%s:%s/grid/admin/live", ZALENIUM_HOST, ZALENIUM_PORT)); | |||
getWebDriver().get(String.format("http://%s:%s/grid/admin/live", hostIpAddress, ZALENIUM_PORT)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could work in kubernetes in theory, if you run the test as a sidecar container (but it'd be fiddly), but just curious why we can't rely on ZALENIUM_HOST
having the hostIpAddress
? That way it can work for both docker and kubernetes.
What do we get out of finding the grid by using the current IP address inside the test? All it seems to do is ensure that maven is running on the same IP address as zalenium?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of it was to check that the live view was reachable also by its ip and that the headers were being forwarded properly, since we broke that once.
When the live view is done again, we can just do it from scratch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the /metrics endpoint looks good.
Also, the change to nginx makes /dashboard and /dashboard/ work regardless of port used
👍 |
Move zalenium resources to /resources and make wildcard
👍 |
1 similar comment
👍 |
Thanks @pearj! |
Comes from #533