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

[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]

@ZPascal any chance you work on this PR?

[ZPascal]

@ZPascal any chance you work on this PR?

Hi @srebhan, I'll continue to work on the PR asap.

[srebhan]

If you find some time @ZPascal, please comment on my question about a separate aliyunrds plugin instead of extending this plugin...

[ZPascal]

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?

You're right that RDS and CMS are technically two separate Alibaba Cloud services. However, from a user experience perspective, introducing a dedicated aliyunrds plugin would likely create more confusion than value.

Users generally prefer to work with a smaller, more predictable set of integrations instead of managing many narrowly scoped plugins. Since CMS already acts as the unified monitoring layer across Alibaba Cloud products—including RDS—it is the most natural place for users to expect monitoring, metrics, and alarms to appear. Splitting RDS monitoring into a separate plugin would require users to understand internal service boundaries within Alibaba Cloud, which is something most users shouldn’t need to worry about.

Keeping everything within the CMS plugin avoids fragmentation, reduces cognitive load, and makes the system easier to navigate. It also aligns with Alibaba Cloud’s own model, where CMS is positioned as the central service for metrics collection and monitoring across resources.

For these reasons, adding a dedicated aliyunrds plugin would ultimately be less intuitive and more cumbersome for users.

[ZPascal]

@srebhan Do you want me to continue with the current adjustments in the CMS plugin, or should I pause and explore handling RDS differently?

[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 5.18 % for linux amd64 (new size: 313.7 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]

Hi @srebhan, I've adapted the code and added new tests. Can you please restart the integration test? The requested Markdown changes are not related to this pull request and the result of the GH action version update.