github.com/tickoalcantara12/micro/v3@v3.0.0-20221007104245-9d75b9bcbab9/docs/v2/design/server/debug.md (about) 1 # Debugging 2 3 Debugging is one of the core requirements for any programming tools and absolutely critical for microservices. 4 5 ## Overview 6 7 Micro provides a built in debugging experience through stats, logs and tracing. Debugging is a separate concern 8 from monitoring. Debugging is a form of observability that's deeply integrated into the go-micro framework. 9 The idea here is to mimic Go's runtime tooling or thereabouts e.g runtime stats, stdout and stderr logs, debug 10 stack traces. Monitoring is built ON debugging. 11 12 Core concerns: 13 14 - Stats - runtime stats including cpu, mem, go routines, request rate, error rate 15 - Logs - the output of stdout and stderr 16 - Trace - The instrumented stack for request, response and messages 17 18 ## Architecture 19 20 We include a go-micro/debug package which adds the above concerns as a core tenant of the framework and platform. 21 Debug is then embedded as a handler into every service with endpoints `Debug.{Log, Stats, Trace}` and may even 22 be extended to Status, Info, etc. Our goal will be to mimic programming tools when it comes to Debug and not 23 overly extend of complicate. Simplicity is key. 24 25 Every service maintains an memory buffers for stats, logs and tracing. This is so any service can be directly 26 queried to retrieve that information. This is a zero dep experience which works locally and in production. 27 28 This data is then scraped by the go.micro.debug service which is part of our micro runtime. This provides an 29 aggregated view of all services. 30 31 ## Centralisation 32 33 Because debug concerns are interfaces like any other, they will be implemented and backed by centralised systems 34 such as netdata for stats, kubernetes for logs and jaeger for tracing. While we can write our own storage 35 and implementations for these, the ability to offload to systems in the platform is useful.