Feature Request: Add metric to monitor ResourceGroup object size against etcd limits
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- go, kubernetes
- Área
- observability
Línea de trabajo
Comience localizando la implementación existente de ResourceGroup y las métricas declared_resources y resource_count. Determine cómo debería definirse el tamaño de la ResourceGroup serializada o una estimación de la proximidad a un límite, y luego identifique las pruebas de monitorización o la documentación que demostrarían que la nueva métrica está expuesta y es útil.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Checklist
- I did not find a related open enhancement request.
- I understand that enhancement requests filed in the GitHub repository are by default low priority.
- If this request is time-sensitive, I have submitted a corresponding issue with GCP support.
Describe the feature
Description: Currently, users struggle to know precisely how close a ResourceGroup object is to hitting the Kubernetes API server or etcd object size limits. While metrics like resource_count exist, they serve only as a rough heuristic and do not accurately reflect the actual serialized size of the object. If the limit is reached, it causes synchronization failures that are hard to predict.
Feature request: We would like Config Sync to surface a new metric that tracks the size of the serialized ResourceGroup object (or an estimate of how close it is to the limit). This would allow users to monitor their usage and proactively restructure their configurations (e.g., by splitting repositories) before hitting hard limits.
Alternatives considered: Monitoring the declared_resources or resource_count metrics. However, since individual resource sizes vary significantly, a simple count is often an insufficient proxy for the actual object size.
Importance
No response
- Lenguaje dominante
- Go
- Estrellas
- 279
- Forks
- 59
- Merge medio
- 5 d 10 h
- PR fusionados (30 d)
- 12
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de GoogleContainerTools/config-sync
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
GoogleContainerTools/config-sync#2090 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
GoogleContainerTools/config-sync#2031 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
GoogleContainerTools/config-sync#2026 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
GoogleContainerTools/config-sync#2025 ·
Los mantenedores suelen responder en 1 día
-
Feature Request: Separate metrics for management vs. resource conflicts and use gauge aggregationAbiertoenhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
GoogleContainerTools/config-sync#2024 ·
Los mantenedores suelen responder en 1 día
Todos los issues de GoogleContainerTools/config-sync
Issues similares
-
Handler accepts zero/negative NNCP_MAX_RETRIES and NNCP backoff values, stalling policies or hot-loopingPosiblemente ocupada @NopeCharon la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
nmstate/kubernetes-nmstate#1604 ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
bug raised-by:desk
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
medici-finance/assay#4723 ·
Los mantenedores suelen responder en 1 día
-
[doc-healer] DDUw improvement: retry integrity-filtered issue reads with direct single-item lookupsAbiertoautomation documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
flannel-io/flannel#2608 ·
Los mantenedores suelen responder en 2 días