Lequel devez-vous utiliser : agent Logging ou bibliothèque cliente ?

Ce document fournit les informations dont vous avez besoin pour vous aider à décider si vous souhaitez envoyer de manière automatisée des journaux d'application à Cloud Logging à l'aide de bibliothèques clientes ou d'un agent de journalisation. Les agents Logging envoient les données écrites dans un fichier, tel que stdout ou un fichier, sous forme de journaux à Cloud Logging. Des services tels que Google Kubernetes Engine, l'environnement flexible App Engine et Cloud Functions contiennent un agent de journalisation intégré. Pour Compute Engine, vous pouvez installer l'agent Ops ou l'ancien agent Cloud Logging. Ces agents collectent des journaux à partir d'emplacements de fichiers connus ou de services de journalisation tels que Windows Event Log, journald ou syslogd.

Lorsque vous ne pouvez pas utiliser de bibliothèque cliente ni d'agent Logging, ou si vous souhaitez uniquement effectuer des tests, vous pouvez écrire des journaux à l'aide de la commande gcloud logging write ou en envoyant des commandes HTTP au point de terminaison entries.write de l'API Cloud Logging. L'API Cloud Logging prend en charge les appels HTTP et gRPC. L'agent Ops et la plupart des bibliothèques clientes Logging appellent l'API Logging gRPC. Pour certains langages, l'ancien agent Logging et les anciennes bibliothèques clientes appellent l'API REST Logging.

Choisir un agent ou des bibliothèques clientes

Lorsque vous décidez entre un agent et les bibliothèques clientes, posez-vous les questions suivantes :

Votre application s'exécute-t-elle en dehors de Google Cloud ?

Si votre application ne s'exécute pas sur Google Cloud, vous devez pouvoir envoyer des journaux à l'API Logging. Pour acheminer les journaux des systèmes sur site vers Logging, nous vous recommandons d'utiliser BindPlane by observIQ. Pour en savoir plus sur BindPlane, consultez À propos d'observIQ et de BindPlane.

Vous pouvez également acheminer les journaux vers Logging directement depuis l'application à l'aide de bibliothèques clientes. Pour les environnements éphémères, tels que l'informatique sans serveur, vous devez utiliser des bibliothèques clientes pour appeler directement l'API Logging.

Le service Google Cloud exécutant votre application gère-t-il
écrire des contenus stdout et stderr dans votre projet ?

Certains services Google Cloud sont entièrement gérés. Vous n'avez donc pas besoin d'utiliser d'agents pour envoyer des journaux à votre projet Google Cloud. Vous pouvez utiliser n'importe quel framework de journalisation établi dans le langage de votre choix, tel que Go, Node.js et Python, pour envoyer des journaux à Logging dans les produits où stdout et stderr sont compatibles par défaut. S'appuyer sur stdout et stderr au lieu d'utiliser des bibliothèques clientes présente un avantage : les plantages de l'application n'empêchent pas l'envoi de journaux à votre projet. Pour en savoir plus sur l'envoi de journaux structurés via stdout et stderr, consultez la section Votre application a-t-elle la possibilité de modifier le format des journaux ?.

Vous pouvez utiliser les bibliothèques clientes Logging, mais gardez à l'esprit qu'elles peuvent introduire une dépendance à Logging pour les tests locaux lorsque vous n'en avez pas nécessairement besoin. L'utilisation des bibliothèques clientes peut également nécessiter un codage plus complexe pour gérer explicitement la mise en mémoire tampon et les nouvelles tentatives. En outre, chaque utilisation des bibliothèques clientes de Logging crée un flux de connexion à l'API. Ces nouvelles connexions accroissent la complexité, utilisent des ports supplémentaires et n'envoient des requêtes distinctes qu'avec les journaux de l'application, ce qui peut être inutile s'il y a peu de journaux.

Les journaux d'application doivent-ils être accessibles dans votre environnement local ?

Si vous devez accéder aux journaux d'application dans votre environnement local à des fins de débogage et autres, vous pouvez utiliser les modules de journalisation dans certains langages pour générer les données stdout et stderr. Les bibliothèques clientes de Logging pour certains langages sont compatibles avec le routage des journaux vers stdout et stderr.

