hyperdx icon indicating copy to clipboard operation
hyperdx copied to clipboard

Hyperdx Loading...

Open satya-soul opened this issue 1 year ago • 17 comments

docker run -p 8000:8000 -p 4318:4318 -p 4317:4317 -p 8080:8080 -p 8002:8002 hyperdx/hyperdx-local

When I deployed it through docker I am getting loading page. Screenshot 2024-07-29 at 3 58 28 PM

satya-soul avatar Jul 29 '24 10:07 satya-soul

I have the same problem

Buringcarbon avatar Aug 01 '24 02:08 Buringcarbon

Hi @satya-soul and @Buringcarbon are you guys both using non-localhost domains to access the page? Can you check if accessing on localhost:8080 works?

It's most likely you'll need to edit the environment variables and rebuild the frontend app with the instructions here for custom domains: https://github.com/hyperdxio/hyperdx#:~:text=Changing%20Hostname%20and%20Port

MikeShi42 avatar Aug 01 '24 03:08 MikeShi42

Hey @MikeShi42 Thanks for the response, it did work on ec2 sever but still facing issue with getting logs from kubernetes. Do you know how to host it on Kubernetes? I have gone through a helm chart by one of open source contributor but still facing issue.

satya-soul avatar Aug 01 '24 05:08 satya-soul

@satya-soul the most important part is you'll need to have an image with the new domain baked in so that the frontend knows where to talk to the backend. I don't believe the helm chart takes care of that step today

MikeShi42 avatar Aug 01 '24 21:08 MikeShi42

Hosting the web UI at non-localhost origin requires some extra configuration

I can use this configuration at LAN host 192.168.2.120 , with no problem submitting and reading the traces

services:
  hyperdx:
    image: hyperdx/hyperdx-local:1.10.0
    environment:
      - FRONTEND_URL=http://192.168.2.120:8081
      - SERVER_URL=http://192.168.2.120:8000
    ports:
      - 8081:8080 # UI
      - 8000:8000 # API
      - 4318:4318 # http collector
      - 4317:4317 # gRPC collector
      - 8002:8002
$ OTEL_EXPORTER_OTLP_ENDPOINT=http://192.168.2.120:4318 node my-server.js

jokester avatar Nov 30 '24 07:11 jokester

Hi, I am facing same problem, "Hyperdx Loading..." with back window. I have tried the solution mentioned at https://github.com/hyperdxio/hyperdx#:~:text=Changing%20Hostname%20and%20Port but that did not work for me. I deployed HyperDx on a EC2 Ubuntu machine.

Here are the steps I followed...

  1. git clone https://github.com/hyperdxio/hyperdx.git
  2. edited .env file with domain name
  3. make build-local
  4. docker-compose up -d
  5. "docker-compose ps" shows all services up and running
  6. When I access UI at http://domain_name:8080 it is just showing "Hyperdx Loading..."
  7. I have also posted some test logs to the v1/logs endpoint using postman, received 200 status with {"partialSuccess": {}} response body
  8. UI again just showing "Hyperdx Loading..."

srinivas-bitla avatar Dec 30 '24 15:12 srinivas-bitla

I found this issue is fixed in v2.

srinivas-bitla avatar Jan 04 '25 07:01 srinivas-bitla

I found this issue is fixed in v2.

I'm not sure, because login isn't possible, redirecting to localhost

HeyLey avatar Feb 11 '25 09:02 HeyLey

Hello,

turns out the problem is that the image build using make build-local does not correspond to the image being used inside of the docker-compose.yml

Inside of docker-compose.yml it uses the following

app:
    image: ${IMAGE_NAME_HDX}:${IMAGE_VERSION}-app

with IMAGE_NAME_HDX being defined in the .env as ghcr.hyperdx.io/hyperdxio/hyperdx

Inside of the Makefile it uses the IMAGE_NAME variable defined as ghcr.io/hyperdxio/hyperdx

	docker build \
		--build-arg CODE_VERSION=${LATEST_VERSION} \
		--build-arg OTEL_EXPORTER_OTLP_ENDPOINT=${OTEL_EXPORTER_OTLP_ENDPOINT} \
		--build-arg OTEL_SERVICE_NAME=${OTEL_SERVICE_NAME} \
		--build-arg PORT=${HYPERDX_APP_PORT} \
		--build-arg SERVER_URL=${HYPERDX_API_URL}:${HYPERDX_API_PORT} \
		. -f ./packages/app/Dockerfile -t ${IMAGE_NAME}:${LATEST_VERSION}-app --target prod

So the image you are building locally is never used.

PascalRoessnerDSA avatar Feb 23 '25 12:02 PascalRoessnerDSA

turns out the problem is that the image build using make build-local does not correspond to the image being used inside of the docker-compose.yml

This is correct. Once I updated my .env file so that the correct images were used, the problem went away. Here are the relevant entries from my .env file:

IMAGE_NAME=ghcr.io/hyperdxio/hyperdx IMAGE_NAME_HDX=ghcr.io/hyperdxio/hyperdx

I wish this was documented somewhere.

cheema-corellian avatar Feb 24 '25 10:02 cheema-corellian

There is an issue with the build-local command. I am going to raise a PR to fix it. Thanks for the report 🙏

wrn14897 avatar Feb 24 '25 23:02 wrn14897

The build-local command should work now. I want to clarify that hyperdx/hyperdx-local is the all-in-one container (check out env vars here, but build-local is to rebuild all pre-built images used within the docker-compose.yml file.

  • If you are using hyperdx/hyperdx-local, check out the env vars HYPERDX_API_URL and HYPERDX_APP_URL (internal ports are not changeable atm, but you can update the mapping like https://github.com/hyperdxio/hyperdx/issues/483#issuecomment-2508872542).
  • If you are running with docker-compose.yml, you will need to run build-local after updating the env vars (HYPERDX_XXX_URL and HYPERDX_XXX_PORT)

The api/app URL and port separation issue should be addressed in the v2 branch, as it will no longer involve separate services. (ref: https://github.com/hyperdxio/hyperdx/blob/1e5d97c131e7bb8c23f59fc8116f7f4bd9779e65/docker-compose.yml#L112-L135)

wrn14897 avatar Feb 25 '25 00:02 wrn14897

Using 2-beta.10 image. Tried NEXT_PUBLIC_SERVER_URL, SERVER_URL, HYPERDX_API_URL. Nothing works. It still tries the url.

kalashnikovisme avatar Feb 26 '25 08:02 kalashnikovisme

@kalashnikovisme the v2 images are quite different (that tag is basically a v2 local mode), what was your setup and what were you looking to do with the v2 image?

MikeShi42 avatar Feb 27 '25 00:02 MikeShi42

@MikeShi42 thanks! I've figured out that this is v2. So, I already prepared deployment configuration with rebuilding of the image with needed API url.

kalashnikovisme avatar Feb 27 '25 00:02 kalashnikovisme

@kalashnikovisme got it, just to confirm things are working? Just wanted to point out that the issues/responses above for v1 probably won't apply for the v2 images given they've changed quite a bit :) (and if there are any issues, probably a new issue should be created).

MikeShi42 avatar Feb 27 '25 01:02 MikeShi42

@MikeShi42 I understood this, thanks. I've tried to deploy 2.beta-10 and it basically did not work 😆

It's not a problem, I understand it's the beta, so, no worries 🙂

kalashnikovisme avatar Feb 28 '25 13:02 kalashnikovisme