a WoW player, a millenial that grew up playing pokemon on her nintendo and ragnarok during countless nights
that rock'n'roll teeenager that listens to everything especially pop & reggaeton nowadays but is never sick of pink floyd and led zeppelin
passionate about coffee & beer
all things dev ops: ci/cd, cloud infra, observability, etc
web & distributed systems & system architecture
- Choosing an APM/Logging tool and setting up your application
- A simple problem
- Good logging practices
- A slightly more complex performance issue
- Finding the root cause
- Elastic (Elastic Search, Elastic APM)
- New Relic
and you might want to consider...
personal, opinionated, but also very backed up with researches and open to discussion and changes as I see new things
write your logs for a computer to process, not a for a human to read, but make it so a human can read and understand
put as much info as you can - don't abuse in the sense of sending a huge payload, but those fields are hidden by default in the view and they are extremely useful
Request Identifiers should be present in all log messages in order to be able to trace what happened in a particular request
customer identifiers should exists in all requests in order to measure the experience of a particular customer
everytime you save an object and you write a log line about it, keep add the ID as an extra field - this allows easy inspection
you should know what kind of information you want to see while developing and what kind of information is only useful for production.
my rule of thumb is that ERROR is something to pay attention, INFO is extra info in production environment and DEBUG is made for my local dev.
follow me on twitter for random things in english, portuguese and sometimes spanish: https://twitter.com/__biancarosa
(i answer DMs slow, but I always try!)