BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Inside Stack Overflow’s Monitoring Systems

Inside Stack Overflow’s Monitoring Systems

Nick Craver, líder de arquitetura da Stack Exchange, escreveu sobre seus sistemas de monitoramento em um artigo recente. Ele discutiu a filosofia e a motivação por trás de sua estratégia de monitoramento e falou sobre seu conjunto de ferramentas - principalmente Bosun, Grafana e Opserver.

O Stack Overflow e seus sites parceiros no Stack Exchange são executados em .NET e MS SQL Server, servidores de aplicações web IIS, HAProxy (como balanceador de carga) e serviços adicionais fornecidos pelo Redis e Elasticsearch. Seu principal datacenter está em Nova York com um failover no Oregon. O monitoramento no Stack Exchange, observa Craver, geralmente consiste em "logs, métricas, verificações de integridade e perfis", e eles usam Bosun, Opserver, Grafana e MiniProfiler como ferramentas principais.

As fontes de dados para os sistemas de monitoramento do Stack Exchange são logs, verificações de integridade e métricas de séries temporais. O registro é feito por meio de mecanismos padrão e bibliotecas personalizadas que são enviadas para um banco de dados. Também inclui Logstash e eventos de log resumidos de solicitações HTTP dos balanceadores de carga HAProxy. Existem verificações de integridade significativas que realmente testam o que o usuário final vê, como a home page. As métricas são coletadas e armazenadas em sua ferramenta de monitoramento Bosun de software livre, com OpenTSDB como backend. O Bosun também envia alertas e o Pagerduty manipula o gerenciamento de escalonamento. Uma ferramenta chamada Opserver - que mostra uma visão do painel de todo o sistema de monitoramento - completa a imagem.

Imagem cortesia: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/

Todos os aplicativos do Stack Exchange usam uma biblioteca de log de erros chamada StackExchange.Exceptional que envia os logs para o MSSQL Server. Este é um fork de uma biblioteca de log do .NET chamada ELMAH. Redis, Elasticsearch e SQL Server registram em log seus locais de registro padrão, embora não esteja claro se esses registros são enviados a um servidor central para agregação e pesquisa. Os logs do equipamento de rede são enviados para o Logstash e podem ser visualizados por meio de um painel do Kibana. Os tempos de carregamento de páginas podem ser analisados detalhadamente usando o MiniProfiler, que exibe os tempos de chamadas do método nas várias camadas.

O Bosun é uma ferramenta de monitoramento criada no Stack Exchange e posteriormente aberta. Os principais recursos do Bosun são a capacidade de testar alertas em relação a dados históricos, uma linguagem de consulta para avaliação de séries temporais, alertas modelados e alertas e previsões de tendências de séries temporais. Ao contrário das ferramentas tradicionais de monitoramento, como o Nagios, o Zabbix, etc, e similares às modernas, como o Prometheus, o Bosun não requer que alertas individuais sejam configurados para cada servidor. Uma única verificação de limite é suficiente para a série temporal que mede, digamos, o uso da CPU, em todos os servidores. O alerta tem a lista de séries temporais que violaram o limite, que podem ser usadas para identificar os servidores problemáticos.

O Bosun suporta vários back-ends para armazenamento e o OpenTSDB (com o HBase) é usado no Stack Exchange. Esse é um dos pontos problemáticos, e como eles "não usam o HBase em nenhum outro lugar, a sobrecarga administrativa consome muito tempo", escreve Kyle Brandt, um dos autores originais de Bosun. O agente complementar da Bosun é o scollector, que coleta métricas das máquinas monitoradas. É uma substituição baseada em Go do agente tcollector do OpenTSDB. Métricas de aplicativo são enviadas com o BosunReporter.

Os health checks concentram-se na experiência do usuário final, bem como na integridade dos serviços internos. Pingdom verifica os URLs acessíveis externamente. O usuário final que enfrenta as verificações de URL, como para a página inicial, é fundamental porque "a home page verifica coisas que não podemos verificar de outra forma, e uma verificação holística é importante", escreve Craver. Atua rapidamente como um CDN e proxy para os sites do Stack Exchange, e suas verificações de integridade garantem que o failover para o datacenter secundário ocorra quando o principal ficar inativo. Além do monitoramento do lado do servidor, os timings do lado do cliente também são rastreados usando as APIs do navegador.

Amarrando tudo isso juntos estão Grafana e Opserver. O Grafana conecta-se aos dados do Bosun para exibir métricas de séries temporais. O Opserver, por outro lado, se concentra no status geral de monitoramento em toda a infraestrutura. Por que a equipe criou o Opserver em vez de usar o Nagios ou ferramentas similares? Craver explica que nenhuma ferramenta única atendeu a todas as suas necessidades naquele momento. Como a maioria de seu conjunto de ferramentas, ele evoluiu de requisitos específicos. O painel do Opserver pode ser usado para detalhar serviços e servidores individuais. Ele precisa que a configuração seja estaticamente fornecida no formato JSON e apresentará alguns obstáculos se usada para monitorar ambientes de nuvem onde as máquinas são efêmeras.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT