LOGLEVEL - Detailed description

Overview

Parameter:LOGLEVEL
Category: Logging
Default value: 1 (Warnings)
Product: eTASK.Other (Logging)

What does this parameter do?

This parameter controls the level of detail with which the system writes information to the application log. It determines which types of events are logged—ranging from critical errors to detailed debug information for developers.

The setting acts as a filter: The higher the value, the more information is logged.

What is this parameter used for?

• Error analysis: Recording system errors for later investigation

• Maintenance and monitoring: Detecting warnings before they become problems

• Debugging: Detailed information for troubleshooting during development or complex issues

• Compliance and audit: Traceable documentation of system events

• Performance monitoring: Identification of performance bottlenecks

• Security monitoring: Detection of suspicious activity

Technical Details (for Administrators)

Format: Integer (0-3)
Default value: 1 (Warnings)

Valid values and their meanings:

Important notes:

• Cumulative: Higher levels automatically include all lower levels (e.g., 2 also displays warnings and errors)

• Applies system-wide: Affects the entire eTASK.FM portal

• Immediate effect: Changes take effect without a restart

• Log location: Configurable via LOGFILENAME (default: etask_log) in the directory /neon/Log.Etask

• Email notification: For error levels, automatic email notification can be EXNOTIFYEMAILFLAG can be enabled

• Log retention: Controllable via KEEPLOGSDAYS parameter

Interaction with other parameters:

• SENDLOGERRORMAIL / EXNOTIFYEMAILFLAG: Email notification at error level

• EXRECIPIENTMAIL: Recipient address for error emails

• KEEPLOGSDAYS: Retention period for log files

• LOGFILENAME: Name of the log file (default: etask_log)

When should you change this value?

Increase value (to 2 or 3) if:

• Troubleshooting is required: A problem occurs sporadically and you need more details

• New features are being tested: To monitor new functionality during rollouts

• Performance issues need to be analyzed: Detailed information on runtime is required

• Support requests are being handled: Customer support needs detailed logs

• Development environment: Developers are working on new features

• After updates/upgrades: Monitor the system after major changes

Decrease value (to 0) if:

• Log files become too large: Storage space is limited

• Performance optimization is needed: Logging causes measurable system load

• Only critical errors are relevant: The production system is running stably

• Compliance requires minimal logs: Data protection requirements

Set to 1 (default) if:

• Normal operation is running without any particular problems

• A balance between detail and performance is desired

• Warnings should be detected early before they turn into errors

Important notes

1. Monitor log size at high levels
   LOGLEVEL=3 (Debug) can generate several gigabytes per day in production environments. Ensure that sufficient storage space is available and that old logs are automatically archived/deleted.

2. Performance impact at debug level
   LOGLEVEL=3 can reduce system performance, as every operation is logged in detail. Use the debug level only temporarily!

3. Security: Sensitive data in logs
   Higher log levels may record sensitive information (SQL queries, user data, API keys). Observe GDPR requirements regarding personal data, access restrictions on log files, and regular deletion of sensitive logs.

4. Temporary increase for debugging
   Best practice: Increase the value 3 only for short periods (hours, max. days) and then set it back to 1 .

5. Log level is not retroactive
   Changes only affect future events. Logs that have already been written remain unchanged.

6. Coordination in Teamwork
   Inform your team when you change the log level—others might be relying on specific log entries or be surprised by the increased volume of logs.

Security

Does changing this parameter affect security?

Yes, this parameter is security-relevant—albeit indirectly.

Security benefits (PRO higher log levels):

• Attack detection: Suspicious activities are logged in greater detail

• Forensics: In the event of security incidents, attacks can be better traced

• Compliance: Meeting audit requirements (e.g., ISO 27001, GDPR)

• Early warning: Alerts highlight potential security issues before they become critical

• Traceability: Changes and access are documented

Security risks (vs. higher log levels):

• Sensitive data in logs: SQL queries, personal data

• Log files as a target: Extensive logs contain valuable information for attackers

