Comments on: sar-sql: The Script Formerly Known as MySAR

By: Announcing mycheckpoint: lightweight, SQL oriented monitoring for MySQL | code.openark.org

Tue, 10 Nov 2009 13:17:30 +0000

[...] recently, a somewhat similar project, sar-sql was announced by Gerry Narvaja (Ex-Pythian). When sar-sql (formerly MySAR) was announced, my own [...]

By: Sheeri Cabral

Sheeri Cabral — Thu, 29 Oct 2009 19:10:26 +0000

Giannis — Gerry’s tool was named “mysar”, just like your tool, but it’s completely different. When someone let him know that there was already a tool named “mysar”, Gerry changed the name, and that was one of the points of this post — Gerry’s tool is now called “sar-sql” and is different from your “mysar” tool.

By: Giannis Stoilis

Giannis Stoilis — Thu, 29 Oct 2009 05:44:53 +0000

Hi,

I am the original MySAR maintainer. It’s great to finally see someone pick up where I left off. Good luck!

By: Justin Swanhart

Justin Swanhart — Thu, 29 Oct 2009 04:32:51 +0000

I’m sorry. I assumed that it was collecting SAR data and persisting it into a mysql database.

By: Gerry Narvaja

Gerry Narvaja — Wed, 28 Oct 2009 23:23:14 +0000

As I explained in my initial article: MySAR: A sar-like Utility for MySQL (http://www.pythian.com/news/4230/mysar-a-sar-like-utility-for-mysql) and the follow up: MySAR, a Sidekick for Other Monitoring Tools (http://www.pythian.com/news/4230/mysar-a-sar-like-utility-for-mysql), this script is not intended to replace any monitoring tool.

Example #1: At Pythian, we rarely have access to any of the monitoring tools that the customer might have installed, but we still need to look at a snapshot of what happened when there is an incident. This script gives us a quick and dirty way to query the global status and/or processlist at the time. It has very low overhead and it can be enabled and disabled at will on the crontab.

Example #2: The reason it has *sar* in the name is not casual. Many system administrators that use these monitoring systems, still consult its output for quick and dirty diagnosis and nobody argues about it’s usefulness.

Before starting to code, I spend some time googling for similar utilities, and found none that would provide any persistency of the values in a database.

Using *sar-sql* as a monitoring tool is not going to work. Monitoring tools provide alarms, graphics and notifications which are beyond the scope of this project.

My $.02
G

By: Justin Swanhart

Justin Swanhart — Wed, 28 Oct 2009 21:40:41 +0000

Seems like you are reinventing the wheel.

There are so many pluggable systems that generate and save metrics that it seems silly to reinvent another one.

Nagios – active/NRPE checks can collect metrics directly to RRD, but RRD is lossy

EMT – wrap iostat,sar,vmstat,etc and collect CSV files – but there is no way to centrally collect and aggregate them

MonAMI – pluggable monitoring agent that can forward probes to multiple places (nagios, ganglia, mysql collection etc)

Cacti – has its own poller to collect stats for CPU/MySQL/etc into RRD

And more…

Why keep reinventing the wheel?

I’m becoming a huge fan of MonAMI, as it is a single agent that pushes data to multiple systems for processing.