fix(detector-aws): extract full container ID from ECS Fargate cgroup

[seongpil0948]

Which problem is this PR solving?

AWS ECS Fargate changed their cgroup naming convention to /ecs/<taskId>/<taskId>-<containerId> format. The existing container ID extraction logic only takes the last 64 characters, causing truncation in the middle of the taskId and resulting in incomplete container IDs like 438aa1824ca4058bdcab/c23e5f76c09d438aa1824ca4058bdcab-1234678 instead of the expected full c23e5f76c09d438aa1824ca4058bdcab-1234678.

This breaks compatibility with observability vendors like DataDog that require the complete taskId-containerId format for proper container identification.

Short description of the changes

• Enhanced container ID extraction: Extract the last path segment from cgroup paths instead of truncating to 64 characters
• New _extractContainerIdFromLine() method: Handles various container runtime formats (Docker, containerd, CRI-O) with proper prefix/suffix removal
• Flexible validation: Uses permissive regex pattern [a-zA-Z0-9\-_]+ to support real-world container ID formats
• Backward compatibility: Maintains fallback to original 64-char logic for legacy formats
• Comprehensive tests: Added test cases covering DataDog compatibility scenarios and edge cases

Supported formats:

• New ECS Fargate: /ecs/<taskId>/<taskId>-<containerId> → taskId-containerId
• Docker: /docker/containerid.scope → containerid
• Containerd: system.slice:cri-containerd:containerid → containerid
• UUID format: /uuid/34dc0b5e-626f-2c5c-4c51-70e34b10e765 → 34dc0b5e-626f-2c5c-4c51-70e34b10e765

Fixes #2455

[pichlermarc]

@seongpil0948 looks like this PR is in draft, is this intentional? 🤔

[seongpil0948]

@seongpil0948 looks like this PR is in draft, is this intentional? 🤔

i'm sorry to late .. 🫡

[david-luna]

@seongpil0948

There has been a re-organization of the packages in this repository, see #2928

Would you mind to sync your PR with main branch?

[dyladan]

Looks like this needs reviews. The conflicts are just from package naming. @jj22ee can you please take a look?

[seongpil0948]

i worked on a new branch based on new structured packages
thanks all

[codecov]

Codecov Report

Attention: Patch coverage is 96.66667% with 1 line in your changes missing coverage. Please review.

Project coverage is 89.09%. Comparing base (de22600) to head (f3db796).
Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
...ource-detector-aws/src/detectors/AwsEcsDetector.ts	96.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2855      +/-   ##
==========================================
+ Coverage   89.02%   89.09%   +0.06%     
==========================================
  Files         188      188              
  Lines        9223     9251      +28     
  Branches     1900     1909       +9     
==========================================
+ Hits         8211     8242      +31     
+ Misses       1012     1009       -3     

Files with missing lines	Coverage Δ
...ource-detector-aws/src/detectors/AwsEcsDetector.ts	97.14% <96.66%> (-0.18%)	⬇️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jj22ee]

Hi @seongpil0948, wondering why not opt to use a more automated regex based approach (as mentioned in the issue, something like in DataDog/dd-trace-js#1176, which is now here)?

IMO that would help alleviate some of the burden in the current PR which adds logic to "track and remove known prefixes", execute step-by-step extraction+sanitizing of the lastSegment, and perform two sanity validations based on the length of the extracted segment based on what we think is reasonable. Regex would be more "straight to the point" at a glance, easier to maintain.