Service Map
O Service Map é uma visualização gráfica das dependências entre seus monitores. Ele mostra como os seus serviços se conectam e como uma falha em um componente pode afetar outros — essencial para entender falhas em cascata.
O Service Map requer o plano PRO ou superior.
O que é o Service Map
Imagine que sua API de Pagamentos depende do Banco de Dados PostgreSQL. Se o banco cair, a API vai falhar como consequência — mas sem o Service Map, você vê dois monitores DOWN e pode não saber imediatamente qual é a causa raiz.
Com o Service Map:
[PostgreSQL DB] ──dependência→ [API de Pagamentos] ──dependência→ [Checkout Web]
DOWN AFETADO AFETADOFica imediatamente claro que a causa raiz é o banco de dados, não a API ou o checkout.
Acessando o Service Map
No menu lateral: "Service Map"
O mapa exibe todos os seus monitores como nós (nodes) em um gráfico interativo. Você pode:
- Arrastar e reorganizar os nós
- Clicar em um nó para ver detalhes do monitor
- Adicionar e remover dependências
- Filtrar por status
Criando dependências
Para criar uma dependência entre dois monitores:
- Acesse Service Map
- Clique no monitor que depende de outro (ex: API de Pagamentos)
- Clique em "+ Adicionar Dependência"
- Selecione o monitor do qual ele depende (ex: PostgreSQL DB)
- Salve
A dependência aparece como uma seta no mapa:
[PostgreSQL DB] ──→ [API de Pagamentos]Leia como: "API de Pagamentos depende de PostgreSQL DB".
Interpretando o mapa durante incidentes
Quando um monitor vai DOWN, o Service Map atualiza automaticamente com indicadores visuais:
| Cor | Estado |
|---|---|
| Verde | UP — operando normalmente |
| Amarelo | DEGRADED — operando com problemas |
| Vermelho | DOWN — fora do ar |
| Cinza | Dependência em DOWN — potencialmente afetado |
Causa raiz vs. afetado: monitores cujas dependências estão DOWN aparecem em cinza com indicador "Afetado por dependência", ajudando a distinguir a causa raiz dos sintomas.
Casos de uso
Diagnóstico de causa raiz
Quando vários monitores vão DOWN simultaneamente, o Service Map mostra imediatamente qual é o nó raiz da falha (o componente sem dependências afetadas).
Comunicação com stakeholders não técnicos
O mapa visual é mais fácil de entender do que uma lista de monitores. Em uma call de incidente, compartilhe a tela do Service Map para mostrar exatamente onde está o problema e o que está sendo afetado.
Planejamento de capacidade e arquitetura
Use o Service Map como documentação viva da sua arquitetura de serviços. Visualize pontos únicos de falha (single points of failure) — monitores dos quais muitos outros dependem.
Priorização de manutenção
Monitores com muitas dependências são mais críticos. O Service Map ajuda a priorizar qual infra merece mais atenção e redundância.
Exemplo de mapa completo
[CDN Cloudflare]──────────────────────────────┐
↓
[DNS Registro.br] [Frontend Web]
↓
[PostgreSQL DB]──→ [Redis Cache]──→ [API Principal]──→ [App Mobile]
↑ ↓
[Backup DB] [API de Pagamentos]──→ [Checkout]
↓
[Gateway Stripe (External)]Boas práticas
Comece simples Mapeie apenas as dependências mais críticas primeiro. Um mapa com 50 dependências pode ficar confuso. Adicione progressivamente.
Documente dependências externas Inclua no mapa dependências de terceiros (gateways de pagamento, APIs de parceiros, CDN). Eles também podem causar falhas em cascata.
Mantenha o mapa atualizado À medida que sua arquitetura evolui, atualize o Service Map. Um mapa desatualizado é pior do que nenhum mapa.
Use em post-mortems Após um incidente, revise o Service Map para identificar se dependências não mapeadas contribuíram para a falha. Adicione ao mapa o que você aprendeu.