willsion / appaloosa-zabbix-templates

Automatically exported from code.google.com/p/appaloosa-zabbix-templates
0 stars 0 forks source link

Zabbix trapper instead of Zabbix agent #1

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I've written a simple shell script and Perl wrapper for Cacti's PHP script, 
because IMHO Zabbix trapper is better solution here. I need to run the PHP 
script only once instead of 165 times like for Zabbix agent.

Please note that I run my script via Cron 2 times in 1 minute (hint: `sleep 
30`). For debugging/verbose mode you can set DEBUG=1. I also renamed Cacti's 
ss_get_mysql_stats.php file to mysql-stats.php.

I like your Zabbix template and I'm happy with it, so I would like to share my 
files with another users. I hope they will be useful.

Original issue reported on code.google.com by pte...@icm.edu.pl on 11 Jan 2011 at 10:21

Attachments:

GoogleCodeExporter commented 9 years ago
Hi,

Thanks for submitting the patch.

For the time being, I don't think we'll integrate your changes because we 
haven't seen any noticeable performance impact. The PHP script is very highly 
tuned and it only actually connects to mysql the first time it runs every 
couple of minutes. The remaining 164 are reading a simple cache file.

If this issue becomes a popular one, we'll likely integrate then.

-B

Original comment by br...@palominodb.com on 11 Jan 2011 at 10:43

GoogleCodeExporter commented 9 years ago
Thanks for your comments! OK, feel free! :)

Probably you're right with the PHP script. But please note that you have to 
load and run /usr/bin/php binary and its static/dynamic libraries 165 times... 
Yes, of course your OS can cache them too, but I prefer to do it only one time 
:)

Original comment by pte...@icm.edu.pl on 11 Jan 2011 at 11:13

GoogleCodeExporter commented 9 years ago
That's definitely true. I'm certainly not saying that being parsimonious with 
system resources is bad. Just that when we were building it, going this route 
was easier and didn't cause any appreciable difference in overall cpu usage 
thus it was deemed low priority.

If at some point we find a need to be more parsimonious, we will certainly do 
that.

FWIW, there are also scales of parsimony - and the tradeoffs associated. A good 
example is that the cacti script is written in PHP at all, versus Perl or C, 
both of which may or may not be more parsimonious with system resources.

-B

Original comment by br...@palominodb.com on 12 Jan 2011 at 4:33

GoogleCodeExporter commented 9 years ago
Thanks - this was useful not only for reducing load but allowing us to remotely 
execute the php scripts outside of the db hosts.  Our db servers are heavily 
loaded and we'd prefer not to have php on them, let alone ~200 load/run cycles 
just to collect a pass of metrics.

Original comment by pepperni...@gmail.com on 4 Mar 2011 at 12:40

GoogleCodeExporter commented 9 years ago
I'm glad it was helpful for you :) I didn't think about remotly executing my 
scripts, because I don't have the performance issues with my db server. So you 
can see there hardcoded localhost, for example. But probably I could fix it and 
send here improved version of the shell script.

Original comment by pte...@icm.edu.pl on 4 Mar 2011 at 1:22