Todos los productos
Search
Centro de documentos

Application Real-Time Monitoring Service:Actualización a Helm v1.1.17 y al agente v4.0.0

Última actualización: Sep 05, 2026

La versión más reciente de ARMS Prometheus es Helm v1.1.17, que corresponde al agente v4.0.0. Esta versión incluye varias mejoras para aumentar la estabilidad de la recolección, corregir errores conocidos y optimizar el consumo de recursos.

Importante

Si su clúster ejecuta un agente de ARMS Prometheus de la serie v3.x.x, se recomienda actualizar a la versión más reciente. Las versiones anteriores pueden contener componentes sin optimizar y representan un riesgo de desconexión de datos.

Novedades en v4.0.0

Tipo de cambio

Descripción

Nuevo

Se agregó un trabajo de recolección para eventos del clúster con el fin de admitir el panel de Kubernetes Deployment.

Nuevo

Se agregaron métricas de automonitoreo basadas en acuerdos de nivel de servicio (SLA) para proporcionar datos al panel de estabilidad de SLA.

Nuevo

Se añadió compatibilidad con la autenticación BasicAuth en ServiceMonitor. El Secret debe estar en el mismo namespace que el ServiceMonitor.

Nuevo

Se incorporó una función de metadatos de métricas que muestra el significado de métricas específicas.

Nuevo

El agente ahora transmite su versión de chart al servidor. Este utiliza el número de versión para inicializar o actualizar los paneles.

Nuevo

Se agregaron métricas de automonitoreo de RemoteWrite para rastrear la duración de envío de cada lote de datos.

Nuevo

Se añadieron métricas de automonitoreo para errores y latencia en la recolección de métricas básicas.

Nuevo

Se añadieron métricas de automonitoreo para errores y latencia en la recolección de métricas de negocio.

Mejorado

Se mejoró la configuración predeterminada de queue_config de RemoteWrite. Los parámetros se establecieron en min_shards=10, max_samples_per_send=5000 y capacity=10000 para mejorar la escalabilidad en clústeres de gran tamaño.

Mejorado

Se mejoró el método de detección de servicios para los trabajos de recolección de CSI, principalmente en la recolección de PersistentVolume (PV).

Mejorado

Se optimizó la frecuencia de senderLoop y syncWorkersSeries para reducir operaciones innecesarias.

Mejorado

Se simplificaron algunas entradas de registro y se mejoraron otras para ofrecer información de tiempos más detallada sobre la canalización de extracción.

Mejorado

Se mejoraron los trabajos de recolección de métricas básicas para usar un intervalo de extracción y un tiempo de espera fijos. Esto los desacopla de la configuración global y reduce interferencias.

Mejorado

Se optimizó la lógica de interacción en el modo de múltiples réplicas maestro-trabajador. Las réplicas maestras y trabajadoras ya no interfieren entre sí, lo que aumenta la estabilidad general.

Mejorado

Se mejoró la estrategia de distribución de destinos desde la réplica maestra. El consumo de CPU se redujo aproximadamente un 30 % y el de memoria un 40 %, lo que mejora el rendimiento de la recolección.

Mejorado

Se optimizó el procesamiento de metrics_relabel y se redujo el uso de CPU en un 70 %.

Mejorado

Se optimizó la lógica del listener de Informer para escenarios multiinquilino. El consumo de CPU disminuyó alrededor de un 20 %.

Mejorado

Se mejoró el manejo de fallas intermitentes en la resolución de CoreDNS. Ahora el agente recurre a una dirección IP almacenada en caché, lo que reduce la dependencia de la resolución DNS en tiempo real y aumenta la estabilidad de la transmisión de datos.

Mejorado

Se optimizó la lógica de distribución de configuraciones de extracción mediante SendConfig para mejorar la estabilidad.

Mejorado

Se optimizó la estrategia de preextracción en la réplica maestra para reducir el consumo de recursos y mejorar sus capacidades de detección de servicios y programación de destinos.

Mejorado

Se añadió un manejo adaptativo para lotes de datos individuales mayores a 1 MB. Esto reduce la pérdida de datos causada por limitaciones del backend.

Corregido

