Logging

FiniAC provides multiple logging systems to help you monitor server activity, debug issues, and investigate exploits. Server detection and event logs are sent to the web panel where they can be viewed and searched in real-time.
The event and trigger logs are also stored in local files within the FiniAC resource folder.

FiniAC Detection Logs

All FiniAC detection logs (connections, disconnections, anti-cheat detections) are available on the Logs page in the web panel. Logs can also be sent to Discord or third-party services via webhooks. Server events can be forwarded to external services using event drains.

Server Event Logs

Server event logs record all server-side events processed by FiniAC, such as entity creation and weapon damage events. Server events are viewable on the Event Logs page in the web panel and also stored in a local file on the server.

File: server-events.log in the FiniAC resource folder
Config Option: Server-event logs → File

Use Cases:

• Investigating cheater actions - See how cheaters spawned entities or damaged other players.
• Debugging false positives - Investigate why BadEntityCreating or EntityRatelimit detections were triggered and how to fix them.

Server Trigger Logs

File: server-triggers.log in the FiniAC resource folder
Config Option: EP: Log all events → Enabled

Server trigger logs record all triggers sent to the server from event-protected resources. This log captures every event that passes through Event Protection, allowing you to trace the full event flow.

Use Cases:

• Tracing dupe exploits - Follow the event chain that allows players to dupe items
• Investigating exploitable resources - Identify events that exploit vulnerabilities in open source resources
• Illegal item tracking - If a cheater managed to spawn in items/money, use trigger logs to track if any other players were given them

Event Statistics

File: events.stats.csv in the FiniAC resource folder
Config Option: EP: Log event stats → Enabled

Event statistics create a CSV file that records how many times each server event was triggered through Event Protection. The counters are flushed to disk once every minute, and only events that fired at least once during the interval are written. Counts are reset after each flush, so each row represents activity for the preceding minute only.

Format:

• Header row: timestamp,eventName,count
• Data rows: one row per event name that fired during the interval
• timestamp is an ISO 8601 UTC timestamp of the flush
• Rows are written sorted alphabetically by event name within each flush
• Only events passing through Event Protection are counted

Use Cases:

• Server optimization - Identify events being triggered excessively
• Performance debugging - Pinpoint events that may be causing lag or backpressure
• Event monitoring - Track event volume patterns over time
• Exploit investigation - Spot unusual spikes in specific events that may indicate abuse

Example CSV:

timestamp,eventName,count
2024-11-20T14:30:00.000Z,esx:useItem,145
2024-11-20T14:30:00.000Z,ox_inventory:swapItems,89
2024-11-20T14:30:00.000Z,qb-shops:server:buyItem,23
2024-11-20T14:31:00.000Z,esx:useItem,152
2024-11-20T14:31:00.000Z,ox_inventory:swapItems,94
2024-11-20T14:31:00.000Z,qb-shops:server:buyItem,19

Analysis Tools

Open the CSV in Excel, Google Sheets, or use Python/R for advanced analysis. Pivoting on eventName makes it easy to chart per-event activity over time.

Log Rotation

All log files are automatically rotated when they reach 250 MB in size.

How it works:

1. When a log file reaches 250 MB, it is renamed to filename.rotated
2. A new empty log file is created with the original name
3. The next rotation replaces the old .rotated file

Example:

server-events.log (current, 150 MB)
server-events.log.rotated (previous, 250 MB)

File Replacement

Only one rotated file is kept. When the current log reaches 250 MB again, the old .rotated file is deleted and replaced with the newly rotated file.

Best Practices

• Keep logging active - Logging has minimal performance impact and it's useful to have all logs available for investigation when needed.
• Monitor log sizes and dates - Make sure the logs are being written correctly and not blocked by file permissions or similar.
• Use CSV stats for optimization - Review events.stats.csv to identify events that could be causing performance issues.

Troubleshooting

Logs Not Being Created

Issue: Log files are not appearing in the FiniAC resource folder.

Solutions:

1. Verify the config option is set to File or Enabled
2. Check FiveM server has write permissions to the resource folder
3. If there are existing log files delete them and try again. If there are no existing log files try creating them manually

Log Files Too Large

Issue: Log files consuming too much disk space.

Solutions:

1. Logs automatically rotate at 250 MB
2. Manually delete .rotated files if needed
3. Disable logs you don't actively use

CSV Not Recording Expected Events

Issue: events.stats.csv missing events you expected to see.

Solutions:

1. Only events handled by Event Protection are counted - events from non-protected resources are not included
2. Verify Event Protection is installed on the resource triggering the event
3. Confirm the event fired at least once during the one-minute interval - empty intervals do not produce rows
4. Check that EP: Log event stats is set to Enabled