Есть ли подобный софт?

djb daemon tools?

1) собирать инфу скорее всего придётся скриптами, из-за специфичности софта (за которым следят). из софта может пригодится что-то типа nagios, daemontools.

2) по количеству используемой памяти можно более менее определить что утечки есть, сами утечки стоит отлавливать во время отладки. тут тоже скорее всего придётся писать специфичный скрипт. сетевой трафик - отдельная тема, смотря что требуется определить.

3) выполнять трассировку? во время штатной работы? и чего этим можно добиться? тут тоже поможет отладчик.

4) пусть софт пишет максимально подробную инфу, чтобы супервизор (пункт 1) выполнял перезапуск если это требуется.

если софт своего производства, его надо лучше отладить. если не своего - ну тут надо думать - нужен ли такой бажный софт =)

в любом случае всякие мемори-лик чекеры тормозят работу. синтетический процессор тормозит в любом случае и запуск приложения в продакшен на такой системе - плох небыстрой работой.

1) Ну почему же? Очень много инфы есть в том же /proc. Если запустить трассировку (ptrace) можно узнать кучу всего. Причём избыточность не критична совсем.
2) Понятно что для отлавливания утечек требуется специфичный софт, но можно же трассировать банально вызовы malloc/free и как-то анализировать объём выделяемой/освобождаемой памяти. Это как вариант, понятно что не единственный. Даже банальный анализ /proc на предмет расходуемой процессом памяти поможет сделать выводы.
Сетевой трафик - не думаю что сверхсложно, хотябы обьёмы посчитать можно, даже подключения можно вычислить (ip, порты и тд). Можно выдать свединия по открытым сокетам, файлам, IPC...
Согласен - что-то нужно будет анализировать скриптами, но я думаю это уже как возможность расширения функциональности подобного ПО.
3) А почему бы и не трассировать?


По-поводу перерасхода CPU - ну я не думаю что это критично, всё зависит от приложения. В крайнем случае можно сделать опциональную трассировку. Можно трассировать только тогда, когда появляется подозрение на некорректное поведение, когда сработает ватчдог, по запросу...
Главное - чтобы как-то оценивать состояние запущенного приложения, выдать максимально подробную информацию о статусе.

> если софт своего производства, его надо лучше отладить. если не своего - ну тут надо думать - нужен ли такой бажный софт =)
естественно речь идёт о своём софте и о его обновлениях. Не все ошибки могут быть отловлены на этапе отладки, зачастую много всего интересного вылезает уже когда ПО работает под реальной нагрузкой, зачастую ошибки появляются с течением времени и т.д. А в условиях когда любое падение софта или его некоррктное поведение чрезвычайно критично подобное решение необходимо как никогда.
Тем более что ПЕРЕЗАПУСТИТЬ софт в таких случаях - это не решение проблемы, а с одной коркой и логами искать баг не всегда возможно.

> По-поводу перерасхода CPU - ну я не думаю что это критично, всё зависит от приложения.

программа под valgrind работает раз так от 10 до 400 медленнее, чем она же без отладки. И памяти жрет в разы больше (хотя вот это зависот он настроек/используемых тулзов).

Такое не живет никак в продакшене.

Всё относительно
Возьмём приложение работающее с БД и занимающееся по сути проведением транзакций или например какой-нибудь сервер формирующий ответ по запросу - на таком софте не думаю что производительность упадёт хотя бы раза в два.

Но даже не в этом дело, всё таки с valgrid нужно специфичным образом компилировать само приложение - это не выход. Кроме того найти точное место утечек в коде (чем занимается valgrid) не требуется, требуется установить скоре факт утечки и собрать какую-нибудь полезную информацию о характере утечек.

Интересно насколько медленее будет работать софт с трассировкой.
Использование ptrace в том стиле, в каком его используют утилиты strace и ltrace - вот это на мой взгляд будет очень полезно.

И опять же - ну вот вываливается продакшен-приложение, вот что с ним делать? Как лечить? Логи и в лучшем случае корка - всё что есть. Кроме того логов скорее всего не будет в избыточном количестве.

хм. то о чём вы говорите, есть например у lotus. когда сервак domino валится - запускается скрипт nsd.sh. он как раз и собирает всю доступную инфу, например процессы в системе, сетевые подключения, ipc, стеки всех тредов и т.п.

как уже сказали выше, под valgrind приложение тормозит существенно и работать так можно только в режиме ОТЛАДКИ под нагрузкой (ито не большой), но не в продакшен.

запуски ptrace и другое вмешательство в работу софта само по себе требует отладки т.к. может завалить нормально работающее приложение.

чтобы выявлять подозрительное поведение приложения - нужно обозначить критерии этой "подозрительности", что опять же специфично для приложения. думаю вы не найдёте такого софта от стороннего производителя =)

под valgrind приложение нужно менять далеко не всегда, а скорее редкоо - при специфических операциях =)

> И опять же - ну вот вываливается продакшен-приложение, вот что с ним делать?

отлаживать. если с коркой - значит ядро всё-таки убило. врятли приложение само решило завершиться. ну вот например, по логам смотрим какая операция выполнялась (запустилась синхронизации между серверами, клиент новый пришёл, сработал такой-то таймер и т.п.). приложение меняем и ставим запуск внешней трассировки в начале операции. если свалилось - есть результаты strace, ltrace. если не свалилось - приложение отлючает трассировку самого себя. вам такой вариант нужен?

Из того, что я знаю, ближе всего - gdb с набором скриптов на его языке (или как-нибудь использовать MI).

> под valgrind приложение нужно менять далеко не всегда, а скорее редкоо - при специфических операциях =)
Да, согласен.

> хм. то о чём вы говорите, есть например у lotus. когда сервак domino валится - запускается скрипт nsd.sh. он как раз и собирает всю доступную инфу, например процессы в системе, сетевые подключения, ipc, стеки всех тредов и т.п.
Да, именно об этом в частности идёт речь. Всё это сильно облегчает процесс обнаружения багов. Даже более того - такую процедуру над приложением можно запускать раз в час к примеру чтобы отслеживать динамику (например собрать статистику расхода памяти, сокетов, трафика, кол-ва подключений... ну всего по-максимому).

> как уже сказали выше, под valgrind приложение тормозит существенно и работать так можно только в режиме ОТЛАДКИ под нагрузкой (ито не большой), но не в продакшен.
ну и фиг с ним :)

> запуски ptrace и другое вмешательство в работу софта само по себе требует отладки т.к. может завалить нормально работающее приложение.
??
насколько я знаю ptrace не сильно вмешивается в работу, и если грамотно один раз написать подобный трассировщик (ну там не допускать записи в память трассируемого приложения и тд) то проблем не будет.

> чтобы выявлять подозрительное поведение приложения - нужно обозначить критерии этой "подозрительности"
ну естественно. Есть ряд общих критериев (например перебор по памяти, открытым сокетам, совсем очевидный - по нагрузке, по кол-ву расплодившихся процессов), для них просто устанавливать своего рода threshold, ну и частично приложение можно обвязать скриптами для диагностики, но опять же - что бы всё это обрабатывалось централизовано.

Целью ставится собрать как можно больше данных о работающей программе как в момент падения, так и в процессе работы - и то и другое поможет найти возможные баги.

>> И опять же - ну вот вываливается продакшен-приложение, вот что с ним делать?
>отлаживать.
Но ведь оно уже как Вы говорите в продакшен!
> по логам смотрим какая операция выполнялась (запустилась синхронизации между серверами, клиент новый пришёл, сработал такой-то таймер и т.п.)
А если нет достаточной информации в логах? Ведь если вываливать в логи всё - это увеличивает нагрузку - приложение будет только дампить логи.
>приложение меняем и ставим запуск внешней трассировки в начале операции.
>приложение отлючает трассировку самого себя
Не понял... это как?
> если свалилось - есть результаты strace, ltrace
Это если оно запущено с ltrace/strace