Se corrigió un problema en ScrapeLoop donde algunos destinos no se detenían, lo que provocaba extracciones duplicadas.

Corregido

Se corrigió un problema en escenarios multiinquilino donde las actualizaciones retrasadas de la caché de etiquetas de Pod dividían una sola serie temporal en dos.

Corregido

Se corrigió un problema donde la réplica maestra ocasionalmente no distribuía destinos a una réplica reiniciada o con un error de falta de memoria (OOM), lo que provocaba destinos de extracción omitidos.

Corregido

Se corrigieron problemas con el análisis sintáctico del tipo Secret y la transmisión de encabezados en RemoteWrite.

Corregido

Se corrigió un problema donde la acción de deshabilitar kubernetes-pods ocasionalmente no surtía efecto.

Corregido

Se corrigió un problema donde los parámetros globales predeterminados y external_labels no se aplicaban correctamente. Ahora también se admiten modificaciones personalizadas.

Riesgos de la actualización

  • Riesgo de la actualización: esta actualización a Helm v1.1.17 y al agente v4.0.0 es disruptiva. Dependiendo de la carga de recolección de métricas de su clúster (cantidad de destinos y series temporales), podría experimentar una breve interrupción de datos. Se espera que dure entre 0 y 5 minutos, aunque este tiempo varía entre clústeres.

  • Antes de la actualización: debe ejecutar las comprobaciones previas descritas en Step 1: Pre-upgrade checks (Required) para minimizar el impacto en los datos de monitoreo de su clúster.

  • Después de la actualización: si detecta problemas con los datos, siga los pasos descritos en Step 3: Post-upgrade checks (Optional). Si el problema persiste, consulte Post-upgrade FAQ. Para obtener más ayuda, comuníquese con nuestros expertos técnicos en DingTalk (ID: aliprometheus).

Procedimiento de actualización

Paso 1: Comprobaciones previas a la actualización (obligatorio)

Cuando actualiza de una versión de Helm anterior a la 1.1.16 hacia la 1.1.17, la actualización no conserva la configuración personalizada de parámetros. Debe revisar cualquier configuración personalizada antes de continuar. Si desea conservar estos ajustes, vuelva a aplicarlos manualmente una vez finalizada la actualización.

Las actualizaciones desde la versión 1.1.16 de Helm o posteriores heredan automáticamente los parámetros personalizados, por lo que no necesita volver a aplicarlos en actualizaciones subsecuentes. Siga estos pasos para revisar sus parámetros antes de la actualización:

  1. Inicie sesión en la consola de Container Service for Kubernetes (ACK).

  2. Haga clic en el nombre de su clúster de destino. En el panel de navegación izquierdo, elija Workload > Stateless. Seleccione el namespace arms-prom. Busque la carga de trabajo arms-prometheus-ack-arms-prometheus y, en la columna Operation, elija More > View YAML para consultar la configuración YAML completa.

  3. Revise los siguientes parámetros y anote los valores personalizados que desee conservar:

    • spec.replicas: el valor predeterminado después de la actualización es 1. Si su valor actual es distinto, anótelo.

    • spec.containers.args: son los parámetros de inicio del agente para el modo multiinquilino. Si este modo no está habilitado, es posible que el campo no exista. Si personalizó estos parámetros, anote sus valores:

      • tenant_userid

      • tenant_clusterid

      • tenant_token

    • spec.containers.resources: los límites predeterminados son 3 núcleos y 4 GiB de memoria. Las solicitudes predeterminadas son 1 núcleo y 1 GiB de memoria.

      Si su configuración es distinta, anote los valores para volver a aplicarlos después de la actualización.image.png

    Una vez completada la actualización, use el mismo método para consultar la configuración YAML. Edite el archivo para volver a aplicar sus valores personalizados y luego haga clic en Update para guardar los cambios.image.png

Paso 2: Procedimiento de actualización

