Hyperdx Loading...

[satya-soul]

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.

[Buringcarbon]

I have the same problem

[MikeShi42]

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

[satya-soul]

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.

[MikeShi42]

@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

[jokester]

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

[srinivas-bitla]

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]

I found this issue is fixed in v2.

[HeyLey]

I found this issue is fixed in v2.

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

[PascalRoessnerDSA]

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.

[cheema-corellian]

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.

[wrn14897]

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

[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 Hyperdx Loading... #483 (comment)).
• 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:

hyperdx/docker-compose.yml

Lines 112 to 135 in 1e5d97c

	app:
	image: ${IMAGE_NAME_HDX}:${IMAGE_VERSION}
	ports:
	- ${HYPERDX_API_PORT}:${HYPERDX_API_PORT}
	- ${HYPERDX_APP_PORT}:${HYPERDX_APP_PORT}
	environment:
	FRONTEND_URL: ${HYPERDX_APP_URL}:${HYPERDX_APP_PORT}
	HYPERDX_API_KEY: ${HYPERDX_API_KEY}
	HYPERDX_API_PORT: ${HYPERDX_API_PORT}
	HYPERDX_APP_PORT: ${HYPERDX_APP_PORT}
	HYPERDX_APP_URL: ${HYPERDX_APP_URL}
	HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
	MINER_API_URL: 'http://miner:5123'
	MONGO_URI: 'mongodb://db:27017/hyperdx'
	NEXT_PUBLIC_SERVER_URL: http://127.0.0.1:${HYPERDX_API_PORT}
	OTEL_SERVICE_NAME: 'hdx-oss-api'
	REDIS_URL: redis://redis:6379
	USAGE_STATS_ENABLED: ${USAGE_STATS_ENABLED:-true}
	networks:
	- internal
	depends_on:
	- ch-server
	- db
	- redis

)

[kalashnikovisme]

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

[MikeShi42]

@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?

[kalashnikovisme]

@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.

[MikeShi42]

@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).

[kalashnikovisme]

@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 🙂