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.