Veo que hay 2 métricas separadas ApproximateNumberOfMessagesVisible y ApproximateNumberOfMessagesNotVisible .
El uso de la cantidad de mensajes visibles hace que los pods de procesamiento se activen para la finalización inmediatamente después de que recojan el mensaje de la cola, ya que ya no están visibles. Si uso una cantidad de mensajes no visibles, no se ampliará.
Estoy tratando de escalar un servicio de kubernetes usando un escalador automático de pod horizontal y una métrica externa de SQS. Aquí está la métrica externa de la plantilla:
apiVersion: metrics.aws/v1alpha1 kind: ExternalMetric metadata: name: metric-name spec: name: metric-name queries: - id: metric_name metricStat: metric: namespace: "AWS/SQS" metricName: "ApproximateNumberOfMessagesVisible" dimensions: - name: QueueName value: "queue_name" period: 60 stat: Average unit: Count returnData: trueAquí está la plantilla HPA:
kind: HorizontalPodAutoscaler apiVersion: autoscaling/v2beta1 metadata: name: hpa-name spec: scaleTargetRef: apiVersion: apps/v1beta1 kind: Deployment name: deployment-name minReplicas: 1 maxReplicas: 50 metrics: - type: External external: metricName: metric-name targetAverageValue: 1El problema se resolverá si puedo definir otra métrica personalizada que sea una suma de estas dos métricas, ¿de qué otra forma puedo resolver este problema?
Utilizamos una lambda para obtener dos métricas y publicar una métrica personalizada que es la suma de los mensajes en tránsito y en espera, y activamos esta lambda mediante eventos de vigilancia en la nube con la frecuencia que desee, https://console.aws.amazon.com/cloudwatch /home?region=us-east-1#rules:action=create
Aquí está el código lambda para referencia:
const AWS = require('aws-sdk'); const cloudwatch = new AWS.CloudWatch({region: ''}); // fill region here const sqs = new AWS.SQS(); const SQS_URL = ''; // fill queue url here async function getSqsMetric(queueUrl) { var params = { QueueUrl: queueUrl, AttributeNames: ['All'] }; return new Promise((res, rej) => { sqs.getQueueAttributes(params, function(err, data) { if (err) rej(err); else res(data); }); }) } function buildMetric(numMessages) { return { Namespace: 'yourcompany-custom-metrics', MetricData: [{ MetricName: 'mymetric', Dimensions: [{ Name: 'env', Value: 'prod' }], Timestamp: new Date(), Unit: 'Count', Value: numMessages }] } } async function pushMetrics(metrics) { await new Promise((res) => cloudwatch.putMetricData(metrics, (err, data) => { if (err) { console.log('err', err, err.stack); // an error occurred res(err); } else { console.log('response', data); // successful response res(data); } })); } exports.handler = async (event) => { console.log('Started'); const sqsMetrics = await getSqsMetric(SQS_URL).catch(console.error); var queueSize = null; if (sqsMetrics) { console.log('Got sqsMetrics', sqsMetrics); if (sqsMetrics.Attributes) { queueSize = parseInt(sqsMetrics.Attributes.ApproximateNumberOfMessages) + parseInt(sqsMetrics.Attributes.ApproximateNumberOfMessagesNotVisible); console.log('Pushing', queueSize); await pushMetrics(buildMetric(queueSize)) } } else { console.log('Failed fetching sqsMetrics'); } const response = { statusCode: 200, body: JSON.stringify('Pushed ' + queueSize), }; return response; };Este parece ser un caso de Thrashing: la cantidad de réplicas sigue fluctuando con frecuencia debido a la naturaleza dinámica de las métricas evaluadas.
En mi humilde opinión, tienes un par de opciones aquí. Podría considerar agregar una StabilizationWindow a su HPA y probablemente también limitar la tasa de reducción . Tendría que probar algunas combinaciones de métricas y ver qué funciona mejor para usted, ya que es mejor que conozca la naturaleza de las métricas ( ApproximateNumberOfMessagesVisible en este caso) que ve en su infraestructura.