Hi list,
First, I'd like to apologize if the subject of this mail is somewhat off-topic.
Davide Mendolia and me are currently working on: "Alternative PHP
Monitor" (APM - http://code.google.com/p/peclapm/) which consist of
three parts:
- a PHP extension which has as a goal of capturing "events" (warning,
error, notices,... and slow requests) storing them centrally in an
SQLite DB. - a webfrontend to display captured events (for now, it's basically a
table without any filtering or querying). - a "central aggregator" which collects events from the different
"nodes" (still not developped).
I think it is important to mention that we are talking about 100% Free
Software here :-)
An event is currently characterized with the following properties:
- a unique ID
- a timestamp
- a script filename/line number
- an event level corresponding to error levels
- a message
A "slow request" is characterized with the following properties:
- a unique ID
- a timestamp
- a script filename
- a duration
We'd like to have your opinion on our "next steps", what is the most
important feature according to you:
- The development of the central aggregator
- Collecting more info related to an "event" (content of variables
$GLOBALS, $_GET, $_POST,...) - alert systems (SNMP, Mailing, ...)
- Web services
- extending the webfrontend
Any similarity with existing Israeli products is purely coincidental. :-)
Thanks for your help,
Patrick
Neat idea. Why not open the sqlite db at MINIT rather then RINIT and
add a whole pile of overhead to every request.
Ilia Alshanetsky
Hi list,
First, I'd like to apologize if the subject of this mail is somewhat
off-topic.Davide Mendolia and me are currently working on: "Alternative PHP
Monitor" (APM - http://code.google.com/p/peclapm/) which consist of
three parts:
- a PHP extension which has as a goal of capturing "events" (warning,
error, notices,... and slow requests) storing them centrally in an
SQLite DB.- a webfrontend to display captured events (for now, it's basically a
table without any filtering or querying).- a "central aggregator" which collects events from the different
"nodes" (still not developped).I think it is important to mention that we are talking about 100% Free
Software here :-)An event is currently characterized with the following properties:
- a unique ID
- a timestamp
- a script filename/line number
- an event level corresponding to error levels
- a message
A "slow request" is characterized with the following properties:
- a unique ID
- a timestamp
- a script filename
- a duration
We'd like to have your opinion on our "next steps", what is the most
important feature according to you:
- The development of the central aggregator
- Collecting more info related to an "event" (content of variables
$GLOBALS, $_GET, $_POST,...)- alert systems (SNMP, Mailing, ...)
- Web services
- extending the webfrontend
Any similarity with existing Israeli products is purely
coincidental. :-)Thanks for your help,
Patrick
Neat idea. Why not open the sqlite db at MINIT rather then RINIT and add a
whole pile of overhead to every request.Ilia Alshanetsky
Also:
Pinba is something else that might be interesting to look into.
http://pinba.org
http://groups.google.com/group/pinba-engine/
But yes, pooling errors and such into a central server would be great...
2009/5/25 Ilia Alshanetsky ilia@prohost.org:
Neat idea. Why not open the sqlite db at MINIT rather then RINIT and add a
whole pile of overhead to every request.
Sounds logic, but I remember we thought about it and had to open it at
RINIT but I really don't remember those reason.
Do you see pro's for current situation or con's for implementing this at MINIT?
The only thing I see now is the ability to make the extension active
on a request basis rather than globally.
--
Patrick Allaert
http://code.google.com/p/peclapm/ - Alternative PHP Monitor
On Thu, May 28, 2009 at 5:49 PM, Patrick ALLAERT
patrick.allaert@gmail.comwrote:
The only thing I see now is the ability to make the extension active
on a request basis rather than globally.
Hi,
looks like the extension overrides zend_error_cb. Is this affected by
set_error_handler in the userland? If I remember correctly (might be wrong)
set_error_handler overrides zend_error_cb as well and that would cause APM
not to work out of the box with all applications. Not sure if that is design
goal of this extension..
--
Mikko Koppanen
We'd like to have your opinion on our "next steps", what is the most
important feature according to you:
- The development of the central aggregator
Yes, we run 24 boxes with PHP on them running the same code base. When
we have the occasional PHP error, it will be logged over and over and
over and over until someone sees it in the log. Usually the next day.
We are talking notice/warning level stuff here of course. If we could
have all the errors in file foo.php on line 999 in one interface, it
would be nice. We have started on apps several times to aggregate the
error logs into a database.
- Collecting more info related to an "event" (content of variables
$GLOBALS, $_GET, $_POST,...)
GET, POST and COOKIE would be useful to allow for a recreation of the
environment. Not sure about globals.
- alert systems (SNMP, Mailing, ...)
SNMP would be most flexible. I guess some small shops would want direct
alerting. We use Nagios and Cacti to montior our servers. So, SNMP
would let us see trends using the tools we already use. Also, using
something like the spread protocol could be useful to allow custom
listeners for events.
One question is what type of performance impact are we looking at here?
Brian Moon
http://brian.moonspot.net/
Hi,
why not use reporting thought syslog ? It's standard and "central
aggregation" is already available (thought TCP or databases).
Olivier
Patrick ALLAERT a écrit :
Hi list,
First, I'd like to apologize if the subject of this mail is somewhat off-topic.
Davide Mendolia and me are currently working on: "Alternative PHP
Monitor" (APM - http://code.google.com/p/peclapm/) which consist of
three parts:
- a PHP extension which has as a goal of capturing "events" (warning,
error, notices,... and slow requests) storing them centrally in an
SQLite DB.- a webfrontend to display captured events (for now, it's basically a
table without any filtering or querying).- a "central aggregator" which collects events from the different
"nodes" (still not developped).I think it is important to mention that we are talking about 100% Free
Software here :-)An event is currently characterized with the following properties:
- a unique ID
- a timestamp
- a script filename/line number
- an event level corresponding to error levels
- a message
A "slow request" is characterized with the following properties:
- a unique ID
- a timestamp
- a script filename
- a duration
We'd like to have your opinion on our "next steps", what is the most
important feature according to you:
- The development of the central aggregator
- Collecting more info related to an "event" (content of variables
$GLOBALS, $_GET, $_POST,...)- alert systems (SNMP, Mailing, ...)
- Web services
- extending the webfrontend
Any similarity with existing Israeli products is purely coincidental. :-)
Thanks for your help,
Patrick
Wheels were made to be reinvented!
Hi,
why not use reporting thought syslog ? It's standard and "central
aggregation" is already available (thought TCP or databases).Olivier
Patrick ALLAERT a écrit :
Hi list,
First, I'd like to apologize if the subject of this mail is somewhat
off-topic.Davide Mendolia and me are currently working on: "Alternative PHP
Monitor" (APM - http://code.google.com/p/peclapm/) which consist of
three parts:
- a PHP extension which has as a goal of capturing "events" (warning,
error, notices,... and slow requests) storing them centrally in an
SQLite DB.- a webfrontend to display captured events (for now, it's basically a
table without any filtering or querying).- a "central aggregator" which collects events from the different
"nodes" (still not developped).I think it is important to mention that we are talking about 100% Free
Software here :-)An event is currently characterized with the following properties:
- a unique ID
- a timestamp
- a script filename/line number
- an event level corresponding to error levels
- a message
A "slow request" is characterized with the following properties:
- a unique ID
- a timestamp
- a script filename
- a duration
We'd like to have your opinion on our "next steps", what is the most
important feature according to you:
- The development of the central aggregator
- Collecting more info related to an "event" (content of variables
$GLOBALS, $_GET, $_POST,...)- alert systems (SNMP, Mailing, ...)
- Web services
- extending the webfrontend
Any similarity with existing Israeli products is purely coincidental. :-)
Thanks for your help,
Patrick
Wheels were made to be reinvented!
Or else we'd all be using stone wheels.
2009/5/26 Eddie Drapkin oorza2k5@gmail.com:
Wheels were made to be reinvented!
I already have wheels but I'd like to have tires, it is much more
comfortable while driving fast :)
Hi,
why not use reporting thought syslog ? It's standard and "central
aggregation" is already available (thought TCP or databases).
Syslog is really neat, but it doesn't fit our needs. We'd like to have
functionalities mainly focused on advanced error handling and
providing in the future information like: which was the content of
$_POST and what was the PHP stack trace when request at URL u at time
t generated an E_ERROR in script s on line l in a corporate
environment or hosting company hosting hundreds or thousands of PHP
apps with a mix of custom made application and open source ones.
Replacing the callback function at application level isn't manageable
when you don't have the control of the applications, this is why we
started as an extension that could be plugged, transparently, to PHP.
Triggered error could then be forwarded using SNMP, mailing, syslog,
etc. with additional information.
--
Patrick Allaert
http://code.google.com/p/peclapm/ - Alternative PHP Monitor