[BUG] Reports page empty

[zynexiz]

What happened?

Most of the times when I look at the Reports page, it's empty. Sometimes in the previous version (1.6.5) I could change the number of reports to be viewed and it mostly started showing them. But now it seems that no reports at all is shown. The page just shows "No Reports available". It's a bit frustrating when trying to find errors and tweak the services when they are blocked, without knowing why.

Addresses is still beaned, so it seems to be working. And the raw logs show a lot of bad behaviours and stuff. But nothing will show in the reports page. I have tried to clear the logs in /var/log/bunkerweb and restart the services, but to no avail (not sure if it's the right place, but I would guess it is?).

How to reproduce?

Not sure how to reproduce the error because I don't know whats causing it in my system.

Configuration file(s) (yaml or .env)

DNS_RESOLVERS=192.168.x.x 1.1.1.1
USE_REDIS=yes
REDIS_HOST=192.168.x.x
REDIS_PORT=6379
REDIS_DATABASE=xx
REDIS_SSL=no
REDIS_USERNAME=<redacted>
REDIS_PASSWORD=<redacted>
METRICS_SAVE_TO_REDIS=yes
USE_METRICS=yes
DATABASE_URI=mariadb://.....
HTTP_PORT=80
HTTPS_PORT=443
API_LISTEN_IP=127.0.0.1
MULTISITE=yes
UI_HOST=http://127.0.0.1:7000
SERVER_NAME=
USE_CROWDSEC=yes
CROWDSEC_API=http://127.0.0.1:8080
CROWDSEC_API_KEY=<redacted>
CROWDSEC_APPSEC_URL=http://127.0.0.1:7422

Relevant log output

BunkerWeb version

1.6.6

What integration are you using?

Linux

Linux distribution (if applicable)

Debian 13

Removed private data

• [x] I have removed all private data from the configuration file and the logs

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[dbc-ca]

is it the same problem as : https://github.com/bunkerity/bunkerweb/issues/2674 ?

[TheophileDiot]

Hi @zynexiz, this is likely because the datastore is saturated as @dbc-ca mentions it.

To still have them available (even when the datastore is saturated) I'd recommend using redis: https://docs.bunkerweb.io/latest/advanced/#persistence-of-bans-and-reports

Also this is good to read the recommendations regarding Redis: https://docs.bunkerweb.io/latest/features/#redis-best-practices

[zynexiz]

is it the same problem as : #2674 ?

It seems to touch the same issue, so it could be the same. I think I saw that post while researching this problem.

[zynexiz]

Hi @zynexiz, this is likely because the datastore is saturated as @dbc-ca mentions it.

To still have them available (even when the datastore is saturated) I'd recommend using redis: https://docs.bunkerweb.io/latest/advanced/#persistence-of-bans-and-reports

Also this is good to read the recommendations regarding Redis: https://docs.bunkerweb.io/latest/features/#redis-best-practices

I don't think that's the issue, I saw that post to and tested to purge the valkey database, and tweaked the settings for it. Still the same issue.

[zynexiz]

is it the same problem as : #2674 ?

It seems to touch the same issue, so it could be the same. I think I saw that post while researching this problem.

I just checked my logs, and I could actually see a lot of errors mentioned in the same issue, so I would say that's the same problem I'm facing. I have configured valkey for BunkerWeb, but I can't find any way to check if it's actually working. I can't recall seeing any errors related to Valkey not working though.

2025/12/01 18:12:35 [error] 357207#357207: *439899 [METRICS] can't (safe) set requests_1 : no memory, context: ngx.timer 2025/12/01 18:12:35 [error] 357207#357207: *439899 [TIMER-1] metrics:timer() call failed : no memory, context: ngx.timer

[TheophileDiot]

Hi, there is an auto eviction rule that clears the datastore if the memory is saturated. Reports are the first ones to go (unless redis is configured) @zynexiz

[zynexiz]

Hi, there is an auto eviction rule that clears the datastore if the memory is saturated. Reports are the first ones to go (unless redis is configured) @zynexiz

Hard to imagine my memory is saturated here, have 35 GB RAM allocated to the VM, and using valkey. I also purged valkey at one point to test is that made some difference.

[zynexiz]

It seems to have something to do with Valkey being enabled. I changed USE_REDIS=yes to USE_REDIS=no and now things are starting to show up in the report page.

I checked that there's any actual data in Valkey, and there is 3655 lines in it, containing data. So I know that the connection itself works. This is a example of some of it;

3636. "metrics:badbehavior_counter_url_//media/wp-includes/wlwmanifest.xml:2"
3637. "metrics:badbehavior_counter_url_/recept/chili-pa-hogrev/:1"
3638. "metrics:badbehavior_counter_url_/wp-sitemap.xml:0"
3639. "metrics:badbehavior_table_increments_74.7.241.183:2"
3640. "metrics:badbehavior_counter_ip_134.199.197.153:0"
3641. "metrics:badbehavior_counter_ip_45.93.251.137:0"
3642. "metrics:badbehavior_counter_ip_81.230.115.45:0"

[dbc-ca]

I believe Redis does not replace the NGINX Lua shared dicts. My understanding is that BunkerWeb still needs the NGINX shared dicts as a hot in-memory buffer, and Redis is more like an extension / persistence layer on top of that, not a complete substitute. If the shared dict in front is too small and gets saturated, metric writes start to fail.

From what I see in the logs, BunkerWeb uses safe_set() for metrics, and if that’s correct, it means it does not evict existing entries like set() can do. When the dict is full, safe_set() just returns "no memory" and the new metric is dropped, which explains the “[METRICS] can't (safe) set … : no memory” messages.

[dbc-ca]

It seems to have something to do with Valkey being enabled. I changed USE_REDIS=yes to USE_REDIS=no and now things are starting to show up in the report page.

It is probably due toa systemctl restart bunkerweb that happened after the USE_REDIS and nginx restarting clears its workers lua dict memory

[TheophileDiot]

@zynexiz I'm talking about the datastore memory, there are limitations to not overflow the system's memory: https://docs.bunkerweb.io/latest/features/#__tabbed_1_6

[zynexiz]

I believe Redis does not replace the NGINX Lua shared dicts. My understanding is that BunkerWeb still needs the NGINX shared dicts as a hot in-memory buffer, and Redis is more like an extension / persistence layer on top of that, not a complete substitute. If the shared dict in front is too small and gets saturated, metric writes start to fail.

From what I see in the logs, BunkerWeb uses safe_set() for metrics, and if that’s correct, it means it does not evict existing entries like set() can do. When the dict is full, safe_set() just returns "no memory" and the new metric is dropped, which explains the “[METRICS] can't (safe) set … : no memory” messages.

I get that, but the data that's already in the dict should be shown if there are any? The view is kinda wonky, showing 50 entries renders "No Reports available", and changing it to 25 or 10 shows some, but pagination makes it brake to when showing next page etc. Is there any settings I can change here, or is it a code error?

Regarding restarting the service, it didn't help. Did that multiple times while having REEDIS=yes, only setting it to no started showing the entries again.

[oanqa]

i also having same issue, and i already use redis for the metrics