À l'aide de la trace et de dbg en Erlang

Je suis en train de commencer à utiliser erlang:trace/3 et le dbg module de tracer le comportement d'un système de production réel sans prendre le serveur.

La la documentation est opaque (c'est un euphémisme) et il ne semble pas du tout utile tutoriels en ligne.

Ce que j'ai passé toute la journée à essayer de faire, c'était de capturer ce qui se passait dans une fonction particulière, en essayant d'appliquer une trace de module:fonction à l'aide de dbg:c et dbg:p, mais sans aucun succès...

Quelqu'un a une explication succincte de la façon d'utiliser le suivi en direct dans un Erlang système?

InformationsquelleAutor Gordon Guthrie | 2009-12-23

7

Si vous préférez un graphique traceur puis essayez erlyberly. Il vous permet de sélectionner les fonctions que vous souhaitez trace (sur tous les processus à l'instant) et qui traite avec le dbg API.

Cependant, il ne protège pas contre la surcharge n'est donc pas adapté pour les systèmes de production.

InformationsquelleAutor Andy Till
92

Les étapes de base de suivi pour les appels de fonction sont sur un non-nœud:
```
> dbg:start().   % start dbg
> dbg:tracer().  % start a simple tracer process
> dbg:tp(Module, Function, Arity, []).   % specify MFA you are interested in
> dbg:p(all, c).   % trace calls (c) of that MFA for all processes.

... trace here

> dbg:stop_clear().   % stop tracer and clear effect of tp and p calls.
```
Vous pouvez tracer plusieurs fonctions en même temps. Ajouter des fonctions en appelant tp pour chaque fonction. Si vous souhaitez suivre pour les non-fonctions exportées, vous devez appeler tpl. Pour supprimer des fonctions, appel ctp ou ctpl d'une manière similaire. En général, certains tp appels sont:
```
> dbg:tpl(Module, '_', []).  % all calls in Module
> dbg:tpl(Module, Function, '_', []).   % all calls to Module:Function with any arity.
> dbg:tpl(Module, Function, Arity, []). % all calls to Module:Function/Arity.
> dbg:tpl(M, F, A, [{'_', [], [{return_trace}]}]).   % same as before, but also show return value.
```
Le dernier argument est un match de spécification. Vous pouvez jouer avec des qu'en utilisant dbg:fun2ms.

Vous pouvez sélectionner le processus de trace sur l'appel à p(). Les éléments sont décrits dans la erlang:trace. Certains appels sont:
```
> dbg:p(all, c).   % trace calls to selected functions by all functions
> dbg:p(new, c).   % trace calls by processes spawned from now on
> dbg:p(Pid, c).   % trace calls by given process
> dbg:p(Pid, [c, m]).  % trace calls and messages of a given process
```
Je suppose que vous n'aurez plus jamais besoin d'appeler directement erlang:trace, comme dbg fait à peu près tout pour vous.

Une règle d'or pour un live nœud est de générer une quantité de trace de la sortie de la coquille, qui vous permet de taper dbg:stop_clear().. 🙂

J'ai souvent utiliser un traceur qui l'auto-stop, lui-même, après un certain nombre d'événements. Par exemple:
```
dbg:tracer(process, {fun (_,100) -> dbg:stop_clear();
                        (Msg, N) -> io:format("~p~n", [Msg]), N+1 end, 0
                    }).
```
Si vous êtes à la recherche pour le débogage sur les nœuds distants (ou plusieurs nœuds), recherche pour pan, eper, inviso ou onviso.
- Je n'ai pas été en mesure d'obtenir de la trace à envoyer tout à la coque jusqu'à présent 🙁
- Vous dites que ce sont les étapes de base sur un non-nœud... sans doute parce que sur un nœud de vous pourrait obtenir en un rouleau avec la coquille (et perdre)?
- Le traçage requiert des ressources du système. Si vous avez suivi de nombreuses animations vous pourriez risquer votre performance. Dans le pire des cas, vous perdrez le contact, et il va au -Perche.
- Sur un système live, je serais très précis sur les appels de fonction, dont certains correspondent à des arguments. Aussi, la plupart du temps, vous pouvez limiter le traçage d'un processus à la place de tous.
- Vous pouvez en fait juste dbg utilisation du cluster/nœud distant de débogage. dbg:n(Node) met en place Node pour le même type de suivi que le nœud que vous êtes sur.
- Mon général, adice: Vous pouvez utiliser de traçage des appels (c drapeau) avec l'ensemble des processus si vous configurez une trace de modèle pour l'un de vos propres modules (système/trace processus ne sera pas l'appeler), mais seulement d'utiliser message (envoyer/recevoir/indicateur de message) avec un petit ensemble de processus (qui ne comporte pas de système/suivi de processus).
InformationsquelleAutor Zed
22

Sur des systèmes informatiques que nous avons rarement trace sur la coque.
Si le système est bien configuré, il est déjà à la collecte de votre Erlang journaux qui ont été imprimés à la coque. J'ai pas besoin de souligner pourquoi il est essentiel de n'importe quel nœud...

Permettez-moi d'insister sur la recherche de fichiers:

Il est possible de tracer une ligne de fichier, ce qui va produire une sortie binaire qui peut être converti et analysées plus tard. (pour une analyse plus approfondie ou automatiques, système de contrôle, etc.)

Un exemple pourrait être:
- Trace de plusieurs fichiers enveloppé (12x50 Mo).Veuillez toujours vérifier l'espace disque disponible avant d'utiliser une grosse trace!
```
dbg:tracer(port,dbg:trace_port(file,{"/log/trace",wrap,atom_to_list(node()),50000000,12})).
```
  dbg:p(all,[call,timestamp,return_to]).
  - Toujours tester sur un nœud de test avant d'entrer dans quelque chose d'un nœud de l'interpréteur de!
  - Il est plus que conseillé d'avoir un nœud de test ou de répliques nœud d'essayer les scripts d'abord.
Cela dit, nous allons avoir un coup d'oeil à une base de traçage de la séquence de commande:

<1> dbg:stop_clear().
- Toujours commencer par rinçage à l'trace de ports et de s'assurer qu'aucun des précédents traçage interfère avec la trace actuelle.
<2> dbg:tracer().
- Démarrer le traceur processus.
<3> dbg:p(all,[call, timestamp]).
- Dans ce cas nous avons suivi pour tous les processus et pour les appels de fonction.
<4> dbg:tp( ... ).
- Comme on le voit dans Zed réponse.
<5> dbg:tpl( ... ).
- Comme on le voit dans Zed réponse.
<42> dbg:stop_clear().
- Encore, c'est de s'assurer que toutes les traces ont été écrits à la sortie et de l'éviter tout désagrément.
Vous pouvez:
- ajouter des déclencheurs par la définition de certains fun()-s dans le shell pour arrêter le suivi à un moment donné ou à un événement. Récursive fun()-s sont les meilleurs pour atteindre cet objectif, mais être très prudent lors de l'application de celles-ci.
- appliquer une grande variété de pattern matching pour s'assurer que vous ne trace pour le processus spécifique de la spécificité de l'appel de fonction, le type d'arguments...
J'ai eu un problème un moment en arrière, lorsque nous avons eu à vérifier le contenu d'un ETS de la table et sur l'apparition d'une certaine entrée, nous avons dû arrêter la trace dans les 2-3 minutes.

Je suggère également le livre Erlang de Programmation écrit par Francesco Cesarini. (Erlang Programmation @ Amazon)

InformationsquelleAutor cdlf
9

Le " dbg " module est assez bas niveau de stuff. Il y a deux hacks que j'utilise très
souvent pour les tâches que j'ai souvent besoin.
1. Utiliser Erlang CLI/shell extension de code à http://www.snookles.com/erlang/user_default.erl. Il a été écrit à l'origine (autant que je sache) par Serge Aleynikov et
  a été utile "c'est ainsi que j'ai ajouter des fonctions personnalisées à la coquille" exemple. Compiler
  le module et l'édition de votre ~/.erlang fichier à point de son chemin d'accès (voir le commentaire au dessus
  du fichier).
2. Utiliser le "redbug" de l'utilitaire fourni avec le L'EPER collection d'utilitaires.
  Il est très facile à utiliser " dbg " pour créer des millions d'événements de trace en quelques secondes. Faire
  ainsi, dans un environnement de production peuvent être désastreuses. Pour le développement ou de production,
  redbug fait qu'il est quasiment impossible de tuer un système en cours d'exécution, avec une trace induite par la surcharge.
InformationsquelleAutor Scott Lystig Fritchie

Vous devez vous connecter pour publier un commentaire.