Перехват трафика в memcached для статистики / анализа

Question

Я хочу настроить платформу мониторинга статистики для наблюдения за конкретной службой, но я не совсем уверен, как это сделать. Обработка перехваченных данных не моя забота, просто как это сделать. Одна идея заключалась в том, чтобы настроить прокси между клиентским приложением и службой, чтобы весь трафик TCP шел сначала на мой прокси, а затем прокси-сервер передавал перехваченные сообщения ожидающему потоку / ветвлению для передачи сообщения и получения результатов. Другой - попытаться перехватить трафик между клиентом и сервисом.

Моя основная цель - избежать серьезных потерь в скорости передачи данных между клиентом и приложением, но получить 100% полную связь между клиентом и сервисом.

Среда: UBuntu 8.04

Язык: c / c ++

В фоновом режиме я думал об использовании sqlite DB, работающего полностью в памяти, или 20-25 МБ памяти memcache, подчиненной моему процессу.

Обновление: В частности, я пытаюсь отследить использование ключей для демона memcache, сохраняя количество наборов / успешных / неудачных попыток на ключе. Идея состоит в том, что большинство ключей имеют своего рода разделительный символ [`| _- #] для создания своего рода пространства имен. Идея состоит в том, чтобы войти между демоном и клиентом, разделить ключи с помощью настроенного разделителя и записать статистику по ним.

Answer 1

Если вы хотите пойти по пути анализатора, может быть проще использовать tcpflow вместо tcpdump или libpcap. tcpflow будет выводить только полезную нагрузку TCP, поэтому вам не нужно заботиться о повторной сборке потока данных самостоятельно. Если вы предпочитаете использовать библиотеку, а не склеивать кучу программ, вас могут заинтересовать libnids.

libnids и tcpflow также доступны для других разновидностей Unix и не ограничивают вас только Linux (в отличие от iptables).

http://www.circlemud.org/~jelson/software/tcpflow/ http://libnids.sourceforge.net/

Answer 2

Что именно вы пытаетесь отследить? Если вам нужно простое количество пакетов или байтов или информация основного заголовка, то iptables запишет это для вас:

iptables -I INPUT -p tcp -d $HOST_IP --dport $HOST_PORT -j LOG $LOG_OPTIONS

Если вам нужна более подробная информация, посмотрите на цель iptables ULOG, которая отправляет каждый пакет в пространство пользователя для анализа.

См. http://www.netfilter.org для очень подробных документов.

Answer 3

iptables предоставляет libipq , библиотеку очередей пакетов в пользовательском пространстве. С справочной страницы:

Netfilter предоставляет механизм для передача пакетов из стека для ставить в очередь в пространство пользователя, затем получать эти пакеты обратно в ядро с указом, что делать с пакетами (такими как ПРИНЯТЬ или DROP). Эти пакеты также могут быть изменено в пользовательском пространстве до реинъекция обратно в ядро.

Путем настройки индивидуальных iptables правил, которые пересылают пакеты в libipq, помимо определения для них вердикта, можно выполнять проверку пакетов для анализа статистики.

Еще одна жизнеспособная опция - это сниффинг пакетов вручную с помощью libpcap или сокета PF_PACKET с поддержкой фильтра сокетов.

Answer 4

Вы не упомянули об одном подходе: вы можете изменить 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 кажется мне самым разумным подходом.

Кстати: вы смотрели встроенную статистическую отчетность memcached? Я не думаю, что это достаточно детально для того, что вы хотите, но если вы еще этого не видели, посмотрите, прежде чем выполнять реальную работу: -D