PMM-14618 Ability to disable collectors for RDS MySQL, PG technology.

[JiriCtvrtka]

PMM-14618

FB: Percona-Lab/pmm-submodules#4377

[codecov]

Codecov Report

❌ Patch coverage is 60.00000% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 43.18%. Comparing base (d2ea72b) to head (16a09a7).

Files with missing lines	Patch %	Lines
managed/services/management/rds.go	60.00%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##               v3    #5424      +/-   ##
==========================================
- Coverage   43.21%   43.18%   -0.03%     
==========================================
  Files         413      413              
  Lines       42282    42288       +6     
==========================================
- Hits        18274    18264      -10     
- Misses      22139    22153      +14     
- Partials     1869     1871       +2     

Flag	Coverage Δ
admin	34.94% <ø> (ø)
agent	49.04% <ø> (-0.12%)	⬇️
managed	42.33% <60.00%> (-0.01%)	⬇️
vmproxy	72.41% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 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.

[JiriCtvrtka]

@copilot review

[Copilot]

@copilot review

Reviewed the current PR diff and did not find any critical issues that require code changes.

[ademidoff]

Two comments:

1. collector names are not validated (out of scope). This needs to be mentioned both in the code and in the docs
2. If a caller sends postgresql_disable_collectors together with engine = MYSQL, the field is silently ignored (and vice versa).

@JiriCtvrtka Do you think it's acceptable or should we add minimal validation for this case?

[JiriCtvrtka]

Two comments:

1. collector names are not validated (out of scope). This needs to be mentioned both in the code and in the docs
2. If a caller sends postgresql_disable_collectors together with engine = MYSQL, the field is silently ignored (and vice versa).

@JiriCtvrtka Do you think it's acceptable or should we add minimal validation for this case?

@ademidoff

1. It is not validated even on CLI. If we want to include it should be done for CLI and UI also together, so do we want to create ticket? Sure lets mention it in doc. I will add comment to code.

2. Do you think it is problem? Since it has prefix for disable_collectors fields with technology? It is ignored which is same behaviour right now for example to wrong collector name, silently ignored.

[ademidoff]

Two comments:

1. collector names are not validated (out of scope). This needs to be mentioned both in the code and in the docs
2. If a caller sends postgresql_disable_collectors together with engine = MYSQL, the field is silently ignored (and vice versa).

@JiriCtvrtka Do you think it's acceptable or should we add minimal validation for this case?

@ademidoff

1. It is not validated even on CLI. If we want to include it should be done for CLI and UI also together, so do we want to create ticket? Sure lets mention it in doc. I will add comment to code.
2. Do you think it is problem? Since it has prefix for disable_collectors fields with technology? It is ignored which is same behaviour right now for example to wrong collector name, silently ignored.

Reasonable, but if we want to be friendly, a lightweight warning log or a validation error would surface user mistakes earlier. This PR affects the API which is used by many, so letting them know of an unintentional mistake could be worth it.

[JiriCtvrtka]

Two comments:

1. collector names are not validated (out of scope). This needs to be mentioned both in the code and in the docs
2. If a caller sends postgresql_disable_collectors together with engine = MYSQL, the field is silently ignored (and vice versa).

@JiriCtvrtka Do you think it's acceptable or should we add minimal validation for this case?

@ademidoff

1. It is not validated even on CLI. If we want to include it should be done for CLI and UI also together, so do we want to create ticket? Sure lets mention it in doc. I will add comment to code.
2. Do you think it is problem? Since it has prefix for disable_collectors fields with technology? It is ignored which is same behaviour right now for example to wrong collector name, silently ignored.

Reasonable, but if we want to be friendly, a lightweight warning log or a validation error would surface user mistakes earlier. This PR affects the API which is used by many, so letting them know of an unintentional mistake could be worth it.

Warn messages added.