[ENHANCEMENTS] Logging Feature Enhance

@tobychui

Currently, we have a page called “Statistical Analysis” that displays traffic data. While this page is indeed an intuitive statistics page, it does not clearly show fine-grained data. For example, if a potential threat actor (IP: 1.2.3.4) visits the threat page multiple times, the website administrator may find it difficult to track this activity due to the lack of detailed access logs. I’m considering whether we could add a page that displays the access.log files for each website in a list format, with filtering capabilities. I believe this would be a helpful feature for site administrators. If @tobychui think this is a good suggestion, I’ll try using Copilot to implement this feature.

@Lvshujun0918

Hey @Lvshujun0918

The enhancement template exists for a reason. Please update your issue content so that it is more readable with details we need for internal discussion.

Is your feature request related to a problem? Please describe.
Currently, the “Statistical Analysis” page provides an intuitive overview of traffic data, but it lacks fine-grained access details. For example, if a potential threat actor (e.g., IP 1.2.3.4) repeatedly visits a sensitive page, the current interface does not make it easy for administrators to trace or investigate such activity due to the absence of detailed per‑request logs. This makes it difficult to identify abnormal patterns, correlate events, or conduct post‑incident analysis.

Describe the solution you'd like
I would like to add a new page that displays the raw access.log files for each website in a sortable, filterable list format. Administrators should be able to filter by IP address, time range, request path, status code, and other common log fields. The page should also support basic navigation (e.g., pagination or incremental loading) to handle large log files efficiently. This would give site administrators direct visibility into every request and help them quickly pinpoint suspicious activities.

Describe alternatives you've considered

Enhancing the existing “Statistical Analysis” page with a drill‑down view to show detailed logs for selected metrics.
Implementing an export function (e.g., CSV or JSON) from the current page so administrators can analyze logs offline.
Adding alerting rules based on request thresholds, rather than providing full log access.

However, I think these alternatives do not offer the same level of interactive exploration as a dedicated log‑listing page.

Additional context
If you agrees this is a useful addition, I plan to use Copilot to help implement this feature.

@tobychui

@tobychui Hey, I have updated my issue content, how do you like this?

Yeah the issue layout looks good, let see if the community has any comments on this. Usually new features are integrated in rc1 or rc2, I will come back to this issue later in the next release cycle to see how others think about this.

Btw, if you are using copilot, make sure you are using Opus 4.8 High or above for acceptable code quality.

OK. And I will try to review and test all AI code. If there is no other comments, maybe I will start to work about 3 days later and after testing them make a PR.

Plan:

Log Storage Structure

Logs are organized by site, with each website or proxy rule having its own dedicated subdirectory. Within each subdirectory, log files are further split by month (e.g., 2026-07.log).

UI Integration

A new standalone component page will be created for log viewing. It will be accessible via a new menu item in the sidebar, providing a full-featured interface without overloading existing pages.

Data Processing Layer

Log parsing, filtering, sorting, and pagination will be handled entirely on the backend through a new API endpoint. The frontend will only consume the API and render the results, ensuring efficient handling of large log files.

@tobychui

I found that now all log are writen to a single file:

log/
├── zr_2026-7.log

If it better to edit to like this (traffic in individual subfolder) :

log/
├── zr_2026-7.log
├── test.test/
│   └── zr_2026-7.log
├── app.example.com/
│   └── zr_2026-7.log
└── _default/  ->Unkown traffic
    └── zr_2026-7.log

And the traffic log may have some writting-method choice:

Option A (current): Write to both — maintains backward compatibility but doubles disk I/O and storage.
Option B: Write to per-origin subdirectories only, and have the log viewer reconstruct a "master view" by aggregating across all origin subdirectories on read.
Option C: Make it configurable — allow users to choose between dual-write, origin-only, or summary-only via a setting.
Option D: Keep a single log.
How do you like this? @tobychui

@Lvshujun0918

@Lvshujun0918 It seems you are new to building systems like this. Single log file with log rotation is the optimal way to do logging.

I recommend you to do some study on how other larger high concurrent systems implement logging before trying to change anything in this project.

OK, Now I know that. For I always use split access log in Nginx, I didn't know that about log of high concurrent system. Thx a lot!

@tobychui

AI is much quicker as I thought. I have made a pr now, but maybe you can review it until next rc1 or rc2. @tobychui

Navigation Menu

Repository navigation

[ENHANCEMENTS] Logging Feature Enhance #1243

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[ENHANCEMENTS] Logging Feature Enhance #1243

Description

Activity

tobychui commented on Jul 28, 2026

Lvshujun0918 commented on Jul 28, 2026

Lvshujun0918 commented on Jul 28, 2026

tobychui commented on Jul 28, 2026

Lvshujun0918 commented on Jul 28, 2026

Lvshujun0918 commented on Jul 28, 2026

Lvshujun0918 commented on Jul 28, 2026

tobychui commented on Jul 28, 2026

Lvshujun0918 commented on Jul 28, 2026

Lvshujun0918 commented on Jul 28, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions