log Paramètre

Utilisez log pour activer les données de journalisation à des fins de surveillance, de débogage, de diagnostic, de traitement des incidents, de sécurité, d'optimisation des performances d'audit, de visibilité et d'analyse historique. Le site IBM® Sterling Intelligent Promising écrit par défaut les journaux du niveau de l'application sur la console. Toutefois, vous pouvez choisir de rediriger ces journaux vers Kafka à l'aide de l'appender Log4j2 Kafka .

Consignation de la console par défaut

La consignation de la console est activée par défaut. Pour accéder aux journaux, utilisez les commandes kubectl ou oc . Lorsqu'un conteneur est redémarré, supprimé ou recréé, les anciens journaux sont effacés.

Log4j2 Kafka

Utilisez l'appender Log4j2 Kafka pour envoyer des messages de journal à une rubrique Kafka . Pour utiliser l'appender Log4j2 Kafka , vous devez disposer d'un cluster Kafka configuré et en cours d'exécution. Tous les services IBM Sterling Intelligent Promising ont une prise en charge intégrée pour l'appender Kafka Lo4j2 .

Le tableau suivant décrit les propriétés facultatives qui s'appliquent à log.
Propriété Valeur par défaut Type de valeur Obligatoire Descriptif
logChannels CONSOLE chaîne Non Définir le canal de sortie du journal. Par défaut, la consignation de la console est activée. Si vous souhaitez utiliser l'appendice Log4j2 Kafka pour la journalisation, définissez la valeur logChannels sur KAFKA. Si elle est définie sur KAFKA, spécifiez les propriétés spécifiques à Kakfa. Seule la présentation GELF est prise en charge implicitement.

S'il est défini sur CONSOLE, les options de mise en page prises en charge sont PATTERN par défaut ou GELF .
logLevel INFO chaîne Non Cette propriété permet de remplacer le niveau de journalisation au niveau de chaque serveur. Les valeurs autorisées sont OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE, ALL. Pour plus d'informations, voir Types de logLevel et préséance.
logTopic chaîne Non Si vous sélectionnez Kafka pour la journalisation, indiquez la rubrique dans laquelle vous souhaitez consigner les données. logTopic n'est pas applicable pour la consignation de la console par défaut.
console.layout PATTERN chaîne Non

Spécifiez le format de présentation de la console uniquement lorsque logChannels est CONSOLE.

Les valeurs autorisées sont PATTERN, GELF.
logExtraFields

matrice Non Spécifiez la liste des paires clé-valeur supplémentaires à inclure dans chaque entrée du journal. Ces valeurs peuvent également provenir de variables d'environnement.

Attributs personnalisés dans les métadonnées de journal

Les utilitaires de journalisation incluent les attributs personnalisés suivants afin d'améliorer les fonctions de débogage pour la console par défaut et la consignation de l'appender Log4j2 Kafka .
CENTRE DE DONNEES
Nom du cluster de calcul dans lequel vous hébergez et gérez le déploiement Sterling Intelligent Promising . Par exemple, Dublin_data_center.
APP_NAME
Nom du service d'application que vous utilisez. Les valeurs autorisées peuvent être rules, cas, searchet d'autres services.
NOM_COMPONENT_
Indique si le composant est un serveur d'API ou un serveur dorsal.
NODE_NAME
Nom d'hôte du noeud worker dans le cluster.
NOM_PO
Nom du pod.
PD_IP
Adresse IP privée du pod.

Niveaux de configuration des journaux