• GDPR issues: Excessive logging of personal data may violate data protection regulations

• Denial-of-service via logging: Attackers could intentionally trigger log flooding

• Unprotected logs: When log files are unencrypted or have incorrect access permissions

Recommendations from leading security organizations:

OWASP (Open Web Application Security Project): - Log security events (login attempts, authorization errors) - Use structured logging - Do not log passwords or account data

BSI (Federal Office for Information Security): - Adjust log levels to security requirements - Regularly review logs for anomalies - Secure storage and access control

Conclusion: The parameter itself is not directly security-critical, but the handling of the generated logs has significant security implications. Increase the log level for security monitoring, protect log files with access permissions, avoid debug levels in production, and implement log rotation.

Practical example

Scenario 1: Troubleshooting a sporadic issue

Initial situation:
Users report that an error message occasionally appears when saving jobs. With LOGLEVEL=1 , only general warnings are visible, and the cause remains unclear.

Configuration:

1 LOGLEVEL = 3

After the change:

• The system now logs every step when saving a job

• You can view details: SQL commands, operation duration, validations, stack traces

• After 2 days, the logs show: A database timeout occurs with certain job values

• The vendor identifies a missing index on a table

• Problem solved! You LOGLEVEL back to 1
  You can view details: SQL commands, operation duration, validations, stack traces

Result:
Debug logging generated approx. 15 GB in 2 days – important lesson: Always increase temporarily, then reset!

Scenario 2: Optimizing the production environment

Initial situation:
The production system has been running with LOGLEVEL=2 (Information) for 3 years. The log files are huge (200 GB), and the daily backup takes too long. Over 90% of the entries are purely informational messages with no added value.

Configuration:

1 LOGLEVEL = 1

After the change:

• Log volume decreases by 85% (from 2 GB/day to 300 MB/day)

• Backups are 45 minutes faster

• Important warnings and errors are still logged

• Log files are clearer and easier to search

• Storage costs decrease by approximately €500/year

Result:
Optimal balance between detail and efficiency—without losing important information.

Scenario 3: Investigating a security incident

Initial situation:
The security department reports suspicious login attempts. With LOGLEVEL=0 (errors only), only failed logins are visible, but no details.

Configuration:

1 LOGLEVEL = 2 

After the change:

• You now see: successful and failed login attempts, IP addresses, timestamps, affected user accounts

• The logs reveal a pattern: a brute-force attack from 15 IP addresses

• You block the IPs and enable additional security measures

• After 1 week, you revert to 1

Result:
Security incident successfully analyzed and mitigated – log level is a valuable tool for security monitoring!

Recommended setting

For production environments:1(Warning)

Reasoning: - Balanced ratio between detail and performance - Warnings are detected before they become problems - Critical errors are fully logged - Log size remains manageable (typically 200–500 MB/day) - Minimal performance impact (<1%)

This is the default and optimal for most scenarios.

For development/test environments:2 or 3 (Information/Debug)

Reasoning: - Developers receive detailed information for debugging - New features can be closely monitored - Performance is less critical than in production - Log size is acceptable with a short retention period

Tip: Occasionally switch to 1 to simulate production-like conditions.

Temporarily for troubleshooting:3(Debug)

Reason: - Maximum detail for complex problem analysis - Full traceability of all system operations - ONLY for short periods (hours to a few days) - Afterward, BE SURE to reset to 1 reset

Checklist for debug level: 1. Define time window (e.g., "only today from 9 a.m. to 5 p.m.") 2. Check storage space (at least 10 GB free) 3. Enable log rotation 4. Set a reminder to reset 5. Inform the team

For minimal logging:0(Error)

Rationale: - Minimal log size (~50 MB/day) - Maximum performance - Only critical errors visible - Warnings are ignored - Troubleshooting is more difficult

Use only if: - Storage space is extremely limited - System is proven to run very stably - Other monitoring tools are in use

Not recommended for normal production environments!

Summary:

Rule of thumb: If you're unsure, use 1 (Warning)—that’s almost always the right choice.