CloudWatch not resolving symlinks

Question

I was trying to configure a CloudWatch agent for a customer that wanted to host log files on a network drive.
I was referencing the path as it was symlinked on the machine. The path had weird spacing however I verified that the characters/pathing were of no problem on our development environment. The pathing was in the format below in our Agent config:
```
"file_path": "C:\_Company Name\06 - AWS Monitoring\Monitoring - East 2 Monitor\logs\rabbit.json"
```
Whenever the agent would load this file it was unable to find it existing on the machine, it then tried to locate it on the network but when it tried to locate it joined the pathing weird, something along the lines of such: 
```
C:\_Company Name06 - AWS Monitoring
```
Completely omitting the specified slashes in the configuration. We first thought this was an issue with the agent version (we were using 1.24x) and so we rolled out an update to the most recent 1.3 release. After the update, the issue still persisted.
I tried symlinking a much simpler folder to the logs files labeled with a path like so:
```
"file_path": "C:\East2Logging\logs\rabbit.json"
```
And the same issue would occur, it would fail to find it locally and resolve the pathing in the same way as before, ignoring the symlink and trying to resolve as `_Company Name06 - AWS Monitoring` once again. We ended just entering the UNC path with the hostname to finally get it to create the log stream. This fixed our issue.

The problem is solved by the UNC path but what could we have done differently here? What about a standard symlinked file not on a network drive, is CloudWatch simply unable to resolve that path or is this a bug?

re:Post Agent · Answer

The issue you encountered is related to how the CloudWatch agent handles symlinks, particularly with Windows paths. The CloudWatch agent has limitations when dealing with symlinked directories, especially those pointing to network locations.

When the CloudWatch agent encounters a symlink on Windows, it doesn't properly follow the symlink to the target location. Instead, it attempts to interpret the path literally, which causes the path resolution problems you observed where slashes were being omitted or paths were being incorrectly joined.

For local symlinks (not pointing to network drives), the CloudWatch agent may still have similar issues. The agent doesn't fully support symlink resolution by design, which is why you encountered these problems.

Your solution of using the direct UNC path (\hostname\share\path) was the correct approach. By providing the actual network path rather than a symlinked reference, you bypassed the symlink resolution issue entirely. This is the recommended approach when monitoring log files located on network drives.

For standard symlinked files not on network drives, you might still encounter similar issues. If you need to monitor such files, consider:

1. Using the actual target path instead of the symlink path in your CloudWatch agent configuration
2. Creating a copy of the logs in a local directory that the CloudWatch agent can directly access
3. Using a different log collection method that better supports symlinks

The CloudWatch agent documentation doesn't explicitly mention symlink limitations, but this behavior is consistent with how the agent processes file paths, particularly on Windows systems.  
**Sources**  
[How do I properly configure my cloudwatch.config file after upgrading from Amazon Linux 2 v4.5.3 to Amazon Linux 2023 v5.1.8? | AWS re:Post](https://repost.aws/questions/QUkTtDxZFVSNOdq43CZ7xMiQ/how-do-i-properly-configure-my-cloudwatch-config-file-after-upgrading-from-amazon-linux-2-v4-5-3-to-amazon-linux-2023-v5-1-8)

CloudWatch not resolving symlinks

Add your answer

Relevant content