Bonnes pratiques de surveillance

Alertes de surveillance

Apigee Edge vous permet de transférer des alertes vers des journaux système ou des systèmes/outils de surveillance externes lorsqu' une erreur ou un échec se produit en raison de l'échec d'un événement. Ces alertes peuvent être des alertes/événements au niveau du système ou de l'application. Les alertes au niveau de l'application sont principalement des alertes personnalisées qui sont créées en fonction des événements générés. L'administrateur réseau configure généralement les conditions personnalisées. Pour en savoir plus sur les alertes, contactez l'assistance Apigee.

Définir les seuils d'alerte

Définissez un seuil au-delà duquel une alerte doit être générée. Ce que vous définissez dépend de la configuration de votre matériel. Le seuil doit être défini par rapport à votre capacité. Par exemple, Apigee Edge peut être trop bas si vous ne disposez que de 6 Go de capacité. Vous pouvez attribuer un seuil avec un critère égal à (=) ou supérieur à (>). Vous pouvez également spécifier un intervalle de temps entre deux générations d'alertes consécutives. Vous pouvez utiliser l'option heures/minutes/secondes.

Critères de définition des alertes au niveau du système

Le tableau suivant décrit les critères :

Vérifier les ports spécifiques à Apigee et tiers Ports

Surveillez les ports suivants pour vous assurer qu'ils sont actifs.

• Ports 4526, 4527 et 4528 sur le serveur de gestion, le routeur et le processeur de messages
• Ports 1099, 1100 et 1101 sur le serveur de gestion, le routeur et le processeur de messages
• Ports 8081 et 15999 sur les routeurs
• Ports 8082 et 8998 sur les processeurs de messages
• Port 8080 sur le serveur de gestion

Vérifiez que les ports tiers suivants sont actifs :

• Port Qpid 5672
• Port Postgres 5432
• Ports Cassandra 7000, 7199, 9042, 9160
• Port ZooKeeper 2181
• Port SymasLDAP 10389

Pour déterminer sur quel port chaque composant Apigee écoute les appels d'API, envoyez les appels d'API suivants au serveur de gestion (qui se trouve généralement sur le port 8080) :

curl -v -u username:password http://host:port/v1/servers?pod=gateway&region=dc-1
curl -v -u username:password http://host:port/v1/servers?pod=central&region=dc-1
curl -v -u username:password http://host:port/v1/servers?pod=analytics&region=dc-1

La sortie de ces commandes contient des sections semblables à celles présentées ci-dessous. La section http.management.port indique le numéro de port du composant spécifié.

{
  "externalHostName" : "localhost",
  "externalIP" : "111.222.333.444",
  "internalHostName" : "localhost",
  "internalIP" : "111.222.333.444",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "default",
  "tags" : {
    "property" : [ {
      "name" : "Profile",
      "value" : "Router"
    }, {
      "name" : "rpc.port",
      "value" : "4527"
    }, {
      "name" : "http.management.port",
      "value" : "8081"
    }, {
      "name" : "jmx.rmi.port",
      "value" : "1100"
    } ]
  },
  "type" : [ "router" ],
  "uUID" : "2d4ec885-e20a-4173-ae87-10be38b35750"
}

Afficher les journaux

Les fichiers journaux suivent les messages concernant l'événement/l'opération du système. Les messages s'affichent dans le journal lorsque les processus commencent et se terminent, ou lorsqu'une condition d'erreur se produit. En affichant les fichiers journaux , vous pouvez obtenir des informations sur les composants du système (par exemple, le processeur, la mémoire, le disque, la charge, les processus, etc.) avant et après avoir atteint un état d'échec. Cela vous permet également d'identifier et de diagnostiquer la source des problèmes système actuels ou de vous aider à prévoir les problèmes système potentiels.

Par exemple, un journal système typique d'un composant contient les entrées suivantes, comme illustré ci-dessous :

TimeStamp = 25/01/13 19:25 ; NextDelay = 30
Memory
HeapMemoryUsage = {used = 29086176}{max = 64880640} ;
NonHeapMemoryUsage = {init = 24313856}{committed = 57278464} ;
Threading
PeakThreadCount = 53 ; ThreadCount = 53 ;
OperatingSystem
SystemLoadAverage = 0.25 ;

Vous pouvez modifier le fichier /opt/apigee/conf/logback.xml pour contrôler le mécanisme de journalisation sans avoir à redémarrer un serveur. Le fichier logback.xml contient la propriété suivante, qui définit la fréquence à laquelle le mécanisme de journalisation vérifie le fichier logback.xml pour détecter les modifications de configuration :

<configuration scan="true" scanPeriod="30 seconds" >

Par défaut, le mécanisme de journalisation vérifie les modifications toutes les minutes. Si vous omettez les unités de temps de l'attribut scanPeriod, la valeur par défaut est la milliseconde.

Le tableau suivant indique l'emplacement des fichiers journaux des composants Apigee Edge Private Cloud.

Activer les journaux de débogage pour le processeur de messages

Pour activer les journaux de débogage pour le processeur de messages :

1. Sur le nœud du processeur de messages, modifiez /opt/apigee/customer/application/message-processor.properties. Si ce fichier n'existe pas, créez-le.
2. Ajoutez la propriété suivante au fichier :

   conf_system_log.level=DEBUG

3. Redémarrez le processeur de messages :

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Bonnes pratiques concernant apigee-monit

Lorsque vous utilisez apigee-monit, Apigee vous recommande de procéder comme suit :

• Arrêtez la surveillance d'un composant avant d'effectuer une opération qui le démarre ou l'arrête, comme une sauvegarde ou une mise à niveau.
• Surveillez apigee-monit à l'aide d'un outil tel que cron. Pour en savoir plus, consultez Surveiller apigee-monit.

Outils de surveillance

Les outils de surveillance tels que Nagios, Collectd, Graphite, Splunk, Sumologic et Monit peuvent vous aider à surveiller l'ensemble de votre environnement d'entreprise et de vos processus métier.