Помощь GDB на мой взгляд в данном случае актуальна при разборе корки. В процессе выполнения я не очень понимаю как его использовать. Ну можно конечно подцепиться к действующему процессу, но толку... даже от ltrace/ptrace толку больше ИМХО.

А что такое MI?...

>>приложение отлючает трассировку самого себя
>Не понял... это как? 

например так.

/* mock.c */

#include <stdlib.h>
#include <stdio.h>

#include <time.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/wait.h>
#include <signal.h>
#include <unistd.h>

#define TIMEOUT_SEC 1
#define URANDOM "/dev/urandom"

#define TRACE_LOG "/tmp/trace.log"

static int some(int evil, size_t size);

static void trace_start(void);
static void trace_stop(void);

static int i_am_traced = 0;
static pid_t trace_pid = -1;

int main(int argc, char *argv[]) {
  size_t evil;

  for(evil = 0; ; evil++) {
    trace_start();
    if(some(evil, 1024) != 0) return -1;
    sleep(TIMEOUT_SEC);
    trace_stop();
  }

  return 0;
} /* main */
static int some(int evil, size_t size) {
  FILE *urandom;
  char *buf;
  int rval;

  if(!size) return -1;

  rval = 0;

  buf = malloc(size - evil);
  urandom = fopen(URANDOM, "r");

  if(!buf || !urandom) {
    rval = -1;
    goto out;
  }

  if(fread(buf, sizeof(buf[0]), size, urandom) != size) {
    rval = -1;
    goto out;
  }

out:
  if(buf) free(buf);
  if(urandom) fclose(urandom);

  printf("some evil? done\n");

  return rval;
} /* some */
static void trace_start(void) {
  char text_pid[32];

  if(i_am_traced) return;

  if(snprintf(text_pid, sizeof(text_pid), "%u", getpid()) >=
     sizeof(text_pid)) {
    fprintf(stderr, "sizeof(text_pid)\n");
    return;
  }

  trace_pid = fork();

  switch(trace_pid) {
    case -1: return;
    case 0:
      close(0);
      close(1);
      close(2);
      umask(0077);
      execlp("strace", "strace", "-p", text_pid, "-o", TRACE_LOG, NULL);
      exit(-1);
  }

  i_am_traced = 1;
} /* trace_start */

static void trace_stop(void) {
  if(!i_am_traced) return;

  if(trace_pid <= 1) return;

  kill(trace_pid, SIGINT);
  waitpid(trace_pid, NULL, 0);

  i_am_traced = 0;
} /* trace_stop */

legk@topaz /tmp ;) gcc -Wall mock.c -o mock
legk@topaz /tmp ;) ./mock
some evil? done
some evil? done
some evil? done
some evil? done
*** glibc detected *** free(): invalid next size (normal): 0x0804a008 ***
Aborted
legk@topaz /tmp ;) ls -l trace.log
-rw------- 1 legk legk 684 2007-01-13 21:38 trace.log
legk@topaz /tmp ;) cat trace.log
open("/dev/urandom", O_RDONLY)          = 3
fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbff5c6f8) = -1 EINVAL (Invalid argument)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7efb000
read(3, "\334\306\vq<!\366\264X2\362\225\220}\3223\35O\32\240\367"..., 4096) = 4096
open("/dev/tty", O_RDWR|O_NONBLOCK|O_NOCTTY) = 4
writev(4, [{"*** glibc detected *** ", 23}, {"free(): invalid next size (norma"..., 34}, {": 0x", 4}, {"0804a008", 8}, {" ***\n", 5}], 5) = 74
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(7373, 7373, SIGABRT)             = 0
--- SIGABRT (Aborted) @ 0 (0) ---

если вам нужно такое - идею можно развивать дальше.

ну и сборщик информации, как мне кажется, написать довольно просто. он всего то и должен собирать текстовую инфу (логи, /proc).

Те для того чтобы понять где баг нужно чтобы приложение упало, потом туда вставить trace_start/trace_stop и ждать пока оно грохнется снова?
И перед выполнением функции порождать процесс? Ну это как-то дико совсем...

