Re: End of hypocrisy ?
On 8/8/2014 12:18 PM, Zenaan Harkness wrote:
> On 8/8/14, Jerry Stuckle <jstuckle@attglobal.net> wrote:
>> On 8/7/2014 8:28 PM, AW wrote:
>>> On Fri, 8 Aug 2014 09:03:56 +0900
>>> Joel Rees <joel.rees@gmail.com> wrote:
>>>
>>> > You do understand the chicken-and-egg nature of what you're asking
>>> for?
>>> >
>>> > You're needing to output logs to but up servers, but you have to boot
>>> > a server as complex as anySQL server to get there.
>>>
>>> I wasn't going to continue on this thread -- and after playing with
>>> the journalctl cli for much of the day -- I repent of my complaints
>>> [mostly]
>>> -- any remaining complaints are extremely minor. But I guess I should
>>> answer a
>>> direct question... perhaps a new thread should be started, this one is
>>> getting
>>> long in the tooth.
>>>
>>> Of course I understand the chicken-egg problem. However, once the system
>>> is
>>> running, there's no reason why the log data collected during the boot
>>> process couldn't then parsed into a standardized db --- resulting in
>>> standardized sql query capabilities. The boot log data should be
>>> entirely
>>> ASCII until a login prompt. This greatly assists troubleshooting of
>>> failed
>>> boots - undeniably. However, after booting, remove the ASCII boot log
>>> data
>>> from RAM via secure deletion process to increase security of the system as
>>> a
>>> whole...
>>>
>>> --Andrew
>>>
>>>
>>
>> I just wonder - why should I have to look in multiple paces for
>> (possibly related) messages?
>
> Seriously Jerry, your mind needs expanding!
>
You didn't answer the question.
>
>> That is, some to a text file, some to a SQL file.
>
> Of course! You just don't get it.
>
Exactly - why should I have to look multiple places for related messages?
> Whoever does the patch to systemd will I'm sure put some
> options in to send just say every second log message to the
> db, and the others to the journal - for load balancing or
> whatever its needed for.
>
What a mess!
>
>> I have nothing against SQL (I've been using it for over 25 years). But
>
> Awesome! That means you can help out with the --output=sql
> patch yes?
>
Sure I could. But I won't.
>
>> I don't think it's a good solution to everything. Not everything is
>
> Your thinking is questionable at best.
>
>> relational (which is what SQL excels at). And not everything needs a
>
> Except for the journal's binary blob support, it is relational,
> and Postgres has support for all sorts of wierd types, I'm sure
> it can handle binary blobs just fine!
>
>> SQL engine when text files work just as well.
>
> Definitely wrong about that.
>
> Cheers
> Zenaan
>
>
Nope. First of all, messages are NOT relational, unless you are calling
the source of the message and the text of the message relational.
Second, there is significant additional overhead when inserting into a
SQL database vs. adding to the end of a text file.
Third, to insert or retrieve data from the SQL database, you need the
SQL engine running. What if there is a problem with the engine? With a
text file, all you need is the file system up to add to the file, and a
command line prompt plus grep, head, tail, etc. to search the file (vim
is also a possibility but not necessary). It is also faster to grep a
text file than a SQL database unless the log file is huge.
Fourth, the same data in a SQL file takes up more space than in a text file.
Fifth, log files can easily be rotated in a text file; it is much harder
with a SQL database.
I just can't see any advantages to using a SQL database over text files
Jerry
Reply to: