cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Weingärtner <rafaelweingart...@gmail.com>
Subject Re: represent the object in the logs
Date Thu, 13 Apr 2017 03:20:56 GMT
I disagree with the idea of logging anything (increasing logging just by
quantity), like that fallacy of big data era of more and more. If you want
to find a needle in a haystack, you do not add more hay, you remove them.
However, increasing the quality of data being logged, I am totally in
favor! We could try to discuss and formalize a standard to always add in
log entries at least the UUID of the element(s) involved in the event.

When I said ID back there, I meant UUID, because this is the "ID" known by
the users.

On Wed, Apr 12, 2017 at 5:52 PM, Rene Moser <mail@renemoser.net> wrote:

> Hi Rafael
>
> On 04/12/2017 08:27 PM, Rafael Weingärtner wrote:
> > Well, I think the missing point to understand why we have these different
> > situations is the understanding of the developer’s mind. It is so diverse
> > and unique from people to people, and because we do not have a policy on
> > that, each developer is doing the best they know and think.
>
> I should not have asked "why". I know why, nobody is perfect :) That is
> fine.
>
> I just wondered if there is something I've been missing (I am also not
> perfect and I know :P).
>
> > For instance, at first sight, the idea of calling the “toString” of an
> > object to append its information in a log entry might be interesting.
> > However, objects like the “VmInstance” are quite big and would probably
> > clutter the log entry.
>
> So, logs are getting big, we must handle logs anyway. I have no problem
> with big logs. I like big logs, big logs are detailed, bigger logs are
> more detailed.
>
> > In my opinion, for most log entries at the DEBUG/INFO/WARN levels the ID
> of
> > the logged element should be more than enough to the
> > operators/administrators to track down events or problems in the cloud.
>
> I kind of disagree here for 2 technical reasons:
>
> The ID of the record (ID NOT UUID) is not unique, (think about
> upgrade/rollback scenarios, the id will probably be identical but the
> resource would not be the same).
>
> The ID is only used "internally" for relation mapping, there is not
> reason to show this ID to a user/admin as a user will not be able to
> query a VM by its ID, but UUID.
>
> I would like to see at least (only?) the UUID for an resource being
> logged, as it is the external, unique identifier for an resource.
>
> > Others probably think the opposite, meaning that, only the ID is not
> enough
> > and more details about the object in an event are required. In the
> absence
> > of a policy to regulate this, both are valid arguments under different
> > perspectives.
>
> Other thoughts anyone?
>
> Kind Regards
> René
>



-- 
Rafael Weingärtner

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message