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

Cloud Logging fournit plusieurs mécanismes permettant d'interagir avec l'API Cloud Logging v2 : les agents Logging et les bibliothèques clientes Logging Les agents, à la fois l'agent Ops et l'ancien agent Logging, et les bibliothèques clientes Logging appellent l'API gRPC Logging. Pour certains langages, l'ancien agent Logging et les bibliothèques clientes appellent l'API REST Logging.

L'une des principales différences entre ces mécanismes est leur mode d'appel de l'API Logging. Une application utilisant les bibliothèques clientes appelle directement l'API, mais un agent sert de proxy pour vos applications. Si vous faites appel à des agents, vos applications peuvent utiliser n'importe quel framework de journalisation établi pour émettre des journaux. Dans les environnements de conteneurs comme Google Kubernetes Engine ou Container-Optimized OS, les agents collectent par défaut les journaux de stdout et stderr. Sur les VM, les agents collectent les journaux à partir d'emplacements de fichiers ou de services de journalisation connus, tels que le journal des événements Windows, journald ou syslogd.

Cette page fournit des informations sur les agents Logging et les bibliothèques clientes pour vous aider à décider si vous souhaitez envoyer des journaux à Cloud Logging à l'aide de bibliothèques clientes ou d'un agent.

Choisir des agents 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. Dans ce cas, vous pouvez acheminer les journaux vers Logging directement à partir de 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.

Pour acheminer les journaux des systèmes sur site vers Logging, vous pouvez également utiliser BindPlane de Blue Medora.

Le service Google Cloud qui exécute votre application est-il compatible avec l'ingestion automatique des journaux via stdout et stderr ?

Certains services Google Cloud sont entièrement gérés. Vous n'avez donc pas besoin d'utiliser d'agents pour acheminer les journaux. Vous pouvez utiliser n'importe quel framework de journalisation établi dans le langage de votre choix, tel que Go, Node.js et Python, pour acheminer les journaux vers Logging dans des produits où stdout et stderr sont disponibles. par défaut. L'ingestion de journaux via stdout et stderr au lieu d'utiliser des bibliothèques clientes présente l'avantage de ne pas interrompre les ingestions de journaux d'application. Pour en savoir plus sur l'ingestion de journaux structurés via stdout et stderr, consultez la section Votre application peut-elle 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 non compatibles avec l'ingestion automatique des journaux via stdout et stderr, vous pouvez collecter les journaux stdout et stderr sur le disque et configurer l'agent pour les scraper et les envoyer à Logging. Pour plus d'informations, consultez le guide de configuration de l'agent Ops ou de l'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 sur votre système et que vous souhaitez également utiliser ce daemon pour l'ingestion dans 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 Cloud 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éterminer si vous pouvez ingé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 interrompent l'ingestion des journaux.
  • Agent Ops

    • Avantages
      • L'agent Ops accepte l'ingestion de journaux et de métriques à l'aide de technologies Open Source stables : Fluent Bit pour la collecte de journaux et OpenTelementry Collector pour la collecte de métriques.
      • Vous pouvez conserver les journaux dans votre environnement local.
      • Vous devriez pouvoir récupérer les journaux des plantages de l'application.
  • 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.
  • Ingestion automatique des journaux stdout et stderr.

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