Whitespace cleanup

* remove trailing whitespace
* remove empty lines at the end of files

plugins/apache/apache_vhosts/apache_vhosts

@@ -18,13 +18,13 @@ This plugin requires data from apache. You can get at the data in two ways:
   - slightly less performant, but easier to apply to existing installations
   - If you want response time stats, you have to log them in apache:
   <IfModule mod_log_config.c>
-    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D" combined-time  
+    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D" combined-time
   </IfModule>
   - Configure the log parser to match your installation regarding naming and log folders
-    
-You can use both solutions simultaneously, the data will be merged. 
+
+You can use both solutions simultaneously, the data will be merged.
 Be aware that a apache log CustomLog directive in the master config will only log those vhosts that have no directive of their own.
-  
+
 Install plugin conf (after [apache_*])
 
 [apache_vhosts]
@@ -36,14 +36,14 @@ env.checks requests bytes time
 # subgraphs 	- create multigraph subgraphs (watch your graphing performance...), default 0
 # checks	- enable stats on bytes and response times per request, you have to log these in apache
 
-A word on performance: 
+A word on performance:
 Requests/sec should not be much of a problem.  Pipelogger and Logparser should not have man performance problems, as the apply one regex per line and add some stats.
-Stats are saved every n seconds (default: 7) to shared mem in serialized format. That should be ok on the most loaded servers (unless you watch cache logs). 
-I would estimate that > 10k log lines/sec could start becoming a problem, you might have to start tuning there or use a dedicated system. 
+Stats are saved every n seconds (default: 7) to shared mem in serialized format. That should be ok on the most loaded servers (unless you watch cache logs).
+I would estimate that > 10k log lines/sec could start becoming a problem, you might have to start tuning there or use a dedicated system.
 You might think about splitting the logs over multiple Logparser scripts to parallelize and merge in larger intervals.
 
-Graphing is another matter, the more vhosts you have. 
-With subgraphs off, you do 3 main graphs * 4 timescales (day, week, month, year). 
+Graphing is another matter, the more vhosts you have.
+With subgraphs off, you do 3 main graphs * 4 timescales (day, week, month, year).
 With subgraphs on, you get 2 checks * (1 + 6 * #vhosts) + 1 check * (1 + #vhosts * #statuscodes * 4)
 With hundreds of vhosts that becomes a problem, as munin-update and munin-html do not scale well.
 
@@ -152,7 +152,7 @@ ${site}_${graph}_$check.type GAUGE
 END
         } # end graph
       } # end sites
-    } # end subgraph	
+    } # end subgraph
   } # end checks
 
 
@@ -173,7 +173,7 @@ graph_period minute
 graph_order $order
 END
   foreach my $site (keys %data) {
-  
+
     print <<END;
 ${site}_requests.label $data{$site}{'label'}
 ${site}_requests.info $site
@@ -230,7 +230,7 @@ foreach my $check (keys %checks) {
   } # end sites
 
   if ($subgraphs{$check}) {
-    # subgraph values 
+    # subgraph values
     foreach my $site (keys %data) {
       print "\nmultigraph apache_vhosts_$check.$site\n";
       foreach my $graph ("avg","max") {