represent the object in the logs

[Rene Moser <ma...@renemoser.net>]

Hi

In logs we see all kind variations how an object is printed to the
users. E.g. for VMs we have seen, the DB ID, UUID, internal name, name
etc. in different debug log messages. And this makes debugging harder
than it should.

I wondered, why don't we just use the "toString()" in VO classes.

E.g in this PR
https://github.com/apache/cloudstack/pull/1252/files#diff-ab243638abf88707693d464b3b1836feR1503


We see a:

s_logger.debug("Host is in PrepareForMaintenance state - Stop VM
operation on the VM id: " + vm.getId() + " is not allowed");


With a toString in the VO class of the VM this would turn into

s_logger.debug("Host is in PrepareForMaintenance state - Stop VM
operation on the VM: " + vm + " is not allowed");

Did I miss anything?

Ren�

Re: represent the object in the logs

[Rafael Weingärtner <ra...@gmail.com>]

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 <ma...@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

Re: represent the object in the logs

[Rene Moser <ma...@renemoser.net>]

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\u2019s 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 \u201ctoString\u201d of an
> object to append its information in a log entry might be interesting.
> However, objects like the \u201cVmInstance\u201d 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�

Re: represent the object in the logs

[Rafael Weingärtner <ra...@gmail.com>]

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.


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.

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.
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.

On Wed, Apr 12, 2017 at 11:49 AM, Rene Moser <ma...@renemoser.net> wrote:

> Hi
>
> In logs we see all kind variations how an object is printed to the
> users. E.g. for VMs we have seen, the DB ID, UUID, internal name, name
> etc. in different debug log messages. And this makes debugging harder
> than it should.
>
> I wondered, why don't we just use the "toString()" in VO classes.
>
> E.g in this PR
> https://github.com/apache/cloudstack/pull/1252/files#diff-
> ab243638abf88707693d464b3b1836feR1503
>
>
> We see a:
>
> s_logger.debug("Host is in PrepareForMaintenance state - Stop VM
> operation on the VM id: " + vm.getId() + " is not allowed");
>
>
> With a toString in the VO class of the VM this would turn into
>
> s_logger.debug("Host is in PrepareForMaintenance state - Stop VM
> operation on the VM: " + vm + " is not allowed");
>
> Did I miss anything?
>
> René
>



-- 
Rafael Weingärtner