

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Políticas de escalado de seguimiento de destino para Amazon EC2 Auto Scaling
<a name="as-scaling-target-tracking"></a>

Una política de escalado de seguimiento de objetivo escala automáticamente la capacidad del grupo de escalado automático en función de un valor de métrica de destino. Se adapta automáticamente a los patrones de uso particulares de sus aplicaciones individuales. Esto permite que su aplicación mantenga un rendimiento óptimo y una elevada utilización de las instancias de EC2 para una mejor rentabilidad sin intervención manual.

Con el seguimiento de objetivo, seleccione una métrica y un valor objetivo para representar el nivel ideal de utilización promedio o rendimiento para su aplicación. Amazon EC2 Auto Scaling crea y administra CloudWatch las alarmas que invocan eventos de escalado cuando la métrica se desvía del objetivo. Para ejemplificar, esto es similar a cómo un termostato mantiene una temperatura objetivo.

Por ejemplo, supongamos que tiene una aplicación web que actualmente se pone en marcha en dos instancias y desea que la utilización de CPU del grupo de escalado automático permanezca en torno al 50 % cuando cambie la carga en la aplicación. De este modo dispone de capacidad adicional para gestionar picos de tráfico sin mantener una cantidad excesiva de recursos inactivos. 

Puede satisfacer esta necesidad mediante la creación de una política de escalado de seguimiento de destino que tenga como destino una utilización media de CPU del 50 por ciento. Luego, el grupo de escalado automático se escalará horizontalmente, o aumentará su capacidad, cuando la CPU supere el 50 por ciento para gestionar el aumento de carga. Se reducirá horizontalmente, o reducirá su capacidad, cuando la CPU caiga por debajo del 50 por ciento para optimizar los costos durante los periodos de baja utilización.

