"If a Go microservice falls down in the middle of a server farm, does my pager make a sound?"
If your service is automatically monitored, then the answer is "yes!". But what if your service *isn't* monitored yet? Or what if your monitors alert you when the server is offline, but not on subtler problems like latency spikes or CPU load?
Fortunately, there's a quick and easy way to get high-resolution metrics for monitoring your services. The Go standard library now contains the basic building blocks for application tracing. When you combine these tools with Veneur, a pure Go distributed metrics aggregator, you can easily answer the questions you care about, like "Which servers are currently running near maximum capacity?", or "Can our infrastructure handle tomorrow's product launch?".
Observing Your Go Services
Observability Engineer at Stripe
Observability measures how well internal states of a system
can be inferred from knowledge of its external outputs
Go is used to build….
1. What should I observe or monitor?
2. How do I measure and monitor those things in Go?
3. What does the future of Go observability look like?
Let’s Create an API
•Return a list of all Twitter followers
•Record a copy to the database
Service-Level Agreement: What we promise our clients
Service-Level Indicators: Data used to evaluate the SLA
•Rate: Number of requests received
•Errors: Number of responses written, broken down by HTTP status
•Duration: Distribution of response latency
Every monitor involves a service-level indicator*
*for sufficiently broad definitions of “service”
Metrics, logs, and request traces are used to provide greater
visibility beyond our service indicators
Define and measure your service indicator metrics
#veneur on Freenode