Se recomienda actualizar la versión de Helm del componente ARMS Prometheus desde la consola de ACK. Siga estos pasos:

  1. Inicie sesión en la consola de Container Service for Kubernetes (ACK).

  2. Haga clic en el nombre de su clúster de destino. En el panel de navegación izquierdo, elija Operations > Component Management. Haga clic en la pestaña Logs and Monitoring, busque la tarjeta ack-arms-prometheus y haga clic en Upgrade.

  3. Cuando finalice la actualización, elija Operations > Managed Service for Prometheus en el panel de navegación izquierdo. En la esquina superior derecha, haga clic en Go to ARMS Prometheus. El sistema lo redirigirá a la página de lista de instancias de Prometheus en la consola de Managed Service for Prometheus, donde podrá consultar el estado del agente y los detalles de la recolección de métricas.

    Para comprobar la actualización, también puede hacer clic en Settings en el panel de navegación izquierdo y revisar la versión del componente en la pestaña Settings.image.png

Paso 3: Comprobaciones posteriores a la actualización (opcional)

  1. Inicie sesión en la consola de ARMS.

  2. En el panel de navegación izquierdo, elija Managed Service for Prometheus > Instances.

  3. Inicie sesión en la consola de Cloud Monitor.

  4. En el panel de navegación izquierdo, elija Managed Service for Prometheus > Instances para abrir la lista de instancias de Managed Service for Prometheus.

  5. Haga clic en el nombre de su instancia de Prometheus de destino. En el panel de navegación izquierdo, haga clic en Service Discovery. Haga clic en la pestaña Targets para revisar el estado de sus trabajos de recolección.

  6. En el panel de navegación izquierdo, haga clic en Settings. En la pestaña Self-Monitoring, haga clic en View Grafana Dashboard en la esquina superior derecha. Después de la actualización, supervise el estado operativo del agente. Asegúrese de que la cantidad de réplicas sea correcta y de que no haya anomalías en las tasas de envío de datos, el consumo de recursos ni la cantidad de errores.

  7. En la página Self-Monitoring, haga clic en la pestaña Agent Self-monitoring para consultar el panel de automonitoreo del agente de Prometheus.

    Después de la actualización, revise los cuatro trabajos de recolección de métricas básicas: _arms/kubelet/cadvisor, _arms/kubelet/metric, _kube-state-metrics y node-exporter. Use el selector de rango de tiempo en la esquina superior derecha para comparar los datos anteriores y posteriores a la actualización, y así detectar posibles problemas de recolección.

Preguntas frecuentes posteriores a la actualización

Discrepancia en la cantidad de réplicas después de la actualización

Compruebe si alguna réplica del agente se encuentra en estado Pending. El agente de ARMS Prometheus requiere que todas las réplicas estén en estado Running para funcionar correctamente. Puede consultar el estado de todas las réplicas en la página Workload > Stateless de su clúster de destino en la consola de ACK, dentro del namespace arms-prom.

Alto consumo de recursos después de la actualización

Revise si existen errores de transmisión de datos. Estos errores pueden provocar que los datos se acumulen en la memoria del agente, lo que incrementa el consumo de recursos. Puede consultar el uso de memoria y CPU del agente de Prometheus en la consola de ACK. Vaya a la página Operations > Managed Service for Prometheus de su clúster de destino, haga clic en la pestaña Others y busque la sección Prometheus Agent para consultar el uso de recursos.image.png

Métricas básicas faltantes o discontinuas

Si detecta problemas con métricas básicas como node_*** (ícono ①), container_*** (ícono ②), kubelet_*** (ícono ③) o kube_*** (ícono ④), compruebe si los trabajos de recolección correspondientes reportan errores. Puede verificar el estado de estos trabajos en la pestaña Service Discovery > Targets de la consola de Managed Service for Prometheus. Si encuentra errores, comuníquese con nuestros expertos técnicos en DingTalk (ID: aliprometheus) para obtener asistencia.image.png

Caída de tráfico o pérdida de datos en RemoteWrite

  • Si no ha configurado RemoteWrite, puede ignorar este problema.

  • Si configuró RemoteWrite, tenga en cuenta que en el agente v4.0.0 la opción write_relabel_configs ahora está habilitada de forma predeterminada, a diferencia de las versiones anteriores. Si su configuración incluye acciones como drop o keep, es posible que observe una caída en el tráfico. Modifique esta configuración según sus necesidades. Para ello, vaya a la página Settings en la consola de Managed Service for Prometheus. En la pestaña Settings, haga clic en Edit Prometheus.yaml y modifique la configuración.image.png