Log Management

From Server rental store
Revision as of 16:25, 15 April 2025 by Admin (talk | contribs) (Automated server configuration article)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
  1. Log Management

This article details the configuration of log management for our MediaWiki 1.40 installation. Effective log management is crucial for troubleshooting, security auditing, and performance monitoring. This guide will cover log locations, configuration options within `LocalSettings.php`, and considerations for log rotation. It is intended for system administrators and power users responsible for maintaining the wiki server.

Log File Locations

MediaWiki generates several log files that record different types of events. Knowing their locations is the first step in effective log management. These locations are configurable, but the defaults are as follows:

Log File Description Default Location
error.log Records PHP errors, exceptions, and critical system messages. `Template:SERVER PATH/mw-config/error.log`
debug.log Contains detailed debugging information (only enabled with `$wgDebug` set to true). `Template:SERVER PATH/mw-config/debug.log`
access.log Records all incoming HTTP requests (requires web server configuration - see below). Determined by Web Server Configuration (e.g., Apache or Nginx)
watchlist.log Records changes made to pages on users' watchlists. `Template:SERVER PATH/mw-config/watchlist.log`
archive.log Records archive operations performed on pages. `Template:SERVER PATH/mw-config/archive.log`

Note: `Template:SERVER PATH` represents the root directory of your MediaWiki installation. This is defined in your web server configuration.

Configuring Logging in LocalSettings.php

The behavior of MediaWiki logging is primarily controlled through settings in the `LocalSettings.php` file. Here's a breakdown of key configuration options:

Configuration Variable Description Possible Values
`$wgDebug` Enables detailed debugging output. Use with caution in production environments. `true` or `false`
`$wgShowExceptionDetails` Controls whether full error details are displayed to users (use only for development/testing). `true` or `false`
`$wgLogErrors` Enables/disables writing PHP errors to `error.log`. `true` or `false`
`$wgParserCacheType` Affects logging of parser cache misses. `CACHE_NONE`, `CACHE_DB`, `CACHE_MEMCACHED`, `CACHE_REDIS`
`$wgEnableMailerWarning` Enables/disables warnings related to email sending. `true` or `false`
`$wgEmergencyContact` Sets an email address for emergency contact information displayed on error pages. A valid email address string.

Example configuration snippet within `LocalSettings.php`:

```wiki $wgDebug = false; $wgLogErrors = true; $wgShowExceptionDetails = false; $wgEmergencyContact = '[email protected]'; ```

Remember to clear the MediaWiki cache after making changes to `LocalSettings.php`. You can do this by deleting the cache directory or by accessing `https://yourwiki/w/index.php?action=purge&title=Special:AllPages` and letting the system rebuild the cache. See Manual:Configuration settings for more details.

Web Server Logging and Access.log

MediaWiki itself does *not* directly handle access logging (recording every HTTP request). This responsibility falls to your web server (Apache, Nginx, etc.). You *must* configure your web server to generate access logs.

  • **Apache:** Configure `VirtualHost` directives to specify the `CustomLog` directive. See Apache documentation for details.
  • **Nginx:** Use the `access_log` directive within the `server` block. See Nginx documentation for details.

The format of the access log is also configurable within the web server. Common formats include the combined log format. These logs are essential for identifying traffic patterns, detecting potential attacks, and analyzing website performance. Reviewing these logs often requires tools like `grep`, `awk`, or dedicated log analysis software.

Log Rotation

Log files can grow rapidly, consuming disk space. Log rotation is the process of archiving older log files and creating new ones. This is *essential* for maintaining a healthy server.

Here's a recommended log rotation strategy:

Log File Rotation Frequency Retention Period Tools
error.log Daily 7 days `logrotate`
debug.log (if enabled) Daily 1 day `logrotate`
access.log Daily 30 days `logrotate` or web server specific tools
watchlist.log Weekly 4 weeks `logrotate`
archive.log Weekly 4 weeks `logrotate`

