Integrações do Marketplace: Dados em Tempo Real das Suas Ferramentas, na Sua Arquitetura
Mês passado, assisti uma equipe debugar um incidente em produção usando sete abas do navegador. Datadog para métricas. GitHub para o histórico de deploy. SonarQube para o quality gate que alguém pode ter ignorado. ArgoCD para confirmar que o pod estava realmente rodando a versão que achavam. E em algum lugar no fundo, o diagrama de arquitetura em outra aba, perfeitamente preciso, perfeitamente estático, perfeitamente inútil para o problema em questão.
O diagrama dizia o que o sistema era. Não podia dizer como estava indo.
Isso não é uma falha de ferramental. Cada uma dessas ferramentas é excelente no que faz. O problema é a lacuna entre elas — a troca constante de contexto, o modelo mental que você precisa reconstruir cada vez que pula de um dashboard para outro, a pergunta implícita que ninguém faz em voz alta: "Qual dessas sete ferramentas está me mostrando o que eu realmente preciso ver agora?"
Construímos as Integrações do Marketplace para fechar essa lacuna.
A Ideia
A premissa é simples: seu diagrama de arquitetura já é o mapa do seu sistema. É onde você vai para entender o que existe, como as coisas se conectam, que protocolos falam. Por que não deveria ser também o lugar onde você vê como as coisas estão rodando?
O Marketplace do Archyl permite conectar serviços externos — Datadog, GitHub, GitLab, Prometheus, SonarQube, ArgoCD, PagerDuty — e exibir seus dados como widgets ao vivo nos dashboards do seu projeto. Não screenshots. Não links. Dados reais ao vivo, atualizados a cada 30 segundos, ao lado dos seus diagramas C4.
Um badge de status de deploy ao lado do container que ele implanta. Um contador de cobertura de código vinculado ao serviço que ele mede. Uma lista de alertas que mostra o que está pegando fogo, no contexto da arquitetura que está queimando.
O Que Você Pode Conectar
Lançamos com sete produtos, escolhidos porque cobrem a cadeia de ferramentas que a maioria das equipes já usa:
Datadog — Monitore saúde, consultas de métricas, alertas ativos, dashboards embutidos. Se você já usa Datadog para monitorar sua infraestrutura, pode exibir os mesmos dados no seu workspace de arquitetura sem duplicar uma única consulta.
GitHub — Status de workflow, pull requests abertas, estatísticas de repositório, alertas do Dependabot, scanning de segredos, scanning de código. Os widgets de segurança por si só já valem a configuração — ao invés de verificar a aba de segurança de cada repositório individualmente, você vê os achados contextualizados contra a arquitetura.
GitLab — Status de pipeline, merge requests, estatísticas de projeto, e a suite completa de scanners de segurança: análise de vulnerabilidades, SAST, detecção de segredos, DAST. Mesma ideia do GitHub, nativo ao ecossistema GitLab.
Prometheus — Consultas instantâneas para valores de métricas atuais, consultas de intervalo renderizadas como gráficos de séries temporais, e monitoramento de saúde de targets. Se você já tem queries PromQL para suas métricas chave, pode exibi-las diretamente no seu workspace de arquitetura.
SonarQube — Status de quality gate, medidas de projeto (cobertura, bugs, vulnerabilidades, dívida técnica), issues por severidade, hotspots de segurança e ratings de segurança. O widget de quality gate é particularmente útil: um badge verde ou vermelho por serviço diz instantaneamente se o código atende aos seus padrões.
ArgoCD — Saúde e status de sincronização de aplicações, inventários de aplicações, listas de recursos Kubernetes e contagens de aplicações com filtragem. Para equipes rodando no Kubernetes, isso transforma seu diagrama C4 em um dashboard de deployment.
PagerDuty — Status de incidentes, listas de incidentes ativos, escalas de plantão, saúde de serviços e contagem de incidentes. Para equipes gerenciando resposta a incidentes, isso coloca seus alertas operacionais no contexto da arquitetura que eles afetam — sem mais pular entre PagerDuty e seu diagrama de sistema para descobrir qual serviço realmente está pegando fogo.
Cada produto suporta múltiplos tipos de widget — contadores, badges de status, listas, gráficos de séries temporais e iframes embutidos — para que você escolha a visualização certa para os dados.
Como Funciona
O sistema tem três camadas:
Conexões vivem no nível da organização. Um administrador cria uma conexão fornecendo credenciais (uma chave de API, um token, uma URL de servidor). Uma conexão pode alimentar widgets em todos os projetos da organização. Você pode criar múltiplas conexões para o mesmo produto — digamos, uma para sua conta Datadog de produção e outra para staging.
Widgets vivem no nível do projeto (ou do elemento, ou da organização). Você adiciona um widget escolhendo uma conexão, selecionando um tipo de widget e configurando a consulta. Um widget de "Pull Requests Abertas" do GitHub precisa de um owner e nome de repositório. Um widget de "Query de Intervalo" do Prometheus precisa de uma expressão PromQL e um período. Um widget de "Quality Gate" do SonarQube precisa de uma chave de projeto.
O grid é onde os widgets vivem visualmente. É um layout de 12 colunas com drag-and-drop e seções nomeadas. Você pode criar seções como "Monitoramento", "Segurança", "CI/CD", recolhê-las, reordená-las e redimensionar widgets individuais. Tudo salva automaticamente.
A configuração de um widget típico leva cerca de 30 segundos. Escolha a conexão, escolha o tipo, cole a configuração, pronto. O widget começa a buscar dados imediatamente.
Por Que Widgets, Não Dashboards
Poderíamos ter construído um produto de dashboard tradicional. Linhas de gráficos, uma barra lateral de filtros, o de sempre.
Não fizemos, porque isso já existe. Datadog tem dashboards. Grafana tem dashboards. Você não precisa de outra ferramenta de dashboard. O que você precisa é de uma forma de ver os dados certos no contexto certo — e o contexto é sua arquitetura.
Um dashboard do Grafana mostrando métricas de CPU para dez serviços é útil. Mas ele não diz qual desses serviços é o API gateway, qual é o processador de pagamentos e qual é o sistema de notificações. Seu diagrama de arquitetura diz. Colocar a métrica de CPU na arquitetura, ao lado do container a que pertence, significa que você nunca precisa fazer esse mapeamento mental sozinho.
Este é o mesmo princípio por trás de tudo que construímos no Archyl: documentação de arquitetura deveria ser o único lugar onde você vai para entender um sistema. Não apenas sua estrutura — suas decisões (ADRs), suas especificações (API Contracts), seu histórico de deployment (Releases), e agora sua realidade operacional (Integrações do Marketplace).
Seções e Organização
Sabíamos desde o início que uma parede plana de widgets não escalaria. Quando você tem quinze widgets em um projeto — alguns para monitoramento, alguns para segurança, alguns para CI/CD — você precisa de estrutura.
Widgets são organizados em seções nomeadas. Você as cria, nomeia, reordena arrastando seus cabeçalhos, e recolhe as que não precisa agora. Cada seção funciona como um painel que você pode abrir ou fechar.
No modo de edição, você pode:
- Arrastar widgets para reposicioná-los dentro de uma seção
- Mover widgets entre seções
- Redimensionar widgets de um badge compacto a um gráfico de largura total
- Arrastar cabeçalhos de seção para reordenar grupos inteiros
- Criar, renomear e excluir seções
O grid compacta verticalmente, então não há lacunas. Quando terminar de organizar, clique em "Pronto" e o layout fica fixo.
Escopo: Organização, Projeto, Elemento
Nem todos os dados pertencem ao mesmo nível.
Widgets da organização são visíveis em todos os projetos. Use-os para métricas que importam globalmente — contagem total de deploys, status de quality gate do SonarQube em toda a empresa, achados de segurança do GitHub no nível organizacional.
Widgets do projeto aparecem apenas na aba Integrações de um projeto específico. Estes são os mais comuns — dashboards de monitoramento, status de CI/CD, métricas de qualidade de código para os serviços naquele projeto.
Widgets do elemento se anexam diretamente a um elemento C4. Abra o painel de detalhes de um container e você verá seus widgets ao lado de seus relacionamentos, ADRs e API contracts. Este é o escopo mais poderoso: dados operacionais contextualizados no elemento arquitetural a que pertencem.
O Que Isso Muda
Antes das Integrações do Marketplace, entender o estado operacional de um sistema significava abrir múltiplas ferramentas, cruzar dados e manter o mapeamento entre "dashboard de monitoramento" e "diagrama de arquitetura" na sua cabeça.
Depois: você abre um workspace. A arquitetura diz o que existe. Os widgets dizem como está indo. Os releases dizem o que foi entregue. Os ADRs dizem por que foi construído daquela forma. Os API contracts dizem como são as interfaces.
Um lugar. Um contexto. Sem troca de abas.
Essa é a visão que estamos construindo desde o primeiro dia. Documentação de arquitetura que responde perguntas reais — não apenas "o que é este sistema?" mas "este sistema está saudável?", "este serviço está seguro?", "quando foi o último deploy?", e "qual é o status do quality gate deste código?"
As Integrações do Marketplace são um grande passo em direção a essa visão. E estamos apenas começando — mais produtos estão chegando.
Começando
- Vá em Configurações da Organização > Marketplace
- Conecte um produto (você precisará de uma chave de API ou token)
- Abra a aba Integrações de qualquer projeto
- Clique em Personalizar, depois Adicionar Widget
- Escolha uma conexão, selecione um tipo de widget, configure, pronto
Toda a configuração leva menos de cinco minutos. Seus diagramas de arquitetura nunca mais serão os mesmos.
Quer ver como outros recursos dão vida à sua arquitetura? Confira Gerenciamento de Releases para rastreamento de deploys, ou API Contracts para vincular suas especificações de API ao diagrama.