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