Boas Práticas de Observabilidade

Q: Como as seções de observabilidade e performance diferem?

Performance define orçamentos e otimização - observabilidade mede e alerta contra esses orçamentos em produção.

Um resumo condensado das 25 melhores práticas mais importantes, extraídas de todas as páginas desta seção.

Conheça os quatro sinais: Falhas/fatais, erros tratados, transações de performance e análises de produto - um único fornecedor raramente substitui todos os quatro.
Marque cada relatório com a identidade da release: version+build nativo, otaUpdateId, runtimeVersion e channel - triagem sem reproduzir no dispositivo.
Gere sessionId no cold start: Rotacione no logout - a mesma disciplina de ciclo de vida dos tokens de Noções Básicas de Autenticação Mobile.
Anexe a rota a falhas e logs: O pathname do Expo Router supera os nomes de exibição dos componentes - refatorações renomeiam componentes, rotas permanecem estáveis.
Separe falhas nativas de erros JS: Pipelines de symbolication diferentes - mapas Hermes e dSYM do iOS / ProGuard do Android são todos necessários.
Encadeie manipuladores ErrorUtils: Nunca substitua o manipulador global anterior por completo - o redbox do desenvolvedor e as integrações do SDK dependem do encadeamento.
Inicialize o Sentry antes que as rotas sejam montadas: O efeito colateral mais cedo em _layout ou index.js - inicialização tardia perde falhas de inicialização.
Envie source maps em cada build de produção EAS: Pilhas sem symbolication são um bloqueador de release, não um "nice-to-have".
Defina o dist do Sentry para o ID da atualização OTA: Distinga regressões JS de regressões nativas na mesma versão da loja.
Ative a captura de falhas nativas: Módulos nativos do @sentry/react-native - wrappers apenas JS perdem SIGABRT e OOM kills.
Limite breadcrumbs e buffers de log: Anéis ilimitados causam OOM em telas "chatty" - descarte debug primeiro sob pressão.
Agrupe logs estruturados; envie em foreground: HTTPS por linha desperdiça bateria - descarregue em active e melhor esforço em background.
Nunca registre tokens, e-mails ou dados de cartão: Hash de IDs de usuário; remova PII em beforeSend e sanitize() de análises.
Controle análises por consentimento explícito: Alternâncias separadas para relatórios de falhas vs. análises de produto - o jurídico define a política, a engenharia implementa os controles.
Solicite ATT apenas quando necessário no iOS: Alinhe NSUserTrackingUsageDescription com rastreamento real entre aplicativos - cópia vaga falha na revisão.
Redefina a identidade de análises no logout: segment.reset() / Amplitude reset() junto com a limpeza do armazenamento seguro.
Use nomes de eventos de análise estáveis: checkout_completed não completeCheckout - renomeações quebram gráficos ano a ano.
Amostre traces de produção em 10–20%: Captura de 100% sobrecarrega o custo; 100% em rotas de checkout/pagamento é aceitável.
Instrumente a navegação na camada do roteador: Um span de navegação por pathname - não por useEffect folha.
Propague cabeçalhos de trace em chamadas de API: sentry-trace ou W3C traceparent - latência apenas mobile esconde a culpa do backend.
Defina SLO de sessões sem falhas com regras de sessão: Alinhe com o rastreamento de sessão do Sentry - exclua ambientes de desenvolvimento e pré-visualização dos numeradores de produção.
Rastreie explicitamente o sucesso da aplicação OTA: Falhas silenciosas em fetchUpdateAsync corroem a confiança - meça check → download → apply → next-launch updateId.
Emparelhe o SLO de cold start com um dispositivo de referência: p95 na classe Pixel 6a por Noções Básicas de Performance - iPhone Pro mente.
Use orçamentos de erro para controlar releases: Queimar > 50% em uma semana → congelamento de recursos; 0% → interromper a loja e OTA conforme Runbook de Rollback.
Execute a revisão de observabilidade antes de OTAs importantes: Rollout escalonado + Release Health + SLO de sucesso de OTA - canal de rollback antes da emergência da loja.

FAQs

Uma única ferramenta pode substituir Sentry, Segment e OpenTelemetry?

Plataformas unificadas existem, mas raramente se destacam em todos os quatro tipos de sinal desde o primeiro dia.
Comece com falhas + logs + análises controladas por consentimento; adicione OTel quando o tracing de backend amadurecer.

Qual é o mínimo viável de observabilidade para a v1?

Sentry com source maps, tags de release, breadcrumbs de rota e dashboard de sessões sem falhas.
O envio de buffer de log estruturado em foreground é um segundo próximo para aplicativos offline-first.

A observabilidade deve rodar no Expo Go?

Não - valide em builds de desenvolvimento e binários de pré-visualização EAS; o shell do Expo Go distorce falhas e performance.

Como as seções de observabilidade e performance diferem?

Performance define orçamentos e otimização - observabilidade mede e alerta contra esses orçamentos em produção.

Relacionados

Noções Básicas de Observabilidade - tour pela pilha de sinais
Sentry para React Native - configuração de falhas em produção
Logging Estruturado no Dispositivo - logs JSON agrupados
Análises e Privacidade - consentimento e ATT
Monitoramento de Performance - navegação e traces de API
SLOs para Aplicativos Mobile - orçamentos de erro
Boas Práticas de Performance - matriz de dispositivos e proprietários de TTI
Boas Práticas de Atualizações OTA - correlação de release
Ciclo de Vida da Sessão de Autenticação - limites entre telemetria e sessão de autenticação

Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Boas Práticas de Observabilidade

