.png)
Me gustaría utilizar grafito para recopilar métricas de diferentes servidores. De forma predeterminada, Carbon escucha en 2003 en todas las interfaces, lo cual me parece bien.
Ahora, en teoría, cualquiera podría enviar datos métricos allí. ¿Existe una forma estándar de evitar que esto suceda (similar a http base auth) o necesito modificar las restricciones basadas en IP en la interfaz física?
Respuesta1
Depende de cuánto desee "endurecer" los nodos de grafito ("Grafito" es cualquier topología mixta de relés de carbono, cachés de carbono, backend de almacenamiento y, potencialmente, red de grafito/api).
Si sabe qué hosts en su reddeberíaAl enviar métricas a Graphite (normalmente retransmisiones), puede modificar las reglas de firewall de su host Graphite para esperar una lista explícita de IP de host o un rango para los puertos aplicables. O podría hacer algo similar en la red perimetral desde el firewall o el enrutador; no tengo ningún consejo al respecto, ya que su pregunta no brinda un alcance más completo de cómo se ve su topología.
Un enfoque alternativo sería utilizar el soporte AMQP para que sus nodos publiquen sus métricas a un corredor como un usuario autenticado y luego hacer que sus hosts Graphite modifiquen el firewall del host para aceptar solo TCP 2003 de las métricas del corredor que se reciben. Lo bueno aquí son sus nodos GraphitesoloNecesita saber de qué métricas del corredor le llegarán, lo que simplifica drásticamente las reglas del firewall del host. Hacer que los nodos publiquen métricas a través de un servicio liviano asegura las cosas un poco mejor, ya que la preocupación de "confianza" que tiene se soluciona en la parte superior del flujo en lugar de la eventualidad de que las métricas, legítimas o no, lleguen a sus hosts Graphite. ). RabbitMQ es OSS y es bastante sencillo de poner en marcha sin necesidad de complicarse demasiado con la configuración si utiliza el complemento de administración. La mayor parte de su configuración abre los puertos necesarios para su funcionamiento.
Sin embargo, esto hace que un editor de métricas simple para la topología de Graphite sea un poco más complejo para la tarea y establece firmemente un modelo de publicación/subscripción sobre cómo llegan sus métricas a Graphite (pero tiene el beneficio adicional de permitir que las métricas en tránsito no se publiquen). perdido potencialmente). También agrega otro host para asegurar dentro de las razones operativas.
Para ir mucho más allá, podría implementar un sistema de monitoreo de registros para observar el archivo listening.log de carbon-relay, ya que escribirá una línea para cada métrica recibida y procesada. En un nivel alto, observarías ese registro en busca de excepciones a las métricas que esperas. Por ejemplo, si tiene una métrica server.cpu.load, esperaría que se procesen, pero una métrica publicada llamada foo.bar.value no es válida. Como respuesta a tal evento, simplemente puede borrar el directorio correspondiente que crea Whisper para el espacio de nombres no válido (si usa Whisper para almacenamiento).
Endurecer el relé de carbono y el caché de carbono de Graphite están bien y son algo inteligente, pero no olvides que es igual de preocupanteOMSPuede acceder a su aplicación web Graphite o Graphite-api para obtener esas métricas.