Improve error reporting when configured metrics are missing or invalid

[AnannyaMahajan]

Problem

When a metric is configured for a source but its metric definition is missing
or invalid, pgwatch currently emits limited or rate-limited warnings and skips
metric collection.

This makes it difficult for users to understand why certain metrics are not
being collected, especially in larger or dynamic configurations.

** Steps to reproduce**

1. Configure a source with a metric name that does not exist in metric definitions
2. Start pgwatch
3. Observe that metric collection is skipped with minimal or delayed logging

Current behavior

• Warnings are rate-limited and may not appear immediately
• Log messages do not always include enough context (source + metric)
• Users must inspect configuration or code to identify the root cause

Expected behavior

• Clear and immediate warning when a configured metric has no valid definition
• Log messages should include:
  • Source name
  • Metric name
  • Reason (missing definition, unsupported version, etc.)

Proposed improvement

Improve error reporting to:

• Emit clearer warnings when a metric definition is missing or invalid
• Include source and metric context in log messages
• Retain rate-limiting to avoid excessive log spam

** Environment**

• pgwatch version: current master
• OS: independent

[AnannyaMahajan]

I would like to work on this improvement and submit a PR if the approach is acceptable.

[pashagolub]

Would you please show us the exact log message?

[AnannyaMahajan]

Would you please show us the exact log message?

Sure. Here is an example of the current log output when a configured metric is missing or invalid.

ERROR metrics: failed to load metric definition "custom_metric_x"
ERROR metrics: skipping metric "custom_metric_x"

In practice, when multiple metrics are misconfigured, these messages repeat without indicating:

• which source the error belongs to
• which configuration file or preset caused it
• whether the metric was missing vs invalid

My proposal is to improve this by:

• including the source name
• clearly distinguishing between “metric not found” and “invalid metric definition”
• grouping related errors to reduce log noise

If needed, I can reproduce this again and provide a more complete log with context.
Please let me know if this direction makes sense before I proceed with a PR.

[pashagolub]

yeah, I can see. Indeed, would be good to make errors more clear! Thanks for reporting!