jerryshao opened a new issue, #13274:
URL: https://github.com/apache/gravitino/issues/13274
### Version
main branch
### Describe what's wrong
The main appender in `conf/log4j2.properties.template`,
`conf/gravitino-iceberg-rest-log4j2.properties.template`,
`conf/gravitino-lance-rest-log4j2.properties.template`, and the Helm charts
rolls at 10MB and daily, but its
archive name has no `%i`:
appender.rolling.filePattern =
${basePath}/${serverName}_%d{yyyyMMdd}.log.gz
Every 10MB roll in a day writes the same archive name and replaces the
previous archive, so a day's archive
holds only the last 10MB written. Related gaps:
- The audit appender has `%i` but no `fileIndex`, so
`DefaultRolloverStrategy` keeps at most 7 archives a day.
- The main and lineage `Delete` actions have no file name condition and
`maxDepth = 10`, so they delete any
file older than 30 days under the log directory, not only their own
archives.
- No log has a total size limit.
- The `.out` files written by `bin/*.sh start` are appended forever and
never rotated.
### Error message and/or stacktrace
No error. With a busy server, `logs/` holds one archive per day that covers
only a few seconds or minutes
of logs.
### How to reproduce
1. Start a server from the main branch tarball with `bin/gravitino.sh start`.
2. Write more than 10MB of logs in a day, for example with `rootLogger.level
= debug`.
3. `logs/` holds a single `gravitino-server_<date>.log.gz`, and it contains
only the last 10MB. The
earlier logs of that day are gone.
### Additional context
Proposed fix: add `%i` with `fileIndex = nomax`, scope each `Delete` to the
log's own archives, add a per-log
total size cap next to the 30-day age, and rotate `.out` files on start.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
