A equipe de engenharia do Booking.com escalou sua implantação do Graphite de um pequeno cluster, para um que lida com milhões de métricas por segundo. Ao longo do caminho, eles modificaram e otimizaram os principais componentes do Graphite - carbon-relay, carbon-cache e a API de renderização.
O Booking.com rastreia métricas técnicas e de negócios no Graphite. Eles começaram a usar o Graphite em 2012, em uma configuração RAID 1+0, que também foi usada em seus bancos de dados, mas não foi bem dimensionada para o Graphite. Eles dividiram as solicitações para distribuir o tráfego pelos nós de armazenamento. No entanto, isso era difícil de manter e eles mudaram para SSDs em uma configuração RAID 1.
O carbon-relay padrão, escrito em Python, esbarrou com gargalos da CPU e se tornou um ponto único de falha. A equipe o reescreveu em C e também mudou o modelo de implantação para que cada host monitorado tivesse um relay. Isso enviaria as métricas para pontos de extremidade em vários datacenters respaldados por relays maiores e dados de buffer localmente quando houvesse uma falha. Para contornar o balanceamento desigual de métricas entre os servidores, eles implementaram um algoritmo hash consistente. No entanto, eles continuaram a enfrentar problemas ao adicionar novos nós de armazenamento, usar shell scripts para sincronizar dados entre data centers e tiveram que continuar substituindo SSDs (cada um durou de 12 a 18 meses) devido às frequentes gravações feitas no disco. Em determinado momento, a equipe considerou o HBase, o Riak e o Cassandra como backends de armazenamento, mas não está claro se eles perseguiram esses esforços. Outras equipes de engenharia utilizaram com sucesso o Cassandra como um backend do Graphite escalonável.
Uma das otimizações que a equipe fez no início foi o carbonzipper, que poderia fazer solicitações de proxy no front-end da web para um cluster de back-ends de armazenamento, de acordo com Vladimir Smirnov, ex-administrador de sistemas da Booking.com. Em última análise, a equipe teve que substituir o carbon cache padrão e reescrever o seu relay com implementações baseadas em Golang. O projeto go-carbon é a implementação atual da pilha de Graphite/carbon no Go.
O Booking.com tem um "Event Graphite Processor" distribuído que gera métricas do Graphite a partir de fluxos de eventos, processando mais de 500 mil eventos por segundo. Os fluxos de eventos são gerados na pilha e armazenados no Riak. "O Booking.com usa gráficos em todas as camadas de sua pilha técnica. Uma grande parte dos gráficos é gerada a partir dos eventos", diz Damien Krotkine, engenheiro de software sênior e Ivan Paponov, desenvolvedor de software sênior da Booking.com. Além de eventos, vários sistemas coletores e scripts coletam métricas dos sistemas do Booking.com. Inicialmente começando com collectd, eles mudaram para o Diamond, um coletor de métricas do sistema baseado em Python. Será que eles padronizaram as convenções de nomenclatura métricas? Até certo ponto - eles começaram reservando sys.* (para métricas do sistema) e user.* (para testes, etc.) e deixaram todo o resto para os desenvolvedores determinarem os nomes das métricas que desejavam usar.
Além do planejamento de capacidade e solução de problemas, o Booking.com usa o Graphite para "correlacionar as tendências de negócios com as tendências de sistema, rede e nível de aplicativo". Eles usam o Grafana como front-end para visualização.