[RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch

Hartmaier Alexander alexander.hartmaier at t-systems.at
Mon Apr 7 09:29:59 CDT 2014


Hi Heikki,
attached is what I just wrote, feedback welcome!

Feel free to include it in the Radiator dist with an extended copyright,
different name, ...

Best regards, Alex

On 2014-04-04 14:42, Heikki Vatiainen wrote:
> On 04/03/2014 12:28 PM, Hartmaier Alexander wrote:
>
>> I just checked, LogFormat is indeed defined in LogFILE.pm, I thought it
>> is shared by different logging classes and defined in a base class.
> You are correct, there's no common class for LogFILE but the common
> class is LogGeneric instead. And since logs can be pushed to for
> example, SQL, LogFormat is only defined in LogFILE.
>
>> I don't care so much where it is defined but how.
>> Do you think configuring a Perl sub that returns a serialized string is
>> the way to go for structured logging?
> I guess that would be like a in-line Hook? Maybe it could be configured
> as a hook type of parameter with a default value. See for example,
> SqlDb.pm and how ConnectionAttemptFailedHook is initialised with a
> default hook code.
>
>> I was thinking about writing a Log module that uses Log::Any, Log4perl
>> or Log::Dispatch so that you can do everything these modules support.
>> My only concern is that the logging module affects Radiator and if e.g.
>> RabbitMQ is down and logs can't be stored Radiator stops working.
>> This might be intended if logging is an absolute requirement, but others
>> might prefer availability over logging. Ideally this should be configurable.
> Indeed. As noted below, LogSQL can be configured with so that it won't
> make everything stop unless required so.
>
>> What happens for the LogSQL class if the database goes down?
> It uses the functions defined in SqlDb.pm which for example, AuthBy SQL
> uses. Because of this, LogSQL respects FailureBackoffTime, Timeout and
> other common parameters AuthBy SQL uses.
>
>> Is there some documentation how to write a Log class? I looks like It
>> only has to have the ConfigKeywords hash, subclass from
>> Radius::LogGeneric and an initialize and log sub.
> I'd say the existing Log* files are the best example.
>
>> Is there anything special I need to do to allow a ConfigKeyword to hold
>> a Perl sub?
> Maybe create it as a Hook? That should help not duplicating existing
> functionality.
>
> Thanks,
> Heikki
>
>
>> BR Alex
>>
>>>
>>> Thanks,
>>> Heikki
>>>
>>
>>
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>> T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
>> Handelsgericht Wien, FN 79340b
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>> Notice: This e-mail contains information that is confidential and may be privileged.
>> If you are not the intended recipient, please notify the sender and then
>> delete this e-mail immediately.
>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: LogStructured.pm
Type: application/x-perl
Size: 2310 bytes
Desc: not available
Url : http://www.open.com.au/pipermail/radiator/attachments/20140407/a8bbd298/attachment.bin 


More information about the radiator mailing list