Como é uma boa observabilidade para um serviço que você é dono?

Você deveria conseguir responder perguntas que não antecipou. Isso significa logs estruturados com um trace id em cada linha, métricas cobrindo taxa, erros e duração mais saturação dos seus recursos principais, e traces distribuídos que seguem uma requisição entre serviços. Os alertas disparam em sintomas visíveis para o usuário, ligados aos seus objetivos de nível de serviço, os dashboards partem da experiência do cliente, e todo sinal compartilha labels consistentes para você conseguir pivotar entre eles.

O teste que eu uso é se eu consigo responder uma pergunta que ninguém pensou quando o serviço foi construído, por exemplo por que as requisições estão lentas só para um cliente em um endpoint. Para chegar lá os três sinais precisam estar conectados. Toda linha de log é estruturada e carrega o trace id, então de um trace lento eu pulo direto para os logs daquela requisição em vez de fazer grep por timestamp. As métricas cobrem taxa, erros e duração de cada endpoint como percentis e não como médias, mais a saturação das coisas que de fato acabam: pools de conexão, profundidade de fila, disco. Os traces têm amostragem, mas eu sempre guardo os erros e a cauda lenta, porque a requisição média não me ensina nada. Alertas são a parte que as pessoas erram: eu alerto em sintomas que os clientes sentem, ligados ao objetivo, e não em CPU a oitenta por cento. E eu fico de olho no custo, porque colocar um id de usuário em um label de métrica é como você transforma uma conta de duzentos dólares em seis mil da noite para o dia; detalhe no nível de usuário pertence a traces e logs.