LogTide
Replies: 3 comments 8 replies
|
I've tried running the previous version of Postgres, as well as version 1.4.0 of the frontend and backend. No difference. |
|
Thanks for the detailed report, the logs made this easy to track down. The cause is the password itself: it contains Two ways to fix it:
You're also right about the password in the log, that was a bug in the migration script. It's fixed for 1.6.0, which also makes an invalid |
|
1.6.0 should be released today or tomorrow |
|
Thanks for the quick response. Good thing the password wasn't masked or it would have been more difficult to uncover. I need to change that quickly. Ever thought to just pass the DB info to the backend and worker and you calculate the URL internally? Might let passwords be passwords instead of typical API keys? Also, on the compose file, because a lot of the environment variables are duplicate for backend and the worker, have you considered using compose extensions? |
|
Both are good points, and honestly I hadn't thought about either of them. A lot of the setup grew piece by piece without me really noticing, and the compose file is a good example of that.
1.6.0 is going out now, so these will land in 1.6.1. Thanks for the suggestions! |
|
Thank you for making those changes, but it seems like I am running into couple other issues that I'm sure is my environment and my ignorance on Docker. First, I chose to use a different user for the postgres db, which I called svc_logtide. The error message I get is:
The other issue I have is that in my environment, I have other containers and services already running, so I needed to map the host ports to a freely available port. This seems to create a number of problems that are also not easily resolved, and seems to also be causing issues. In my environment file, I created the following variables:
This requires, I think, modification of several things in the docker compose file, including:
The last environment setting was to allow passing of the backend port to the config files much like we do with the LOGTIDE_API_HOST value. This is all before I can even get to the frontend web, which as it stands, current says:
I cannot get this work for the life of me, and I'm not sure what I am doing wrong. Thoughts? |
|
The svc_logtide error is harmless and it's on us. The postgres healthcheck runs pg_isready without -d, so it tries a database named after the user. The check still passes and your real database is fine. To silence it, change the healthcheck to: pg_isready -U ${DB_USER} -d ${DB_NAME} For the ports, only the left side of each mapping should change. The backend should keep listening on 8080 inside the container, but PORT: ${BACKEND_PORT} moves it to 8111 while your mapping still points at 8080, so nothing answers. Set PORT back to 8080, put the healthcheck back on 8080, and remove BACKEND_PORT from the backend and fluent-bit environments. fluent-bit talks to the backend over the docker network, so it wants 8080 too. "Failed to fetch" is because the browser is still calling http://localhost:8080. Add these to your .env, using whatever address you open the UI with: PUBLIC_API_URL=http://your-host:8111 Then run docker compose up -d so the containers get recreated. You don't need to wipe any volumes. Also, the .env.example comment saying the API URL is auto-detected is wrong, that's our bug and not your setup. I'll fix that and the healthcheck, and make the host ports configurable so you don't have to edit the compose file. |
|
Great. Adding the -d ${DB_NAME} has resolved the previous log message. As for the ports, that also seems to be working, for the most part. When I go to the FRONTEND_URL, it initially shows me an "Authenticating" screen, then a login form, but before I can actually enter something, I get a "Failed to Fetch" message. The documentation indicates this is normally because of a PUBLIC_API_URL issue, but it seems to work, and I don't see anything in the logs. If I check from the frontend container with the following command, I can see that it is able to connect with the same PUBLIC_API_URL checking against the /health path successfully.
I don't know if this matters, but as of right now, I am running this behind an Nginx reverse proxy. It was also set to run through an authentication tool, but I disabled that just in case something was breaking it. Any ideas? |
|
Your check runs inside the frontend container, but those API calls come from the browser, so it doesn't tell us much here. Nothing in the backend logs fits that too: the requests never reach it. My guess is mixed content. If you open the UI over https through Nginx, the browser blocks calls to http://192.168.0.3:8111. The browser console (F12) will confirm it, so if you see something else there, send it over. The clean fix is to send the API through Nginx too, on the same domain as the UI: location /api/ {
proxy_pass http://192.168.0.3:8111;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off;
}proxy_buffering off is there for live tail. Then in .env: Run docker compose up -d and reload the page. Don't leave PUBLIC_API_URL empty, because the current compose file turns that back into http://localhost:8080. TRUST_PROXY=1 makes the backend see real client IPs, as long as Nginx is the only proxy in front of it. When you turn the auth tool back on, it has to let /api/ through, or you'll probably get the same error. |
|
I think that finally resolved all the problems. It seems to be ingesting ok with the little test. Now, on to getting the full environment setup. Thank you for your help! What a great tool! |
|
Thank you for using logtide @goni05 |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hey Guys! I am new to Logtide, and I was attempting to spin up my first instance to give the tool a test ride. However, I am having difficulties with the initial setup. The issue is that the Backend keeps restarting. I have reviewed all the typical recommendations (DB_URL, DB_PASSWORD, REDIS_PASSWORD, and API_KEY_SECRET, and everything checks out.
From what I can tell, the configuration is correct, but it's not able to execute the SQL scripts for the initial setup. I can connect to the PostgreSQL logtide DB (confirming the credentials and database has been created) and see it has basically the default timescaledb* default schemas, but no tables.
Here is what I get in the logs:
`
`
I also noticed in the logs that the ENV variable for the DB_PASSWORD is exposed in the log during the dotenv config step, but later masked with ***, so I don't know if that's an issue, but might be something to review (I plan to change this after I get it fixed).
My config is modified from the provided docker-compose.yml file, mostly to change default ports (using env variables). If someone has any ideas that can help, I would appreciate it.
All reactions