Code Monkey home page Code Monkey logo

mod-sflow's Introduction

Copyright (c) 2002-2010 InMon Corp. Licensed under the terms of the InMon sFlow licence:
http://www.inmon.com/technology/sflowlicense.txt

                              mod_sflow
                              =========

  A binary, random-sampling Apache module designed for:
       lightweight,
        centralized,
         continuous,
          real-time monitoring of very large and very busy web farms.

Installation (from rpm)
=======================

  Make sure the httpd-devel package is installed (to get the "apxs"
  command), then try this:

    $ rpmbuild -ba mod_sflow.spec

  (You might have to copy the mod-sflow-<vesrion>.tar.gz file into
   whatever SOURCES directory rpmbuild looks in, and try again)

  rpmbuild will write the rpm into its RPMS/<arch>/ directory. To
  install mod-sflow on this server (and any other server with
  the same architecture, OS and apache version):

    $ rpm -Uvh mod-sflow-<version>.<os>.<arch>.rpm

  confirm that the mod_sflow.so file and related httpd.conf config
  went to the right place, then restart apache via:

    $ apachectl restart

Installation (direct from sources)
==================================

  Compile and install the module into Apache's modules directory 
  and add it to the apache httpd.conf config file by running:

    $ rm -f `apxs -q LIBEXECDIR`/mod_sflow.so
    $ apxs -c -i -a mod_sflow.c sflow_api.c

  Then restart Apache via:

    $ apachectl restart

  Note:  the first step where the module is removed is important as
  a workaround for Apache bug #47951.

  For debug logging, set "LogLevel debug" in your apache httpd.conf
  file and then compile with this extra option:
    $ apxs -Wc,-DSFWB_DEBUG -c -i -a mod_sflow.c sflow_api.c

Configuration
=============

  This module reads it sFlow configuration from the /etc/hsflowd.auto
  file that is generated automatically when you run the host-sflow
  daemon "hsflowd" on the same server:

  http://host-sflow.sourceforge.net

  Optionally,  you can also install a handler that will return the
  latest counter values.  This goes into your httpd.conf file,  or
  in a separate file .../httpd/conf.d/sflow.conf:

    <IfModule mod_sflow.c>
      <Location /sflow>
        SetHandler sflow
      </Location>
    </IfModule>

  After restarting apache again, you should now be able to visit
  http://<server>/sflow/ and see text/plain output like this:

    counter method_option_count 0
    counter method_get_count 34
    counter method_head_count 0
    counter method_post_count 0
    counter method_put_count 0
    counter method_delete_count 0
    counter method_trace_count 0
    counter method_connect_count 0
    counter method_other_count 0
    counter status_1XX_count 0
    counter status_2XX_count 17
    counter status_3XX_count 0
    counter status_4XX_count 17
    counter status_5XX_count 0
    counter status_other_count 0
    string hostname 10.0.0.119
    gauge sampling_n 400

Output
======

  The sFlow output goes to a UDP port on your sFlow collector host.
  There you can examine it using a number of tools,  including the
  freeware "sflowtool", which can be downloaded as source code from:
  
  http://www.inmon.com/technology/sflowTools.php

  For example, to log all the fields in ASCII:
 
  $ sflowtool

  Or to log the HTTP samples in common-log-file format:

  $ sflowtool -H


Example output from sflowtool:

	startDatagram =================================
	datagramSourceIP 10.0.0.150
	datagramSize 192
	unixSecondsUTC 1294168545
	datagramVersion 5
	agentSubId 32576
	agent 10.0.0.150
	packetSequenceNo 7
	sysUpTime 25000
	samplesInPacket 1
	startSample ----------------------
	sampleType_tag 0:1
	sampleType FLOWSAMPLE
	sampleSequenceNo 1
	sourceId 3:65537
	meanSkipCount 400
	samplePool 124
	dropEvents 0
	inputPort 0
	outputPort 1073741823
	flowBlock_tag 0:2100
	extendedType socket4
	socket4_ip_protocol 6
	socket4_local_ip 10.0.0.150
	socket4_remote_ip 10.0.0.70
	socket4_local_port 80
	socket4_remote_port 63023
	flowBlock_tag 0:2201
	flowSampleType http
	http_method 2
	http_protocol 1001
	http_uri /membase.php
	http_host 10.0.0.150
	http_useragent Java/1.6.0_22
	http_bytes 3487
	http_duration_uS 24278
	http_status 200
	endSample   ----------------------
	endDatagram   =================================
	startDatagram =================================
	datagramSourceIP 10.0.0.150
	datagramSize 116
	unixSecondsUTC 1294168501
	datagramVersion 5
	agentSubId 32576
	agent 10.0.0.150
	packetSequenceNo 3
	sysUpTime 42000
	samplesInPacket 1
	startSample ----------------------
	sampleType_tag 0:2
	sampleType COUNTERSSAMPLE
	sampleSequenceNo 3
	sourceId 3:65537
	counterBlock_tag 0:2201
	http_method_option_count 0
	http_method_get_count 113
	http_method_head_count 0
	http_method_post_count 0
	http_method_put_count 0
	http_method_delete_count 0
	http_method_trace_count 0
	http_methd_connect_count 0
	http_method_other_count 0
	http_status_1XX_count 0
	http_status_2XX_count 112
	http_status_3XX_count 0
	http_status_4XX_count 1
	http_status_5XX_count 0
	http_status_other_count 0
	endSample   ----------------------
	endDatagram   =================================

AUTHORS:
Neil McKee <[email protected]>
Ian Meyer <[email protected]>

