немного о работе

[avva]

Пару слов о том, чем я сейчас занят в рамках работы в LiveJournal.

• Пару дней назад закончилась работа над возможностью модерировать коммьюнити, которая растянулась довольно надолго, т.к. в процессе работы над этим было переделано и добавлено немало других вещей, попадавшихся по дороге.
  
• Сейчас Брэд попросил меня заняться улучшением того, как мы собираем статистику работы серверов LJ, и мониторинга нормальной работы системы. Я этим (network management tools, SNMP итп.) никогда не занимался, однако, и совершенно ничего об этом не знаю. План такой: нужно как следует изучить Cricket и Nagios (LJ сейчас пользуется старой версией Nagios, с тех дней ещё, когда она называлась Netsaint), написать для них плагины (на Перле) для мониторинга и сбора статистики именно того, что нам нужно, установить их на серверах ЖЖ и протестировать всё. Особенно важно собрать и проанализировать с помощью Cricket'а различные виды статистики MySQL, и после того, как мы это поизучаем в течение недели-двух, можно будет заняться удалением bottlenecks и оптимизацией неэффективных мест в SQL и Перле внутри нашего кода.
  
• После того, как изучение, инсталляция и отладка Cricket & Nagios будет завершена, я планирую заняться каким-нибудь большим полезным проектом. Это будет, наверное, либо статистика посещений (платные юзеры ЖЖ смогут видеть точную статистику посещений своего журнала вообще и всех записей в отдельности), либо программа-клиент для умной архивации своего дневника и всех комментов, либо ещё что-нибудь, пока не решено.

Comments

[silpol.livejournal.com]

пишу сам себе комментарий, дабы продолжить...

SNMP в силу ряда моментов несколько неадекватен (на мой взгляд) поставленной задаче "сбора статистики"

1) SNMP базируется на UDP - как следствие гарантированный геморрой на утере пакетов, ретрансмиссиях, етц
2) SNMP использует BER, как следствие обмен данными становится обьемным, как по траффику, так и по последующей интерпретации
3) SNMP по природе своей заточен как "статистика для рутеров и прочих коммуникационных коробок", и последние тенденции направлены на на уход с него даже в телекоме
4) чисто человеческий фактор - даже от опытного программиста требуется просто нечеловеческий уровень следования формальным спецификациям и процедурам, иначе слишком легко утратить контроль над ситуацией: один из наших отделов, занимающийся оркестровкой network management architecture внутри конторы, слывет как "стая бюрократических церберов".

мой совет прост - не тратьте драгоценное время на SNMP обвязку, она окупает себя только когда речь идет о промышленной эксплуатации сотен или тысяч коробок однородной направленности, географически разбросанных по большой территории. лучше собирайте raw data с timestaps и, опционально, привязкой к тем или иным events внутри кода...

наблюдать за траффиком на интерфейсах (и не только траффиком) можно банальным MRTG (http://people.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html) - он вполне адекватен, т.к. дает быструю оценку использования почти любых ресурсов в виде временнЫх графиков, с возможностью детализирования по времени вплоть до минут...

к сожалению, я плохой советчик что касается SQL server performance - последние 4 года не касался SQL серверов и, откровенно говоря, счастлив от этого...

Re:

[avva.livejournal.com]

Дык MRTG и использует SNMP, чтобы с раутером говорить.
SNMP нам нужен только для того, чтобы получать информацию от BigIP, и ни для какой другой цели. Мы не собираемся всё остальное через него "обвязывать".