Backend processus VS tâche planifiée

Question

J'ai un certain nombre de processus dorsaux (applications Java) qui s'exécutent 24/7. Pour surveiller ces backends (c'est-à-dire pour vérifier si un processus ne répond pas et notifier via SMS/EMAIL), j'ai écrit une autre application.

Les anciens backends enregistrent désormais les pulsations à intervalles réguliers et ces nouvelles applications vérifient si elles le font régulièrement et notifient si nécessaire.

Maintenant, nous avons deux options

• soit exécuté comme une tâche planifiée, qui se déroulera après chaque (sans dire) 15 min et arrêter après avoir fait son travail ou
• Exécuter comme un autre backend traiter avec 15 min de temps de sommeil.

Le problème que nous pouvons prévoir en ce moment est le suivant: que se passe-t-il si cette application de surveillance passe à l'état de non-réponse? Donc, ma question est Y at-il une différence entre les deux cas ou les deux sont les mêmes? Quelle option conviendrait le mieux à mon cas?

S'il vous plaît noter que ceci est un cas particulier et n'est pas identique à this ou this

Environnement: Java, hébergé sur le serveur LINUX

Answer 1

Par tâche planifiée, voulez-vous dire déclenchée par le planificateur système ou en tant que thread planifié dans les processus backend existants?

Pour capturer une terminaison inattendue ou des états qui ne répondent pas, il est préférable d'exécuter un processus distinct plutôt qu'un thread. Cependant, un thread programmé vous donnera une interaction plus étroite avec le processus propriétaire avec moins de surcharge IPC.

Je voudrais implémenter les deux. Conservez un enregistrement de l'état local dans chaque processus backend, avec une tâche planifiée dans chaque processus déclenchant un thread pour mettre à jour l'état actuel de ce nœud. Cette mise à jour pourrait être assez fréquente, car elle coûtera moins cher que de communiquer avec un processus distinct. Utilisez votre processus de "surveillance continue" distinct pour collecter régulièrement les informations sur tous les processus dorsaux. Cela devrait se produire moins fréquemment - si le processus est en cours d'exécution tout le temps, ou planifié par un travail cron est sans importance puisque l'état est détenu dans chaque processus de backend. Si l'un des backends ne répond plus, cette application de surveillance sera capable de déterminer le manque de réponse et d'effectuer des sondages significatifs pour déterminer quel est le problème. Ce sera ce composant qui notifiera alors votre utilitaire SMS/Email pour envoyer un rapport.

Answer 2

Je pencherais pour un processus back-end car il peut maintenir état jeter un oeil à l'ordonnanceur de quartz de la terre cuite http://terracotta.org/products/quartz-scheduler

Il sera résilient à trans et vous n'avez besoin que d'une simple enveloppe pour que l'application du moniteur soit robuste, à condition que vous obteniez le contenu du thread dans le fichier quartz.properties.

Answer 3

Vous pouvez utiliser nagios core comme core et Naptor pour surveiller votre application. C'est facile à installer et à intégrer dans le développement de votre application.

Vous pouvez vérifier à ce lien: https://github.com/agunghakase/Naptor/tree/ver1.0.0