fix: support metrics collection with alternate report storage

[rzala]

Description

Fixes #2610

This PR adds support for Prometheus metrics collection when alternate report storage (filesystem-based) is enabled. Previously, enabling alternateReportStorage.enabled: true would cause all metrics like trivy_image_vulnerabilities to stop working because the metrics collector only read from Kubernetes CRDs.

Changes

• Added StorageReader interface to abstract storage backend operations
• Implemented CRDStorageReader for reading from Kubernetes CRDs (existing default behavior)
• Implemented FilesystemStorageReader for reading from alternate storage filesystem
• Updated ResourcesMetricsCollector to use the StorageReader abstraction
• Added comprehensive unit tests for both storage backends and edge cases

Impact

• ✅ Backward compatible - No breaking changes, CRD-based metrics work exactly as before
• ✅ Dual-mode support - Metrics now work with both CRD and filesystem storage
• ✅ All report types supported - VulnerabilityReport, ExposedSecretReport, ConfigAuditReport, RbacAssessmentReport, InfraAssessmentReport, ClusterComplianceReport
• ✅ Production ready - Robust error handling, logging, and graceful degradation

Testing

Added comprehensive unit tests in pkg/metrics/storage_reader_test.go:

• Tests for CRD-based collection (validates backward compatibility)
• Tests for filesystem-based collection
• Edge case testing (missing directories, corrupt files, permissions)
• Backend selection tests

How to Test

With CRD Storage (default):

1. Deploy trivy-operator with default configuration
2. Verify metrics endpoint returns data

With Alternate Storage:

1. Enable alternate storage: alternateReportStorage.enabled: true
2. Configure PVC-based storage
3. Verify metrics endpoint still returns data
4. Confirm metrics match report contents

Checklist

• Follows conventional commit format
• References issue Alternate Report Storage doesn't provides metrics #2610
• Includes comprehensive unit tests
• Maintains backward compatibility
• No changes to CRD definitions
• No changes to metrics output format

[CLAassistant]

All committers have signed the CLA.

[Sydney-MF]

Any idea on when this PR would get merged? Thanks:)

[afdesk]

@Sydney-MF thanks for the ping
I'll take a look tomorrow

[Sydney-MF]

@afdesk Any updates on this?:) really appreciate you for taking the time to take a look at this by the way

[afdesk]

@afdesk Any updates on this?:) really appreciate you for taking the time to take a look at this by the way

i'm on it right now
could you pls fix linter errors?

[Sydney-MF]

i'm on it right now could you pls fix linter errors?

It's not my PR so I'm not so sure if I should just go about it and modify it 😅

[rzal]

Will have a look at the linting errors soon

[afdesk]

Hi guys again! thanks for your efforts and contribution! I need more time to investigate it.

I have some concerns about performance here - StorageReader re-reads folders very ofter.
We have to evaluate it

[Sydney-MF]

Hi guys again! thanks for your efforts and contribution! I need more time to investigate it.

I have some concerns about performance here - StorageReader re-reads folders very ofter. We have to evaluate it

No worries, please keep us updated since there's quite an issue with the etcd limit issue so the only way to make Trivy Operator work was for us to use alternateStorage, but then we lose the ability to see the metrics which is a big part of this tool's feature. But once again thank you for taking the time to take a look at this PR:)

Also thank you @rzala @rzal for the PR.

[rzala]

@Sydney-MF thanks for the interest and for nudging this along!

@afdesk linting errors have been fixed in the latest push. Regarding the performance concern around frequent directory re-reads — happy to look into adding a file-watcher or in-memory cache with TTL if that's the preferred direction. Let me know what approach you'd like and I'll update the PR.

[baznikin]

Maybe fine-tune this feature if disk scanning really became a problem? We're evaluating Trivy operator and only way we can run it is 1h ttl on CRD resources and limiting targets and scanners to very narrow set.