mod-sflow's People

Watchers

 avatar

mod-sflow's Issues

httpd graceful sending SIGKILL to ALL processes on the system

What steps will reproduce the problem?
1. httpd -k graceful

What is the expected output? What do you see instead?
Sending HUP/USR1 to the parent httpd process should lead to httpd killing off 
child processes and starting new ones. This works fine *once*.

On the *second* HUP/USR1, the httpd parent process is sending a SIGKILL to pid 
-1 (ALL processes on the system).  

What version of the product are you using? On what operating system?

mod_sflow-1.0.4 with httpd-2.2.15-30.el6 CentOS 6.5.

Please provide any additional information below.

First off, I have mod_sflow installed and running on a few hundred machines 
without any problems. I have about 7 of them that are having this problem. I 
haven't yet determined why these 7 VMs are "special".

I've tracked it down to these lines in mod_sflow.c:
    apr_proc_t *prev_sflow_master = NULL;
    apr_pool_userdata_get((void **)&prev_sflow_master, MOD_SFLOW_USERDATA_KEY_SFLOWMASTER, s->process->pool);
    if(prev_sflow_master) {
        apr_proc_kill(prev_sflow_master, SIGKILL);
    }

The first HUP/USR1 sent to httpd does the right thing. apr_pool_userdata_get() 
returns an apr_proc_t pointer that has a perfectly valid pid of the mod_sflow 
master process.

The second HUP/USR1 sent to httpd returns a valid apr_proc_t pointer with a pid 
of -1. If you watch in strace, you will see 'kill(4294967295, SIGKILL)' in 
strace.

What's going on here?  It don't know much about writing apache modules, but it 
seems to me that the later call to apr_pool_note_subprocess() should tell 
apache to cleanup processes so mod_sflow doesn't have to do it.  Am I wrong?

Adding a simple 'if (prev_sflow_master->pid != -1)' around kill() prevents the 
larger problem from occurring, but I don't understand what's actually going on 
here.


Original issue reported on code.google.com by [email protected] on 30 Apr 2014 at 12:28

Compiling for Apache 2.4.1 requires an edit for connection from remote_addr to client_addr

What steps will reproduce the problem?
1. Use apache 2.4.1 as apache source
2. Compile mod_sflow
3. errors with 
apxs -c -i -a mod_sflow.c sflow_api.c 
/opt/httpd/build/libtool --silent --mode=compile gcc -std=gnu99 -prefer-pic   
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -pthread -I/opt/httpd/include  
-I/opt/httpd/include   -I/opt/httpd/include   -c -o mod_sflow.lo mod_sflow.c && 
touch mod_sflow.slo
mod_sflow.c: In function 'sflow_sample_http':
mod_sflow.c:411: error: 'struct conn_rec' has no member named 'remote_addr'
apxs:Error: Command failed with rc=65536


What version of the product are you using? On what operating system?
building on Centos 6.2 
2.6.32-220.el6.x86_64

Please provide any additional information below.
Following this guide
http://httpd.apache.org/docs/trunk/developer/new_api_2_4.html#upgrading

I found that if I made the following patch to mod_sflow.c it would compile 
properly

diff mod-sflow-1.0.0/mod_sflow.c ../mod-sflow-1.0.0/mod_sflow.c 
411c411
<         apr_sockaddr_t *peersoc = connection->remote_addr;

---
>         apr_sockaddr_t *peersoc = connection->client_addr;

I havent tested yet to verify the host will work.

Original issue reported on code.google.com by [email protected] on 26 Apr 2012 at 7:43

Seg faults after graceful from log rotate

What steps will reproduce the problem?
1. Install mod-sflow 1.0.0 on CentOS 5.7 Httpd - 2.2.3-53
2. Wait for log rotate to run a graceful on httpd
3. See segmentation faults

What is the expected output? What do you see instead?
Should gracefully restart without issue.
Instead immediately all child PIDs begin seg faulting.
[Wed May 30 04:02:04 2012] [notice] Digest: generating secret for digest 
authentication ...
[Wed May 30 04:02:04 2012] [notice] Digest: done
[Wed May 30 04:02:04 2012] [notice] Apache configured -- resuming normal 
operations
[Wed May 30 04:02:04 2012] [notice] child pid 27869 exit signal Segmentation 
fault (11)
[Wed May 30 04:02:04 2012] [notice] child pid 27870 exit signal Segmentation 
fault (11)

What version of the product are you using? On what operating system?
1.0.0
CentOS 5.7

Please provide any additional information below.
Initial  thought it was due to hsflowd not running, but this last seg faulting 
issue occurred while hsflowd was happily running.
Looks like it is directly tied to the httpd graceful call.
Any ideas?

-Chrus

Original issue reported on code.google.com by [email protected] on 30 May 2012 at 11:59

data sent by mod_sflow is incomplete

I've starting playing with mod_sflow (and sflow in general) and it seems the 
URL data sent by mod_sflow is incomplete.

This is what "sflowtool -H" shows:
127.0.0.1 - - [01/Aug/2011:22:57:24 +0200] "GET /index.html HTTP/1.1" 200 14 
"-" "Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/"

This is the entry from the access log:
127.0.0.1 - - [01/Aug/2011:22:57:24 +0200] "GET /index.html?test=1 HTTP/1.1" 
200 14 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0"

There are two problems:
1. The query string is missing
2. The part "5.0" is cut off the end of the line

Original issue reported on code.google.com by [email protected] on 1 Aug 2011 at 9:08

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.