Lorsque vous exécutez votre application dans des services Google Cloud qui ne sont pas compatibles avec l'envoi automatique des journaux écrits sur stdout et stderr dans votre projet Google Cloud, vous pouvez collecter les journaux stdout et stderr dans les fichiers sur disque, et configurer l'agent pour qu'il récupère ces journaux et les envoie à Logging. Pour en savoir plus, consultez le guide de configuration de l'agent Ops ou de l'ancien agent Logging.

Le processus d'installation de l'agent est-il manuel ou automatique ?

Certains services installent les agents automatiquement ou vous permettent d'installer les agents vous-même. Si le service que vous utilisez ne vous permet pas d'installer des agents, vous devez utiliser les bibliothèques clientes pour utiliser Logging.

Exécutez-vous déjà Fluentd dans votre système ?

L'ancien agent Logging est basé sur Fluentd.

Si Fluentd est déjà en cours d'exécution dans votre système et que vous souhaitez utiliser ce daemon pour envoyer vos journaux à Logging, utilisez le plug-in Google Cloud Logging pour fluentd.

Collectez-vous également des métriques d'application pour Cloud Monitoring ?

Dans les VM Compute Engine, l'agent Ops peut collecter les journaux et la plupart des métriques. Pour en savoir plus, consultez la section Fonctionnalités de l'agent Ops.

Si l'agent Ops ne répond pas à vos cas d'utilisation, vous pouvez utiliser l'ancien agent Monitoring ou les bibliothèques clientes Monitoring pour collecter vos métriques.

Votre application peut-elle modifier le format des journaux ?

Cette question vous aide à décider si votre application peut générer des journaux structurés. Logging reconnaît les journaux structurés si vous les envoyez à l'API Logging au format de journalisation structurée. Les bibliothèques clientes fournissent les méthodes permettant de gérer ce format.

Il existe deux façons d'écrire des journaux structurés : la première consiste à définir des champs spécifiques dans l'enveloppe LogEntry et l'autre à définir le champ jsonPayload dans l'enveloppe LogEntry. Le premier schéma est déterminé par Cloud Logging, tandis que le second est déterminé par l'utilisateur.

Vous devez configurer l'agent pour qu'il reconnaisse les journaux structurés. Par défaut, les agents sont configurés pour détecter les journaux au format JSON et les gérer en tant que journaux structurés. Si votre application possède son propre format de journal que vous ne pouvez pas modifier, mais que vous souhaitez que les journaux soient reconnus comme des journaux structurés, vous devez écrire les journaux au format de journalisation structurée, généralement au format JSON., vers stdout et stderr, afin que les agents puissent les reconnaître en tant que journaux structurés. Sinon, vous devez configurer votre agent pour qu'il comprenne votre propre format.

Récapitulatif de chaque option

Schéma des modèles de journalisation

  • Bibliothèques clientes Cloud Logging

    • Avantages

      • Vous pouvez acheminer les journaux directement vers l'API Cloud Logging.
      • Certains langages peuvent générer des journaux vers stdout et stderr à l'aide de la bibliothèque.
    • Inconvénients

      • Les plantages de l'application empêchent l'envoi de journaux à votre projet Google Cloud.
  • Agent Ops

    • Avantages
      • L'agent Ops peut envoyer des journaux et des métriques à l'aide de technologies Open Source stables: Fluent Bit pour la collecte de journaux et le collecteur OpenTelemetry pour la collecte de métriques.
      • Vous pouvez collecter les journaux et les métriques de nombreuses applications courantes. Consultez la page Surveiller et collecter les journaux d'applications tierces.
      • Vous pouvez conserver les journaux dans votre environnement local.
      • Vous devriez pouvoir récupérer les journaux des plantages de l'application.
      • L'agent Ops est en cours de développement actif.
  • Ancien agent Logging

    • Avantages
      • L'agent utilise Fluentd pour collecter les journaux.
      • Vous pouvez conserver les journaux dans votre environnement local.
      • Vous devriez pouvoir récupérer les journaux des plantages de l'application.
    • Inconvénients
      • L'agent est actuellement compatible, mais n'est pas en cours de développement actif.
  • Les journaux stdout et stderr sont automatiquement envoyés à votre projet Google Cloud.

    • Avantages
      • Ce processus est un moyen courant d'émettre des journaux vers des environnements locaux.
      • Vous pouvez utiliser des bibliothèques de journalisation arbitraires.
      • Vous devriez pouvoir récupérer les journaux des plantages de l'application.
    • Inconvénients
      • Certains environnements n'acheminent pas les journaux vers Logging automatiquement.