Je suis intéressé par l'écoute/réaction à l'événement, qu'un service ne peut pas démarrer une tâche en raison d'un processeur ou d'une mémoire insuffisante. Cette information peut être visualisée dans la console, si j'ai choisi le service spécifique et regarde dans son onglet "Événements". Un événement comme celui-ci s'affichera alors:Comment écouter un événement "CPU/mémoire insuffisante" dans un service AWS ECS?
"le service X n'a pas réussi à placer une tâche car aucune instance de conteneur ne répondait à toutes ses exigences L'instance de conteneur correspondante Y la plus proche n'a pas d'unités UC disponibles. , voir la section Dépannage. " Les instances de conteneur du cluster sont gérées dans un groupe AutoScalingGroup. L'action appropriée consiste donc à réagir à cet événement en effectuant une mise à l'échelle dans une instance supplémentaire, ce qui permet ensuite à la tâche d'être planifiée pour exécution. Maintenant, mon problème est, comment puis-je réagir à cet événement?
J'ai un LogGroup qui contient les données des fichiers suivants de toutes les instances EC2 du cluster:
- /var/log/dmesg
- /var/log/messages
- /var/log/docker
- /var/log/ecs/ecs-init.log.*
- /var/log/ecs/ecs-agent.log.*
(Les instances EC2 sont basées sur des images optimisées par amazon-ecs)
Initialement, je pensais que le message "service X était incapable de placer une tâche ..." apparaîtrait dans un de ces fichiers journaux (plus spécifiquement dans ecs-agent.log ou ecs-init.log), mais ce n'était pas le cas. J'ai ensuite réalisé que "ECS Evenets" est une chose (voir plus à http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html). Mais malheureusement, cet événement spécifique n'est pas celui qui est supporté par les "ECS Events". Uniquement: Événements d'événement d'instance de conteneur et Événements de changement d'état de tâche. PAS "Événements de changement d'état du service". Même si, on pourrait penser que les événements de l'onglet "Événements" dans le service seraient également diffusés, ils ne le sont pas. Je suis venu à réaliser la documentation même dit que:
« Vous pouvez utiliser flux d'événements Amazon ECS pour les événements CloudWatch à recevoir près de notifications en temps réel sur l'état actuel des deux instances de conteneur dans un cluster Amazon ECS, et l'état actuel de toutes les tâches exécutant sur ces instances de conteneur. " Par conséquent, «Le flux d'événements Amazon ECS pour CloudWatch Events» n'évolue pas les événements de service (et donc pas les événements pour les tâches dont l'exécution est impossible). J'espère vraiment que "Service State Change Events" sera inclus dans le futur, de cette façon je pourrais faire une règle d'événement CloudWatch qui correspond à cet événement, déclenche une fonction Lambda qui déterminerait alors si l'événement était un événement de type "service X était incapable de placer une tâche ... "et, sur cette base, manipulait AutoScalingGroup pour l'étendre dans une instance supplémentaire au cluster. Mais comme indiqué, cela n'est pas supporté pour le moment.
Y a-t-il un autre moyen que je puisse "écouter" pour cet événement?J'ai même pensé à lancer un lambda toutes les 2-3 minutes qui utilise la CLI pour invoquer "aws ecs describe-services --service X" pour sortir la liste des événements, puis faire correspondre le "service X était incapable de placer une tâche ..." un événement. Mais cela semble juste faux ...
Toute aide est très appréciée. Merci!
Si AWS fournissait des métriques raisonnables pour ECS (* absolu * cpu/mémoire disponible), alors être possible. C'est-à-dire que l'on pourrait déclencher une alarme lorsque ces valeurs sont inférieures aux exigences les plus élevées pour les services s'exécutant sur le cluster et évoluent de manière appropriée. Demande de fonctionnalité à AWS? – MikeGM
Je ne suis pas sûr que cpu/mémoire absolue serait suffisante. Vous pouvez avoir une instance qui a suffisamment de mémoire disponible, et une autre instance qui a suffisamment de CPU, mais aucune instance qui a à la fois suffisamment de mémoire et de CPU. Ensuite, il existe d'autres contraintes qui peuvent aggraver le problème, par ex. ports disponibles, tags d'hôte, etc. Vous obtiendrez toujours des erreurs de positionnement, et vous voudrez toujours les attraper et éventuellement augmenter la taille de votre cluster. –