Maison > développement back-end > tutoriel php > Implémentation de la bibliothèque de surveillance Symfony

Implémentation de la bibliothèque de surveillance Symfony

Linda Hamilton
Libérer: 2024-12-08 16:52:11
original
786 Les gens l'ont consulté

Au cours des derniers mois, j'ai travaillé dur pour rénover l'expérience de surveillance pour les développeurs Symfony. La bibliothèque de surveillance Symfony est la deuxième bibliothèque la plus populaire parmi les clients d'Inspector. Le premier est le package Laravel.

La sortie de la dernière version du framework a offert l'opportunité de rendre l'expérience de surveillance des applications aussi simple que jamais.

Dans cet article, je détaillerai quels sont ces changements et leur impact sur votre expérience de surveillance dans Inspector.

Pour des articles plus techniques vous pouvez me suivre sur Linkedin ou X.

Compatibilité avec Doctrine 3.x

La dernière version majeure du plus important ORM pour Symfony est sortie au début de cette année. Et il a abandonné la prise en charge des enregistreurs SQL au profit d'une nouvelle « architecture middleware ».

Nous avons implémenté une vérification à l'intérieur du bundle pour vérifier quelle version de Doctrine l'application utilise pour injecter un enregistreur SQL ou un middleware en conséquence.

Collectez le nom de l'itinéraire

La première implémentation de la bibliothèque de surveillance Symfony consistait à utiliser le nom de la route pour surveiller le trafic http par rapport à votre application Symfony :

Symfony monitoring library implementation

En gros lorsque vous implémentez une nouvelle route dans Symfony vous pouvez la déclarer via un attribut sur la méthode du Controller :

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;

class HomeController
{
    #[Route('/', name: 'app_homepage')]
    public function home()
    {
        return new Response('Home Page');
    }

    #[Route('/landing', name: 'app_landing')]
    public function landing()
    {
        return new Response('Landing Page');
    }
}
Copier après la connexion
Copier après la connexion

L'objet Route obtient le nom de la route comme deuxième paramètre, vous pouvez donc référencer cette route dans l'application en utilisant son nom au lieu d'écrire le chemin. Cela vous permet de modifier le modèle d'URL à l'avenir sans avoir besoin de le modifier dans chaque ligne de code mentionnée.

Et si vous souhaitez ignorer l'un d'entre eux dans votre bibliothèque de surveillance, vous deviez lister le nom de la route dans le fichier de configuration yaml de l'Inspector :

inspector:
    ingestion_key: '%env(INSPECTOR_INGESTION_KEY)%'
    ignore_routes:
        - 'app_landing'
Copier après la connexion
Copier après la connexion

Le premier développeur qui m'a aidé à construire la première version de la bibliothèque n'a pas trouvé de moyen de collecter le véritable modèle d'URL, nous avons donc continué cette implémentation pour ne pas bloquer le travail.

Mais utiliser le nom de la route pour surveiller le trafic HTTP présente plusieurs inconvénients.

Le problème avec les noms de routes

Tout d'abord, le nom de l'itinéraire est facultatif. Il n'est évidemment pas nécessaire de mapper les URL avec des noms dans Symfony. De nombreux développeurs n'utilisaient pas de noms, donc comme données de secours, la bibliothèque collectait le chemin ultime comme : /users/12/profile.

Pire encore, quelqu'un utilise des noms uniquement pour une partie de l'application et a vu la liste des transactions dans le tableau de bord avec des formats mixtes, certains points de terminaison surveillés à l'aide du nom de la route et d'autres points de terminaison avec l'URL.

Le deuxième problème était la possibilité d'ignorer l'URL pour désactiver la surveillance dans certaines parties de l'application. Une application Symfony est généralement segmentée à l'aide de modèles d'URL. Les développeurs ont tendance à regrouper tous les points de terminaison d'administration sous l'URL principale comme /admin/[other sub urls] . si vous souhaitez ignorer des parties de votre application à l'aide de caractères génériques, il pourrait être plus facile de référencer des URL en raison de cette association naturelle (/users*). Il est plus difficile de trouver un modèle plus cohérent dans les noms de routes.

De plus, les données de secours collectées au cas où le nom de l'itinéraire n'existerait pas étaient la véritable URL comme /users/12/profile. Ainsi, chaque fois que le point de terminaison était appelé avec un identifiant différent, il générait une nouvelle ligne dans la liste des transactions. Créer trop de bruit dans les données de surveillance.

Collecter le modèle d'itinéraire
Les modèles de route sont différents de l’URL réelle que vos utilisateurs appellent. La plupart des URL que vous avez dans votre application Symfony sont essentiellement paramétrées comme /users/{id}/profile

Il s'agit d'une implémentation typique dans un contrôleur Symfony :

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;

class HomeController
{
    #[Route('/', name: 'app_homepage')]
    public function home()
    {
        return new Response('Home Page');
    }

    #[Route('/landing', name: 'app_landing')]
    public function landing()
    {
        return new Response('Landing Page');
    }
}
Copier après la connexion
Copier après la connexion

Et c'est ce que nous devons signaler dans la liste des transactions au lieu de la véritable URL. Car même si le changement d'ID, c'est toujours le même code à exécuter.

Symfony monitoring library implementation

Ce changement permet également d'ignorer plus facilement non seulement des URL spécifiques, mais également des parties entières de votre application à l'aide du caractère générique dans le fichier de configuration de l'Inspecteur :

inspector:
    ingestion_key: '%env(INSPECTOR_INGESTION_KEY)%'
    ignore_routes:
        - 'app_landing'
Copier après la connexion
Copier après la connexion

Pour des articles plus techniques vous pouvez me suivre sur Linkedin ou X.

Surveillez gratuitement votre application Symfony

Inspector est un outil de surveillance de l'exécution de code spécialement conçu pour les développeurs de logiciels. Vous n'avez pas besoin d'installer quoi que ce soit sur l'infrastructure, installez simplement le package Symfony et vous êtes prêt à partir.

Si vous recherchez une surveillance HTTP, des informations sur les requêtes de base de données et la possibilité de transférer des alertes et des notifications vers votre environnement de messagerie préféré, essayez Inspector gratuitement. Enregistrez votre compte.

Ou apprenez-en plus sur le site : https://inspector.dev

Symfony monitoring library implementation

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!

source:dev.to
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Derniers articles par auteur
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal