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 pour envoyer de façon automatisée les journaux d'application à Cloud Logging en utilisant bibliothèques clientes ou à l'aide d'un de l'agent Logging. Les agents Logging envoient des données écrites dans un fichier, comme stdout ou un fichier, en tant que journaux dans Cloud Logging. Des services tels que Google Kubernetes Engine, l'environnement flexible App Engine et Cloud Functions disposent de l'agent Logging. Pour Compute Engine, vous pouvez installer Agent Ops ou ancien agent Cloud Logging. Ces agents collectent les journaux à partir d'emplacements de fichiers connus ou de journaux services tels que Windows Event Log, journald ou syslogd.

Lorsque vous ne pouvez pas utiliser une bibliothèque cliente ou un agent Logging, ou lorsque vous pouvez uniquement effectuer des tests, vous pouvez écrire des journaux gcloud logging write ou en envoyant des commandes HTTP au point de terminaison de l'API Cloud Logging entries.write. L'API Cloud Logging est compatible avec HTTP et gRPC. L'agent Ops et la plupart des clients Logging appellent l'API Logging gRPC. L'ancienne version de Logging et les bibliothèques clientes et d'agents pour certains langages appellent la méthode l'API 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 depuis systèmes sur site à Logging, nous vous recommandons d'utiliser BindPlane de observIQ : Pour en savoir plus sur BindPlane, consultez À propos d'observIQ et de BindPlane

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

Le service Google Cloud qui exécute votre application
é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 des agents pour envoyer des journaux à votre projet Google Cloud. Vous pouvez utiliser un framework de journalisation établi le langage de votre choix (Go, Node.js ou Python, par exemple) pour envoyer des journaux Connexion à des produits compatibles avec les règles stdout et stderr par défaut. L'avantage de s'appuyer sur stdout et stderr au lieu d'utiliser des bibliothèques clientes, c'est que les plantages de l'application l'envoi de journaux à votre projet. Pour en savoir plus sur l'envoi journaux structurés à stdout et stderr, consultez la section Votre application peut-elle modifier le format du journal ?

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 non compatibles envoyant automatiquement les journaux écrits dans stdout et stderr à votre d'un projet Google Cloud, vous pouvez collecter stdout et stderr se connectent aux fichiers sur disque et configurent l'agent pour les récupérer et les envoyer à Logging. Pour plus d'informations, consultez le guide de configuration de l'agent Ops ou 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 utilisez ce daemon pour envoyer vos journaux à Logging, puis utilisez 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 la ancien agent Monitoring ou 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 journaux structurés. Logging reconnaît les journaux structurés si vous les envoyez 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 stables et Open Source: Fluent Bit pour la collecte de journaux et Collecteur OpenTelemetry pour la collecte de métriques
      • Vous pouvez collecter à la fois des journaux et des métriques applications; consultez la page Surveiller et collecter les journaux applications.
      • 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.

  • 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.

  • Journaux stdout et stderr 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.