google/gopacket + libpcap で作るツールのパケットバッファ戦略 - Copy/Cut/Paste/Hatena
tcpdpの中のお話です パケットを一時的に保持するバッファ google/gopacket/pcap パッケージでパケットを取得するようなツールを作る場合、2つのバッファを持つことになります。 libpcapが持つバッファ google/gopacketが持つバッファ（バッファ付きチャネル）。1000で固定。 パケットは加工されつつ上記のバッファを経由して、最後にgopacketからパケットを受けとることになります。 そしてバッファには、以下のような特徴があります。 libpcapが持つバッファが溢れたらパケットロスが発生します gopacketのバッファサイズは固定です libpcapは ImmediateMode がOFFだと、libpcapが持つバッファにある程度パケットを貯めてからまとめて返します 上記特徴からみても、ツールが正しく動くようにするためには いかにlibpcapのバ
TCPパケットを解析して構造化ログでダンプするツール tcpdp を作った - Copy/Cut/Paste/Hatena
やっと形になってきました。 github.com 「データベースのクエリログを取得したい」 例えば、データベース（RDBMS）のクエリログを取得したいとき一番確実な方法は、そのRDBMSに備わっているログ機構を利用することです。 一方で、全てのクエリログを出力するとなるとそれなりにIO負荷がかかることが予想されるので、負荷状況によってはクエリログ出力（のIO負荷）を別サーバに分離したくなります。 では、どうすればよいかというと、例えば アプリケーションサーバとデータベースサーバの間にプロキシサーバを挟んでそこで記録することでIO負荷を分離する アプリケーションサーバ側で（notアプリケーションで）記録することで（大抵、サーバ台数の多い）アプリケーション側にIO負荷を分散する というような方法を思いつきます。 そこで、「もし、TCPコネクション上に流れている（例えば）クエリログを解析してログ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
