Chore: RabbitMQ logging #414
Conversation
…voice-response feat: add created_at to create invoice response
Codecov Report
@@ Coverage Diff @@
## main #414 +/- ##
==========================================
- Coverage 59.12% 58.77% -0.35%
==========================================
Files 51 51
Lines 3481 3556 +75
==========================================
+ Hits 2058 2090 +32
- Misses 1202 1245 +43
Partials 221 221
|
| func captureErr(logger *lecho.Logger, err error) { | ||
| logger.Error(err) | ||
| func captureErr(logger *lecho.Logger, err error, j log.JSON) { | ||
| j["error"] = err |
There was a problem hiding this comment.
what is this adding to the logging? the error message?
| logger.Error(err) | ||
| func captureErr(logger *lecho.Logger, err error, j log.JSON) { | ||
| j["error"] = err | ||
| logger.Errorj(j) | ||
| sentry.CaptureException(err) |
There was a problem hiding this comment.
when I currently look at the sentry stack traces it does not give much information and it does not contain the original stack trace but links to this CaptureException error
I read here something about a different erros package and wrapping an error to keep the stack trace?
https://incident.io/blog/golang-errors
does that make sense?
There was a problem hiding this comment.
Go stacktraces inherently require more work, yes. So that would be something to add later.
| "subroutine": "invoice publisher", | ||
| "message": "succesfully published invoice", | ||
| "payment_hash": invoice.RHash, | ||
| }) |
There was a problem hiding this comment.
is some more metadata helpful like the key (and exchange?)
the key is computed it might be interesting to add.
There was a problem hiding this comment.
exchange is always the same here but key can be added.
Fixes #411
This PR adds metadata fields to the logs from the processes that use Rabbitmq: payment consumer, invoice consumer and publisher routines. This will help us identify issues and also allow us to trace payments/invoices across services.
I also propose a standardized way of naming metadata fields (I would propose snake case), so we can search for them in datadag across different service logs:
payment_hash(only one used in this PR)lndhub_user_id,getalbycom_user_idinvoice_idmessageerrorWe would need some follow up PR's in order to implement this kind of structured logging across LNDhub & other services.