В нашей компании мы используем Elixir, фреймворк Phoenix и Ecto. И недавно на работе мне поставили задачу, сделать профилировщик запросов в БД, чтобы выяснить узкие точки системы, которые следует оптимизировать. Таким образом задачи были следущие: Как и все, изначально я решил попробовать существующие решения. Простой гуглопоиск выдал мне несколько статей, и некоторые решения а-ля: https://github.com/parroty/exprof
http://erlang.org/doc/man/fprof.html
https://github.com/proger/eflame
https://github.com/TheRealReal/new-relixir и др. Беглый осмотр сразу дал понять что существующие решения не подходят. Некоторые не позволяют аккумулировать результаты, некоторые вообще считают общие вызовы и не важно там БД или нет, что-то платное и так же не обладает необходимой функциональностью. Почесав репу, я понял, что придется писать свой личный кастомный профилировщик. К счастью, у Ecto (DSL для работы с базой) есть возможность конфигурировать логгер и посмотреть всю информацию после выполнение запроса, следующим образом: Это значит что мы можем написать свой собственный модуль с именем EctoProfiler который обязательно имеет внутри публичную функцию log, принимающую один аргумент. И сделать что-нибудь интересное внутри этой функции. В частности посмотреть информацию, которую содержит этот аргумент, а содержит он много чего и почти все что нам нужно, но к сожалению не содержит информации о том, откуда прозошел данный вызов.  Тут на сцену и выходит stacktrace. Вызвать и посмотреть информацию о нем в elixir можно различными способами. Я буду использовать метод модуля Process: Но, здесь есть некоторые нюансы. Посмотрите на модуль ниже: Вопрос миллион долларов. Что мы получим в точках f и g при запуске StacktraceTest.a ? Уверен, не каждый опытный elixir-ист правильно на него ответит.  Запустив данный модуль, и вызвав функцию мы получим следующее: Выше то, что вывела функция f, ниже — g. Вроде все круто, информация исчерпывающая, но нет. Внимательный читатель, сразу спросит, а где вызовы функций a, b ? Вот тут мы и подходим к самому интересному.  Если функция a возвращает то же значение, которое возвращает функция b (tail chain), то функция a в stacktrace не попадает. Это следствие оптимизации последнего вызова, так называемая хвостовая рекурсия в Erlang/Elixir. Каждый вызов функции в хвосте означает, что кадр стека для вызывающей функции уничтожен. Это поведение BEAM (Erlang VM). И изменить здесь что-либо невозможно, не переписав код виртуальной машины. Подробное обсуждение было здесь https://github.com/elixir-lang/elixir/issues/6357 Поэтому функция e, также не попала в stacktrace. rescue/catch — являются концевыми вызовами, а вот after (в функции d) — нет.  К сожалению, Stacktrace также не содержит аргументов, вызываемых функций. Это значит, что вы не сможете детализировать информацию в handle_info и других коллбеках, касаемо вызываемых сообщений. Причина также кроется в том, как Erlang работает со стеком. Так как он хранится некоторое время, а аргументы могут быть сколь угодно большими, stacktrace в этом случае, сьедал бы всю память. Это кстати причина того, что Erlang планирует переделать обработку и хранение стека вызовов в случае ошибок (там как раз сохраняются аргументы). По этому поводу есть обсуждение. Кто-то спросит, почему же я не использовал стадартный debugger, который идет из коробки в Erlang и который сохраняет аргументы. Я думал об этом, но debugger не позволяет сохранить стектрейс вызовов в переменной и затем как-либо обработать эти данные. Только в файл или в консоль. Поэтому решение с ним отпало сразу. Итак стектрейс вызовов мы получили. Вся сопуствующая информация у нас есть. Время обработать ее. Использов всю эту информацию был написан свой собственный профилировщик. Я не буду здесь приводить подробное описание его работы с примерами кода. Кому интересно — может ознакомиться с ним на гитхабе Здесь я лишь вкратце опишу принцип работы: К сожалению у решения есть недостатки, связанные с работой стектрейса, описанные выше. Но получить информацию о том как работает ваше приложение и сделать выводы об оптимизации вы вполне можете. P.S. Что касается самого плагина. Я буду рад любым дополнениям и PR. Возможно кто-то добавить плюшек и сделать красивый интерфейс :)