- title
Proxy Logger Component
- data-transition-duration
2000
Under licence of LGPL-3. You can get the source from: https://github.com/stevleibelt/slides/tree/master/2013/131203_symfinyug_proxy_logger Based on the example: https://hovercraft.readthedocs.org/en/1.0/_sources/examples/hovercraft.txt - http://regebro.github.io/hovercraft Based on the docs: https://hovercraft.readthedocs.org/en/1.0/ http://docutils.sourceforge.net/docs/user/rst/cheatsheet.txt http://docutils.sourceforge.net/docs/user/rst/quickref.html http://en.wikipedia.org/wiki/ReStructuredText https://raw.github.com/regebro/hovercraft/master/docs/examples/positions.rst
- distinction between logging, metrics and writing of history
- present a concept of logging
- present a logging component
"symfony/event-dispatcher": "v2.3.5" //since version 1.2.0 :-)
- data-y
r1000
We are web developers and web analytics is a mixture of all.
- analyse internal data
- archive internal data
- collect internal data
- meter internal data
- record internal data
The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance testing, software debugging, software performance optimization, and optimal personnel task assignments. ([1])
- recoding of events like:
- user (id 3) had registerd with link "http://www.foo.bar/my-add-uuid-123"
- user (id 3) purchased contract (id 9)
- archive user interactions for the reason of law
- preserve state of a bunch of data
- create graph of data transformation
- record when happen what on which set of data
Graylog2 is for data analysis ([2])
So graylog is pure web analytics (doing all at once if you ask me).
- don't do web analytics
- do logging
- do metrics
- do writing of history
- figure out what your customer want
- your customer should know what to measure
- avoid measure everything
- do not interpret data by adding wished cross connections
- try to define common terms for your team and your customer
- separate you data (by metric, logging and history)
- create logger, history and metric handler (even if they are all simple file writer)
- data-x
r1500
- not webserver logs but web application logs
- record of workflow / processed data
- dump of processed data if something went wrong
- logging per instance (webserver)
- deletion of log files or entries should be fearless
- changing of log behaviour without fear
- split logs into logical units (import/export/registration)
- never found the right balance between logging enough to debug and do not glut the logfiles
- set loglevel to warning and you are loosing notice, info or debug
- set loglevel to info and your log file will be flooded with messages
- if something goes wrong, "i want it all" ([3])
Log all process data but only when something goes wrong.
- buffer log entries
- clean or flush the buffer under well defined circumstances
- deal with (a collection of) psr3 loggers
- one log target (file/database column/whatever) per logical log unit (like import/purchase/migration)
- data-y
r1000
- so i searched and found nothing good for php
- started developing and released version 0.9.0 with FlushBufferTrigger
- it was working but, it looks like a first draft ;-)
- version 1.0.0 adds a lot of examples and the BypassBuffer
- big refactoring leads to version 1.1.0
- implementation of event driven design leads to version 1.2.0
- story continues :-)
- later on i stumbled over monolog and its FingersCrossedHandler (so i'm not alone with that concept of logging :-))
- monolog looks like big logging component with a log of features
- it simple deals with log entries
- defines a log request as a php object
- wraps your existing logger or loggers
- handles a logger collection with the proxy logger
- buffer a bunch of log entries with the buffer logger
- controls the buffer behaviour with the buffer manipulators
- influences the process flow by the event driven design
- supports laziness with the factories
- validates the given log levels IsValidLogLevel
- follows unix philosophy (do one thing and do it well)
- enriches you existing logger component
- it does not care how to store
- it does not care where to store
- is not the logger component, just a part of it
- RealLogger represents a psr-3 logger
- LogRequest represents a log request (log level, message and context)
- LogRequestBuffer represents a collection of log requests that are not pushed to the real loggers
- ProxyLogger represents a collection of real loggers
- BufferLogger represents as a log request keeper that pass each log request to a buffer
- BypassBufferInterface represents a buffer manipulation to bypass a certain log level to all added real loggers
- FlushBufferTriggerInterface represents a buffer manipulation to trigger a buffer flush based on a log level
Time for some example implementation!
require: "net_bazzline/component_proxy_logger": "dev-master"
class MyLoggerFactory
{
public function createMyProcessLogger()
{
return new Logger();
}
}
class MyLoggerFactory
{
public function createMyProcessLogger()
{
$realLogger = new Logger();
//of course this should not be done on each create call
$proxyLoggerFactory = new ProxyLoggerFactory();
$proxyLogger = $proxyLoggerFactory->create($realLogger);
return $proxyLogger;
}
}
If you have to deal with log4php loggers, use an adapter.
And the adapter works vica versa (super cool, use a psr3 logger in a log4php environment).
- data-x
r0
- data-y
r500
- data-scale
0.1
- do not log all
- structure your log
- explain your customer that they want metric or history
- add bugs or remarks to the component
- joind the development team
- who is using monolog?
- what are your experience?
- positives
- negatives?
- what loggers are you using?
- do you use your log files to create metrics?
- how do you like the main idea of the component?