Bonnes pratiques de surveillance

Edge pour Private Cloud version 4.17.09

Alertes de surveillance

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

Définir des seuils d'alerte

Définissez un seuil à partir duquel une alerte doit être générée. Ce que vous définissez dépend de votre configuration matérielle. Le seuil doit être défini en fonction de votre capacité. Par exemple, Apigee Il se peut que la périphérie soit trop faible si vous n'avez que 6 Go de capacité. Vous pouvez attribuer un seuil avec une valeur égale à (=) ou supérieur au critère (>). Vous pouvez également spécifier un intervalle de temps entre deux la génération d'alertes. Vous pouvez utiliser l'option heures/minutes/secondes.

Critères de paramétrage des alertes au niveau du système

Le tableau suivant décrit les critères:

Vérification des versions spécifiques à Apigee et tierces 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 2181 de ZooKeeper
• Port OpenLDAP 10389

Pour déterminer le port sur lequel chaque composant Apigee écoute les appels d'API, 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

Le résultat de ces commandes contiendra des sections semblables à celle présentée ci-dessous. La "http.management.port" section donne 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 gardent une trace des messages concernant l'événement ou le fonctionnement du système. Messages s'affichent dans le journal lorsque les processus commencent et se terminent ou lorsqu'une condition d'erreur se produit. En consultant le journal fichiers, vous pouvez obtenir des informations sur les composants du système, par exemple, CPU, mémoire, disque, charge, les processus, ainsi de suite, avant et après avoir atteint un état d'échec. Cela vous permet également d'identifier et diagnostiquer la source des problèmes actuels du système ou vous aider à prévoir un système potentiel ; des problèmes.

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 de devoir redémarrer un serveur. Le fichier logback.xml contient la propriété suivante, qui définit le fréquence à laquelle le mécanisme de journalisation recherche les modifications de configuration dans le fichier logback.xml:

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

Par défaut, le mécanisme de journalisation recherche les modifications toutes les minutes. Si vous omettez les unités de temps à l'attribut scanPeriod, la valeur par défaut est définie en millisecondes.

Le tableau suivant indique l'emplacement des fichiers journaux des composants de cloud privé Apigee Edge.

Activer les journaux de débogage pour le message Processeur et interface utilisateur Edge

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/messsage-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 redémarrage

Pour activer les journaux de débogage pour l'interface utilisateur Edge:

1. Sur le nœud d'interface utilisateur Edge, modifiez /opt/apigee/customer/application/ui.properties. Si ce fichier n'existe pas, créez-le.
2. Ajoutez la propriété suivante au fichier:
   conf_application_logger.application=DEBUG
3. Redémarrez l'interface utilisateur Edge:
   > /opt/apigee/apigee-service/bin/apigee-service redémarrage de l'interface utilisateur périphérique

Outils de surveillance

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