Intercepter le trafic vers memcached pour des statistiques/analyses

Question

Je veux configurer une plate-forme de surveillance de statistiques pour regarder un service spécifique, mais je ne suis pas sûr de savoir comment procéder. Le traitement des données interceptées n'est pas mon souci, mais comment s'y prendre. Une idée consistait à configurer un proxy entre l'application client et le service afin que tout le trafic TCP passe d'abord à mon proxy, le proxy déléguait ensuite les messages interceptés à un thread/fork en attente pour transmettre le message et recevoir les résultats. L'autre était d'essayer et de renifler le trafic entre le service client &.

Mon objectif principal est d'éviter toute perte de vitesse de transmission entre l'application client &, mais obtenir 100% de communications complètes entre le service client &.

Environnement: ubuntu 8.04

Langue: c/C++

En arrière-plan, je pensais à l'aide d'un DB sqlite fonctionnant complètement en mémoire ou un 20-25MB memcache Dameon à mon processus asservi.

Mise à jour: Spécifiquement j'essaye de dépister l'utilisation des clefs pour un démon de memcache, en stockant le nombre d'ensembles/obtient le succès/échoue sur la clef. L'idée est que la plupart des clés ont une sorte de caractère séparant [`| _- #] pour créer une sorte d'espace de noms. L'idée est d'intervenir entre le démon et le client, de séparer les clés par un séparateur configuré et d'enregistrer les statistiques sur celles-ci.

Answer 1

Vous n'avez pas mentionné une approche: vous pouvez modifier memcached ou votre client pour enregistrer les statistiques dont vous avez besoin. C'est probablement l'approche la plus simple et la plus propre.

entre le proxy et l'approche libpcap, il y a quelques compromis:

- 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. 

En bref, le proxy sera probablement plus facile à coder, mais sa mise en œuvre peut être une douleur royale, et il avait Mieux vaut être parfait ou supprimer sa mise en cache. Changer l'application ou memcached semble être la meilleure approche pour moi.

BTW: Vous avez examiné les statistiques intégrées de memcached? Je ne pense pas que son assez granulaire pour ce que vous voulez, mais si vous ne l'avez pas vu, jetez un coup d'œil avant de faire le travail réel :-D

Answer 2

Exactement ce que vous essayez de suivre? Si vous voulez un simple comptage de paquets ou d'octets, ou les informations d'en-tête de base, puis iptables enregistrera pour vous:

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

Si vous avez besoin de plus amples informations, regardez dans la cible iptables ULOG, qui envoie chaque paquet vers l'espace utilisateur pour l'analyse.

Voir http://www.netfilter.org pour très docs approfondies.

Answer 3

iptables fournit libipq, une bibliothèque faire la queue paquet de l'espace utilisateur.De la page de manuel:

Netfilter fournit un mécanisme pour paquets sortant de la pile pour faire la queue à l'espace utilisateur, puis recevoir ces paquets de nouveau dans le noyau avec un verdict indiquant ce qu'il faut faire avec les paquets (comme ACCEPT ou DROP). Ces paquets peuvent également être modifiés dans l'espace utilisateur avant la réinjection dans le noyau.

En mettant en place sur mesure iptables règles qui transmettent les paquets à libipq, en plus de préciser le verdict pour eux, il est possible de faire l'inspection des paquets pour l'analyse des statistiques.

Une autre option viable consiste à renifler manuellement les paquets au moyen de la socket libpcap ou PF_PACKET avec le support du filtre de socket.

Answer 4

Si vous voulez utiliser la méthode sniffer, il peut être plus simple d'utiliser tcpflow au lieu de tcpdump ou libpcap. tcpflow ne publiera que la charge utile TCP, vous n'avez donc pas besoin de vous préoccuper du réassemblage du flux de données. Si vous préférez utiliser une bibliothèque au lieu de coller un tas de programmes, vous pourriez être intéressé par libnids. Libnids et tcpflow sont également disponibles sur d'autres versions d'Unix et ne vous limitent pas à Linux (contrairement à iptables).

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