Мне кажется должен быть сугубо сепарированый supervisor, который мог бы работать с приложением как есть, без его предварительной модификации.
Я склоняюсь к запуску приложения в тотальной трассировке и анализу его поведения. Простые примеры:
*) Также как это делает strace отслеживаем вызовы accept, ведём статистику по возможным удачным/неудачным подключениям. В итоге в отчёте пишется кто когда и сколько раз подключался к данному приложению. Информация может помочь в дальнейшем для анализа загрузки.
*) Трассируем send/recv - пожалуйста вх/исх трафик. Опять же кому куда и сколько ушло за сеанс.
*) Трассируем open - получаем в отчёте ошибки открытия файлов.
*) connect - ошибки соединения и возможные причины.

В конечном итоге хочется просто регулярно просматирвать отчёты приложения (например через web) и делать выводы о качестве его работы.

> Помощь GDB на мой взгляд в данном случае актуальна при разборе корки.

Это очевидно :)

> В процессе выполнения я не очень понимаю как его использовать.

Трассировка - везде, где можно поставить точку останова. По ней активируется дебаггер и выполняет скрипт, который может делать с программой _всё_ - лезть в любые ее потроха. Особенно с использованием MI

> А что такое MI?...

Machine Interface, кажется. Особый язычок, который позволяет другой программе управлять gdb.

Это всё здорово, я просто использую что-то вроде этого
echo -e "thread 0\n bt\n thread 1\n bt\n" | gdb -batch -p `cat /var/run/prog.pid` -x /dev/stdin

Тут вот какой момент - gdb скорее нужен для АКТИВНОЙ отладки: поставить точки останова, менять значения переменных... я же говорю про своего рода ПАССИВНУЮ отладку - просто сбор и анализ некоторых данных в процессе работы (и при падении) программы, которые могли бы быть полезны для поиска багов.

> я же говорю про своего рода ПАССИВНУЮ отладку - просто сбор и анализ некоторых данных в процессе работы

И я говорю о ней же - по достижению точки останова gdb активизируется и выполняет скрипт, который может собрать информацию о внутреннем состоянии программы, пользуясь возможностями gdb. То есть - инспекция локальных и глобальных переменных, точки останова на системных вызовах. А после того, как информация собрана, gdb возобновляет исполнение программы.

По крайней мере, у меня была такая идея - реализовать руки не дошли :/

Так вот проблемы:
1) КАК назначить точки останова? Ведь это нужно укзатать либо по исходному коду либо как-то ещё - в любом случае для каждого конкретного приложения ИНДИВИДУАЛЬНО.
2) Нужно ПРЕДПОЛОЖИТЬ о проблемных участках кода. А если проблема появится не там, где её ожидали?
3) gdb не может выполнять трассировку аналогичную strace/ltrace, последняя на мой взгляд даёт более важную для отладки информацию.
4) Нет возможности выполнять трассировку на протяжении выполнения программы. Только в точках останова.

> По крайней мере, у меня была такая идея - реализовать руки не дошли :/
На данный момент я пока разыскиваю подобный софт, если ничего не найду - придётся воплощать, такая штука ну очень нужна нам. Если кто-то заинтересован в подобном - можно объединить усилия, можно сделать под GPL.

> 1) КАК назначить точки останова? Ведь это нужно укзатать либо по исходному коду либо как-то ещё - в любом случае для каждого конкретного приложения ИНДИВИДУАЛЬНО.

Да. И что?

> 2) Нужно ПРЕДПОЛОЖИТЬ о проблемных участках кода. А если проблема появится не там, где её ожидали?

Да. Но трассировка - она вообще такая штука, что ее надо _вставлять_. Отладчик позволяет тебе сделать это на ходу, без рекомпиляции.

> 3) gdb не может выполнять трассировку аналогичную strace/ltrace, последняя на мой взгляд даёт более важную для отладки информацию.

даже если не выполняет (в чем я сомневаюсь), точки останова на функциях libc дадут тебе ту же информацию.

> 4) Нет возможности выполнять трассировку на протяжении выполнения программы. Только в точках останова.

