Vk-io: Impossible de trouver comment attacher un enregistreur personnalisé

Par exemple?

Eeeem ..... Par exemple, qu'est-ce que c'est ? Si, par exemple, une implémentation possible, alors je déclarerais l'interface llgger, comme l'objet console. C'est-à-dire que les méthodes habituelles, debug () info (), varn () et error (), et dans le constructeur de classe, dans le paramètre opshen, accepteraient un objet avec une telle interface.

Où cela serait-il utile : c'est très utile quand en général il y a un système de journalisation pour le projet, par exemple, comme nous avons visé les élans. Dans un tel projet, les messages VK doivent également s'intégrer dans le système de journalisation général.

La bibliothèque, en principe, ne consigne pas les erreurs, car toutes sont jetées dans Promise (sinon il y aurait un anti-modèle). Si nous parlons d'exceptions dans les middleware, elles peuvent toutes être détectées avec un middleware racine :

// Custom catch all the errors
vk.updates.use(async (context, next) => {
    try {
        await next();
    } catch (error) {
        logger.error('An error has occurred', { error });
    }
});

Plus d'informations sur la gestion globale des erreurs de middleware ici .

Et qui parlait de la journalisation des erreurs ? Le ticket, dans lequel nous sommes maintenant, est ouvert sur un enregistreur personnalisé qui enregistre tous les événements. Par exemple, le nom de la méthode appelée, les paramètres de la méthode. Il est important pour nous de comprendre la mécanique du travail interne de la bibliothèque pour voir quels appels se produisent à l'intérieur, voir ces appels dans les journaux, collecter des statistiques sur le nombre d'appels par seconde, minute, heure, mois, analyser les résultats, car tout cela est lié à la limitation du nombre de requêtes autorisé, optimisez. Il ne s'agit pas du tout de gérer les erreurs lors des exécutions. Il s'agit de journaux.

@isinkin @negezor Pourquoi le ticket a-t-il fermé d'ailleurs ?

Ce n'est pas la responsabilité de la bibliothèque, vous pouvez envelopper toutes les méthodes avec votre propre gestionnaire et vous connecter comme vous le souhaitez. La bibliothèque a la capacité de connaître les méthodes appelées du module avec l'indication env DEBUG=vk-io:* , puisque le module de débogage est

@negezor Je voudrais clarifier ma demande, elle peut être mal comprise. Je ne suggère pas de créer votre propre bibliothèque pour vous connecter dans vk-io . Si c'était ainsi compris, c'est une litière. Je suis d'accord que ce n'est pas la responsabilité de la bibliothèque. J'ai demandé comment seule une bibliothèque existante (dans mon cas https://www.npmjs.com/package/bunyan) peut être connectée à vk-io . C'est-à-dire pas как создать , mais как подключить .

Je pense qu'il est évident que le mécanisme de connexion des loggers externes est du domaine de responsabilité de vk-io .
Par exemple, je joins comment il est organisé dans TypeORM. Même simplement copier un tel mécanisme serait très cool. https://typeorm.io/#/logging

La promesse que vous pouvez encapsuler les appels de méthode publique dans des wrappers qui enregistrent est acceptée. Cependant, cette méthode ne permet pas de déterminer à partir des journaux que dix appels à messages.send ont en réalité été remplacés par un execute . Par conséquent, il est inutile comme outil de journalisation.

Le message qu'il y a un enregistreur intégré DEBUG=vk-io:* ne sais même pas comment commenter. Ce n'est pas un bûcheron avec tout le respect que je vous dois. S'il s'agit d'un enregistreur, dites-moi comment transférer ces journaux à ELK ? alors je suis d'accord.

Frères, où êtes-vous ?