sampctl
sampctl copied to clipboard
Add logging output option
This revives #6 with a more declarative and configurable approach to logging.
My hatred of how SA:MP handles logging is documented in the Readme of samp-nolog. Now that this plugin is stable and ready to use, sampctl should provide some tools for enhancing the logging output of SA:MP.
My first thoughts are to add a logging
section to runtime
which would contain an option to disable server_log.txt
which would be shorthand for adding nolog
to the plugins list. This section would also contain some options for how log files are handled and rotated.
"logging": {
"enable": true, // adds nolog and activates sampctl's logging manager
"mode": "file" // see below
"directory": "logs", // directory to store log files
"filename": "%Y-%m-%d" // date based rotation, could add %H to this to make a new log file for hour-level granularity
}
The mode
setting could also support logging aggregators such as syslog. But maybe this would be left to the user to handle via their system configuration. So far, undecided.
Seriously, I would think more modes for other logging implementations could be done, perhaps implemented directly into sampctl or in another way. I do use https://github.com/maddinat0r/samp-log not just for MySQL errors but also the main gamemode logging, which ranges from chats, commands and other stuff.
Something like
{
"mode": "log-core"
}
could be useful, but this is only an idea, perhaps there's a less intrusive way to implement such a thing.
The log-core library will have logging rotation based on date and size in the near future, so there might be some conflict there when two programs attempt to rotate logs (sampctl and log-core).
Yeah I wouldn't advise users use both features at once. However, I would like to see the option to disable log-core writing to stdout.
The reason for that would be, all the logs generated by log-core could go to their files and anything else that's captured in stdout could be handled by this system.
log-core never writes to stdout (it writes to stderr on a detected server crash though), and I don't really plan on adding that feature, so no conflict there 👍
But does it call logprintf
to print logs to the console?
No, it doesn't have access to that function. I was planning on adding logprintf
redirection into my normal log plugin though, so that every logprintf
call gets logged through log-core. Basically your nolog plugin, but instead of writing to stdout, it uses log-core to write into a log file.
Oh okay, that's perfect than! And hooking logprintf
also sounds useful, depending on the user's needs.