Résoudre les problèmes de configuration d'Observability Analytics

Ce document explique comment résoudre les erreurs qui peuvent se produire lorsque vous utilisez la page Observability Analytics de la Google Cloud console.

Messages d'erreur

Cette section décrit les messages d'erreur que vous pouvez voir et comment résoudre les conditions d'erreur correspondantes.

Message d'erreur No completion signal within allotted timeframe

Vous saisissez une requête SQL et sélectionnez Exécuter la requête. La requête ne se termine pas et le message d'erreur suivant s'affiche :

The query failed to execute and return results due to error: No completion signal within allotted timeframe.

Pour résoudre cette erreur, effectuez l'une des opérations suivantes :

  • Raccourcissez l'intervalle sur lequel les journaux sont interrogés, puis réessayez la requête. Par exemple, si l'intervalle d'une requête est de 14 jours, raccourcissez-le à 7 jours, puis exécutez la requête.

  • Créez un ensemble de données BigQuery associé puis exécutez la requête à partir de l'interface BigQuery. L'interface BigQuery accepte les requêtes qui nécessitent un temps d'exécution plus long que l'interface Cloud Logging. Pour en savoir plus, consultez la section Interroger un ensemble de données BigQuery associé.

Message d'erreur "Queries against buckets with distinct CMEK keys"

Vous saisissez une requête SQL qui interroge plusieurs buckets de journaux et sélectionnez Exécuter la requête. La requête ne se termine pas et le message d'erreur suivant s'affiche :

Queries against buckets with distinct CMEK keys must have a key configured in the LogSettings.

Pour résoudre ce problème, effectuez l'une des opérations suivantes :

  • Configurez vos buckets de journaux pour qu'ils utilisent la même clé Cloud Key Management Service (Cloud KMS).
  • Lorsque les buckets de journaux se trouvent au même emplacement, vous pouvez configurer un dossier ou une organisation qui est une ressource parente pour les buckets de journaux avec une clé Cloud KMS par défaut. La clé par défaut du parent doit se trouver au même emplacement que les buckets de journaux. Avec cette configuration, la clé par défaut du parent chiffre toutes les données temporaires générées par la requête Observability Analytics. Pour en savoir plus, consultez la section Restrictions d'Observability Analytics.

Message d'erreur "FROM clause must contain exactly one view"

Vous saisissez une requête SQL dans le volet de requête de la page Observability Analytics de la Google Cloud console, mais l'analyseur SQL affiche l'erreur suivante :

FROM clause must contain exactly one log view

L'erreur précédente est signalée lorsque la table spécifiée dans l'instruction FROM ne peut pas être résolue en une vue de journal spécifique.