Um resumo condensado das 25 melhores práticas mais importantes, extraídas de todas as páginas desta seção.

Conheça os quatro sinais: Falhas/fatais, erros tratados, transações de performance e análises de produto - um único fornecedor raramente substitui todos os quatro.
Marque cada relatório com a identidade da release: version+build nativo, otaUpdateId, runtimeVersion e channel - triagem sem reproduzir no dispositivo.
Gere sessionId no cold start: Rotacione no logout - a mesma disciplina de ciclo de vida dos tokens de Noções Básicas de Autenticação Mobile.
Anexe a rota a falhas e logs: O pathname do Expo Router supera os nomes de exibição dos componentes - refatorações renomeiam componentes, rotas permanecem estáveis.
Separe falhas nativas de erros JS: Pipelines de symbolication diferentes - mapas Hermes e dSYM do iOS / ProGuard do Android são todos necessários.
Encadeie manipuladores ErrorUtils: Nunca substitua o manipulador global anterior por completo - o redbox do desenvolvedor e as integrações do SDK dependem do encadeamento.
Inicialize o Sentry antes que as rotas sejam montadas: O efeito colateral mais cedo em _layout ou index.js - inicialização tardia perde falhas de inicialização.
Envie source maps em cada build de produção EAS: Pilhas sem symbolication são um bloqueador de release, não um "nice-to-have".
Defina o dist do Sentry para o ID da atualização OTA: Distinga regressões JS de regressões nativas na mesma versão da loja.
Ative a captura de falhas nativas: Módulos nativos do @sentry/react-native - wrappers apenas JS perdem SIGABRT e OOM kills.
Limite breadcrumbs e buffers de log: Anéis ilimitados causam OOM em telas "chatty" - descarte debug primeiro sob pressão.
Agrupe logs estruturados; envie em foreground: HTTPS por linha desperdiça bateria - descarregue em active e melhor esforço em background.
Nunca registre tokens, e-mails ou dados de cartão: Hash de IDs de usuário; remova PII em beforeSend e sanitize() de análises.
Controle análises por consentimento explícito: Alternâncias separadas para relatórios de falhas vs. análises de produto - o jurídico define a política, a engenharia implementa os controles.
Solicite ATT apenas quando necessário no iOS: Alinhe NSUserTrackingUsageDescription com rastreamento real entre aplicativos - cópia vaga falha na revisão.
Redefina a identidade de análises no logout: segment.reset() / Amplitude reset() junto com a limpeza do armazenamento seguro.
Use nomes de eventos de análise estáveis: checkout_completed não completeCheckout - renomeações quebram gráficos ano a ano.
Amostre traces de produção em 10–20%: Captura de 100% sobrecarrega o custo; 100% em rotas de checkout/pagamento é aceitável.
Instrumente a navegação na camada do roteador: Um span de navegação por pathname - não por useEffect folha.
Propague cabeçalhos de trace em chamadas de API: sentry-trace ou W3C traceparent - latência apenas mobile esconde a culpa do backend.
Defina SLO de sessões sem falhas com regras de sessão: Alinhe com o rastreamento de sessão do Sentry - exclua ambientes de desenvolvimento e pré-visualização dos numeradores de produção.
Rastreie explicitamente o sucesso da aplicação OTA: Falhas silenciosas em fetchUpdateAsync corroem a confiança - meça check → download → apply → next-launch updateId.
Emparelhe o SLO de cold start com um dispositivo de referência: p95 na classe Pixel 6a por Noções Básicas de Performance - iPhone Pro mente.
Use orçamentos de erro para controlar releases: Queimar > 50% em uma semana → congelamento de recursos; 0% → interromper a loja e OTA conforme Runbook de Rollback.
Execute a revisão de observabilidade antes de OTAs importantes: Rollout escalonado + Release Health + SLO de sucesso de OTA - canal de rollback antes da emergência da loja.

FAQs

Uma única ferramenta pode substituir Sentry, Segment e OpenTelemetry?

Plataformas unificadas existem, mas raramente se destacam em todos os quatro tipos de sinal desde o primeiro dia.
Comece com falhas + logs + análises controladas por consentimento; adicione OTel quando o tracing de backend amadurecer.

Qual é o mínimo viável de observabilidade para a v1?

Sentry com source maps, tags de release, breadcrumbs de rota e dashboard de sessões sem falhas.
O envio de buffer de log estruturado em foreground é um segundo próximo para aplicativos offline-first.

A observabilidade deve rodar no Expo Go?

Não - valide em builds de desenvolvimento e binários de pré-visualização EAS; o shell do Expo Go distorce falhas e performance.

Como as seções de observabilidade e performance diferem?

Performance define orçamentos e otimização - observabilidade mede e alerta contra esses orçamentos em produção.

Relacionados

Noções Básicas de Observabilidade - tour pela pilha de sinais
Sentry para React Native - configuração de falhas em produção
Logging Estruturado no Dispositivo - logs JSON agrupados
Análises e Privacidade - consentimento e ATT
Monitoramento de Performance - navegação e traces de API
SLOs para Aplicativos Mobile - orçamentos de erro
Boas Práticas de Performance - matriz de dispositivos e proprietários de TTI
Boas Práticas de Atualizações OTA - correlação de release
Ciclo de Vida da Sessão de Autenticação - limites entre telemetria e sessão de autenticação

Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Boas Práticas de Observabilidade

FAQs

Relacionados

Buscar na documentação

Boas Práticas de Observabilidade

FAQs

Relacionados