**Topics**
+ [Políticas de escalado de seguimiento de destino](#target-tracking-multiple-policies)
+ [Elección de métricas](#target-tracking-choose-metrics)
+ [Definición del valor de destino](#target-tracking-define-target-value)
+ [Definición del tiempo de preparación de la instancia](#as-target-tracking-scaling-warmup)
+ [Consideraciones](#target-tracking-considerations)
+ [Creación de una política de escalado de seguimiento de destino](policy_creating.md)
+ [Cómo crear una política de seguimiento de objetivos con métricas de alta resolución para obtener una respuesta más rápida](policy-creating-high-resolution-metrics.md)
+ [Creación de una política de escalado de seguimiento de destino con cálculos métricos](ec2-auto-scaling-target-tracking-metric-math.md)

## Políticas de escalado de seguimiento de destino
<a name="target-tracking-multiple-policies"></a>

Puede tener varias políticas de escalado de seguimiento de destino juntas que le ayuden a optimizar su rendimiento, siempre que cada una de ellas use una métrica diferente. Por ejemplo, la utilización y el rendimiento pueden influir mutuamente. Cada vez que una de estas métricas cambia, normalmente implica que otras métricas también se verán afectadas. Por lo tanto, el uso de varias métricas proporciona información adicional sobre la carga a la que se encuentra el grupo de escalado automático. Esto puede ayudar a Amazon EC2 Auto Scaling a tomar decisiones mejor informadas a la hora de determinar cuánta capacidad añadir a su grupo. 

La intención de Amazon EC2 Auto Scaling es priorizar siempre la disponibilidad. Escalará horizontalmente el grupo de escalado automático si cualquiera de las políticas de seguimiento de objetivo está lista para el escalado horizontal. Solo realizará una reducción horizontal si todas las políticas de seguimiento de objetivo (que tienen habilitada la reducción horizontal) estén listas para la reducción horizontal.

## Elección de métricas
<a name="target-tracking-choose-metrics"></a>

Puede crear políticas de escalado de seguimiento de destino con métricas predefinidas o personalizadas. Las métricas predefinidas facilitan el acceso a las métricas más utilizadas para el escalado. Las métricas personalizadas le permiten escalar en función de otras CloudWatch métricas disponibles, incluidas las métricas [de alta resolución](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Resolution_definition) que se publican en intervalos más precisos del orden de unos pocos segundos. Puede publicar sus propias métricas de alta resolución o las que publiquen otros servicios de AWS .

Para obtener más información sobre la creación de políticas de seguimiento de objetivos con métricas de alta resolución, consulte [Cómo crear una política de seguimiento de objetivos con métricas de alta resolución para obtener una respuesta más rápida](policy-creating-high-resolution-metrics.md).

El seguimiento de objetivos admite las siguientes métricas predefinidas:
+ `ASGAverageCPUUtilization`: promedio de utilización de la CPU del grupo de Auto Scaling.
+ `ASGAverageNetworkIn`: número promedio de bytes recibidos en todas las interfaces de red por el grupo de Auto Scaling.
+ `ASGAverageNetworkOut`: número promedio de bytes enviados en todas las interfaces de red por el grupo de Auto Scaling.
+ `ALBRequestCountPerTarget`: recuento medio de solicitudes de Application Load Balancer por destino para su grupo de Auto Scaling.

**importante**  
Encontrará más información valiosa sobre las métricas de uso de la CPU, E/S de red y recuento de solicitudes de Application Load Balancer por objetivo en [el tema Enumere las métricas CloudWatch disponibles para sus instancias de la](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) Guía del *usuario de Amazon EC2* y [las métricas de su Application Load Balancer de CloudWatch la Guía del usuario de Application Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) *Balancers*, respectivamente.

Puede elegir otras CloudWatch métricas disponibles o las suyas propias especificando una métrica personalizada CloudWatch . Para ver un ejemplo que especifique una especificación de métrica personalizada para una política de escalado de seguimiento de objetivos mediante la AWS CLI, consulte[Ejemplos de políticas de escalado para AWS CLI](examples-scaling-policies.md).

Tenga en cuenta las siguientes consideraciones al elegir una métrica:
+ Recomendamos que solo utilice métricas que estén disponibles en intervalos de un minuto o menos para permitir escalar más rápido en respuesta a los cambios de uso. Las métricas que se publican a intervalos más bajos permiten que la política de seguimiento de objetivos detecte y responda más rápido a los cambios en la utilización del grupo de escalado automático.
+ Si elige métricas predefinidas publicadas por Amazon EC2, como el uso de la CPU, le recomendamos que habilite el monitoreo detallado. Por defecto, todas las métricas de Amazon EC2 se publican en intervalos de cinco minutos, pero se pueden configurar a un intervalo más bajo al habilitar el monitoreo detallado. Para obtener información acerca de cómo habilitar el monitoreo detallado, consulte [Configuración de la supervisión para instancias de Auto Scaling](enable-as-instance-metrics.md).
+ No todas las métricas personalizadas funcionan para el seguimiento de destino. La métrica debe ser una métrica de utilización válida y describir el nivel de actividad de una instancia. El valor de la métrica debe aumentar o disminuir proporcionalmente al número de instancias del grupo de escalado automático. De esta forma, los datos de las métricas se pueden utilizar para ampliar o reducir proporcionalmente el número de instancias. Por ejemplo, la utilización de la CPU de un grupo de escalado automático (es decir, la métrica `CPUUtilization` de Amazon EC2 con la dimensión de métrica `AutoScalingGroupName`) funciona si la carga del grupo de escalado automático se distribuye entre las instancias. 
+ Las siguientes métricas no sirven para hacer un seguimiento de destino:
  + El número de solicitudes recibidas por el balanceador de carga frente al grupo de escalado automático (es decir, la métrica Elastic Load Balancing de `RequestCount`). El número de solicitudes recibidas por el balanceador de carga no cambia en función de la utilización del grupo de escalado automático.
  + La latencia de las solicitudes del balanceador de carga (es decir, la métrica `Latency` de Elastic Load Balancing). La latencia de las solicitudes puede aumentar si lo hace la utilización, pero el cambio no tiene que ser necesariamente proporcional.
  + La métrica CloudWatch de colas de Amazon SQS. `ApproximateNumberOfMessagesVisible` El número de mensajes de una cola no tiene por qué cambiar en proporción al tamaño del grupo de escalado automático que procesa los mensajes de la cola. Sin embargo, puede que funcione una métrica personalizada que mida el número de mensajes de la cola por instancia de EC2 en el grupo de escalado automático. Para obtener más información, consulte [Política de escalado basada en Amazon SQS](as-using-sqs-queue.md).
+ Para utilizar la métrica `ALBRequestCountPerTarget`, debe especificar el parámetro `ResourceLabel` para identificar el grupo de destino del balanceador de carga asociado a la métrica. Para ver un ejemplo que especifique el `ResourceLabel` parámetro de una política de escalado de seguimiento de objetivos mediante el AWS CLI, consulte. [Ejemplos de políticas de escalado para AWS CLI](examples-scaling-policies.md)
+ Cuando una métrica emite valores 0 reales a CloudWatch (por ejemplo,`ALBRequestCountPerTarget`), un grupo de Auto Scaling puede escalar a 0 cuando no haya tráfico en su aplicación durante un período prolongado de tiempo. Para que el grupo de escalado automático se reduzca horizontalmente a 0 cuando no se envíen solicitudes, la capacidad mínima del grupo debe ser de 0.
+ En lugar de publicar métricas nuevas para utilizarlas en su política de escalado, puede utilizar la matemáticas métricas para combinar las métricas existentes. Para obtener más información, consulte [Creación de una política de escalado de seguimiento de destino con cálculos métricos](ec2-auto-scaling-target-tracking-metric-math.md).

## Definición del valor de destino
<a name="target-tracking-define-target-value"></a>

Al crear una política de escalado de seguimiento de destino, debe especificar un valor de destino. El valor objetivo representa la utilización o el rendimiento promedio óptimo para el grupo de escalado automático. Para usar los recursos de manera rentable, establezca el valor objetivo lo más alto posible con un búfer razonable para aumentos inesperados de tráfico. Cuando la aplicación se escala horizontalmente de manera óptima para un flujo de tráfico normal, el valor de la métrica real debe ser igual al valor de destino, o estar justo por debajo de él. 

Cuando una política de escalado se basa en el rendimiento, como el recuento de solicitudes por objetivo para un equilibrador de carga de aplicación, E/S de red u otras métricas de recuento, el valor objetivo representa el rendimiento promedio óptimo de una sola instancia, para un periodo de un minuto.

## Definición del tiempo de preparación de la instancia
<a name="as-target-tracking-scaling-warmup"></a>

Puede especificar el número de segundos que se tarda en preparar una instancia recién lanzada. Hasta que finaliza el tiempo de preparación especificado, la instancia no se tiene en cuenta para las métricas agregadas de la instancia de EC2 del grupo de escalado automático.

Mientras las instancias se encuentran en el periodo de preparación, las políticas de escalado solo escalan horizontalmente si el valor de la métrica de las instancias que no están en preparación es mayor que la utilización objetivo de la política.

Si el grupo se vuelve a escalar horizontalmente, las instancias que aún estén en preparación se considerarán parte de la capacidad deseada para la siguiente actividad de escalado horizontal. La intención es realizar continuamente (pero no excesivamente) un escalado ascendente.

Mientras la actividad de escalado horizontal está en curso, todas las actividades de reducción horizontal iniciadas por las políticas de escalado se bloquean hasta que las instancias terminen de prepararse. Cuando las instancias terminen de prepararse, si se produce un evento de reducción horizontal, cualquier instancia que se encuentre actualmente en proceso de terminación se tendrá en cuenta para la capacidad actual del grupo al calcular la nueva capacidad deseada. Por lo tanto, no se eliminan más instancias del grupo de Auto Scaling que las necesarias.

**Predeterminado**  
Si no se establece ningún valor, la política de escalado utilizará el valor predeterminado, que es el valor de la [preparación de instancias por defecto](ec2-auto-scaling-default-instance-warmup.md) definido para el grupo. Si la preparación predeterminada de instancias es nula, se revertirá al valor de [recuperación predeterminado](ec2-auto-scaling-scaling-cooldowns.md#set-default-cooldown). Recomendamos usar la preparación de instancias predeterminada para facilitar la actualización de todas las políticas de escalado cuando cambie el tiempo de preparación.

## Consideraciones
<a name="target-tracking-considerations"></a>

Las siguientes consideraciones se aplican al trabajar con las políticas de escalado de seguimiento de destino:
+ No cree, edite ni elimine las CloudWatch alarmas que se utilizan con una política de escalado y seguimiento de Target. Amazon EC2 Auto Scaling crea y administra CloudWatch las alarmas asociadas a las políticas de escalado de seguimiento de destino y puede editarlas, sustituirlas o eliminarlas cuando sea necesario para personalizar la experiencia de escalado de sus aplicaciones y sus patrones de utilización cambiantes. 
+ Una política de escalado de seguimiento de objetivos prioriza la disponibilidad durante los períodos de niveles de tráfico fluctuantes al reducir horizontalmente de forma más gradual cuando el tráfico disminuye. Si desea tener un mayor control, una política de escalado por pasos podría ser la mejor opción. Puede deshabilitar la reducción horizontal de una política de seguimiento de objetivo. Esto permite mantener una cantidad mínima de instancias para que las implementaciones se realicen correctamente. 
+ Si a la métrica le faltan puntos de datos, el estado de la CloudWatch alarma cambia a`INSUFFICIENT_DATA`. Cuando esto ocurre, Amazon EC2 Auto Scaling no puede escalar su grupo hasta que se encuentren nuevos puntos de datos.
+ Si la métrica se presenta de forma dispersa por diseño, las matemáticas métricas pueden resultar útiles. Por ejemplo, para usar los valores más recientes, utilice la función `FILL(m1,REPEAT)`, donde `m1` es la métrica.
+ Es posible que haya diferencias entre el valor objetivo y los puntos de datos de la métrica real. Esto se debe a que actuamos de forma conservadora redondeando hacia arriba o hacia abajo a la hora de determinar el número de instancias que se deben agregar o quitar. Esto impide que agreguemos un número insuficiente de instancias o eliminemos demasiadas. Sin embargo, en el caso de los grupos de Auto Scaling que son más pequeños y tienen menos instancias, la utilización del grupo puede parecer que está muy lejos del valor de destino.

  Por ejemplo, supongamos que se establece un valor de destino del 50 por ciento de utilización de la CPU y el grupo de escalado automático lo supera. Es posible determinar que la adición de 1,5 instancias disminuirá la utilización de la CPU hasta aproximadamente el 50 por ciento. Como no es posible agregar 1,5 instancias, redondeamos hacia arriba y añadimos dos instancias. Esto podría reducir la utilización de la CPU a un valor inferior al 50 por ciento, pero garantizaría que la aplicación cuenta con los recursos suficientes. Del mismo modo, si determinamos que la eliminación de 0,5 instancias aumentaría la utilización de la CPU por encima del 50 %, decidiremos no reducir horizontalmente hasta que la métrica baje lo suficiente como para que la reducción horizontal no provoque oscilaciones. 

  En el caso de grupos de Auto Scaling más grandes con más instancias, la utilización se distribuye entre un número de instancias mayor, en cuyo caso, si se agregan o quitan instancias, la diferencia entre el valor de destino y los puntos de datos de la métrica real es menor.
+ En las políticas de escalado de seguimiento de destino, se presupone que el grupo de escalado automático debe escalarse horizontalmente cuando la métrica especificada está por encima del valor de destino. Las políticas de escalado de seguimiento de destino no pueden utilizarse para escalar horizontalmente el grupo de escalado automático si la métrica está por debajo del valor de destino.

# Creación de una política de escalado de seguimiento de destino
<a name="policy_creating"></a>

Para crear una política de escalado de seguimiento de objetivo para el grupo de escalado automático, use uno de los siguientes métodos: 

Antes de empezar, confirme que su métrica preferida esté disponible en intervalos de 1 minuto (en comparación con el intervalo de 5 minutos predeterminado de las métricas de Amazon EC2).

------
#### [ Console ]

**Creación de una política de escalado de seguimiento de destino para un nuevo grupo de escalado automático**

1. Abra la consola Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)y seleccione **Auto Scaling Groups** en el panel de navegación.

1. Elija **Create Auto Scaling group (Crear grupo de escalado automático)**.

1. En los pasos 1, 2 y 3, elija las opciones que desee y continúe en el **Paso 4: Configurar el tamaño del grupo y las políticas de escalado**.

1. En **Escalado**, especifique el rango entre el que desea escalar actualizando la **Capacidad deseada mínima** y la **Capacidad deseada máxima**. Estas dos configuraciones permiten escalar dinámicamente el grupo de escalado automático. Para obtener más información, consulte [Establecimiento de límites de escalado para el grupo de escalado automático](asg-capacity-limits.md).

1. En **Escalado automático**, elija **Política de escalado de seguimiento de destino**.

1. Para definir una política, haga lo siguiente:

   1. Especifique un nombre para la política.

   1. En **Tipo de métrica**, elija una métrica. 

      Si eligió **Application Load Balancer request count per target (Recuento de solicitudes de Application Load Balancer por destino)**, elija un grupo de destino en **Target group (Grupo de destino)**.

   1. Especifique un valor de destino para la métrica en **Target value**.

   1. (Opcional) Para **Preparación de instancias**, actualice el valor de preparación de la instancia según sea necesario.

   1. (Opcional) Seleccione **Deshabilitar la reducción horizontal para crear solo una política de escalado horizontal**. De este modo, si lo desea, puede crear por separado una política de reducción horizontal de otro tipo.

1. Proceda a crear el grupo de escalado automático. La política de escalado se creará después de que se haya creado el grupo de escalado automático. 

**Para crear una política de escalado de seguimiento de destino para un grupo de escalado automático existente**

1. Abra la consola Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)y seleccione **Auto Scaling Groups** en el panel de navegación.

1. Seleccione la casilla situada junto al grupo de escalado automático.

   Se abre un panel dividido en la parte inferior de la página. 

1. Verifique que los límites de escalado estén establecidos correctamente. Por ejemplo, si la capacidad deseada de su grupo ya tiene el tamaño máximo, necesita especificar un nuevo máximo de escalado horizontal. Para obtener más información, consulte [Establecimiento de límites de escalado para el grupo de escalado automático](asg-capacity-limits.md).

1. En la pestaña **Automatic scaling** (Escalado automático), en **Dynamic scaling policies** (Políticas de escalado dinámico), elija **Create dynamic scaling policy** (Crear política de escalado dinámico).

1. Para definir una política, haga lo siguiente:

   1. En **Tipo de política**, mantenga el valor predeterminado de **Escalado de seguimiento de destino**. 

   1. Especifique un nombre para la política.

   1. En **Tipo de métrica**, elija una métrica. Solo puede elegir un tipo de métrica. Para utilizar más de una métrica, cree varias políticas.

      Si eligió **Application Load Balancer request count per target (Recuento de solicitudes de Application Load Balancer por destino)**, elija un grupo de destino en **Target group (Grupo de destino)**.

   1. Especifique un valor de destino para la métrica en **Target value**.

   1. (Opcional) Para **Preparación de instancias**, actualice el valor de preparación de la instancia según sea necesario.

   1. (Opcional) Seleccione **Deshabilitar la reducción horizontal para crear solo una política de escalado horizontal**. De este modo, si lo desea, puede crear por separado una política de reducción horizontal de otro tipo.

1. Seleccione **Crear**.

------
#### [ AWS CLI ]

Para crear una política de escalado de seguimiento de objetivo, puede utilizar el siguiente ejemplo para empezar. Reemplace cada *user input placeholder* por su propia información.

**nota**  
Para obtener más ejemplos, consulte [Ejemplos de políticas de escalado para AWS CLI](examples-scaling-policies.md).

**Creación de una política de escalado de seguimiento de destino (AWS CLI)**

1. Utilice el siguiente comando `cat` para almacenar un valor de destino para su política de escalado y una especificación de métricas predefinida en un archivo JSON llamado `config.json` en su directorio principal. A continuación, se incluye un ejemplo de configuración de seguimiento de destino que mantiene la utilización media de la CPU en un 50 por ciento.

   ```
   $ cat ~/config.json
   {
     "TargetValue": 50.0,
     "PredefinedMetricSpecification": 
       {
         "PredefinedMetricType": "ASGAverageCPUUtilization"
       }
   }
   ```

   Para obtener más información, consulte la [PredefinedMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredefinedMetricSpecification.html)referencia de la *API Amazon EC2 Auto Scaling*.

1. Utilice el comando [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html), junto con el archivo `config.json` creado en el paso anterior, para crear la política de escalado.

   ```
   aws autoscaling put-scaling-policy --policy-name cpu50-target-tracking-scaling-policy \
     --auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
     --target-tracking-configuration file://config.json
   ```

   Si se ejecuta correctamente, este comando devuelve los nombres ARNs y los nombres de las dos CloudWatch alarmas creadas en su nombre.

   ```
   {
       "PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:228f02c2-c665-4bfd-aaac-8b04080bea3c:autoScalingGroupName/my-asg:policyName/cpu50-target-tracking-scaling-policy",
       "Alarms": [
           {
               "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e",
               "AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e"
           },
           {
               "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2",
               "AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2"
           }
       ]
   }
   ```

------

# Cómo crear una política de seguimiento de objetivos con métricas de alta resolución para obtener una respuesta más rápida
<a name="policy-creating-high-resolution-metrics"></a>

El seguimiento de Target admite CloudWatch métricas de alta resolución con puntos de datos de segundo nivel que se publican a intervalos inferiores a un minuto. Configure políticas de seguimiento de objetivos para supervisar la utilización mediante CloudWatch métricas de alta resolución para las aplicaciones que tienen patrones de demanda volátiles, como las API de servicio a los clientes, los servicios de streaming en directo, los sitios web de comercio electrónico y el procesamiento de datos bajo demanda. Para lograr una mayor precisión a la hora de ajustar la capacidad a la demanda, el seguimiento de objetivos utilizará este monitoreo detallado para detectar y responder a los cambios en la demanda y el uso de las instancias de EC2 con mayor rapidez.

Para obtener más información sobre cómo publicar tus métricas en alta resolución, consulta [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) en la *Guía del CloudWatch usuario de Amazon*. Para acceder a las métricas de EC2 y publicarlas, como el uso de la CPU en alta resolución, puede utilizar [CloudWatch un agente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html).

## Regiones de AWS
<a name="policy-creating-high-resolution-metrics-regions"></a>

El seguimiento de objetivos mediante métricas de alta resolución está disponible en todos los países Regiones de AWS excepto en. AWS GovCloud (US) Regions

## Cómo funciona la política de seguimiento de objetivos con métricas de alta resolución
<a name="policy-high-resolution-metrics-how-works"></a>

Las políticas de seguimiento de objetivos se crean definiendo la métrica de la que se quiere hacer un seguimiento y el valor objetivo que se quiere mantener para la métrica. Para escalar en función de una métrica de alta resolución, especifique el nombre de la métrica y establezca el periodo de observación de la métrica en un valor inferior a 60 segundos. El intervalo mínimo actual admitido es de 10 segundos. Puede publicar su métrica a intervalos más bajos que este.

**nota**  
No se admiten periodos de métricas superiores a 60 segundos.

Puede configurar el seguimiento de objetivos en una única CloudWatch métrica o consultar varias CloudWatch métricas y utilizar expresiones matemáticas para crear nuevas series temporales únicas basadas en estas métricas. Ambas opciones permiten definir el periodo de métricas.

## Ejemplos
<a name="high-resolution-metrics-examples"></a>

**Ejemplo 1**  
En el siguiente ejemplo, se crea una política de seguimiento de objetivos basada en una CloudWatch métrica de alta resolución. La métrica se publica con una resolución de 10 segundos. Tras definir el periodo, puede habilitar el seguimiento de objetivos para monitorear esta métrica con una granularidad de 10 segundos. Reemplace cada *user input placeholder* por su propia información.

```
$ cat ~/config.json
{
  "TargetValue": 100.0,
  "CustomizedMetricSpecification": {
      "MetricName": "MyHighResolutionMetric",
      "Namespace": "MyNamespace",
      "Dimensions": [
        {
          "Name": "MyOptionalDimensionName",
          "Value": "MyOptionalMetricDimensionValue"
        }
      ],
      "Statistic": "Average",
      "Unit": "None"
      "Period": "10                  
  }
}
```

**Ejemplo 2**  
Puede usar expresiones matemáticas métricas para combinar varias métricas en una única serie temporal para el escalado. Las matemáticas métricas son especialmente útiles para convertir las métricas existentes en un promedio por instancia. La conversión de métricas es importante porque el seguimiento de objetivos asume que la métrica es inversamente proporcional a la capacidad del grupo de escalado automático. Por lo tanto, cuando la capacidad aumenta, la métrica debería disminuir casi en la misma proporción.

Por ejemplo, suponga que tiene una métrica que representa los trabajos pendientes que debe procesar su aplicación. Puede utilizar las matemáticas métricas para dividir los trabajos pendientes entre la capacidad de ejecución de su grupo de escalado automático. Auto Scaling publica la métrica de capacidad con una granularidad de 1 minuto, por lo que no habrá ningún valor para esta métrica en intervalos de menos de un minuto. Si desea utilizar una resolución más alta para el escalado, esto puede provocar una discordancia temporal entre la métrica de capacidad y de tareas pendientes. Para evitar este desajuste, recomendamos utilizar la expresión FILL para rellenar los valores faltantes con el número de capacidad registrado en la marca de tiempo del minuto anterior. 

En el siguiente ejemplo se utilizan las matemáticas métricas para dividir la métrica de trabajos pendientes por la capacidad. En el caso del periodo, estableceremos ambas métricas en 10 segundos. Puesto que la métrica se publica a intervalos de 1 minuto, utilizaremos la operación FILL en la métrica de capacidad.

Cómo utilizar las matemáticas métricas para modificar varias métricas

```
{
    "CustomizedMetricSpecification": {
        "Metrics": [
            {
                "Label": "Pending jobs to be processed",
                "Id": "m1",
                "MetricStat": {
                    "Metric": {
                        "MetricName": "MyPendingJobsMetric",
                        "Namespace": "Custom",
                    },
                    "Stat": "Sum"
                    "Period": 10
                },
                "ReturnData": false
            },
            {
                "Label": "Get the running instance capacity (matching the period to that of the m1)",
                "Id": "m2",
                "MetricStat": {
                    "Metric": {
                        "MetricName": "GroupInServiceInstances",
                        "Namespace": "AWS/AutoScaling",
                        "Dimensions": [
                            {
                                "Name": "AutoScalingGroupName",
                                "Value": "my-asg"
                            }
                        ]
                    },
                    "Stat": "Average"
                    "Period": 10
                },
                "ReturnData": false
            },
            {
                "Label": "Calculate the pending job per capacity (note the use of the FILL expression)",
                "Id": "e1",
                "Expression": "m1 / FILL(m2,REPEAT)",
                "ReturnData": true
            }
        ]
    },
    "TargetValue": 100
}
```

## Consideraciones
<a name="high-resolution-considerations"></a>

Tenga presente lo siguiente al utilizar el seguimiento de objetivos y las métricas de alta resolución.
+ Para asegurarse de que no le faltan puntos de datos que puedan generar resultados de escalado automático no deseados, la CloudWatch métrica debe publicarse con una resolución igual o superior a la del período que especifique.
+ Defina el valor objetivo como el valor per-instance-per-minute métrico que desea mantener para su grupo de Auto Scaling. Establecer un valor objetivo adecuado es fundamental si utiliza una métrica cuyo valor se pueda multiplicar según el periodo de la métrica. Por ejemplo, cualquier métrica basada en recuentos, como el recuento de solicitudes o trabajos pendientes, que utilice la estadística SUM tendrá un valor de métrica diferente según el periodo elegido. Aun así, debe asumir que está fijando un objetivo con respecto al promedio por minuto.
+ Si bien no hay tarifas adicionales por el uso de Amazon EC2 Auto Scaling, debe pagar los recursos, como las CloudWatch instancias, las métricas CloudWatch y las alarmas de Amazon EC2. Las alarmas de alta resolución creadas en el ejemplo anterior tienen un precio diferente al de las alarmas estándar. CloudWatch Para obtener más información sobre CloudWatch los precios, consulta [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
+ El seguimiento de objetivos requiere que las métricas representen el uso promedio por instancia de las instancias de EC2. Para lograrlo, puede utilizar [operaciones matemáticas métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) como parte de la configuración de su política de seguimiento de objetivos. Divida la métrica entre la capacidad de ejecución de su grupo de escalado automático. Asegúrese de definir el mismo periodo de métrica para cada una de las métricas que utilice para crear una sola serie temporal. Si estas métricas se publican a intervalos diferentes, utilice la operación FILL en la métrica con el intervalo más alto para rellenar los puntos de datos faltantes.

# Creación de una política de escalado de seguimiento de destino con cálculos métricos
<a name="ec2-auto-scaling-target-tracking-metric-math"></a>

Con la matemática métrica, puedes consultar múltiples CloudWatch métricas y usar expresiones matemáticas para crear nuevas series temporales basadas en estas métricas. Puede visualizar las series temporales resultantes en la CloudWatch consola y añadirlas a los paneles. Para obtener más información sobre las matemáticas métricas, consulte [Uso de las matemáticas métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) en la *Guía del CloudWatch usuario de Amazon*. 

Las siguientes consideraciones se aplican a las expresiones de la calculadora de métricas:
+ Puede consultar cualquier CloudWatch métrica disponible. Cada métrica es una combinación única de nombre de métrica, espacio de nombres y cero o más dimensiones. 
+ Puede usar cualquier operador aritmético (\$1 - \$1/^), función estadística (como AVG o SUM) u otra función compatible. CloudWatch 
+ Puede utilizar tanto las métricas como los resultados de otras expresiones matemáticas en las fórmulas de la expresión matemática. 
+ Todas las expresiones utilizadas en la especificación de una métrica deben devolver en última instancia una única serie temporal.
+ Puede comprobar que una expresión matemática métrica es válida mediante la CloudWatch consola o la API. CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)

## Ejemplo: cola de tareas pendientes de Amazon SQS por instancia
<a name="metric-math-sqs-queue-backlog"></a>

Para calcular la cola de tareas pendientes de Amazon SQS por instancia, se toma el número aproximado de mensajes disponibles para recuperar de la cola y se divide por la capacidad de ejecución del grupo de escalado automático, que es el número de instancias con estado `InService`. Para obtener más información, consulte [Política de escalado basada en Amazon SQS](as-using-sqs-queue.md).

La lógica de la expresión es la siguiente:

 `sum of (number of messages in the queue)/(number of InService instances)`

A continuación, la información de su CloudWatch métrica es la siguiente.


| ID | CloudWatch métrica | Estadística | Periodo | 
| --- | --- | --- | --- | 
| m1 | ApproximateNumberOfMessagesVisible | Sum | 1 minuto | 
| m2 | GroupInServiceInstances | Media | 1 minuto | 

Su ID de cálculo de métrica y expresión son los siguientes.


| ID | Expression | 
| --- | --- | 
| e1 | (m1)/(m2) | 

El siguiente diagrama ilustra la arquitectura de esta métrica:

![\[Diagrama de arquitectura de Amazon EC2 Auto Scaling que utiliza colas\]](http://docs.aws.amazon.com/es_es/autoscaling/ec2/userguide/images/sqs-as-custom-metric-diagram.png)


**Para utilizar esta calculadora de métricas para crear una política de escalado de seguimiento de destino (AWS CLI)**

1. Guarde la expresión de la calculadora de métricas como parte de una especificación métrica personalizada en un archivo JSON denominado `config.json`. 

   Utilice el siguiente ejemplo como ayuda para comenzar. Reemplace cada *user input placeholder* por su propia información.

   ```
   {
       "CustomizedMetricSpecification": {
           "Metrics": [
               {
                   "Label": "Get the queue size (the number of messages waiting to be processed)",
                   "Id": "m1",
                   "MetricStat": {
                       "Metric": {
                           "MetricName": "ApproximateNumberOfMessagesVisible",
                           "Namespace": "AWS/SQS",
                           "Dimensions": [
                               {
                                   "Name": "QueueName",
                                   "Value": "my-queue"
                               }
                           ]
                       },
                       "Stat": "Sum"
                   },
                   "ReturnData": false
               },
               {
                   "Label": "Get the group size (the number of InService instances)",
                   "Id": "m2",
                   "MetricStat": {
                       "Metric": {
                           "MetricName": "GroupInServiceInstances",
                           "Namespace": "AWS/AutoScaling",
                           "Dimensions": [
                               {
                                   "Name": "AutoScalingGroupName",
                                   "Value": "my-asg"
                               }
                           ]
                       },
                       "Stat": "Average"
                   },
                   "ReturnData": false
               },
               {
                   "Label": "Calculate the backlog per instance",
                   "Id": "e1",
                   "Expression": "m1 / m2",
                   "ReturnData": true
               }
           ]
       },
       "TargetValue": 100
   }
   ```

   Para obtener más información, consulte la [TargetTrackingConfiguration](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TargetTrackingConfiguration.html)referencia de la *API Amazon EC2 Auto Scaling*.
**nota**  
Los siguientes son algunos recursos adicionales que pueden ayudarle a encontrar nombres de métricas, espacios de nombres, dimensiones y estadísticas para las métricas: CloudWatch   
Para obtener información sobre las métricas disponibles para AWS los servicios, consulta [AWS los servicios que publican CloudWatch métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html) en la *Guía del CloudWatch usuario de Amazon*.
[Para obtener el nombre, el espacio de nombres y las dimensiones exactos (si corresponde) de una CloudWatch métrica con el AWS CLI, consulta list-metrics.](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/list-metrics.html) 

1. Para crear esta política, ejecute el [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)comando con el archivo JSON como entrada, como se muestra en el siguiente ejemplo.

   ```
   aws autoscaling put-scaling-policy --policy-name sqs-backlog-target-tracking-scaling-policy \
     --auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
     --target-tracking-configuration file://config.json
   ```

   Si se ejecuta correctamente, este comando devuelve el nombre de recurso de Amazon (ARN) de la política y la ARNs de las dos CloudWatch alarmas creadas en su nombre.

   ```
   {
       "PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:228f02c2-c665-4bfd-aaac-8b04080bea3c:autoScalingGroupName/my-asg:policyName/sqs-backlog-target-tracking-scaling-policy",
       "Alarms": [
           {
               "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e",
               "AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e"
           },
           {
               "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2",
               "AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2"
           }
       ]
   }
   ```
**nota**  
Si este comando arroja un error, asegúrese de haber actualizado la versión AWS CLI local a la última versión.