Skip to main content
Fixing some typos
Source Link
manlio
  • 4.3k
  • 3
  • 28
  • 38

Making logging more efficient and useful by categorizing data (and virtually not wrtiningwritining messages anymore)

They are unsearchable and unparsable and writing messsgesmessages and adding some data to them is not actually helping. Consequently when something goes wrong I'm not able to easily find the answer by just looking at the logs and need to debug my application.

The questions that need to be asnweredanswered are not only about why the application crashed or didn't do something correctltlycorrectly but also about business rules like: why did I get a bonus when ordering ABC?

They both usualyusually contain small object dumps in json format.

  • Undefined - when not run like invalid parameters; log-level: Warning

  • Success - everything went well; log-level: Information

  • Completed - conditions not met, no errors; log-level: Information

  • Failure - an error occured;occurred; log-level: Error

  • Message - finally there is the old good message which I usually use to give some hints how to fix what might went wrong but I now write it very rarely.

  • Exception - here I put the stack-trace of execptionsexceptions.

Making logging more efficient and useful by categorizing data (and virtually not wrtining messages anymore)

They are unsearchable and unparsable and writing messsges and adding some data to them is not actually helping. Consequently when something goes wrong I'm not able to easily find the answer by just looking at the logs and need to debug my application.

The questions that need to be asnwered are not only about why the application crashed or didn't do something correctltly but also about business rules like: why did I get a bonus when ordering ABC?

They both usualy contain small object dumps in json format.

  • Undefined - when not run like invalid parameters; log-level: Warning

  • Success - everything went well; log-level: Information

  • Completed - conditions not met, no errors; log-level: Information

  • Failure - an error occured; log-level: Error

  • Message - finally there is the old good message which I usually use to give some hints how to fix what might went wrong but I now write it very rarely.

  • Exception - here I put the stack-trace of execptions.

Making logging more efficient and useful by categorizing data (and virtually not writining messages anymore)

They are unsearchable and unparsable and writing messages and adding some data to them is not actually helping. Consequently when something goes wrong I'm not able to easily find the answer by just looking at the logs and need to debug my application.

The questions that need to be answered are not only about why the application crashed or didn't do something correctly but also about business rules like: why did I get a bonus when ordering ABC?

They both usually contain small object dumps in json format.

  • Undefined - when not run like invalid parameters; log-level: Warning

  • Success - everything went well; log-level: Information

  • Completed - conditions not met, no errors; log-level: Information

  • Failure - an error occurred; log-level: Error

  • Message - finally there is the old good message which I usually use to give some hints how to fix what might went wrong but I now write it very rarely.

  • Exception - here I put the stack-trace of exceptions.

added 137 characters in body
Source Link
t3chb0t
  • 2.6k
  • 3
  • 23
  • 35

As a state I can log twothree types of information:

  • State(Name) - this is the name of the state that I can search for (could be a CustomerInfo, an array of active downloaders, etc.)
  • Actual(State) - this is current state; log-level: Trace
  • Excpected(State) - this is what I expected; log-level: Trace
Log-Table
--------------
Id
Timestamp
---
Environment | development, production
Product | Product-v0
Logger | RepositoryXLogger
TransactionId | 123
Layer | Application, Business
Level | Debug, Information
State | like a variable name for the state
Expected | small object dumps (json)
Actual | small object dumps (json)
Event | LoadConfiguration, GetDataX
Elapsed | milliseconds
Result | Undefined, Success, Completed, Failure
Message
Exception

As a state I can log two types of information:

  • Actual(State) - this is current state; log-level: Trace
  • Excpected(State) - this is what I expected; log-level: Trace
Log-Table
--------------
Id
Timestamp
---
Environment | development, production
Product | Product-v0
Logger | RepositoryXLogger
TransactionId | 123
Layer | Application, Business
Level | Debug, Information
Expected | small object dumps (json)
Actual | small object dumps (json)
Event | LoadConfiguration, GetDataX
Elapsed | milliseconds
Result | Undefined, Success, Completed, Failure
Message
Exception

As a state I can log three types of information:

  • State(Name) - this is the name of the state that I can search for (could be a CustomerInfo, an array of active downloaders, etc.)
  • Actual(State) - this is current state; log-level: Trace
  • Excpected(State) - this is what I expected; log-level: Trace
Log-Table
--------------
Id
Timestamp
---
Environment | development, production
Product | Product-v0
Logger | RepositoryXLogger
TransactionId | 123
Layer | Application, Business
Level | Debug, Information
State | like a variable name for the state
Expected | small object dumps (json)
Actual | small object dumps (json)
Event | LoadConfiguration, GetDataX
Elapsed | milliseconds
Result | Undefined, Success, Completed, Failure
Message
Exception
added 3 characters in body; edited title
Source Link
t3chb0t
  • 2.6k
  • 3
  • 23
  • 35

Making logging more efficient and useful by categorizing data (and virtually not wrtining messages anymore)

Disclaimer I'd like to kindly ask you not to comment about how to write a better message. There are already more then enough such questions on SE and I've tried them all and it does not work. My question is about how not to write a message at all. I find it is not necessary if the data we log is properly segmented/categorized. This question is about breaking the so called universally valid rules about logging. If you are not open to new ideas then please just ignore this question.

Making logging more efficient and useful by categorizing data

Disclaimer I'd like to kindly ask you not to comment about how to write a better message. There are already more then enough such questions on SE and I've tried them all and it does not work. My question is about how not to write a message at all. I find is not necessary if the data we log is properly segmented/categorized. This question is about breaking the so called universally valid rules about logging. If you are not open to new ideas then please just ignore this question.

Making logging more efficient and useful by categorizing data (and virtually not wrtining messages anymore)

Disclaimer I'd like to kindly ask you not to comment about how to write a better message. There are already more then enough such questions on SE and I've tried them all and it does not work. My question is about how not to write a message at all. I find it is not necessary if the data we log is properly segmented/categorized. This question is about breaking the so called universally valid rules about logging. If you are not open to new ideas then please just ignore this question.

added 499 characters in body
Source Link
t3chb0t
  • 2.6k
  • 3
  • 23
  • 35
Loading
edited title
Link
t3chb0t
  • 2.6k
  • 3
  • 23
  • 35
Loading
Source Link
t3chb0t
  • 2.6k
  • 3
  • 23
  • 35
Loading