Тут по работе возникла задачка с PostgreSQL. Нужно было определить, как часто при определенных условиях вызываются такие-то процедуры, и что они при этом возвращают. Трейсить предстояло совсем чуть-чуть, да и не в проде, поэтому я воспользовался LLDB. Несмотря на то, что это не инструмент трассировки, в моем случае с задачей он справился. И тут я вспомнил, что еще не так давно читал про bpftrace. Хотя, конечно же, успел напрочь все позабыть. Было решено проверить, насколько лучше или хуже bpftrace подошел бы для той же задачи.
Типичная проблема, возникающая при разработке распределенных систем, состоит в следующем. Допустим, пользователь посылает системе запрос, и запрос этот обрабатывался очень долго. При этом внутри системы запрос распался на запросы к нескольким внутренним микросервисам, которые в свою очередь могли также превратиться в несколько подзапросов, возможно, даже выполняемых параллельно. Как в такой ситуации выяснить, где тормозит система? Метрики не дают ответа на данный вопрос, поскольку в целом вся система работает нормально, затупил только отдельный запрос конкретного пользователя. Логи могут дать ответ, но они разбросаны по множеству машин, время на которых не синхронизировано. На помощь приходит Jaeger.
Если вы давно читаете этот блог, то можете помнить некоторые старые посты, посвященные мониторингу. В частности, была рассмотрена связка из Graphite, StatsD и CollectD, а также, несколько поверхностно, сервис Datadog. Однако мир не стоит на месте. Приходят новые технологии, некоторые из которых даже оказываются лучше своих предшественников. В качестве таких новых технологий можно привести в пример связку из Prometheus и Grafana.
Недавно у меня наконец-то дошли руки поиграться с eBPF. Если вдруг вы все пропустили, eBPF — это очередная реализация идеи «а давайте сделаем DTrace для Linux». Другой реализацией этой идеи является SystemTap. Только SystemTap трудно устанавливается, пользоваться им не очень удобно, и его страшно запускать на проде. В отличие от него, eBPF прямо-таки похож на нормальный инструмент. Давайте же поскорее с ним познакомимся!
Рассмотрим типичную задачу. Есть программа на C или C++ с исходниками. Известно, что при выполнении определенных условий программа начинает отжирать слишком много памяти. Нужно понять, почему это происходит, и по возможности исправить. Инструменты, которые мы рассматривали до этого, например, в заметке Профилирование кода на C/C++ в Linux и FreeBSD, для этого явно не подходят. Спрашивается, что же тогда делать? На помощь приходит Heaptrack!
Ранее в заметке Профилирование кода на C/C++ в Linux и FreeBSD вскользь упоминалось, что аналогом perf из мира Linux во FreeBSD является утилита pmcstat. Однако не сообщалось, как именно этим pmcstat пользоваться, просто потому что на тот момент я этого и не умел. Не так давно, благодаря помощи со стороны Федора Сигаева, мне все-таки удалось осилить pmcstat. А теперь, благодаря помощи с моей стороны, осилить удастся и вам!
Некоторое время назад мы с вами научились пользоваться DTrace. SystemTap представляет собой нечто похожее, но сильно заточенное под Linux и с рядом важных отличий. Во-первых, SystemTap не требует ручного добавления пробов в код ядра или приложений. Он работает и так, правда, требуя взамен знания исходников. Во-вторых, скрипты SystemTap транслируются в язык C и загружаются в ядро в виде модулей. За это приходится платить временем компиляции скриптов. Зато скриптовый язык SystemTap намного мощнее, чем у DTrace.
DTrace — это такая штука, присутствующая во FreeBSD, NetBSD, MacOS, Solaris и Linux. DTrace предназначен для динамической трассировки ядра системы и приложений в реальном времени, главным образом с целью их профайлинга и отладки. Сегодня мы попробуем поработать с DTrace во FreeBSD. Кроме того, мы установим DTrace и в Ubuntu, хотя по поводу стабильности такой конфигурации и остаются вопросы.
Рассмотрим типичную ситуацию — приходит пользователь и говорит «я делаю в приложении то-то и то-то и у меня все сильно тормозит». Как понять, в чем проблема, и исправить ее? Вот об этом мы и поговорим в данной заметке. Приведенный список методов не претендует на полноту, однако это то, что в настоящее время я чаще всего использую на практике. Несмотря на то, что пишу я сейчас в основном на C, описанные методы будут также применимы в проектах, использующих С++, и, возможно, другие языки программирования.
Любые сайтики и бэкенды должны писать метрики, это бесспорно. Однако возникает вопрос, куда именно их писать. Есть неплохие SaaS решения, например, Datadog. Но Datadog на момент написания этих строк стоял 15$ в месяц за один хост. При определенном количестве хостов в какой-то момент вы можете обнаружить, что 30% стоимости всей инфраструктуры приходится на метрики. В связи с чем возникает желание перевести все на self hosted решение. О том, как поднять такой вот self hosted недо Datadog, и пойдет речь в посте.