Vous pouvez configurer les journaux aux trois niveaux suivants.

  1. Configuration globale du canal d'enregistrement

    Définir la propriété logChannels avec KAFKA ou CONSOLE dans l' environnement SIP de manière globale. Cette configuration du journal est applicable à tous les services Sterling Intelligent Promising .

  2. Configuration du niveau de journalisation

    Définissez la propriété logLevel dans les champs d'application suivants.

    Niveau mondial
    La configuration à ce niveau s'applique à tous les services et serveurs Sterling Intelligent Promising .
    Niveau de service
    La configuration à ce niveau s'applique à un service spécifique de Sterling Intelligent Promising où le niveau de journalisation est défini.
    Niveau serveur
    La configuration à ce niveau s'applique à des serveurs individuels au sein d'un service Sterling Intelligent Promising particulier.

    Pour plus d'informations, voir Types de logLevel et préséance.

  3. Configuration personnalisée

    Définir des champs personnalisés tels que les noms d'environnement à inclure dans les journaux. Des configurations personnalisées peuvent être définies au niveau du groupe de services et de l' environnement SIP. Pour un serveur, l'ensemble final de champs est une combinaison des deux niveaux, les champs de niveau service étant prioritaires.

Hiérarchie de configuration

Portée Fonction Priorité
Global : SIPEnvironnement La valeur par défaut pour tous les services et serveurs. La plus faible
Niveau de service Remplace les paramètres globaux d'un service. Moyen
Niveau serveur Personnalisation pour chaque serveur. La plus élevée

Exemple de configuration du journal

L'exemple suivant montre comment définir les propriétés du journal. Dans le site logExtraFields, la valeur de key:env1 est QA. Pour la paire key:env2 la valeur provient d'une variable d'environnement définie dans la page servers.properties. Assurez-vous que le déploiement correspondant inclut cette variable d'environnement. Pour plus d'informations, voir le paramètre serverProperties.
spec:
  log:
    console:
      layout: GELF
    logLevel: DEBUG
    logChannels: CONSOLE
    logExtraFields:
      - key: env1
        value: QA
      - key: env2
        envVar: var1

Types de logLevel et préséance

La propriété logLevel peut être configurée à trois niveaux : serveur individuel, groupe de services ou global (SIPEnvironment).
Le niveau de journalisation par défaut est INFO. Les options disponibles sont les suivantes : OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE, ALL.

Journalisation au niveau du serveur individuel
Les journaux peuvent être personnalisés pour chaque instance de serveur. S'il est configuré, le niveau de journalisation du serveur individuel a la priorité sur les autres configurations.
Exemple
spec:
  active: true
  appServers:
    - active: true
      names:
        - ApiSupplies
      logLevel: DEBUG
    - active: true
      names:
        - ApiDemands
      logLevel: DEBUG
Journalisation au niveau du groupe de services
Si le niveau de journalisation n'est pas défini pour un serveur individuel, la configuration définie au niveau du groupe de services est appliquée.

Exemple

spec:
  active: true
  logLevel: DEBUG
  appServers:
    - active: true
      names:
        - ApiSupplies
    - active: true
      names:
        - ApiDemands
Journalisation au niveau global dans SIPEnvironment
Si les niveaux de journalisation pour le serveur individuel et le groupe de services ne sont pas définis, la configuration globale dans SIPEnvironment est prise en compte. Si aucun niveau de journalisation n'est explicitement défini, quel que soit le niveau, le niveau INFO par défaut est appliqué. Cette approche hiérarchique permet d'adapter le contrôle de la journalisation à chaque instance de serveur.

Exemple

spec:
  license:
    accept: true 
  secret: ""
  # log: 
  #   logChannels: CONSOLE
  #   logTopic: ""
  #   logLevel: INFO
Pour une configuration complète, voir SIPEnvironment custom resource manifest.

Configuration des journaux pour deux clusters Kafka

Si vous utilisez deux clusters Kafka , l'un pour l'application et l'autre pour la journalisation, spécifiez loggingContactPoints dans la ressource personnalisée externalServices pour Kafka. De plus, dans le secret, ajoutez les propriétés Kafka qui sont préfixées avec log_. Pour plus d'informations, voir Création d'un secret.

Si vous souhaitez utiliser le même contactPoints que celui que vous avez défini pour l'application, ne définissez pas loggingContactPoints. Par défaut, contactPoints est utilisé pour envoyer des journaux à une rubrique Kafka . Pour plus d'informations sur Kafka, voir loggingContactPoints dans le paramètre kafka.