(aws-greengrass-log-manager): Incorrect Log Matching for Components with Similar Names

[t04glovern]

Describe the bug

There appears to be a bug in the AWS Greengrass Log Manager component. The component's default log configuration uses a regular expression to match component names, and it seems this is causing some logs to be misrouted. Specifically, when there are two components whose names are similar — such as com.devopstar.Robocat and com.devopstar.RobocatContainer — the logs for the latter are incorrectly being picked up by the former due to the regular expression matching the beginning of both names.

To Reproduce

1. Create two components with similar names, where one name is a prefix of the other. For example, com.devopstar.Robocat and com.devopstar.RobocatContainer.
2. Configure logging for com.devopstar.Robocat using the default logFileRegex option
3. Observe that logs generated for com.devopstar.RobocatContainer get forwarded to the log configuration for com.devopstar.Robocat

Environment

• OS: Rasbian 32bit
• JDK version: openjdk 11.0.18 2023-01-17
• Nucleus version: 2.10.1
• Log Manager version: 2.3.3

Additional context

This bug could potentially result in incorrect logging, with logs from one application mistakenly sent to another. While not necessarily catastrophic, it could lead to confusion when troubleshooting and auditing logs, as it isn't immediately obvious that logs from different applications are being mixed up. It's recommended that the regular expression be revised to ensure a more accurate matching of component names to their logs.

I am currently able to prevent this behaviour by setting the logFileRegex to something like the following: com\\.devopstar\\.Robocat(_\\d{4}_\\d{1,2}_\\d{1,2}_\\d{1,2}_\\d{1,2})?\\.log

[MikeDombo]

Thank you for submitting the issue, the default log regular expression is written in order to support multiple log file rotation schemes (ie, not every logger would add _year_month_day_hour_extra). And as you found, you are able to update the regex in order to fulfill your needs.

We will consider changing the default regular expression, but that change is technically a breaking change so we certainly would not make that change with a patch version release.

Thank you again for letting us know.