Pour résoudre cette erreur, assurez-vous que le nom de votre table respecte la syntaxe appropriée :

  • Assurez-vous que le nom de la table respecte la syntaxe requise par le schéma de dénomination d'Observability Analytics. BigQuery et Observability Analytics ont des exigences différentes pour le nom de la table. Vous pouvez trouver la syntaxe requise pour le nom de la table en affichant la requête par défaut.

  • Si l'ID de Google Cloud projet, la région, l'ID de bucket ou l'ID de vue d'un bucket de journaux contient des points (.), assurez-vous que chacun de ces champs est placé entre accents graves simples (`).

    Par exemple, si un Google Cloud ID de projet est example.com:bluebird, alors pour interroger la vue _AllLogs du bucket de journaux _Default, utilisez la syntaxe suivante pour spécifier la table :

    
SELECT *
FROM `example.com:bluebird`.`global`.`_Default`.`_AllLogs`

    La requête précédente suppose que le bucket _Default se trouve dans la région global.

Impossible d'enregistrer une requête

Vous souhaitez enregistrer votre requête actuelle. Vous l'exécutez, puis cliquez sur Enregistrer. Toutefois, l'option Enregistrer la requête est désactivée ou vous ne pouvez pas suivre les étapes de la boîte de dialogue.

Cet échec est dû à un conflit entre une règle d'administration et les paramètres de ressource par défaut pour Cloud Logging. Pour une organisation ou un dossier, vous pouvez configurer les paramètres de ressource par défaut pour Cloud Logging qui spécifient un emplacement. C'est là que vos requêtes enregistrées sont stockées. Toutefois, si l'emplacement est en conflit avec une règle d'administration, vos requêtes ne peuvent pas être enregistrées.

Pour résoudre cet échec, demandez à l'administrateur de votre organisation de mettre à jour les paramètres de ressource par défaut pour Cloud Logging afin que le paramètre d'emplacement soit autorisé par votre règle d'administration. Pour en savoir plus, consultez la section Configurer les paramètres de ressource par défaut pour Cloud Logging.

Si l'option Enregistrer la requête est activée, mais que vous ne parvenez pas à terminer la boîte de dialogue et à enregistrer la requête, procédez comme suit :

  1. Assurez-vous que la requête ne contient pas d'erreurs de syntaxe. Vous ne pouvez enregistrer que les requêtes valides.
  2. (Facultatif) Copiez la requête dans le presse-papiers.
  3. Actualisez la page.
  4. Si vous avez copié la requête dans le presse-papiers, collez-la dans le volet Requête, exécutez-la, puis effectuez l'opération d'enregistrement.

Impossible de créer une vue Analytics

Vous souhaitez créer une vue Analytics. Vous saisissez et exécutez une requête SQL, puis cliquez sur Enregistrer . Toutefois, l'option Enregistrer en tant que vue Analytics est désactivée.

Pour résoudre ce problème, assurez-vous que vos rôles IAM incluent les autorisations suivantes :

  • observability.analyticsViews.{get, list, create, update, delete}

Ces autorisations ne sont incluses dans aucun rôle Cloud Logging prédéfini. Pour en savoir plus sur les rôles requis, consultez la section Créer et interroger des vues Analytics : avant de commencer.

Impossible d'interroger une vue Analytics

Vous souhaitez interroger une vue Analytics, mais le volet Vues de la page Observability Analytics n'affiche aucune vue Analytics.

Pour résoudre cet échec, essayez les solutions suivantes :

  • Assurez-vous que vos rôles IAM incluent les autorisations suivantes :

    • observability.analyticsViews.{get, list}

    Ces autorisations ne sont incluses dans aucun rôle Cloud Logging prédéfini. Pour en savoir plus sur les rôles requis, consultez la section Créer et interroger des vues Analytics : avant de commencer.

  • Assurez-vous que des vues Analytics existent dans votre Google Cloud projet.

Accès refusé à la page Observability Analytics

Vous ouvrez la page Observability Analytics dans la Google Cloud console et un message d'erreur "Autorisation refusée" s'affiche.

Pour obtenir les autorisations nécessaires pour charger la page Observability Analytics, exécuter des requêtes et afficher les journaux, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou Logging des rôles prédéfinis.

Les autorisations dont vous avez besoin pour afficher les entrées de journal et exécuter des requêtes sur la page Observability Analytics sont les mêmes que celles dont vous avez besoin pour afficher les journaux sur la page Explorateur de journaux. Pour en savoir plus sur les rôles supplémentaires dont vous avez besoin pour interroger des vues sur des buckets définis par l'utilisateur ou pour interroger la vue _AllLogs du bucket de journaux _Default, consultez la section Rôles Cloud Logging.

Échec de la mise à niveau du bucket de journaux pour utiliser Observability Analytics

Vous créez un bucket de journaux et sélectionnez l'option permettant d'utiliser Observability Analytics, ou vous mettez à niveau un bucket de journaux existant pour utiliser Observability Analytics. La mise à niveau échoue avec une condition d'erreur semblable à la suivante :

Failed precondition (HTTP 400): Constraint "my-constraint" violated for PROJECT_ID  with location global.

Le message d'erreur précédent indique que votre organisation a configuré une règle d'administration qui limite les régions pouvant être utilisées. Les buckets de journaux pouvant être mis à niveau pour utiliser Observability Analytics doivent utiliser la région global. Si vous pouvez supprimer la règle d'administration qui limite l'utilisation de la région global, vous pouvez mettre à niveau votre bucket de journaux. Sinon, vous ne pouvez pas mettre à niveau vos buckets de journaux.

Échec de la création d'un ensemble de données BigQuery associé

Vous modifiez un bucket de journaux pour créer un ensemble de données BigQuery associé ou vous créez un bucket de journaux et sélectionnez l'option permettant de créer un ensemble de données associé. Toutefois, l'ensemble de données associé n'est pas créé.

Pour résoudre cette erreur, demandez à l'administrateur système du Google Cloud projet de vous accorder un rôle IAM incluant l'autorisation suivante :

  • logging.links.create

L'autorisation précédente est incluse dans les rôles Administrateur Logging (roles/logging.admin) et Rédacteur de configuration des journaux (roles/logging.configWriter).

Pour en savoir plus sur les rôles et les autorisations, consultez Contrôle des accès avec IAM.

Échec de la suppression d'un ensemble de données BigQuery associé

Vous ne souhaitez plus utiliser l'ensemble de données associé, mais l'option permettant de le supprimer est désactivée.

Pour résoudre cette erreur, demandez à l'administrateur système du Google Cloud projet de vous accorder un rôle IAM incluant l'autorisation suivante :

  • logging.links.delete

L'autorisation précédente est incluse dans les rôles Administrateur Logging (roles/logging.admin) et Rédacteur de configuration des journaux (roles/logging.configWriter).

Cette autorisation vous permet de supprimer l'ensemble de données associé de la page Stockage des journaux de la Google Cloud console. Pour en savoir plus sur les rôles et les autorisations, consultez Contrôle des accès avec IAM.

Observability Analytics affiche un avertissement concernant les métadonnées sensibles

La page Observability Analytics affiche un message semblable à celui-ci :

This SQL query is configured to run on the BigQuery engine using [PROJECT_ID],
and references resources from [RESOURCE, ...]. Sensitive metadata,
including table contents, may be written to [PROJECT_ID].

Le message d'avertissement indique que la requête dépasse les limites de propriété et vous permet de la vérifier avant son exécution. Les limites de propriété sont déterminées par plusieurs facteurs, dont la hiérarchie des ressources utilisées par la requête.

Vous ne pouvez pas empêcher ces types d'avertissements.

Si la page Observability Analytics affiche une boîte de dialogue d'avertissement, vous pouvez effectuer l'une des opérations suivantes :

  • Si vous savez que la requête peut être exécutée en toute sécurité et que vous souhaitez afficher les résultats, cliquez sur Confirmer et exécuter.

  • Analysez la requête et, si nécessaire, supprimez-la. Par exemple, vous pouvez procéder comme suit :

    1. Inspectez la requête. Lors de votre inspection, tenez compte des données interrogées, de la taille potentielle de l'ensemble de données interrogé et du moteur de requête. Les requêtes exécutées sur le service BigQuery peuvent entraîner des frais.
    2. Si vous avez reçu un lien vers la page Observability Analytics, vérifiez que l'expéditeur est une source de confiance.

Google Cloud offre certaines fonctionnalités qui peuvent aider à empêcher l'exfiltration de données par hameçonnage, attaques internes ou entités externes. Pour en savoir plus, consultez la section Sécurité des données avec Observability Analytics.

Impossible de définir le moteur de requête sur BigQuery

L'option BigQuery est désactivée dans le menu Paramètres.

Pour activer cette option, assurez-vous qu'un ensemble de données BigQuery associé est présent dans le bucket de journaux qui est interrogé.

Le bouton "Exécuter sur BigQuery" est désactivé

Si le bouton Exécuter sur BigQuery s'affiche, mais qu'il est désactivé, cela signifie qu'une vue de journal référencée par votre requête ne comporte pas d'ensemble de données associé. Pour exécuter votre requête sur le moteur BigQuery, créez un ensemble de données BigQuery associé dans votre bucket de journaux.

Aucun compte de service Monitoring

Vous souhaitez créer une règle d'alerte pour surveiller les résultats d'une requête SQL. Les étapes de configuration vous ont demandé d'accorder des rôles IAM au compte de service Monitoring, mais ce compte n'existe pas.

Le compte de service Monitoring est appelé agent de service, car il est créé et géré par Google Cloud. Le compte est créé automatiquement lorsque vous configurez une ressource ou un service qui le nécessite. Par exemple, si vous créez un canal de notification Pub/Sub, cette action peut entraîner la création du compte de service Monitoring.

Pour créer le compte de service de surveillance et lui accorder les autorisations requises pour les règles d'alerte basées sur SQL, procédez comme suit :

  1. Créez le compte de service Monitoring. Pour en savoir plus, consultez la section Créer et attribuer des rôles aux agents de service.

  2. Attribuez les rôles suivants au compte de service Monitoring :

Erreur "Autorisation refusée" pour le compte de service Monitoring

Vous souhaitez créer une règle d'alerte pour surveiller les résultats d'une requête SQL. Toutefois, vous voyez une erreur PermissionDenied avec un message commençant par Error authenticating service account.

Pour résoudre cet échec, attribuez les rôles suivants au compte de service Monitoring :

Des entrées de journal en double figurent dans mes résultats Observability Analytics

Vous exécutez une requête qui compte ou signale des entrées en double. Étant donné que l'explorateur de journaux supprime les entrées en double en fonction du nom du journal, de l'horodatage et de l'ID d'insertion, vous vous attendez à ce qu'Observability Analytics déduplique les entrées de journal avant l'exécution d'une requête.

Observability Analytics n'effectue pas le même type de déduplication que l'explorateur de journaux.

Pour résoudre le problème des entrées de journal en double, essayez les solutions suivantes :

  1. Déterminez si les entrées de journal en double ont des valeurs d'horodatage de réception différentes. Lorsque les horodatages sont différents, cela indique que les mêmes données ont été écrites plusieurs fois dans Logging.

    Pour résoudre les écritures en double, examinez votre intégration de journalisation pour détecter les messages d'erreur ou les erreurs de configuration.

  2. Si votre bucket est configuré pour utiliser des clés Cloud Key Management Service, assurez-vous que vous respectez le quota et que votre clé est accessible de manière cohérente . Le dépassement du quota ou la perte d'accès à la clé peuvent entraîner des entrées de journal en double.

    Pour résoudre ces échecs, assurez-vous de ne pas dépasser votre quota et que votre clé est accessible.

  3. Modifiez votre requête pour supprimer les entrées de journal en double.

    Par exemple, supposons que la charge utile JSON contienne fieldA et fieldB, la première étant une chaîne et la seconde un nombre. Supposons également que la charge utile JSON contienne un champ libellé server, qui contient une chaîne. Prenons ensuite l'exemple de la requête suivante :

    SELECT
  JSON_VALUE(json_payload.fieldA) AS fieldA
  SUM(IFNULL(SAFE_CAST(JSON_VALUE(json_payload.fieldB) AS INT64), 0)) AS sum_fieldB
FROM
  `VIEW`
WHERE
  JSON_VALUE(json_payload.server) = "test"
GROUP BY
  fieldA;

    Vous pouvez modifier la requête pour supprimer les entrées de journal en double, où le nom du journal, l'horodatage et l'ID d'insertion sont examinés pour déterminer si une entrée de journal est un doublon :

    WITH
  deduplicated AS (
  SELECT
    JSON_VALUE(json_payload.fieldA) AS fieldA
    IFNULL(SAFE_CAST(JSON_VALUE(json_payload.fieldB) AS INT64), 0) AS fieldB
  FROM
    `VIEW` a
  WHERE
    JSON_VALUE(json_payload.server) = "test"
  QUALIFY
    ROW_NUMBER() OVER (PARTITION BY a.log_name, a.timestamp, a.insert_id ) = 1 )

SELECT
  fieldA,
  SUM(fieldB) AS sum_fieldB
FROM
  deduplicated
GROUP BY
  fieldA;