.png)
Gostaria de usar grafite para coletar métricas de diferentes servidores. Por padrão, o carbono escuta 2003 em todas as interfaces, o que é bom para mim.
Agora, qualquer um poderia, teoricamente, enviar dados métricos para lá. Existe uma maneira padrão de evitar que isso aconteça (semelhante a http base auth ) ou preciso mexer nas restrições baseadas em IP na interface física?
Responder1
Depende de quanto você deseja "endurecer" qualquer nó de grafite ("Grafite" sendo qualquer topologia de mistura de relés de carbono, caches de carbono, back-end de armazenamento e, potencialmente, web/api de grafite).
Se você sabe quais hosts em sua rededeveAo enviar métricas para o Graphite (normalmente retransmissões), você pode modificar as regras de firewall do host Graphite para esperar uma lista explícita de IPs de host ou um intervalo para as portas aplicáveis. Ou você poderia fazer algo semelhante na rede de borda do firewall ou roteador - não tenho nenhum conselho, pois sua pergunta não fornece um escopo mais completo da aparência da sua topologia.
Uma abordagem alternativa seria usar o suporte AMQP para que seus nós publicassem suas métricas para um corretor como um usuário autenticado e, em seguida, fazer com que seu (s) host (s) Graphite modificassem o firewall do host para aceitar apenas o TCP 2003 das métricas do corretor que estão sendo recebidas. A vantagem aqui são seus nós de grafiteapenasprecisa saber de quais métricas do corretor virão, o que simplifica drasticamente quaisquer regras de firewall do host. Fazer com que os nós publiquem métricas por meio de um serviço leve protege as coisas um pouco melhor, pois a preocupação de "confiança" que você tem é resolvida no topo do fluxo, em vez da eventualidade de métricas - legítimas ou não - chegarem ao (s) seu (s) host (s) Graphite ). RabbitMQ é OSS e muito simples de instalar e usar, sem precisar mexer muito na configuração, se você usar o plug-in de gerenciamento. A maior parte de sua configuração está abrindo portas necessárias para operação.
No entanto, isso torna um editor de métrica simples para a topologia do Graphite um pouco mais complexo para a tarefa e estabelece firmemente um modelo pub/sub de como suas métricas chegam ao Graphite (mas vem com um bom benefício colateral de permitir que as métricas em trânsito não sejam perdido potencialmente). Ele também adiciona outro host para proteger por motivos operacionais.
Para ir mais longe, você poderia implementar um sistema de monitoramento de log para observar o arquivo listener.log do carbon-relay, pois ele escreverá uma linha para cada métrica recebida e processada. Em um nível alto, você observaria esse log em busca de exceções às métricas esperadas. Por exemplo, se você tivesse uma métrica server.cpu.load, esperaria vê-los sendo processados, mas uma métrica postada chamada foo.bar.value não é válida. Como resposta a tal evento, você pode simplesmente limpar o diretório correspondente que o Whisper cria para o namespace inválido (se você usar o Whisper para armazenamento).
O relé de carbono e o cache de carbono do Hardening Graphite são bons e uma coisa inteligente de se fazer, mas não se esqueça que é igualmente preocupante.Quempode acessar seu webapp Graphite ou API de grafite para obter essas métricas.