Stats Control (Yet another AwStats Plugin ;)

getting more permission type problems now.

on the server I tried it on first, where only the static page worked but now without changing anything I suddenly get an error it cannot write a temp file in the stats dir, when navigating to that dir the file doesnt exist. The dir was owned by root:wheel and i changed to user:user to see if this will fix after next update.

On another server I am installing this onto, the static page fails with the create dir error, but this is in the user's dir not the ip url, having checked the dir permissions and ownership I see no reason for the error assuming it is running as the user. It works with the awstats viewer but all the stats are 0 and it says no update has been performed yet. This is the 3rd day so at elast 2 updates should have been performed and I ran the command manually in the shell a couple of times.

Can give you feedback but their seems to be no debugging info been logged and the log file in /var/log shows no errors.
 
ClayRabbit said: However plugin have additional option where you can specify maximum log size, so it will be rotated any day when it's goes over specified limit.
Click to expand...
When it triggers by size, I would assume that the stats run and rotation would occur at night along with the normal stats run and not in the middle of the day?
 
ClayRabbit:
I'm not seeing any winners on this thread. You say it works for you. So perhaps we can create a success story. Chrysalis has been working with it on his FreeBSD servers and mine to get it to work. We both want reliable stats that work on FreeBSD and DA. The logs don't seem to give us anything to go on. You have knowledge of the product that no one else has so you know what needs to change when things don't work. I will private contact you to see if we can work something out to where you can get the plug-in going on our server. This server has one domain that maintains between 400,000 and 1.1 million pages in Google, and does more traffic in an hour than most sites do in a year. It has another with over a 1/4 million pages. These two sites have a secondary tracking service that records one in every 10 pages. That ratio has been verified for over two years with our previous server that had AWStats. It will be easy to determine when it's working right, and you won't have to need to wait for traffic to test.

If we could work something out, I think that would encourage others as well to persevere with your plug-in, and may highlight some common problems and solutions. If it can track that server's traffic, it can track any server's traffic, and nobody will be able to dispute your plug-in's capabilities.
 
IT_Architect said:
I'm not seeing any winners on this thread. You say it works for you. So perhaps we can create a success story. Chrysalis has been working with it on his FreeBSD servers and mine to get it to work.
Click to expand...

You've not been following it closely then, it's working perfectly on our Debian server, all the steps I've taken are within this thread.
 
Because it works on one server it doesnt mean its a flawless peice of code, each and every server is different, different configurations and versions of software can cause problems. I have tried debugging the plugin for instance seeing an error unable to create stats dir in /../stats indicates it cant create the stats dir in the parent directory, When running the awstats viewer we are able to view a stats page but all the stats are empty and it says no stats run yet and this gave me an idea of what might be going wrong, I see the plugin is using one central awstats.conf and then inserts variables into it dependant on what domain is been accessed, I believe on his server the variables are been inserted wrong causing all these problems. I have no idea why they would be wrong due to the no debugging capability, but we are at a loss now until we can either debug or clayrabbit has a look.

On my own test server my problem was resolved with the webalizier fix I had to add the disable line in directadmin.conf.

