Erweiterte prädiktive Skalierungsrichtlinie mit benutzerdefinierten Metriken für Amazon ECS
In einer prädiktiven Skalierungsrichtlinie können Sie vordefinierte oder benutzerdefinierte Metriken verwenden. Benutzerdefinierte Metriken sind nützlich, wenn die vordefinierten Metriken (z. B. CPU, Arbeitsspeicher usw.) nicht ausreichen, um Ihre Anwendungslast ausreichend zu beschreiben.
Wenn Sie eine Richtlinie für die prädiktive Skalierung mit benutzerdefinierten Metriken erstellen, können Sie andere CloudWatch-Metriken angeben, die von AWS bereitgestellt werden. Alternativ können Sie Metriken angeben, die Sie selbst definieren und veröffentlichen. Sie können Metrikmathematik auch verwenden, um vorhandene Metriken zu aggregieren und in eine neue Zeitreihe umzuwandeln, die nicht automatisch von AWS erfasst wird. Wenn Sie beispielsweise Werte in Ihren Daten kombinieren, indem Sie neue Summen oder Durchschnittswerte berechnen, nennt man das Aggregieren. Die resultierenden Daten werden als Aggregat bezeichnet.
Der folgende Abschnitt enthält bewährte Verfahren und Beispiele für die Erstellung der JSON-Struktur für die Richtlinie.
Voraussetzungen
Um benutzerdefinierte Metriken zu Ihrer prädiktiven Skalierungsrichtlinie hinzuzufügen, müssen Sie über entsprechende cloudwatch:GetMetricData-Berechtigungen verfügen.
Um Ihre eigenen Metriken anstelle der von AWS bereitgestellten Metriken anzugeben, müssen Sie Ihre Metriken zunächst in CloudWatch veröffentlichen. Weitere Informationen finden Sie unter Veröffentlichen von benutzerdefinierten Metriken im Amazon CloudWatch Benutzerhandbuch.
Sollten Sie Ihre eigenen Metriken veröffentlichen, achten Sie darauf, dass Sie die Datenpunkte mindestens alle fünf Minuten veröffentlichen. Datenpunkte werden von CloudWatch basierend auf der Länge des benötigten Zeitraums abgerufen. Die Spezifikation der Lastmetrik verwendet beispielsweise stündliche Metriken, um die Last Ihrer Anwendung zu messen. CloudWatch verwendet Ihre veröffentlichten Metrikdaten, um einen einzigen Datenwert für einen beliebigen Ein-Stunden-Zeitraum bereitzustellen, indem alle Datenpunkte mit Zeitstempeln, die in den jeweiligen Ein-Stunden-Zeitraum fallen, zusammengefasst werden.
Bewährte Methoden
Die folgenden bewährten Methoden können Ihnen helfen, benutzerdefinierte Metriken effektiver zu nutzen:
-
Bei der Angabe der Lastmetrik ist die sinnvollste Metrik eine, die die Last einer Auto-Scaling-Gruppe als Ganzes darstellt.
-
Bei der Angabe der Skalierungsmetrik ist die sinnvollste Metrik für die Skalierung ein durchschnittlicher Durchsatz oder eine durchschnittliche Auslastung pro Aufgabe.
-
Die Zielauslastung muss mit der Art der Skalierungsmetrik übereinstimmen. Bei einer Richtlinienkonfiguration, die die CPU-Auslastung verwendet, ist dies beispielsweise ein Zielprozentsatz.
-
Wenn diese Empfehlungen nicht befolgt werden, werden die prognostizierten zukünftigen Werte der Zeitreihen wahrscheinlich falsch sein. Um zu überprüfen, ob die Daten korrekt sind, können Sie die prognostizierten Werte in der Konsole einsehen. Alternativ können Sie, nachdem Sie Ihre prädiktive Skalierungsrichtlinie erstellt haben, die
LoadForecast-Objekte untersuchen, die durch einen Aufruf der GetPredictiveScalingForecast-API zurückgegeben werden. -
Wir empfehlen Ihnen dringend, die prädiktive Skalierung im Modus Nur Prognose zu konfigurieren, damit Sie die Prognose auswerten können, bevor die prädiktive Skalierung mit der aktiven Skalierung beginnt.
Einschränkungen
-
Sie können Datenpunkte von bis zu 10 Metriken in einer Metrikspezifikation abfragen.
-
Für die Zwecke dieses Limits zählt ein Ausdruck als eine Metrik.
Fehlerbehebung einer Richtlinie für die prädiktive Skalierung mit benutzerdefinierten Metriken
Wenn bei der Verwendung von benutzerdefinierten Metriken ein Problem auftritt, empfehlen wir Ihnen, wie folgt vorzugehen:
-
Wenn Sie bei der Verwendung eines Suchausdrucks in einer Blau/Grün-Bereitstellung auf ein Problem stoßen, stellen Sie sicher, dass Sie einen Suchausdruck erstellt haben, der nach einer teilweisen und nicht nach einer exakten Übereinstimmung sucht. Vergewissern Sie sich außerdem, dass Ihre Anfrage nur die Auto-Scaling-Gruppen findet, in denen die betreffende Anwendung ausgeführt wird. Weitere Informationen über die Syntax des Suchausdrucks finden Sie unter CloudWatch-Suchausdrucksyntax im Amazon CloudWatch-Benutzerhandbuch.
-
Der Befehl put-scaling-policy validiert einen Ausdruck, wenn Sie Ihre Skalierungsrichtlinie erstellen. Es besteht jedoch die Möglichkeit, dass dieser Befehl die genaue Ursache der erkannten Fehler nicht identifizieren kann. Um die Probleme zu beheben, beheben Sie die Fehler, die Sie in einer Antwort auf eine Anfrage an den Befehl get-metric-data erhalten. Sie können den Ausdruck auch über die CloudWatch-Konsole beheben.
-
Sie müssen
falsefürReturnDataangeben, wennMetricDataQueriesdie Funktion SEARCH() allein ohne eine mathematische Funktion wie SUM() angibt. Das liegt daran, dass Suchausdrücke mehrere Zeitreihen zurückgeben können, während eine auf einem Ausdruck basierende Metrikspezifikation nur eine Zeitreihe zurückgeben kann. -
Alle an einem Suchausdruck beteiligten Metriken sollten die gleiche Auflösung haben.
Beispiel für eine prädiktive Skalierungspolitik, die Metriken mit metrischer Mathematik kombiniert (AWS CLI)
Manchmal müssen Sie die Metrik nicht direkt angeben, sondern die Daten erst auf irgendeine Weise verarbeiten. Sie könnten zum Beispiel eine Anwendung haben, die Arbeit aus einer Amazon SQS-Warteschlange abruft, und Sie könnten die Anzahl der Objekte in der Warteschlange als Kriterium für die prädiktive Skalierung verwenden wollen. Die Anzahl der Nachrichten in der Warteschlange bestimmt nicht allein die Anzahl der Instances, die Sie benötigen. Daher ist weitere Arbeit erforderlich, um eine Metrik zu erstellen, die zur Berechnung des Rückstands pro Instance verwendet werden kann.
Im Folgenden finden Sie ein Beispiel für eine prädiktive Skalierungsrichtlinie für dieses Szenario. Sie legt Skalierungs- und Auslastungsmetriken fest, die auf der Amazon SQS ApproximateNumberOfMessagesVisible-Metrik basieren, d.h. der Anzahl der Nachrichten, die für den Abruf aus der Warteschlange verfügbar sind. Es verwendet auch die Amazon EC2 Auto Scaling GroupInServiceInstances-Metrik und einen mathematischen Ausdruck, um den Rückstand pro Instance für die Skalierungsmetrik zu berechnen.
aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \
--policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
--service-namespace ecs \
--resource-id service/MyCluster/test \
"MetricSpecifications": [
{
"TargetValue": 100,
"CustomizedScalingMetricSpecification": {
"MetricDataQueries": [
{
"Label": "Get the queue size (the number of messages waiting to be processed)",
"Id": "queue_size",
"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 running instances)",
"Id": "running_capacity",
"MetricStat": {
"Metric": {
"MetricName": "GroupInServiceInstances",
"Namespace": "AWS/AutoScaling",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
}
]
},
"Stat": "Sum"
},
"ReturnData": false
},
{
"Label": "Calculate the backlog per instance",
"Id": "scaling_metric",
"Expression": "queue_size / running_capacity",
"ReturnData": true
}
]
},
"CustomizedLoadMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_metric",
"MetricStat": {
"Metric": {
"MetricName": "ApproximateNumberOfMessagesVisible",
"Namespace": "AWS/SQS",
"Dimensions": [
{
"Name": "QueueName",
"Value": "my-queue"
}
],
},
"Stat": "Sum"
},
"ReturnData": true
}
]
}
}
]
}
Das Beispiel gibt den ARN der Richtlinie zurück.
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy",
"Alarms": []
}