Feed: Site apache-monitor.com News RSS feed. - AggScore: 46.8
Summary: Site apache-monitor.com News RSS feed.
Site apache-monitor.com news and events. New software announcements and software updates
How to monitor Apache web server traffic in real-time using apachetop
Apachetop is a very useful program that displays the stats for Apache in real time. Apachetop can show you how many requests per second are coming in, what files have been accessed and how many times. It can also show you who is hitting the sites and where they are coming from.
1. Installing apachetop
To install apachetop in CentOS, Fedora:
# yum install apachetop
Make sure you have DAG repository enabled.
To install apachetop in Debian,
Ubuntu:
# sudo apt-get install apachetop
To install apachetop in FreeBSD:
# cd /usr/ports/sysutils/apachetop/
# make install clean
2. Using apachetop
apachetop essentially just watches the log files and constantly
computes the stats. It can be set to show stats for the last set
amount of time, or for the last set number of hosts.
It defaults to monitoring the defaults apache log file, but if
you have virtual hosts, you will need to tell it to watch these
also with the -f flag.
# apachetop -f /var/log/httpd/site1-access_log -f /var/log/httpd/site2-access_log
If your web server gets a low number of hits you can use the -N flag so that it shows you more information instead of clearing hits after 30 seconds. The -N flag sets the number of hits apachetop remembers. You can also use -T to change the length of time it remembers the hits.
This command will show stats for hits in the last 5 minutes.
# apachetop -N 300 -f /var/log/httpd/access_log
This command will have apachetop remember the last 100 hits and show the statistics for them.
# apachetop -T 100 -f /var/log/httpd/access_log
Once in apachetop the program will begin displaying and calculating the stats as they come in, so at first it will be blank. To switch between showing what files are getting hit, what hosts are accessing the web server, and where they are coming from press "d".
For the help menu press "h".
What is HSLAB HTTP Monitor ?
Real-time performance monitoring solution for Apache servers.
Company
Website : http://apache-monitor.com
HSLAB HTTP Monitor is a handy real-time performance monitoring
and statistics analysis software application for Apache servers,
which are used ubiquitously in the web hosting industry.
Basically, with HSLAB monitoring system administrators always
know who is currently connected (via connection tree), server
operations distribution, amount of bandwidth being consumed,
number of server requests per unit of time and other important
server parameters.
Most importantly, HSLAB HTTP Monitor is server-independent. That
is the server running on Apache may be located thousands of miles
away, while the program (HSLAB HTTP Monitor) could be installed
on home or office PC and the system administrator will always
have access to server’s statistics or history real-time. This
tool is very handy for many system administrators and web
masters, because less then 1% of all servers are located in the
same place where IT professionals work from.
HSLAB HTTP Monitor shows all virtual servers being hosted,
statistics for them and what files or documents are being
accessed. There is an option to create a profile for each virtual
server – a handy feature indeed. HSLAB HTTP Monitor shows what
operations are being executed:
Waiting for Connection, Starting up, Reading Request; Sending
Reply; Keepalive (read); DNS Lookup; Closing connection; Logging;
Gracefully finishing; Idle cleanup of worker; Open slot with no
current process.
Apache VirtualHost Examples: Running several name-based web sites on a single IP address
Your server has a single IP address, and multiple aliases (CNAMES) point to this machine in DNS. You want to run a web server for www.example.com and www.example.org on this machine.
Note
Creating virtual host configurations on your Apache server does not magically cause DNS entries to be created for those host names. You must have the names in DNS, resolving to your IP address, or nobody else will be able to see your web site. You can put entries in your hosts file for local testing, but that will work only from the machine with those hosts entries.
Server configuration
# Ensure that Apache listens on port 80
Listen 80
# Listen for virtual host requests on all IP addresses
NameVirtualHost *:80
DocumentRoot /www/example1
ServerName www.example.com
# Other directives here
DocumentRoot /www/example2
ServerName www.example.org
# Other directives here
The asterisks match all addresses, so the main server serves no requests. Due to the fact that www.example.com is first in the configuration file, it has the highest priority and can be seen as the default or primary server. That means that if a request is received that does not match one of the specified ServerName directives, it will be served by this first VirtualHost.
Note
You can, if you wish, replace * with the actual IP address of the system. In that case, the argument to VirtualHost must match the argument to NameVirtualHost:
NameVirtualHost 172.20.30.40
# etc ...
However, it is additionally useful to use * on systems where the IP address is not predictable - for example if you have a dynamic IP address with your ISP, and you are using some variety of dynamic DNS solution. Since * matches any IP address, this configuration would work without changes whenever your IP address changes.
The above configuration is what you will want to use in almost all name-based virtual hosting situations. The only thing that this configuration will not work for, in fact, is when you are serving different content based on differing IP addresses or ports.
Name-based hosts on more than one
IP address.
Note
Any of the techniques discussed here can be extended to any number of IP addresses.
The server has two IP addresses. On one (172.20.30.40), we will serve the "main" server, server.domain.com and on the other (172.20.30.50), we will serve two or more virtual hosts.
Server configuration
Listen 80
# This is the "main" server running on 172.20.30.40
ServerName server.domain.com
DocumentRoot /www/mainserver
# This is the other address
NameVirtualHost 172.20.30.50
DocumentRoot /www/example1
ServerName www.example.com
# Other directives here ...
DocumentRoot /www/example2
ServerName www.example.org
# Other directives here ...
Any request to an address other than 172.20.30.50 will be served from the main server. A request to 172.20.30.50 with an unknown hostname, or no Host: header, will be served from www.example.com.
Serving the same content on
different IP addresses (such as an internal and external
address).
The server machine has two IP addresses (192.168.1.1 and 172.20.30.40). The machine is sitting between an internal (intranet) network and an external (internet) network. Outside of the network, the name server.example.com resolves to the external address (172.20.30.40), but inside the network, that same name resolves to the internal address (192.168.1.1).
The server can be made to respond to internal and external requests with the same content, with just one VirtualHost section.
Server configuration
NameVirtualHost 192.168.1.1
NameVirtualHost 172.20.30.40
DocumentRoot /www/server1
ServerName server.example.com
ServerAlias server
Now requests from both networks will be served from the same VirtualHost.
Note:
On the internal network, one can just use the name server rather than the fully qualified host name server.example.com.
Note also that, in the above example, you can replace the list of IP addresses with *, which will cause the server to respond the same on all addresses.
Running different sites on
different ports.
You have multiple domains going to the same IP and also want to serve multiple ports. By defining the ports in the "NameVirtualHost" tag, you can allow this to work. If you try using without the NameVirtualHost name:port or you try to use the Listen directive, your configuration will not work.
Server configuration
Listen 80
Listen 8080
NameVirtualHost 172.20.30.40:80
NameVirtualHost 172.20.30.40:8080
ServerName www.example.com
DocumentRoot /www/domain-80
ServerName www.example.com
DocumentRoot /www/domain-8080
ServerName www.example.org
DocumentRoot /www/otherdomain-80
ServerName www.example.org
DocumentRoot /www/otherdomain-8080
IP-based virtual hosting
The server has two IP addresses (172.20.30.40 and 172.20.30.50) which resolve to the names www.example.com and www.example.org respectively.
Server configuration
Listen 80
DocumentRoot /www/example1
ServerName www.example.com
DocumentRoot /www/example2
ServerName www.example.org
Requests for any address not specified in one of the directives (such as localhost, for example) will go to the main server, if there is one.
Mixed port-based and ip-based
virtual hosts
The server machine has two IP addresses (172.20.30.40 and 172.20.30.50) which resolve to the names www.example.com and www.example.org respectively. In each case, we want to run hosts on ports 80 and 8080.
Server configuration
Listen 172.20.30.40:80
Listen 172.20.30.40:8080
Listen 172.20.30.50:80
Listen 172.20.30.50:8080
DocumentRoot /www/example1-80
ServerName www.example.com
DocumentRoot /www/example1-8080
ServerName www.example.com
DocumentRoot /www/example2-80
ServerName www.example.org
DocumentRoot /www/example2-8080
ServerName www.example.org
Mixed name-based and IP-based
vhosts
On some of my addresses, I want to do name-based virtual hosts, and on others, IP-based hosts.
Server configuration
Listen 80
NameVirtualHost 172.20.30.40
DocumentRoot /www/example1
ServerName www.example.com
DocumentRoot /www/example2
ServerName www.example.org
DocumentRoot /www/example3
ServerName www.example3.net
# IP-based
DocumentRoot /www/example4
ServerName www.example4.edu
DocumentRoot /www/example5
ServerName www.example5.gov
Using Virtual_host and mod_proxy
together
The following example allows a front-end machine to proxy a virtual host through to a server running on another machine. In the example, a virtual host of the same name is configured on a machine at 192.168.111.2. The ProxyPreserveHost On directive is used so that the desired hostname is passed through, in case we are proxying multiple hostnames to a single machine.
ProxyPreserveHost On
ProxyPass / http://192.168.111.2
ProxyPassReverse / http://192.168.111.2/
ServerName hostname.example.com
Using _default_ vhosts
_default_ vhosts for all ports
Catching every request to any unspecified IP address and port, i.e., an address/port combination that is not used for any other virtual host.
Server configuration
DocumentRoot /www/default
Using such a default vhost with a wildcard port effectively prevents any request going to the main server.
A default vhost never serves a request that was sent to an address/port that is used for name-based vhosts. If the request contained an unknown or no Host: header it is always served from the primary name-based vhost (the vhost for that address/port appearing first in the configuration file).
You can use AliasMatch or RewriteRule to rewrite any request to a single information page (or script).
_default_ vhosts for different
ports
Same as setup 1, but the server listens on several ports and we want to use a second _default_ vhost for port 80.
Server configuration
DocumentRoot /www/default80
# ...
DocumentRoot /www/default
# ...
The default vhost for port 80 (which must appear before any default vhost with a wildcard port) catches all requests that were sent to an unspecified IP address. The main server is never used to serve a request.
_default_ vhosts for one port
We want to have a default vhost for port 80, but no other default vhosts.
Server configuration
DocumentRoot /www/default
...
A request to an unspecified address on port 80 is served from the default vhost. Any other request to an unspecified address and port is served from the main server.
Migrating a name-based vhost to
an IP-based vhost
The name-based vhost with the hostname www.example.org (from our name-based example, setup 2) should get its own IP address. To avoid problems with name servers or proxies who cached the old IP address for the name-based vhost we want to provide both variants during a migration phase.
The solution is easy, because we can simply add the new IP address (172.20.30.50) to the VirtualHost directive.
Server configuration
Listen 80
ServerName www.example.com
DocumentRoot /www/example1
NameVirtualHost 172.20.30.40
DocumentRoot /www/example2
ServerName www.example.org
# ...
DocumentRoot /www/example3
ServerName www.example.net
ServerAlias *.example.net
# ...
The vhost can now be accessed through the new address (as an IP-based vhost) and through the old address (as a name-based vhost).
Using the ServerPath directive
We have a server with two name-based vhosts. In order to match the correct virtual host a client must send the correct Host: header. Old HTTP/1.0 clients do not send such a header and Apache has no clue what vhost the client tried to reach (and serves the request from the primary vhost). To provide as much backward compatibility as possible we create a primary vhost which returns a single page containing links with an URL prefix to the name-based virtual hosts.
Server configuration
NameVirtualHost 172.20.30.40
# primary vhost
DocumentRoot /www/subdomain
RewriteEngine On
RewriteRule ^/.* /www/subdomain/index.html
# ...
DocumentRoot /www/subdomain/sub1
ServerName www.sub1.domain.tld
ServerPath /sub1/
RewriteEngine On
RewriteRule ^(/sub1/.*) /www/subdomain$1
# ...
DocumentRoot /www/subdomain/sub2
ServerName www.sub2.domain.tld
ServerPath /sub2/
RewriteEngine On
RewriteRule ^(/sub2/.*) /www/subdomain$1
# ...
Due to the ServerPath directive a request to the URL
http://www.sub1.domain.tld/sub1/ is always served from
the sub1-vhost.
A request to the URL http://www.sub1.domain.tld/ is only served
from the sub1-vhost if the client sent a correct Host: header. If
no Host: header is sent the client gets the information page from
the primary host.
Please note that there is one oddity: A request to http://www.sub2.domain.tld/sub1/ is also served from the sub1-vhost if the client sent no Host: header.
The RewriteRule directives are used to make sure that a client which sent a correct Host: header can use both URL variants, i.e., with or without URL prefix.
Copyright 2006 The Apache Software Foundation.
Licensed under the Apache License, Version 2.0
How to configure For Apache versions 2.2.x ?
First of all, you should be convinced, that your server uses the mod_status module. For this purpose open in your text editor a web server configuration file httpd.conf. Find the section loading modules and check up, whether there is there a line:
LoadModule status_module modules/mod_status.so
This line can differ a little depending on the version of your
server and operation system. If this line has ahead a symbol
# that remove it.
Now you should locate lines:
# Real-time info on requests and configuration
#Include conf/extra/httpd-info.conf
and uncomment second line:
# Real-time info on requests and configuration
Include conf/extra/httpd-info.conf
Now need to proceed to a configuration of the status. Open
conf/extra/httpd-info.conf file and find the lines:
#ExtendedStatus On
Remove # symbol:
ExtendedStatus On
Check your domain name:
SetHandler server-status
Order deny,allow
Deny from all
Allow from .yourdomain.com
Or for testing:
SetHandler server-status
Order deny,allow
Deny from all
Allow from all
Line "Allow from .yourdomain.com" enables queries of the status from any computer of your domain(yourdomain.com). If you want to limit access only for the your computer, you should write "Allow from yourcomputer.yourdomain.com". Where your computer is a name of your computer and yourdomain - a name of your domain. Also you can write "Allow from all". In this case, the statistics of your wed server will be accessible from any computer in the Internet. We urgently do not recommend so to do, you should have very serious reason for this purpose!
Your web server configuration is finished! Now you should save your changes and restart your web the server.
Announcing HSLAB HTTP Monitor Windows 7/Windows Server 2008 R2 Compatibility Status
For Release 17:48 GMT +2 30.08.2010 Handy Software Lab Releases New Version of its HSLAB HTTP Monitor, a handy real-time performance monitoring and statistics analysis software application for Apache web servers
Handy Software Lab today announced it will launch a new version of its application, HSLAB HTTP Monitor, which works with Microsoft Windows7/Microsoft Windows Server2008 R2 to offer customers enhanced security, as well as innovative user interface features and reliability improvements.With HSLAB HTTP Monitor, administrators always know who is currently connected, server operations distribution, amount of bandwidth being consumed, and number of server requests per unit of time. Since software is server independent, server running on Apache may be located thousands of miles away from where program is installed. Software shows all virtual servers being hosted, statistics for them, and what files or documents are being accessed.
?Our ISV community is alive with innovation, and we?re committed to helping our partners drive the next generation of software experiences,? said Ross Brown, Vice President of ISV and Solutions Partners for the Worldwide Partner Group at Microsoft. ?Adding compatibility for the latest Microsoft operating systems helps ISVs to stay ahead of the competition and give their customers access to cutting-edge technologies.?
Handy Software Lab is excited to launch this new version of HSLAB HTTP Monitor, said CEO at Handy Software Lab. ?Making our application compatible with Microsoft Windows 7/Microsoft Windows Server 2008 R2 helps us offer our customers compelling benefits, including intuitive user interfaces, improved security and reliability features, full support for multi-core processing, sophisticated management features, flexible access administration.
Handy Software Lab(HSLAB), founded in 1998 as a wholly-owned business is focused on the development, marketing, distribution and support of leading control and statistical software in a variety of application areas. Our software meets the needs of both corporate system administrators and home users. The company is capable of satisfy a consumer demand for high-quality and hi-tech software, at maintenance of secure online sales transactions, immediate delivery of a product and high-quality support.
HSLAB's award winning programs are powerful, designed with high-quality and extensive functionality, and presented in an easy-to-use graphical and command line interface designed to appeal to and fulfill the needs of administrators, power users and novices alike. HSLAB is continually working to improve existing products, as well as to produce new ones to satisfy every specific customer's needs. Whether you are looking for innovative software or software for process-control, security, or statistical software, HSLAB has products which will help you cope with the tasks you face.
How to configure Apache versions 1.3.x - 2.0.x ?
First of all, you should be convinced, that your server uses
the
mod_status module. For this purpose open in your text editor a
web
server configuration file httpd.conf. Find the section loading
modules
and check up, whether there is there a line:
LoadModule status_module modules/mod_status.so
This line can differ a little depending on the version of your
server
and operation system. If this line has ahead a symbol # that
remove
it.
Read more at
http://www.hs-lab.com/usage/faq/content/2/1/en/how-to-configure-apach...
Visitor Rating: 5 (1) (Rate)
 |
|
Story Clicks: 0
Feed Views: 20
Lenses (Add|?)
Comments (Log in to add)
Feed Details
Date Approved: 02/19/2011
By: Anonymous
Search FeedAgg.com
3600 mp8680 serv 1.2949 seconds to generate.