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á. # Práticas recomendadas para dashboards **** **Este tópico de documentação foi desenvolvido para espaços de trabalho do Grafana que oferecem suporte ao Grafana versão 12.x.** Para espaços de trabalho do Grafana compatíveis com o Grafana versão 10.x, consulte [Trabalhar no Grafana versão 10](using-grafana-v10.md). Para espaços de trabalho do Grafana compatíveis com o Grafana versão 9.x, consulte [Trabalhar no Grafana versão 9](using-grafana-v9.md). Para espaços de trabalho do Grafana compatíveis com o Grafana versão 8.x, consulte [Trabalhar no Grafana versão 8](using-grafana-v8.md). Esta seção fornece informações sobre as práticas recomendadas para administradores e usuários do Grafana sobre como criar e manter dashboards do Grafana. Para obter informações sobre os diferentes tipos de dashboards que você pode criar, consulte a postagem do blog [Grafana dashboards: A complete guide to all the different types you can build](https://grafana.com/blog/2022/06/06/grafana-dashboards-a-complete-guide-to-all-the-different-types-you-can-build/?pg=webinar-getting-started-with-grafana-dashboard-design-amer&plcmt=related-content-1) no site da Grafana Labs. **nota** Esta seção pode ajudar a criar uma estratégia para o monitoramento e a manutenção do dashboard. Você conhece melhor seus sistemas e deve usar esta seção para ajudar na sua compreensão. Em última análise, é sua responsabilidade criar a melhor estratégia para o seu sistema. ## Estratégias comuns de observabilidade Quando você tem muito a monitorar, como um parque de servidores, precisa de uma estratégia para decidir o que é realmente importante para monitorar. Esta página descreve vários métodos comuns para escolher o que monitorar. Uma estratégia lógica permite criar dashboards uniformes e escalar a plataforma de observabilidade com mais facilidade. **Diretrizes para estratégias** + O método USE mostra o quanto as máquinas estão satisfeitas, o método RED mostra o quanto os usuários estão satisfeitos. + Relatórios USE sobre as causas dos problemas. + O RED relata a experiência do usuário e é mais provável de relatar os sintomas de problemas. + O monitoramento de ambos é importante para entender o sistema. Como prática recomendada, alerte sobre os sintomas em vez das causas. Normalmente, os alertas são configurados em dashboards RED. **Método USE** USE significa: + **Utilização**: a porcentagem de tempo em que o recurso está ocupado, como o uso do nó da CPU. + **Saturação**: a quantidade de trabalho que um recurso precisa realizar, geralmente o tamanho da fila ou a carga do nó. + **Erros**: a contagem de eventos de erros. Esse método é melhor para recursos de hardware em infraestrutura, como CPU, memória e dispositivos de rede. Para obter mais informações, consulte a postagem do blog de Brendan Gregg, [The USE Method](http://www.brendangregg.com/usemethod.html). **Método RED** RED significa: + **Taxa**: solicitações por segundo. + **Erros**: número de solicitações que estão falhando. + **Duração**: período de tempo que essas solicitações levam, distribuição das medições de latência. Esse método é mais aplicável a serviços, especialmente a um ambiente de microsserviços. Para cada um dos seus serviços, instrumente o código para expor essas métricas para cada componente. Os dashboards RED são bons para alertas e SLAs. Um dashboard RED bem projetado é um proxy para a experiência do usuário. Para obter mais informações, consulte a postagem do blog de Tom Wilkie [The RED method: How to instrument your services](https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services). **Os quatro sinais dourados** De acordo com o [Manual do SRE do Google](https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/#xref_monitoring_golden-signals), se você puder avaliar apenas quatro métricas do seu sistema voltado para o usuário, concentre-se nestas quatro. Esse método é semelhante ao método RED, mas inclui saturação. + **Latência**: tempo gasto para atender a uma solicitação. + **Tráfego**: a previsão de demanda para seu sistema. + **Erros**: taxa de solicitações que estão falhando. + **Saturação**: o quão “cheio” seu sistema está. ## Modelo de maturidade do gerenciamento de dashboards A *maturidade do gerenciamento de dashboards* refere-se ao quão bem projetado e eficiente é o ecossistema de dashboards. Recomendamos revisar periodicamente a configuração do dashboard para avaliar onde você está e como você pode melhorar. Em termos gerais, a maturidade do dashboard pode ser definida como baixa, média ou alta. Muito do conteúdo desse tópico foi retirado da palestra de KubeCon 2019 [Fool-Proof Kubernetes Dashboards](https://www.youtube.com/watch?v=YE2aQFiMGfY) for Oncalls. Sleep-Deprived **Baixa: estado padrão** Neste estágio, você não tem uma estratégia coerente de gerenciamento de dashboards. Quase todo mundo começa aqui. Como você pode saber que está aqui? + Todos podem modificar seus dashboards. + Muitos dashboards copiados, pouca ou nenhuma reutilização do dashboard. + One-off painéis que duram para sempre. + Nenhum controle de versão (JSON do dashboard com controle de versão). + Muita navegação por dashboards, busca pelo dashboard certo. Isso significa muito tempo perdido tentando encontrar o dashboard de que você precisa. + Não há nenhum alerta para direcionar você para o dashboard certo. **Média: dashboards metódicos** Neste estágio, você está começando a gerenciar o uso do dashboard com dashboards metódicos. Você pode ter traçado uma estratégia, mas há algumas coisas que você poderia melhorar. Como você pode saber que está aqui? + Evite a dispersão usando variáveis de modelo. Por exemplo, você não precisa de um dashboard separado para cada nó. Você pode usar variáveis de consulta. Melhor ainda, você também pode tornar a fonte de dados uma variável de modelo para poder reutilizar o mesmo dashboard em diferentes clusters e backends de monitoramento. Consulte a lista de exemplos em [Variáveis](v12-dash-variables.md) para obter ideias. + Dashboards metódicos de acordo com uma [estratégia de observabilidade](#v12-dash-common-observability-strategies). + Dashboards hierárquicos com opções para acessar o próximo nível. + O design do dashboard reflete as hierarquias de serviços. Por exemplo, é possível usar o método RED com uma linha por serviço. A ordem das linhas pode refletir o fluxo de dados à medida que você rola para baixo no dashboard. + Compare coisas semelhantes: divida os dashboards de serviços quando a magnitude for diferente. Certifique-se de que as métricas agregadas não ocultem informações importantes. + Gráficos expressivos com uso significativo de cores e eixos de normalização sempre que possível. + Exemplo de cor significativa: azul significa que é bom, vermelho significa que é ruim. Os [limites](v12-panels-configure-thresholds.md) podem ajudar com isso. + Exemplo de eixos de normalização: ao comparar o uso da CPU, avalie por porcentagem em vez de pelo número bruto, pois as máquinas podem ter um número diferente de núcleos. Normalizar o uso da CPU pelo número de núcleos reduz a carga cognitiva porque o visualizador pode confiar que 100% de todos os núcleos estão sendo usados, sem precisar saber o número de CPUs. + A navegação direcionada reduz a suposição. + As variáveis do modelo dificultam a navegação aleatória ou sem propósito. + A maioria dos dashboards deve ser vinculada por alertas. + A navegação é direcionada com links. Para obter mais informações, consulte [Gerenciar links do dashboard](v12-dash-manage-dashboard-links.md). + Version-controlled painel JSON. **Alta: uso otimizado** Neste estágio, você otimizou o uso do gerenciamento do dashboard com uma estratégia consistente e cuidadosa. Requer manutenção, mas os resultados valem a pena. + Redução ativa da dispersão. + Analise regularmente os dashboards existentes para garantir que sejam relevantes. + Somente dashboards aprovados foram adicionados à lista de dashboards principais. + Rastreamento do uso do dashboard. Você pode aproveitar os [Insights de uso](v12-dash-assess-dashboard-usage.md). + Consistência por projeto. + Use bibliotecas de scripts para gerar dashboards e garantir a consistência no padrão e no estilo. + grafonnet (Jsonnet) + grafanalib (Python) + Nenhuma edição no navegador. Os visualizadores do dashboard alteram as visualizações com variáveis. + Procurar dashboards é a exceção, não a regra. + Faça experiências e testes em uma instância separada do Grafana dedicada a esse propósito, não em sua instância de produção. Quando um dashboard no ambiente de teste for comprovadamente útil, adicione-o à instância principal do Grafana. ## Práticas recomendadas para criar dashboards Esta seção descreve algumas práticas recomendadas a serem seguidas ao criar dashboards do Grafana. **Antes de começar** Aqui estão alguns princípios a serem considerados antes de criar um dashboard. **Um dashboard deve contar uma história ou responder a uma pergunta** Que história você está tentando contar com seu dashboard? Tente criar uma progressão lógica de dados, como de grandes para pequenos ou de gerais para específicos. Qual é o objetivo desse dashboard? (Dica: se o dashboard não tiver um objetivo, pergunte a si mesmo se realmente precisa dele.) Mantenha seus grafos simples e focados em responder à pergunta que você está fazendo. Por exemplo, se a pergunta for “quais servidores estão com problemas?”, então talvez você não precise mostrar todos os dados de servidores. Basta mostrar os dados dos que estão com problemas. **Os dashboards devem reduzir a carga cognitiva, não aumentá-la** A *carga cognitiva* é basicamente a dificuldade que existe para se pensar sobre algo a fim de poder entendê-lo. Facilite a interpretação do dashboard. Outros usuários e você no futuro (quando estiver tentando descobrir o que se rompeu às 2h da manhã) agradecerão. Pergunte a si mesmo: + Posso dizer exatamente o que cada grafo representa? Está óbvio ou eu tenho de pensar sobre ele? + Se eu mostrar isso para outra pessoa, quanto tempo ela levará para descobrir? Eles vão se perder? **Tenha uma estratégia de monitoramento** É fácil criar dashboards. É mais difícil otimizar a criação de dashboards e seguir um plano, mas vale a pena. Essa estratégia deve orientar o esquema geral do dashboard e garantir a consistência no design individual do dashboard. Consulte [Estratégias comuns de observabilidade](#v12-dash-common-observability-strategies) e [Níveis de maturidade do gerenciamento de dashboards](#v12-dash-management-maturity-model) para obter mais informações. **Anote isto** Depois de ter uma estratégia ou as diretrizes do projeto, anote-as para ajudar a manter a consistência ao longo do tempo. **Práticas recomendadas a serem seguidas** + Ao criar um novo dashboard, verifique se ele tem um nome significativo. + Se estiver criando um dashboard para jogar ou experimentar, coloque a palavra `TEST` ou `TMP` no nome. + Considere incluir seu nome ou iniciais no nome do dashboard ou como uma tag para que as pessoas saibam quem é o proprietário do dashboard. + Remova os dashboards temporários do experimento quando terminar de usá-los. + Se você criar muitos dashboards relacionados, pense em como fazer uma referência cruzada para facilitar a navegação. Para obter mais informações, consulte [Práticas recomendadas para gerenciamento de dashboards](#v12-dash-best-practices-for-managing-dashboards), posteriormente nesta seção. + O Grafana recupera dados de uma fonte de dados. Uma compreensão básica de [Conectar-se à fonte de dados](AMG-data-sources.md) em geral, e de suas fontes de dados específicas, é importante. + Evite a atualização desnecessária do dashboard para reduzir a carga na rede ou no backend. Por exemplo, se seus dados mudarem a cada hora, então não precisará definir a taxa de atualização do dashboard para 30 segundos. + Use a esquerda e a direita Y-axes ao exibir séries temporais com unidades ou intervalos diferentes. + Adicione documentação aos dashboards e painéis. + Para adicionar documentação a um dashboard, adicione uma [Visualização do painel de texto](v12-panels-text.md) ao dashboard. Registre coisas como a finalidade do dashboard, links de recursos úteis e quaisquer instruções de que os usuários possam precisar para interagir com o dashboard. + Para adicionar documentação a um painel, edite as configurações do painel e adicione uma descrição. Qualquer texto que você adicionar aparecerá se você passar o cursor sobre o pequeno `i` no canto superior esquerdo do painel. + Reutilize seus dashboards e garanta a consistência usando [modelos e variáveis](v12-dash-variables.md). + Tenha cuidado ao empilhar dados de grafos. As visualizações podem ser enganosas e ocultar dados importantes. Recomendamos desativá-lo na maioria dos casos. ## Práticas recomendadas para gerenciamento de dashboards Esta página descreve algumas práticas recomendadas a serem seguidas durante o gerenciamento dos dashboards do Grafana. **Antes de começar** Aqui estão alguns princípios a serem considerados antes de começar a gerenciar dashboards. **Observabilidade estratégica** Existem várias [estratégias comuns de observabilidade](#v12-dash-common-observability-strategies). Você deve pesquisá-las e decidir se uma delas funciona para você ou se deseja criar a sua própria. De qualquer forma, tenha um plano, anote-o e cumpra-o. Adapte sua estratégia às necessidades dinâmicas, conforme necessário. **Nível de maturidade** Qual é o nível de maturidade do dashboard? Analise a configuração atual do dashboard e compare-a com o [Modelo de maturidade do gerenciamento do dashboard](#v12-dash-management-maturity-model). Entender onde você está pode ajudar a decidir como chegar aonde você deseja. **Práticas recomendadas a serem seguidas** + Evite a dispersão de dashboards, ou seja, o crescimento descontrolado dos dashboards. A dispersão de dashboards afeta negativamente o tempo necessário para encontrar o dashboard certo. Duplicar dashboards e alterar “uma coisa” (pior: manter as tags originais) é o tipo de dispersão mais fácil. + Revise periodicamente os dashboards e remova os desnecessários. + Se você criar um dashboard temporário, talvez para testar algo, coloque o nome com o prefixo `TEST:`. Exclua o dashboard quando terminar. + Copiar dashboards sem alterações significativas não é uma boa ideia. + Você perde atualizações no dashboard original, como alterações na documentação, correções de bugs ou adições às métricas. + Em muitos casos, as cópias estão sendo feitas para simplesmente personalizar a visualização definindo os parâmetros do modelo. Em vez disso, isso deve ser feito mantendo um link para o dashboard principal e personalizando a visualização com [parâmetros de URL](v12-panels-configure-data-links.md#v12-panels-data-link-variables). + Quando precisar copiar um dashboard, renomeie-o claramente e *não* copie as tags dele. As tags são metadados importantes para dashboards usados durante a pesquisa. Copiar tags pode resultar em correspondências falsas. + Mantenha um dashboard de dashboards ou dashboards com referência cruzada. Isso pode ser feito de diversas formas: + Crie links de dashboards, painéis ou links de dados. Os links podem levar para outros dashboards ou para sistemas externos. Para obter mais informações, consulte [Gerenciar links de dashboard](v12-dash-manage-dashboard-links.md). + Adicione um [Painel de lista de dashboards](v12-panels-dashboard-list.md). Em seguida, você pode personalizar o que visualiza fazendo pesquisas por tags ou pastas. + Adicione um [painel de texto](v12-panels-dashboard-list.md) e use o markdown para personalizar a exibição.