Мне кажется, ты неудачно выразился. Трассировка происходит на протяжении выполнения программы, но только в точках останова, которых ты можешь задать сколько надо.

> если ничего не найду - придётся воплощать, такая штука ну очень нужна нам.

Найдешь. Гугли на тему Frysk и SystemTap (только сейчас вспомнил о них - с этого надо было начать :/).

>> 1) КАК назначить точки останова? Ведь это нужно укзатать либо по исходному коду либо как-то ещё - в любом случае для каждого конкретного приложения ИНДИВИДУАЛЬНО.
> Да. И что?
Чтобы НАЙТИ где поставить точки останова на самом деле - нужно ещё поэксперементировать. Если уже и случилось падение - хотелось чтобы УЖЕ присутствовала информация по максимуму для поиска ошибок, а ещё лучше чтобы по ходу работы велась некоторая диагностика работающего ПО, чтобы можно было ПРЕДОТВРАТИТЬ крах.

> Да. Но трассировка - она вообще такая штука, что ее надо _вставлять_. Отладчик позволяет тебе сделать это на ходу, без рекомпиляции.
Да. Но трассировка в этом понимании выполняется уже когда есть корка - тут уже можно извращаться по-всякому, в том числе использовать тот же SysTrap.

> Трассировка происходит на протяжении выполнения программы, но только в точках останова, которых ты можешь задать сколько надо.
Да, но уже не на рабочей системе. Под трассировкой для данной задачи я имею ввиду просто ptrace, выполненый супервизором и сбор данных. Не о каких точках останова речи не должно идти. Цель - собрать максимум инфы чтобы было проще обнаружить а ещё лучше предотвратить сбой ПО.

>Frysk и SystemTap
Systrap - это хорошая вещь, но требует генерации и внедрения модулей в ядро, специфичных для запускаемого приложения. Для отладки и профилирования годится, для поставленой задачи - врядли.
Frysk ближе к теме. Но кажется всё равно не то. Посмотрю детальнее.

Чем дальше, тем хуже я понимаю твои требования...

> трассировка в этом понимании выполняется уже когда есть корка

трассировка _по определению_ выполняется на работающей программе

>> Трассировка происходит на протяжении выполнения программы, но только в точках останова, которых ты можешь задать сколько надо.

>Да, но уже не на рабочей системе.

Именно на рабочей. Почему нет?

> Под трассировкой для данной задачи я имею ввиду просто ptrace

В требованиях ты указал трассировку библиотечных вызовов. Ptrace это сделает _только_ точками останова.

> Не о каких точках останова речи не должно идти.

почему? потеря производительности? без них всё равно не обойтись.

> Systrap - это хорошая вещь, но требует генерации и внедрения модулей в ядро, специфичных для запускаемого приложения.

Не всегда, насколько я понимаю - можно использовать стандартные. Впрочем, SystemTap - это больше для компонентов ядра. А вот Frysk - это как раз инструмент для мониторинга приложений.

Поясняю ещё раз
Типичный цикл запуска ПО (ну или апдейта) - мы его пишем, тестируем, отлаживаем. После чего наступает момент, когда необходимо запускать как ты говоришь в продакшн. Но до этого софт отработывал только на тестах.
Запускаем. Ну вот случилась неприятность - вывалился. Ну допустим есть логи (а может и нет...). Есть корка. Как правило этого мало. Опять начинается отладка, тестирования.
Мне же хочется УЖЕ В ПРОЦЕССЕ запуска софта в рабочем режиме уже собирать некоторую информацию, которая даст дополнительные сведения о работающем ПО (примеры см. выше), те некоторое обобщение. Для того чтобы
1) предотвратить падения (например если замечаешь что число открытых дескрипторов подкатывает к пределу - уже понятно что что-то нужно делать не дожидаясь сбоя.).
2) после падения оставалась какая-то история.
3) Перезапуск ПО в случае необходимости
Для этого можно трассировать системные вызовы, можно дополнительно трассировать библиотечные, отслеживать /proc и тд. overhead к примеру в 2 раза годится.
Всё это должно выполняться без предварительной подготовки ПО, должно работать с любым ПО.
> В требованиях ты указал трассировку библиотечных вызовов. Ptrace это сделает _только_ точками останова.
Это 100% верно, по-другому никак. Только трапы кажется отлавливаются без точек. А это самое важное.
С другой стороны если ltrace позволяет автоматически выставлять точки останова на библиотечные вызовы - значит это реализуемо, наверное только нагрузка будет больше чем при отслеживании трапов.
но опять в данном случае можно выполнить что-то вроде модулей для трассировки часто испольуемых библиотек - например к libmysql/libpqfe, позволяя отслеживать транзакции и т.д.
> А вот Frysk - это как раз инструмент для мониторинга приложений.
Ещё не вникал, но Java+графический интерфейс... уже как-то мутновато.

