Automatisation des téléchargements de journaux de déclenchement MongoDB Atlas au-delà des limitations de l'interface graphique et de la CLI

J'ai récemment rencontré un scénario dans lequel je devais télécharger localement des journaux complets à partir de MongoDB Atlas Triggers. Actuellement, il existe trois façons de télécharger les journaux d'Atlas :

1. Utilisation de l'interface graphique
2. Utilisation de la CLI
3. Utilisation de l'API d'administration App Services

Cependant, les options GUI et CLI ont des limites concernant le volume de journaux pouvant être téléchargés, en particulier un plafond de 10 000 journaux.

Limitations de l'interface graphique et de la CLI pour les téléchargements de journaux

Utilisation de l'interface graphique

Avec l'interface graphique, les utilisateurs peuvent filtrer les journaux par date, type, ID utilisateur ou ID de demande, mais la limite est fixée à 10 000 journaux en matière de téléchargement.

Utilisation de la CLI

Avec la CLI, nous pouvons exécuter une commande comme :

appservices logs list --project 5e208aa2d5ec1375ecd5*** --app triggers_realmapp-**** --type=trigger --start="2024-10-15T00:00:00.000+0000" -o log.logs

Cependant, cela a également la même limite de téléchargement de 10 000 journaux.

Une solution : API d'administration App Services avec pagination

Pour surmonter ces limitations de téléchargement, l'API d'administration App Services fournit un moyen d'accéder aux journaux avec pagination. En implémentant la pagination, les utilisateurs peuvent récupérer les journaux au-delà de la limite par défaut de 10 Ko.

Des instructions détaillées sur l'utilisation de la pagination avec l'API peuvent être trouvées dans la documentation de MongoDB : Obtenir les journaux paginés.

Solution proposée : un script automatisé pour les téléchargements de journaux volumineux

Pour rationaliser cela, j'ai développé un script qui récupère automatiquement les journaux à l'aide de la pagination. Ce script est disponible dans un référentiel public ici : Atlas App Logs Aggregator.

Principales caractéristiques du script

• Récupération automatisée des journaux : récupère les journaux de MongoDB Atlas App Services avec prise en charge de grands ensembles de journaux via la pagination.
• Filtrage flexible de la plage de dates : permet un filtrage de date facultatif à l'aide des paramètres start_date et end_date.
• Validation ISO 8601 : Validez les dates pour vous assurer qu'elles respectent le format ISO 8601.
• Authentification sécurisée : prend en charge l'authentification à l'aide des clés API publiques et privées de MongoDB Atlas.
• user_id facultatif pour les journaux de filtrage des identifiants utilisateur.
• Co_id facultatif pour les journaux de filtrage des ID de corrélation.
• Récupérez uniquement les journaux d'erreurs à l'aide de l'option erreurs_only.
• Filtrer les journaux par paires clé-valeur à l'aide de l'option --filter.

Le script utilise uniquement le point de terminaison GET et regroupe les journaux dans un fichier sans modifier aucune donnée.

Comment l'utiliser

Exigences

• Python 3.6 ou supérieur.
• Dépendances de la bibliothèque Requirements.txt.

Installation

Créer un environnement virtuel

appservices logs list --project 5e208aa2d5ec1375ecd5*** --app triggers_realmapp-**** --type=trigger --start="2024-10-15T00:00:00.000+0000" -o log.logs

Installer les dépendances

python3 -m venv venv
source venv/bin/activate  # On Windows use `venv\Scripts\activate`

Usage

Arguments de ligne de commande

• project_id (obligatoire) : l'ID du projet Atlas (chaîne hexadécimale). app_id (obligatoire) : l'ID de l'application (chaîne).
• public_api_key (obligatoire) : la clé API publique Atlas (chaîne).
• private_api_key (obligatoire) : la clé API privée Atlas (chaîne avec tirets).
• --start_date (facultatif) : date de début au format ISO 8601 (AAAA-MM-JJTHH : MM : SS.MMMZ).
• --end_date (facultatif) : Date de fin au format ISO 8601 (AAAA-MM-JJTHH : MM : SS.MMMZ).
• --type (facultatif) : liste des types de journaux pris en charge, séparés par des virgules. Actuellement, les types disponibles sont : TRIGGER_FAILURE, TRIGGER_ERROR_HANDLER, DB_TRIGGER, AUTH_TRIGGER, SCHEDULED_TRIGGER, FUNCTION, SERVICE_FUNCTION, STREAM_FUNCTION, SERVICE_STREAM_FUNCTION, AUTH, WEBHOOK, ENDPOINT, PUSH, API, API_KEY, GRAPHQL, SYNC_CONNECTION_START, SYNC_SESSION_START, SYNC_SESSION_END, SYNC_CLIENT_WRITE, SYNC_ERROR , SYNC_OTHER, SCHEMA_ADDITIVE_CHANGE, SCHEMA_GENERATION, SCHEMA_VALIDATION, LOG_FORWARDER
• --user_id (facultatif) : renvoie uniquement les messages de journal associés à l'id_utilisateur donné.
• --co_id (facultatif) : renvoie uniquement les messages de journal associés à l'ID de corrélation de la demande donnée.
• --filter (facultatif) : filtrez les journaux par paires clé-valeur (par exemple, --filter event_subscription_name=,function_name=).
• --errors_only (facultatif) : renvoie uniquement les messages du journal d'erreurs.
• --verbose (facultatif) : Activer les informations de journalisation détaillées.

