Métricas de histogramas exponenciais
O suporte inicial a consultas para métricas de histogramas exponenciais do OpenTelemetry foi adicionado. Já era possível registrar uma dessas métricas em uma fonte, mas não havia como consultá-la. Agora, contagens e quantis funcionam por meio do construtor de consultas.
Histogramas exponenciais são semelhantes aos histogramas com buckets explícitos, mas os limites dos buckets são calculados com base em potências de dois, em vez de serem armazenados para cada bucket. A escala controla qual potência de dois é usada. Uma escala maior produz buckets menores, enquanto o deslocamento move os limites para múltiplos maiores ou menores. A contagem de cada bucket registra quantas observações se enquadram nesse intervalo.
Máximo, mínimo, soma e média continuam sem suporte, em conformidade com a implementação existente de histogramas explícitos. Esses campos são opcionais no modelo de dados do OpenTelemetry, portanto não dependemos de que estejam presentes.
Como a demonstração mostra, o SQL gerado é longo e não é particularmente legível. Ele tem desempenho aceitável e não esgota a memória, mas este é apenas o suporte funcional inicial. O desempenho é a próxima etapa do trabalho, e um schema atualizado já está em desenvolvimento, o que deve tornar essas consultas consideravelmente mais rápidas.
Por enquanto, apenas o tipo de exibição de séries temporais é renderizado corretamente. Isso é consistente com o tipo de métrica de histograma existente.
PRs relacionados: #2687 feat: Exibir métricas de histogramas exponenciais no menu suspenso de nomes de métricas, #2697 feat: Implementar quantil+soma para métricas de histogramas exponenciais, #2705 feat: Oferecer suporte a histogramas exponenciais no MCP, #2707 fix: Oferecer suporte ao agrupamento de agregações de quantis de histogramas em colunas que não são atributos
Validação de gráficos de SQL bruto
Os gráficos de SQL bruto agora emitem um aviso quando faltam macros esperadas. Essa mudança surgiu de um caso de suporte em que uma pessoa que criava muitos gráficos de SQL bruto continuava obtendo resultados confusos.
As consultas do dashboard devem incluir as macros de filtros e de tabela de origem. Os gráficos de séries temporais também devem incluir as macros de intervalo de tempo e de intervalo. Antes, essas verificações só eram executadas depois que um alerta era anexado ao tile. Agora, elas são executadas para todos os gráficos de SQL bruto; assim, remover uma macro exibe um aviso no Editor em vez de gerar um gráfico confuso mais tarde.
A validação também considera as dependências de cada macro. As macros de tabela de origem e de filtros exigem que uma fonte esteja selecionada, embora os gráficos de SQL bruto não precisem de uma em outras circunstâncias. Portanto, usar qualquer uma dessas macros sem selecionar uma fonte produz um erro, e não um aviso.
É uma pequena mudança, mas deve facilitar a identificação de problemas em SQL bruto sem precisar acionar o suporte.
PRs relacionados: #2742 feat: Aviso sobre params/macros ausentes no SQL Editor
Vincular a fontes pelo nome, não pelo ID
A equipe do LogHouse solicitou uma maneira mais estável de criar links para fontes. Ela opera o ambiente de logging do ClickHouse Cloud e provisiona fontes programaticamente usando infraestrutura como código. Os IDs das fontes mudam quando uma fonte é recriada e variam entre os ambientes de desenvolvimento, staging e produção, o que torna frágeis os links baseados em ID. Como eles criam links para o ClickStack a partir de sistemas de alerta e do Grafana, não era prático manter um conjunto separado de IDs de fontes para cada ambiente.
O parâmetro de URL
source agora aceita o nome de uma fonte, além de um ID. Os nomes são definidos durante o provisionamento das fontes, portanto o mesmo link pode funcionar em todos os ambientes. Inicialmente, o suporte foi adicionado à página Busca. Um PR subsequente o estende a todas as páginas com um parâmetro de fonte, incluindo o Chart Explorer, o service map, as sessões, o dashboard de serviços e o dashboard do Kubernetes.
A maior parte da discussão subsequente se concentrou na facilidade de descoberta. Na prática, isso é uma API de URL, e é improvável que alguém a encontre por acaso. Uma opção é usar nomes em vez de IDs por padrão, embora conflitos de nomes tornem isso inseguro. Outras sugestões incluíram disponibilizar links por meio de um botão de compartilhamento, permitir que agents os gerem pelo MCP e documentar adequadamente a API de URL. Intervalos de tempo relativos se beneficiariam da mesma documentação.
As referências baseadas em nome também poderiam ser estendidas aos dashboards. Um workflow de infraestrutura como código poderia então provisionar fontes, importar dashboards e conectar tudo automaticamente. As importações de dashboards pela IU já associam fontes por nome, portanto a lacuna restante está principalmente nos workflows programáticos.
PRs relacionados: #2746 feat: Aceitar nomes de fontes além de IDs nos parâmetros de URL, #2758 feat: Oferecer suporte a links diretos por nome de fonte em páginas adicionais
Redesenho das configurações de exibição de gráficos
Ainda está sendo definido onde as configurações de exibição de gráficos devem ficar. A alteração original as moveu para a direita do editor de tile, de forma inline, em vez de abri-las em um drawer separado. Antes, o editor de tile era um modal, e as Configurações de exibição eram abertas em um drawer sobre ele. Pressionar Escape uma vez fechava ambos, e um drawer sobre um modal nunca pareceu adequado.
O PR se tornou mais complexo quando as configurações de séries também precisaram ser empilhadas, então recuamos e começamos a analisar a página de forma mais ampla. O trabalho ainda está na fase de wireframe. O design atual coloca as configurações em um painel acoplado e aplica as alterações automaticamente, permitindo visualizar o resultado em tempo real sem pressionar o botão Aplicar.
O plano é concluir o redesenho antes de incorporá-lo novamente ao PR existente. O que há agora está sendo tratado como um protótipo, especialmente porque o novo design também altera partes da página do dashboard.
PRs relacionados: #2721 feat(dashboards): mover o editor de tile para um drawer com painel de configurações acoplado
Nova página Explore
Esta é uma exploração inicial de uma página Explore unificada que poderá, futuramente, substituir Busca, buscas salvas e o Chart Explorer por um único ponto de entrada.
A implementação se baseia no que aprendemos com a reformulação do visualizador de traces. Em vez de mudar a experiência de todos de uma só vez, a nova página seria disponibilizada por meio de uma flag de recurso para um pequeno grupo de usuários. Usaríamos esse período para identificar e corrigir problemas antes de expandir a disponibilização. Se a ideia não funcionar, continuará sendo um experimento e não será lançada. Esse é um resultado perfeitamente válido.
A página começa com um tipo de sinal. Ao escolher traces, logs ou métricas, o restante da experiência se adapta de acordo. Por exemplo, ao selecionar logs, você tem acesso à visualização de lista, aos padrões de eventos, às séries temporais e às outras visualizações disponíveis atualmente no Chart Explorer.
Uma investigação deve poder continuar sem a necessidade de trocar de página. Você pode começar com uma lista, passar para um número ou uma tabela agrupada, adicionar o resultado a um dashboard e, em seguida, escrever uma consulta personalizada caso precise de mais controle.
Diversas ideias menores estão incluídas, a maioria motivada pelo feedback dos usuários. O editor de consultas funcionaria mais como o SQL Editor, eliminando as diferenças atuais no comportamento do preenchimento automático. Erros e avisos apareceriam durante a edição, em vez de somente após a execução da consulta.
As colunas teriam um picker dedicado. Pelo menos um usuário não percebeu que alterar a cláusula
SELECT controlava quais colunas apareciam na tabela. Com o picker, clicar em um campo atualiza o SQL e permite ordenar por esse campo. A cláusula SELECT continua disponível para usuários avançados.
As visualizações salvas também ficariam na página, permitindo explorar sem salvar e, depois, salvar a visualização atual no próprio lugar. O SQL gerado seria exibido inline.
Ainda falta bastante, incluindo algumas das visualizações disponíveis atualmente no Chart Explorer. O design continuará evoluindo à medida que esses elementos forem adicionados.
PRs relacionados: nenhum ainda; esta é uma exploração, e não um recurso lançado
Vinculação de filtros do dashboard
A vinculação de filtros do dashboard foi incorporada. Nós a demonstramos inicialmente em versão preliminar há vários meses e depois a pausamos enquanto avaliávamos as implicações de desempenho. A vinculação altera a estrutura das consultas do dashboard e nem sempre aproveita da melhor forma as visões materializadas; portanto, será disponibilizada como uma alternância opcional, e não como comportamento padrão.
Quando a vinculação está ativada, a escolha de um valor em um filtro restringe os valores disponíveis nos demais. Selecionar um serviço deixa apenas os valores de severidade encontrados para esse serviço. Selecionar um ID de trace deixa apenas os IDs de trace pai relacionados. Isso impede que os usuários escolham combinações que não retornam dados.
Um PR complementar torna a vinculação sensível à fonte. Os filtros são agrupados por fonte, com ícones de corrente entre filtros adjacentes que podem restringir uns aos outros. Em um dashboard com dois filtros de log e dois filtros de trace, deve ficar claro quais filtros interagem.
O caso de uso original era o dashboard do Kubernetes. Selecionar um pod do Kubernetes deve deixar apenas as implantações e os nós que contêm esse pod. Os valores restritos são buscados sob demanda quando um menu suspenso é aberto, limitando o custo das consultas adicionais.
A discussão deixou duas questões em aberto. Atualmente, a configuração é armazenada por usuário no armazenamento do navegador. A expectativa da chamada era que, no futuro, as pessoas queiram salvá-la no nível do dashboard. Nesse caso, talvez seja melhor manter temporária a preferência no nível do usuário, em vez de fazê-la competir futuramente com o comportamento no nível do dashboard.
A outra questão é como os filtros dependentes se comportam enquanto seus valores estão sendo carregados. Atualmente, selecionar um valor mostra um estado de carregamento dentro do menu suspenso dependente, em vez de bloqueá-lo, embora o comportamento com um segundo filtro dependente ainda precise ser verificado. A preferência era manter os filtros utilizáveis enquanto a restrição está em andamento e indicar que a lista ainda não terminou de ser atualizada. Quem já sabe o valor que deseja não deveria ter de esperar pelos metadados.
PRs relacionados: #2423 feat(dashboards): valores de filtro em cascata (facetados), #2760 feat(dashboards): persistir a alternância de vinculação de filtros e esclarecer a vinculação dentro da fonte
Lembrar a última aba do painel lateral
O menor PR da semana também é um bom exemplo de uma pequena irritação que vale corrigir.
O painel lateral da linha sempre era aberto na aba Overview, projetada com base nos campos de logs do OpenTelemetry. Para logs que não seguem o formato do OTel, a aba exibe poucas informações úteis. Você acaba alternando para Column Values sempre que abre uma linha.
Agora, o painel lembra a última aba usada e a abre novamente na próxima vez. Não há nada a configurar. Usuários que não usam OTel e alternam para Column Values permanecerão nessa aba, enquanto quem usa Overview mantém o comportamento atual.
PRs relacionados: #2752 feat(app): lembrar a última aba usada do painel lateral entre aberturas