feat: Add the RDS performance and generic metrics option

[ZPascal]

Description

This PR extends the aliyuncms input plugin to support additional metric data sources beyond Cloud Monitor Service (CMS). Specifically, it adds support for collecting performance metrics directly from Alibaba Cloud's Relational Database Service (RDS) API.

Changes

• Added new metric_services configuration option to specify which metric services to query (defaults to ["cms"])
• Implemented RDS performance metrics collection via DescribeDBInstancePerformance API
• Refactored metric gathering to abstract data source selection between CMS and RDS
• Improved timestamp parsing to handle different formats from various APIs
• Enhanced code organization with extracted constants and helper functions
• Updated documentation with new configuration options

Key Features

• Multi-source metrics: Support for both CMS and RDS data sources
• Flexible configuration: Users can specify metric_services = ["cms", "rds"] to enable RDS metrics
• Backward compatible: Defaults to CMS-only behavior if metric_services is not configured
• RDS-specific handling: Parses compound metrics (e.g., CPUUsage&IOPS) and normalizes them into separate datapoints

Configuration Example

[[inputs.aliyuncms]] 
project = "acs_rds_dashboard" metric_services = ["cms", "rds"]
  [[inputs.aliyuncms.metrics]] 
  names = ["CPUUtilization", "MemoryUsage"] 
  dimensions = '{"instanceId": "rm-xxxxx"}'

Testing

• Added unit tests for RDS client mock
• Added test cases for single and compound metric parsing
• Added error handling tests for malformed responses
• Note: I will adapt the remaining unit tests once the general functionality is approved

Related Issues

Checklist

• Updated README.md with new configuration option
• Updated sample.conf with new configuration option
• Added initial unit tests for new functionality
• Complete unit test coverage (pending approval of approach)
• Code follows project style guidelines
• Backward compatible with existing configurations
• No AI generated code was used in this PR

Breaking Changes

None. The change is fully backward compatible with existing configurations.

Notes:

• The RDS metrics API has a different structure than CMS, requiring specialized parsing logic
• Compound metrics from RDS (separated by &) are automatically split into individual datapoints
• Unit tests are partially complete and will be fully updated once the general approach is confirmed

[telegraf-tiger]

Download PR build artifacts for linux_amd64.tar.gz, darwin_arm64.tar.gz, and windows_amd64.zip.
Downloads for additional architectures and packages are available below.

⚠️ This pull request increases the Telegraf binary size by 4.60 % for linux amd64 (new size: 311.9 MB, nightly size 298.2 MB)

📦 Click here to get additional PR build artifacts

Artifact URLs

. DEB	. RPM	. TAR . GZ	. ZIP
amd64.deb	aarch64.rpm	darwin_amd64.tar.gz	windows_amd64.zip
arm64.deb	armel.rpm	darwin_arm64.tar.gz	windows_arm64.zip
armel.deb	armv6hl.rpm	freebsd_amd64.tar.gz	windows_i386.zip
armhf.deb	i386.rpm	freebsd_armv7.tar.gz
i386.deb	ppc64le.rpm	freebsd_i386.tar.gz
mips.deb	riscv64.rpm	linux_amd64.tar.gz
mipsel.deb	s390x.rpm	linux_arm64.tar.gz
ppc64el.deb	x86_64.rpm	linux_armel.tar.gz
riscv64.deb		linux_armhf.tar.gz
s390x.deb		linux_i386.tar.gz
		linux_mips.tar.gz
		linux_mipsel.tar.gz
		linux_ppc64le.tar.gz
		linux_riscv64.tar.gz
		linux_s390x.tar.gz

[ZPascal]

@srebhan Can you please check the PR?

[ZPascal]

Hi @srebhan, should I write more unit tests before the review can start?

[srebhan]

Thanks for your contribution @ZPascal! I have some small comments in the code from skimming over the PR.

However, I wonder if RDS and CMS are not two different services!? Wouldn't it be hard for a user to find the RDS part as you probably won't expect it to be in CMS, would you?
Should we add a aliyunrds plugin?

Furthermore, please reduce the amount of changes, especially in the gatherMetric function! No unnecessary renames or restructuring please as this makes it hard to review this PR!

[srebhan]

Can we please use the strings instead of declaring them as constants? This pattern is only helpful if the declared const adds information e.g. when declaring const ErrorNotFound = 5. This is not the case here so this only adds lines and makes it harder to find out which value is actually used in the code.

[srebhan]

This does not add any information, please remove!

[srebhan]

Why do you need this indirection? Please unroll this function!