Exemple

pip install -r requirements.txt

Avec paramètres optionnels

python main.py <project_id> <app_id> <public_api_key> <private_api_key> --start_date 2024-10-05T14:30:00.000Z --end_date 2024-10-06T14:30:00.000Z --type TRIGGER_FAILURE,SCHEMA_GENERATION

Si start_date et end_date ne sont pas fournis, le script définira par défaut start_date sur les dernières 24 heures à partir de l'heure actuelle.

 Filtrage des journaux

L'option --filter vous permet de filtrer les journaux par paires clé-valeur. Cette option accepte plusieurs paires clé-valeur séparées par des espaces. Chaque paire clé-valeur doit être au format clé=valeur.

La paire clé-valeur doit être constituée des valeurs renvoyées par le point de terminaison. De cette façon, il les utilisera pour filtrer et ne conservera que ceux qui correspondent. Par exemple, pour un "type" : "SCHEDULED_TRIGGER", les valeurs-clés de réponse seront similaires à :

python main.py <project_id> <app_id> <public_api_key> <private_api_key> --start_date 2024-10-05T14:30:00.000Z --type TRIGGER_FAILURE,SCHEMA_GENERATION --user_id 671d2e2010733ecbaa2bab8f --filter event_subscription_name=getUnpausedClustersMetrics

Nous pouvons utiliser n'importe lequel de ces éléments dans l'option --filter (par exemple, --filter event_subscription_name=getUnpausedClustersMetrics)

Enregistrement

Le script prend en charge la journalisation à la fois sur la console et dans un fichier journal. Par défaut, les fichiers journaux sont stockés dans le dossier des journaux. Le nom du fichier journal inclut un horodatage pour garantir l'unicité de chaque exécution.

--verbose : lorsque cet indicateur est utilisé, le niveau de journalisation est défini sur DEBUG, fournissant des informations de journalisation détaillées. Sans cet indicateur, le niveau de journalisation est défini sur INFO.

Emplacement du fichier journal

Les fichiers journaux sont stockés dans le dossier des journaux. Chaque fichier journal est nommé avec un horodatage pour garantir que les journaux des différentes exécutions ne s'écrasent pas.

Exemple de nom de fichier journal

appservices logs list --project 5e208aa2d5ec1375ecd5*** --app triggers_realmapp-**** --type=trigger --start="2024-10-15T00:00:00.000+0000" -o log.logs

Avantages

• Récupération automatisée des journaux : récupérez facilement les journaux de MongoDB Atlas App Services sans intervention manuelle.
• Filtrage par plage de dates : filtrez les journaux par plage de dates pour vous concentrer sur des périodes spécifiques.
• Prise en charge de la pagination : gérez efficacement de grands ensembles de journaux à l'aide de la pagination.
• Validation : assurez-vous que les entrées de date sont dans le format correct pour éviter les erreurs.

CLAUSE DE NON-RESPONSABILITÉ

Veuillez noter : ce dépôt est publié pour une utilisation « EN L'ÉTAT » sans aucune garantie d'aucune sorte, y compris, mais sans s'y limiter, leur installation, leur utilisation ou leurs performances. Nous déclinons toute garantie, expresse ou implicite, y compris, mais sans s'y limiter, toute garantie de non-contrefaçon, de qualité marchande et/ou d'adéquation à un usage particulier. Nous ne garantissons pas que la technologie répondra à vos exigences, que son fonctionnement sera ininterrompu ou sans erreur, ni que toute erreur sera corrigée.

Toute utilisation de ces scripts et outils est à vos propres risques. Il n'y a aucune garantie qu'ils aient été soumis à des tests approfondis dans un environnement comparable et nous ne sommes pas responsables de tout dommage ou perte de données résultant de leur utilisation.

Vous êtes responsable d'examiner et de tester minutieusement tous les scripts que vous exécutez avant de les utiliser dans un environnement non testé.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!