Move otel-collector-metrics to k8s-infra chart

[grandwizard28]

Background

There has been some confusion in the community regarding the role and placement of the otel-collector-metrics component. This discussion aims to address these concerns and propose a more logical organization of our collector components.

Current Issues

User Confusion

Recent feedback indicates that users are misunderstanding the purpose of otel-collector-metrics:

• In #147, a user expected that disabling k8s-infra would disable all collection functionality
• A Medium article incorrectly suggested that otelCollectorMetrics is responsible for general metrics ingestion
• In #445, a user is overriding otel-deployment of k8s-infra to enable prometheus collection
• If a user has more than 1 k8s cluster, the user would want to install SigNoz in one cluster and install k8s-infra in all clusters. With the current setup, it becomes impossible for the user to do prometheus-based scraping in clusters which do not have the SigNoz chart.

Architectural Misalignment

The current placement of otel-collector-metrics in the main SigNoz chart doesn't align with our architectural principles:

• The component's primary function is scraping Prometheus endpoints from pods with the signoz.io/scrape annotation
• This is fundamentally a cluster telemetry collection function, which aligns more with the k8s-infra chart's responsibilities
• The main SigNoz chart should focus on deploying SigNoz's core functionality, while k8s-infra handles collection

Proposed Solution

Component Migration

Move the otel-collector-metrics functionality to the otel-deployment component in the k8s-infra chart. otel-deployment already handles cluster-wide telemetry (such as k8sevents, k8sclustermetrics) and it makes sense to have it handle cluster-wide metric prometheus telemetry as well.

Security Posture

Consolidating privileged collection operations under otel-deployment reduces the number of components requiring elevated cluster access which improves the overall security posture