Surveillance dans le service géré pour Apache Flink - Service géré pour Apache Flink

Le service géré Amazon pour Apache Flink était auparavant connu sous le nom d’Amazon Kinesis Data Analytics pour Apache Flink.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Surveillance dans le service géré pour Apache Flink

Lorsque vous exécutez des applications de streaming en production, vous souhaitez exécuter l’application en continu et indéfiniment. Il est crucial de mettre en œuvre une surveillance et une alarme appropriées de tous les composants, et pas seulement de l’application Flink. Sinon, vous risquez de passer à côté des problèmes émergents dès le début et de ne vous rendre compte d’un événement opérationnel trop tard, quand il est beaucoup plus difficile de les atténuer. Les éléments généraux à surveiller incluent :

  • La source ingère-t-elle des données ?

  • Les données sont-elles lues depuis la source (du point de vue de la source) ?

  • L’application Flink reçoit-elle des données ?

  • L’application Flink parvient-elle à suivre le rythme ou prend-elle du retard ?

  • L’application Flink permet-elle de conserver les données dans le récepteur (du point de vue de l’application) ?

  • Le récepteur reçoit-il des données ?

Des métriques plus spécifiques doivent ensuite être prises en compte pour l’application Flink. Ce CloudWatch tableau de bord constitue un bon point de départ. Pour plus d’informations sur les métriques à surveiller pour les applications de production, consultez Utiliser les CloudWatch alarmes avec Amazon Managed Service pour Apache Flink. Ces métriques incluent :

  • records_lag_max et millisbehindLatest— Si l'application consomme depuis Kinesis ou Kafka, ces indicateurs indiquent si l'application prend du retard et doit être redimensionnée afin de suivre le rythme de charge actuel. Il s’agit d’une bonne métrique générique facile à suivre pour tous les types d’applications. Mais elle ne peut être utilisée que pour une mise à l’échelle réactive, c’est-à-dire lorsque l’application a déjà pris du retard.

  • cpuUtilizationet heapMemoryUtilization— Ces métriques donnent une bonne indication de l'utilisation globale des ressources de l'application et peuvent être utilisées pour une mise à l'échelle proactive, sauf si l'application est liée aux E/S.

  • downtime : un temps d’arrêt supérieur à zéro indique une défaillance de l’application. Si la valeur est supérieure à 0, l’application ne traite aucune donnée.

  • lastCheckpointSizeet lastCheckpointDuration— Ces indicateurs surveillent la quantité de données stockées en état et le temps nécessaire pour passer un point de contrôle. Si les points de contrôle augmentent ou prennent du temps, l’application passe continuellement du temps à effectuer les points de contrôle et réduit le nombre de cycles de traitement réels. À certains moments, les points de contrôle peuvent devenir trop grands ou prendre tellement de temps qu’ils échouent. En plus de surveiller les valeurs absolues, les clients devraient également envisager de surveiller le taux de variation avec RATE(lastCheckpointSize) et RATE(lastCheckpointDuration).

  • numberOfFailedPoints de contrôle : cette métrique compte le nombre de points de contrôle ayant échoué depuis le démarrage de l'application. Selon l’application, il peut être tolérable que les points de contrôle échouent de temps en temps. Mais si les points de contrôle échouent régulièrement, l’application est probablement malsaine et nécessite une attention accrue. Nous recommandons de surveiller RATE(numberOfFailedCheckpoints) pour être alerté en fonction de la pente et non en fonction des valeurs absolues.