As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Etapa 2: Implementar a observabilidade
Nesse estágio, você inicia o processo para que suas equipes trabalhem gradativamente até a Estrela Polar.
Escolha sua plataforma de observabilidade
A primeira etapa é identificar as ferramentas certas para ingerir, visualizar e analisar os sinais e enviar alertas. Ao selecionar uma ferramenta, considere seu conjunto de recursos, modelo de licenciamento, preço, requisitos de habilidades e manutenção.
Conjunto de recursos
Aqui estão algumas das questões a serem consideradas:
-
Configurabilidade e personalização. Quais recursos a ferramenta fornece para simplificar a experiência investigativa e ajudar a reduzir o MTTR? A ferramenta fornece correlação de alarmes, matemática métrica, flexibilidade para lidar com telemetria perdida ou detecção de anomalias?
-
Granularidade. Qual é a granularidade suportada da ingestão e visualização do sinal de telemetria?
-
Personas. A ferramenta oferece suporte às experiências que você deseja oferecer aos seus desenvolvedores, engenheiros de plataforma e outras pessoas? Funciona tanto para pessoas técnicas quanto comerciais?
-
Widgets. Quais tipos de widgets são compatíveis com os painéis? A ferramenta permite a criação de widgets personalizados?
-
Soluções pré-construídas. Que tipos de soluções de observabilidade pré-criadas a ferramenta oferece para reduzir o tempo de geração de valor?
-
Automação e IA generativa. Quais recursos a ferramenta fornece que podem ajudar a automatizar ou reduzir o trabalho para você e sua equipe? Por exemplo, a detecção automática de anomalias, a análise preditiva e outros recursos generativos de IA podem ajudar a reduzir o estresse de suposições e incógnitas (ou seja, coisas que você não conhece nem compreende totalmente). A ferramenta suporta o uso de AI/ML modelos generativos para aprimorar a análise dos dados em escala? Ele oferece a opção de automatizar e implementar AIOps?
-
Segurança.A ferramenta oferece suporte a quais tipos de integrações de autenticação e autorização? As experiências de usuário e login atendem às necessidades da sua organização?
-
OpenTelemetry apoio. A ferramenta e o agente oferecem suporte OpenTelemetry? A maioria das plataformas de observabilidade suporta a ingestão de sinais OpenTelemetry compatíveis, mas nem todos os agentes fornecem opções de configuração para encaminhar esses sinais para uma plataforma de observabilidade.
-
Integrações. Quais integrações a ferramenta oferece? Considere se você precisa enviar alertas para o Slack, para os membros da equipe da página ou automatizar a resolução.
-
Escalabilidade. Quão escalável e eficiente é a ferramenta? A solução de observabilidade precisa ser dimensionada à medida que suas demandas e uso aumentam, para que possa fornecer diagnósticos mesmo se seu aplicativo não estiver disponível.
-
Support. Qual modelo de suporte é oferecido? Sua ferramenta de observabilidade precisa estar disponível mesmo se seu aplicativo falhar para que você possa atingir suas metas de MTTR e disponibilidade de aplicativos ou contratos de nível de serviço (). SLAs As soluções de código aberto podem oferecer suporte formal limitado.
Modelo de licenciamento e implantação
Considere o modelo de licenciamento (de código aberto ou comercial) e o modelo de implantação (auto-hospedado ou baseado em nuvem) da solução. As opções de código aberto geralmente têm custos iniciais mais baixos, mas podem exigir mais tempo para implantação, instalação e configuração, manutenção e aprimoramento da equipe antes de fornecerem valor. Se você está considerando opções de código aberto, talvez precise de uma equipe dedicada de especialistas em observabilidade. O software comercial normalmente oferece um tempo de valorização mais rápido com um custo inicial mais alto, e a necessidade de uma equipe dedicada de observabilidade evolui com o tempo à medida que a adoção, a complexidade e a maturidade aumentam. As soluções auto-hospedadas exigem mais tempo para implantação, instalação e configuração, manutenção e sobrecarga operacional em comparação com as soluções baseadas em nuvem.
Dimensões de preço
Como o modelo de preços da ferramenta afetará seu custo total de propriedade (TCO) à medida que seu aplicativo ganha novos usuários, uma maior área de arquitetura ou novos recursos e aplicativos? Por exemplo, alguns modelos de licenciamento típicos são perpétuos ou baseados em assinaturas, no número de usuários nomeados, no consumo ou no volume. Considere como seu aplicativo e a ferramenta de observabilidade aumentarão o uso e como o modelo de licenciamento pode afetar o custo da ferramenta.
Habilidades de equipe
Dependendo do conjunto atual de habilidades e da maturidade de sua equipe, você precisará determinar quanto aprimoramento será necessário. Considere o tipo de suporte que o fornecedor oferece para treinar sua equipe. Considere também se sua estrutura organizacional suporta a configuração e o gerenciamento da ferramenta que você escolher. Por exemplo, se você escolher OpenTelemetry, considere a criação de uma equipe separada especializada em observabilidade.
Operações e manutenção
Avalie as seguintes perguntas:
-
Quais opções de implantação o agente ou coletor de observabilidade oferece? Essas opções atendem aos requisitos de sua arquitetura? Por exemplo, se você usa uma implantação em contêiner para a ferramenta de observabilidade, ela oferece suporte a um daemonset ou sidecar? Quais etapas ou ferramentas adicionais a equipe de operações precisaria adotar ou usar para garantir o alinhamento com a segurança e todos os outros processos?
-
Qual é o esforço necessário para manter a solução? Quão simples ou automatizado é o processo de atualização do agente ou coletor? Interfaces de observabilidade totalmente gerenciadas e baseadas em nuvem geralmente têm menor sobrecarga operacional em comparação com aplicativos autoimplantados e hospedados, embora o gerenciamento do agente ou coletor permaneça o mesmo. Leve em consideração a estrutura de sua equipe e considere o custo humano de manter a opção escolhida.
Instrumente sua aplicação
As respostas às perguntas da seção anterior fornecem as informações necessárias para instrumentar seu aplicativo, ou seja, adicionar código para capturar sinais de telemetria em seu aplicativo e medir, observar e validar comportamentos. Você pode usar SDKs esse OpenTelemetry SDK para a linguagem do seu aplicativo para instrumentar automaticamente seu aplicativo. Talvez você ainda precise adicionar um código de instrumentação manual para cobrir quaisquer lacunas e garantir end-to-end a visibilidade. Seja intencional com a telemetria que você adiciona e certifique-se de poder conectá-la novamente a uma ou mais SLIs e SLOs que você estabeleceu na etapa anterior.
Colete telemetria
Implemente componentes de observabilidade
Quando a telemetria estiver fluindo e sendo ingerida em uma plataforma de observabilidade, crie painéis, alertas, playbooks e runbooks.
-
Painéis: crie painéis que contenham informações relevantes, incluindo uma representação visual das tendências atuais e históricas associadas aos seus resultados priorizados. Disponibilize esses painéis para as partes interessadas que você definiu no estágio 1. Para obter mais informações, consulte Criação de painéis para visibilidade operacional no site
da Amazon Builders' Library. -
Alertas: defina alertas para notificar sua equipe quando os resultados estão em risco ou estão sendo violados. Considere adicionar alertas para problemas de segurança e desempenho. Otimize os alertas para reduzir a fadiga e os custos dos alertas adotando o seguinte:
-
Use a detecção de anomalias para evitar a definição de limites rígidos, que exigem ajustes frequentes, e para reduzir a ocorrência de incógnitas desconhecidas.
-
Use combinações inteligentes de alertas que analisem várias métricas relacionadas em conjunto, em vez de configurar alertas individuais para cada métrica. Por exemplo, em vez de configurar alertas separados para CPU, memória e tempo de resposta, crie um alerta significativo que seja acionado somente quando essas métricas indicarem coletivamente um problema real. Essa abordagem reduz significativamente o ruído de alerta e ajuda suas equipes a se concentrarem nos problemas reais que afetam o serviço, em vez de precisarem responder a picos métricos isolados.
-
Gere alertas somente quando a experiência ou os resultados do usuário estiverem em risco. Por exemplo, evite receber alertas sobre um pico de CPU causado por uma atualização automática quando seu aplicativo não tem usuários ativos.
-
-
Manuais: um manual fornece um modelo mental e um contexto para a pessoa que responde a um incidente ou alerta e a ajuda a identificar a causa raiz mais rapidamente. Considere criar manuais para aplicativos complexos e altamente acoplados e para aplicativos que não possuem instrumentação, mas impactam diretamente os resultados que você identificou e priorizou na etapa 1.
-
Runbooks: use runbooks para definir as etapas necessárias para resolver um incidente ou alerta.
Valide o sistema de observabilidade
Em todo o ciclo de vida de desenvolvimento de software (SDLC), verifique se os painéis fornecem os comportamentos e as atualizações esperados durante os testes do sistema. Implemente a engenharia do caos e valide as etapas documentadas em manuais e runbooks, para garantir que sejam precisas e atendam a seus propósitos. Você também deve validar a propriedade do alerta e os caminhos de escalonamento.
