lalabuy948 / PhoenixAnalytics

📊 Plug and play analytics for Phoenix applications.
https://theindiestack.com/analytics
Apache License 2.0
254 stars 9 forks source link

Analytics are not updated #26

Open skota opened 6 days ago

skota commented 6 days ago

I have deployed a phoenix app with phoenix anaytics. However the analytics are not updating. I had 3 persons from diff geographic locations access the site. The analytics are not updating.

I can see analytics.dukdb in the deployment folder. How do i troubleshoot this?

thanks.

lalabuy948 commented 3 days ago

Hi @skota, easiest way if you install duckdb client locally and copy production analytics.duckdb file locally:

duckdb analytics.duckdb 
 SELECT * FROM requests;

Could you please tell which version of PA you are using?

skota commented 3 days ago

I am on {:phoenix, "~> 1.7.14"}, {:phoenix_analytics, "~> 0.2"},

I copied the analytics.duckdb to my desktop and can confirm requests has only 1 row.

It works fine locally though. Have an issue on prod.

Prod server is a ubuntu box if that matters.

lalabuy948 commented 2 days ago

Interesting. Do you have any special configuration for prod environment?

MoonsilverTV commented 1 day ago

I am encountering the same issue: version 0.2 application is released as a mix release inside a docker container with MIX_ENV="prod" it will seem to track a single write and display it correctly in the analytics live view however, no subsequent interactions are displayed the duckdb file is put onto a docker compose volume

i too could only see a single row in my duck db when i manually opened it at runtime

however: when i shut down my docker image and restarted it, it then went on to show everything it had been tracking in the past 2 days - though it appears to not be updating the view again

i just went to double check if the behaviour is the same outside a docker container, and it does seem like i'm getting inconsistent update timing with a simple development environment and mix phx.server as well

VPS is running Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-47-generic x86_64) dev environment is running NixOS 24.11.20240923.30439d9 (Vicuna) x86_64 (Kernel: 6.6.52)

i'll report if I find anything solid, but my suspicion is that the data might not get flushed to the database as often as it should which would be a plausible bug in the batcher. i'll report back if i find anything more concrete.

MoonsilverTV commented 1 day ago

just did some printf debugging, the batcher is doing something every second like it should it hits the if branch that sends the batch update when i would expect it to it batches reasonable RequestLog structs stuff gets correctly forwarded to Repo.insert_many

here i have the following things happen, which also all seems reasonable to me:

insert_many
connection ok
not in postgres mode
connection:
#Reference<0.1471136449.775553092.21491>
prepared:
[
  ["dfa324a7-4769-4ae4-86fb-adf339657668", "GET", "/phoenix/live_reload/frame",
   200, 0,
   "Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0",
   "127.0.0.1", "http://localhost:4000/dev/analytics", "desktop",
   "063c2772-9a55-4aa1-af75-8525c0b8706d", 134, "2024-10-24 20:31:24.514"],
  ["d9cebb47-c374-43d7-9edc-99c29fbf9584", "GET", "/dev/analytics", 200, 7,
   "Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0",
   "127.0.0.1", "Direct", "desktop", "063c2772-9a55-4aa1-af75-8525c0b8706d",
   133, "2024-10-24 20:31:24.411"]
]
appender:
#Reference<0.1471136449.775553097.21746>
result:
:ok
MoonsilverTV commented 1 day ago

However, these requests above were apparently not persisted in the .duckdb file I then restarted the server (double ctrl c cancel -> mix phx.server) and navigated around some more, saw similar logs, and that time they were persisted in the duckdb file That's a rough one...

I'm out of time for the day, if I find time on the weekend, i'll try and check if this also happens with Postgres

skota commented 1 day ago

No i don't have any special config. I just deploy a release. I will try to dig through the code and see if i can set up logging to see where the problem could be.