> Мне же хочется УЖЕ В ПРОЦЕССЕ запуска софта в рабочем режиме уже собирать некоторую информацию, которая даст дополнительные сведения о работающем ПО (примеры см. выше

[sl]trace позволит тебе собирать _только_ информацию о вызовах (системных и библиотечных). А состояние _структур данных_ отслеживать не нужно? Если нет, то задача решается относительно просто - мониторингом /proc и трассировочных данных [sl]trace.

> Только трапы кажется отлавливаются без точек. А это самое важное.

Имеются в виду системные вызовы, да? Именно это я не совсем понимаю - по-моему, происходящее внутри программы (то, что не выливается в системные вызовы) гораздо важнее. В конце концов, падают/текут программы из-за того, что запутались в своих внутренних данных.

> но Java+графический интерфейс... уже как-то мутновато.

да, Java не рулит ни разу

> [sl]trace позволит тебе собирать _только_ информацию о вызовах (системных и библиотечных). А состояние _структур данных_ отслеживать не нужно?
Влёгкую. Во-первых аргументы, передаваемые в системный вызов выцепить проще простого. Даже если это указатель (ну например read/write) - можно считать по указателю. Доступно же всё. strace это замечательно делает - посмотри его вывод, он же не только названия системных вызовов пишет.

>Имеются в виду системные вызовы, да? Именно это я не совсем понимаю - по-моему, происходящее внутри программы (то, что не выливается в системные вызовы) гораздо важнее.
Всё зависит исключительно от приложения. Если это дробилка чисел - то ежу понятно что тут трассировка системных вызовов не поможет, да и библиотечных тоже. А взять сетевое приложение - например прокси или какой-нибудь web-сервер - тут уже системных вызовов навалом, да и ко многим библиотечным можно привязаться.
И важно ещё одслеживать не только падения, но и выявлять причины некорректного поведения. Даже просто устанавливать ФАКТ некорректного поведения.

>> состояние _структур данных_ отслеживать не нужно?

<Влёгкую. Во-первых аргументы, передаваемые в системный вызов выцепить проще простого. Даже если это указатель (ну например read/write) - можно считать по указателю. Доступно же всё. strace это замечательно делает

strace отслеживает небольшое число структур данных, используемых _системой_, а я говорю о потенциально бесконечном наборе структур данных, используемых приложением - такие структуры strace тебе покажет в виде байтового массива. Тебе этого достаточно? Не говоря уже о том, что внутренние структуры программы никогда не передаются в strace.

Так а зачем трассировать всё подряд, понятно что не получится проанализировать сырые данные.
Я говорю о некоторых стандартных (системных/библиотечных) вызовах, которые будут трассироваться. Параметры всех системных вызовов можно разобрать - это факт. И этого уже достаточно, это уже довольно большой объём данных для качественного и количественного анализа поведения ПО.
Если будет к примеру модуль трассировки libmysqlclient, то он будет знать о содержании параметров, передаваемых в качестве аргументов функциям именно этой библиотеки. Используя такой модуль можно получать данные например о кол-ве SQL-запросов, количестве выборок(SELECT), вставок, удалений, статистика запросов по таблицам... И так далее. Ведь это всё доступно. Если программа не использует libmysqlclient - модуль и не будет выставлять свои точки останова.