Перехват трафика в memcached для статистики / анализа
Я хочу настроить платформу мониторинга статистики для просмотра определенной службы, но не знаю, как это сделать. Меня не беспокоит обработка перехваченных данных, а только то, как это сделать. Одна из идей заключалась в том, чтобы настроить прокси между клиентским приложением и службой, чтобы весь трафик TCP шел сначала на мой прокси, затем прокси делегировал перехваченные сообщения ожидающему потоку / вилке, чтобы передать сообщение и получить результаты. Другой - попытаться перехватить трафик между клиентом и сервисом.
Моя основная цель - избежать серьезных потерь в скорости передачи данных между клиентом и приложением, но получить 100% полную связь между клиентом и службой.
Среда: UBuntu 8.04
Язык: c / C++
В фоновом режиме я думал об использовании базы данных sqlite, полностью работающей в памяти, или кэш-памяти памяти размером 20-25 МБ, подчиненного моему процессу.
Обновлять: В частности, я пытаюсь отслеживать использование ключей для демона memcache, сохраняя количество наборов / успехов / сбоев на ключе. Идея состоит в том, что у большинства ключей есть какой-то разделительный символ [`| _- #] для создания своего рода пространства имен. Идея состоит в том, чтобы встать между демоном и клиентом, разделить ключи настроенным разделителем и записать статистику по ним.
Ответы 4
Что именно вы пытаетесь отследить? Если вам нужен простой подсчет пакетов или байтов или основная информация заголовка, iptables запишет это для вас:
iptables -I INPUT -p tcp -d $HOST_IP --dport $HOST_PORT -j LOG $LOG_OPTIONS
Если вам нужна более подробная информация, посмотрите на цель iptables ULOG, которая отправляет каждый пакет в пользовательское пространство для анализа.
Подробную документацию по очень см. В http://www.netfilter.org.
Вы не упомянули один подход: вы можете изменить memcached или своего клиента для записи необходимой вам статистики. Это, наверное, самый простой и чистый подход.
Между прокси-сервером и подходом libpcap есть несколько компромиссов:
- If you do the packet capture approach, you have to reassemble the TCP
streams into something usable yourself. OTOH, if your monitor program
gets bogged down, it'll just lose some packets, it won't break the cache.
Same if it crashes. You also don't have to reconfigure anything; packet
capture is transparent.
- If you do the proxy approach, the kernel handles all the TCP work for
you. You'll never lose requests. But if your monitor bogs down, it'll bog
down the app. And if your monitor crashes, it'll break caching. You
probably will have to reconfigure your app and/or memcached servers so
that the connections go through the proxy.
Короче говоря, прокси-сервер, вероятно, будет легче кодировать, но его реализация может быть королевской головной болью, и лучше бы он был идеальным, иначе кеширование уменьшилось бы. Смена приложения или memcached кажется мне самым разумным подходом.
BTW: Вы смотрели на встроенную статистику memcached? Я не думаю, что он достаточно подробный для того, что вы хотите, но если вы его не видели, взгляните, прежде чем приступить к реальной работе :-D
Наборы против получения - это то, на что может ответить встроенная статистика.
iptables предоставляет libipq, библиотеку очередей пакетов пользовательского пространства. На странице руководства:
Netfilter provides a mechanism for passing packets out of the stack for queueing to userspace, then receiving these packets back into the kernel with a verdict specifying what to do with the packets (such as ACCEPT or DROP). These packets may also be modified in userspace prior to reinjection back into the kernel.
Настроив индивидуальные правила iptables, которые пересылают пакеты в libipq, помимо определения вердикта для них, можно выполнять проверку пакетов для анализа статистики.
Другой жизнеспособный вариант - вручную прослушивать пакеты с помощью сокета libpcap или PF_PACKET с поддержкой фильтра сокетов.
Если вы хотите использовать сниффер, возможно, будет проще использовать tcpflow вместо tcpdump или libpcap. tcpflow будет выводить только полезную нагрузку TCP, поэтому вам не нужно заботиться о повторной сборке потока данных самостоятельно. Если вы предпочитаете использовать библиотеку вместо того, чтобы склеивать кучу программ, вас могут заинтересовать libnids.
libnids и tcpflow также доступны в других версиях Unix и не ограничивают вас только Linux (в отличие от iptables).
http://www.circlemud.org/~jelson/software/tcpflow/http://libnids.sourceforge.net/
Проблема, которую я пытаюсь решить, заключается в том, чтобы знать, что wtf memcache и приложение делают: «Срок действия ключей скоро истечет, и есть ли еще наборы, которые затем получают»