what I noticed on my server is that its got a seperatly named awstats.conf for the domain (not the case on it architect just /etc/awstats/awstats.conf and the dir does exist on my server but it says it cant write to a dir that has the right permissions so this would indicate that the variable are not working on his server and so its probably trying to make the dir in the wrong place and not reading the right logs, somehow its not able to send the username and domain name to awstats.

Also if webalizer is disabled in the main directadmin.conf will this stop it working for any domains at all?
 
Found problem with /bin/csh as default shell. When doing 'su' to user uid csh overrides environment variable $HOST which is used in scripts, and all goes wrong because of that. Fixed. Now scripts will use $HOSTNAME variable instead.

Also fixed minor bug in install script - rotation and webalizer was not disabled if lines 'rotation=1' and 'webalizer=1' was not found inside directadmin.conf. Now will add additional lines with rotation=0 and webalizer=0.

Version 2.07 released.
 
ahh good then.

On my server its resolved as far as I know, I forgot to do the webalizer=0 line so the dir permissions were been reset to root.

For the static page failure I believe its postnuke throwing a fit and taking over the entire domain so will add some other domain to the server that doesnt run postnuke to confirm this.

I just want to know if webalizer is disabled in directadmin.conf will this still allow some domains to run it if set in the plugin?
 
Chrysalis said:
I just want to know if webalizer is disabled in directadmin.conf will this still allow some domains to run it if set in the plugin?
Click to expand...
Of course. webalizer=0 means that DA wouldn't run webalizer, but it still can be used via plugin.
 
Success I think, thanks to ClayRabbit

It looks like I may have good stats. I tracked the log file on one of our large sites that also has cross-check capabilities. The log was ~253 megs for that domain for yesterday, and since I left the default log rotation size at 200 megs, I'm getting my daily rotation that I wanted anyway. Stats ran 00:40 EDT, which is perfect. The traffic distribution on the time graph lines up with our known traffic profile. So far what I see is encouraging. The site did approximately 6.25 gigs of transfer yesterday. Since it's a slow time and the middle of the week, the numbers could be correct. Rich is the traffic expert, and he will run the cross-check to verify the numbers. We have another somewhat smaller site on this server too with cross-check capabilities. That one creates a log file that ranges between 35 and 85 megs day. We will run the numbers on that one too.
 
It works!
The AWStats didn't cross to our other stats. It took awhile to figure things out. Then I noticed that AWStats was accurate when traffic wasn't heavy. Much past 9AM EDT, the two grow apart. I remembered running TOP at 9:40 today and noticed the server load was 17.7, but still very responsive. I remember thinking then that time that it looks like I'm not going to be able to wait until FreeBSD 6.1 before do something about that load. The max recording that we got from AWStats was just over 30,000 pages an hour with a consistent traffic pattern from 9AM all the way to 4PM. The other stats that record one in ten pages has a totally different and a curve that we are more accustomed to where the traffic continued upward to 3,800 by mid-day. Another oddity was the 30,000 mark didn't occur at the high point of the one in 10 service. Rich called me later and said things started to slow down around eleven, but I was not in the office to check the load. I'm guessing that Apache starts skipping entries in the log once it starts exceeding about 25,000 pages an hour. I'm guessing that some of the other sites were warming up in the middle of the day which is why the 30,000+ high mark didn't coincide with the high mark on the other stats. If the traffic actually had followed the AWStats curve, it would have been just as responsive at eleven as when I checked it. We'll have to aggregate with the other logs to get a more accurate picture, but that's what it looks like so far. Thus, it appears that ClayRabbit's plug-in for AWStats is working fine. I get good cut-offs and stats that check out. This site rotates automatically each night due to it's log size, so I won't be able to vouch for the monthly rotation on this particular site, but we do have a few small sites that we will be able to check it on. I'm not quite sure what my next move will be. This is not the site that needs the stats, but it was an easy one to test with. I'm concerned about what this site does to the stats of the others who do need it on the server.
 
IT_Architect said:
PS: I'm also going to need to get something better to monitor server load like ZABBIX.
Click to expand...

Wow.. ZABBIX sounds really cool.
Does it combine MRTG, CPU Loads and other vital sign info into a single repository?
Does it have a kill and restart triggers for high CPU loads?



http://www.zabbix.com/
 
Last edited:
Wow.. ZABBIX sounds really cool.
Does it combine MRTG, CPU Loads and other vital sign info into a single repository?
Does it have a kill and restart triggers for high CPU loads?
Click to expand...
Yes, but first let me clarify that I have not used ZABBIX yet. I've done my homework on the newsgroups and with the author on their newsgroup.

One limitation is that while it can monitor Windows machines, the machine hosting the database and managing the data collection cannot be a Windows machine. In theory, the monitoring machine can be on one of the same machines you are monitoring, but then it's difficult to make sense of the load on that machine. Of course in our case, that idea is out the window because of our server load.

Nagios is another very popular monitor, probably the most popular. It is also open source. The reason that I am going for ZABBIX rather than Nagios is that Nagios is less efficient and a lot more work to configure and maintain. It requires add-ons to get reports that you can stand to look at. The upside to Nagios, is it has been around for a long time, and there are a lot of vertical monitoring solutions built on top of it. I needed something as efficient as possible and low maintenance.

People on the forums indicate that ZABBIX is easy to install, very configurable, and the reports easy to put together. I doubt I would do that. You can contract the author to help you set it up and he will also do custom reports for you. Moreover, I would get the benefits of his insights and probably wouldn't think to do what comes naturally for him. His free product has become a revenue generator for his company. I just want a custom report or two that merges the data that I want to see, setup some triggers to do intelligent things when something goes wrong, and text message me when there is a problem.
 
Last edited:
You must log in or register to reply here.
Back
Top