On most Linux systems, the `logrotate` utility is used for log rotation. A sample `logrotate` configuration file for `error.log` might look like this:

``` /path/to/mw-config/error.log { 

   daily
   rotate 7
   missingok
   notifempty
   create 644 wikiuser wikigroup

} ```

Replace `/path/to/mw-config/error.log`, `wikiuser`, and `wikigroup` with the appropriate values for your system. See Logrotate documentation for more information.

Further Considerations

  • **Centralized Logging:** Consider using a centralized logging system like ELK Stack (Elasticsearch, Logstash, Kibana) or Graylog to collect and analyze logs from multiple servers in a single location.
  • **Security Auditing:** Regularly review log files for suspicious activity, such as failed login attempts or unauthorized access.
  • **Monitoring:** Set up monitoring alerts to notify you of critical errors or unusual log activity. Link to Monitoring tools.
  • **Permissions:** Ensure that log files are properly protected with appropriate file permissions.
  • **Database Logging:** MediaWiki also logs changes to the database via the Special:Log pages, which provide a user-friendly interface for reviewing these events.
  • **Cron Jobs:** Review Cron Jobs as these can also generate log entries.


Manual:Configuration settings Help:Logging Special:Log Apache documentation Nginx documentation Logrotate documentation ELK Stack Graylog Monitoring tools Help:Watchlist Help:Revision history Help:AbuseLog Manual:Database Manual:Caching Manual:Maintenance Special:AllPages Help:Search


Intel-Based Server Configurations

Configuration Specifications Benchmark
Core i7-6700K/7700 Server 64 GB DDR4, NVMe SSD 2 x 512 GB CPU Benchmark: 8046
Core i7-8700 Server 64 GB DDR4, NVMe SSD 2x1 TB CPU Benchmark: 13124
Core i9-9900K Server 128 GB DDR4, NVMe SSD 2 x 1 TB CPU Benchmark: 49969
Core i9-13900 Server (64GB) 64 GB RAM, 2x2 TB NVMe SSD
Core i9-13900 Server (128GB) 128 GB RAM, 2x2 TB NVMe SSD
Core i5-13500 Server (64GB) 64 GB RAM, 2x500 GB NVMe SSD
Core i5-13500 Server (128GB) 128 GB RAM, 2x500 GB NVMe SSD
Core i5-13500 Workstation 64 GB DDR5 RAM, 2 NVMe SSD, NVIDIA RTX 4000

AMD-Based Server Configurations

Configuration Specifications Benchmark
Ryzen 5 3600 Server 64 GB RAM, 2x480 GB NVMe CPU Benchmark: 17849
Ryzen 7 7700 Server 64 GB DDR5 RAM, 2x1 TB NVMe CPU Benchmark: 35224
Ryzen 9 5950X Server 128 GB RAM, 2x4 TB NVMe CPU Benchmark: 46045
Ryzen 9 7950X Server 128 GB DDR5 ECC, 2x2 TB NVMe CPU Benchmark: 63561
EPYC 7502P Server (128GB/1TB) 128 GB RAM, 1 TB NVMe CPU Benchmark: 48021
EPYC 7502P Server (128GB/2TB) 128 GB RAM, 2 TB NVMe CPU Benchmark: 48021
EPYC 7502P Server (128GB/4TB) 128 GB RAM, 2x2 TB NVMe CPU Benchmark: 48021
EPYC 7502P Server (256GB/1TB) 256 GB RAM, 1 TB NVMe CPU Benchmark: 48021
EPYC 7502P Server (256GB/4TB) 256 GB RAM, 2x2 TB NVMe CPU Benchmark: 48021
EPYC 9454P Server 256 GB RAM, 2x2 TB NVMe

Order Your Dedicated Server

Configure and order your ideal server configuration

Need Assistance?

⚠️ *Note: All benchmark scores are approximate and may vary based on configuration. Server availability subject to stock.* ⚠️

Retrieved from "https://serverrental.store/index.php?title=Log_Management&oldid=1915"