4 votos

¿Qué parámetros debo vigilar al monitorizar un servidor?

Vi un montón de herramientas de monitoreo y sobre todo mostrar lo mismo. Pero me pregunto si es realmente necesario ver todas estas cosas.

Me gustaría saber qué métricas importan por ejemplo un servidor web que se ejecutan principalmente un sitio web, con PHP-FPM, Nginx y MySQL.

Y también, estoy mirando en gráficos, pero ¿cómo entenderlos y analizarlos para evitar cualquier falla futura?

5voto

Ryan Sampson Puntos 2898

Las métricas que importan son aquellos que:

  • Indicar un problema con el correcto y adecuado funcionamiento de los servicios que se proporcionan; o
  • Indicar la causa root de un problema

¿Qué métricas de materia para usted depende de lo que el juez, en su opinión profesional, a las métricas que mejor modo de cumplir con los dos criterios. Si usted no tiene la experiencia para ser capaz de juzgar con precisión que antes, así que... sí. La recolección de más datos que nunca necesitará es mejor que no la recogida de unos datos que usted necesite más adelante. (La advertencia de que no es que si la supervisión está empezando a interferir con el funcionamiento eficiente del servicio, usted puede ser que necesite que lo baje un poco, o para optimizar la recopilación de estadísticas).

Si estás buscando un atajo respuesta, me temo que no tiene uno, usted está en una empinada curva de aprendizaje que habla al corazón de lo que significa ser un sysadmin. Si estás en una situación en la que en algún tiempo de inactividad no importa, ¡genial! usted tiene una gran oportunidad de aprendizaje. Si usted va a terminar encima de conseguir demandado o ir a la quiebra si este servicio no se ejecuta a la perfección, es posible que desee encontrar a alguien con más experiencia para darle uno a uno de orientación y tutoría.

3voto

Doug Sillars Puntos 11

Sólo me escribió y publicó una guía sobre este tema:

Permítanme resumir aquí: Hay 3 principales objetivos a pensar cuando la supervisión de cualquier tipo de sistema de producción:

  1. Identificar tantos problemas como sea posible;
  2. Identificar los problemas tan pronto como sea posible; y
  3. Generar como pocas falsas alarmas como sea posible (es decir, el establecimiento adecuado de alertas)

Y de que quieres hacer esto mediante la selección de métricas en la siguiente marco:

  1. Vigilar Posibles Malas Cosas (cosas que podrían ir mal - esto es a menudo en la forma de las cosas que llenan / ejecutar -- es decir, de memoria, de disco, ancho de banda)
  2. Monitor de Real Bad Things (cosas que hacer ir mal a pesar de sus mejores esfuerzos)
  3. Monitor de Cosas Buenas (o la falta de ella - prestar atención a las cosas que usted quiere que suceda y establecer una alerta cuando se producen con menos frecuencia
  4. Ajustar y Mejorar (de lo contrario corres el riesgo de "alerta de fatiga", alias el DevOps equivalente de "crying wolf")

Cada implementación va a ser un poco diferente, así que la YMMV, pero este es el marco que la gran cantidad de profesionales experimentados utilizar para pensar acerca de las cosas (ya sean explícitas o no).

[Editar de la divulgación: estoy afiliado con Scalyr, una empresa que participa en este espacio, y el enlace de arriba es publicado en su sitio]

1voto

öde Puntos 142

La más básica es la de mantener un ojo en la cantidad de carga de la CPU, la memoria libre y de intercambio, espacio en disco, e/S de disco y de red/ancho de banda de I/O. Esto se puede hacer uso de herramientas como el munin o collectd. Algunas personas, como para controlar un montón de cosas, pero si se mantiene simple, al menos, se puede obtener una imagen global. También le recomendamos que configure el seguimiento de herramientas para enviar alertas por correo electrónico cuando las cosas empiezan a ir mal (es decir, el uso de "umbrales" o similar).

Otra cosa muy útil es mantener un ojo en el más importante de los registros del servidor para cualquier cosa inusual, es decir, mensajes de error o tal vez incluso advertencias. Pero ese tipo de mensajes pueden ser muy comunes, dependiendo de cómo los distintos programas están configurados para iniciar sesión. Generalmente, los demonios tiene un archivo de configuración donde se puede cambiar el "LogLevel" de error (=de registro sólo cuando algo está roto) para depurar (=log a nada). Compruebe que los demonios que se ejecuta en el servidor y cambiar el registro de los niveles de error o de advertencia. A continuación, puede instalar un archivo de registro de la herramienta de análisis tales como OSSEC y entrenar para estar en silencio cuando ciertas cosas son aceptables, mientras que debe de alerta cuando las cosas se rompen. Estas alertas pueden ser enviadas a través de correo electrónico a usted.

Por su servicios específicos Nginx y Mysql, te recomiendo que controle su tiempo de respuesta. Esto es bueno por dos razones: si usted no recibe una respuesta, algo que está roto. Y si usted consigue una respuesta que indica una inusualmente alto tiempo de respuesta - sobre todo si no es temporal, pero durante un período de decir un par de minutos o de horas, a continuación, el servicio está luchando.

0voto

Bittrance Puntos 1926

Recomiendo que echa un vistazo a estancada. Puede configurarse para registrar numerosas mediciones en RRD-archivos para su posterior análisis. Se requiere muy poca CPU y le ayudará a entender cómo su rendimiento cambia con la carga.

No he encontrado una herramienta realmente impresionante realmente dibujar gráficos de RRDs generados, pero a menos que quiera proyectar en realime, usando rrdgraph en línea de comandos suele ser bastante periódicamente cheque para grandes cambios.

0voto

Tilendor Puntos 9622

Excelentes consejos anteriores. Pero si usted realmente necesita para empezar, ver los conceptos básicos en un primer momento: el uso de la CPU a través del tiempo, el uso de la memoria a lo largo del tiempo, uso de ancho de banda y uso de espacio en disco (o espacio libre en el disco). Los cuatro son muy comunes debido a que prácticamente define las capacidades de un ordenador.

Una vez que haya supervisado por un tiempo y saber lo 'normal' es para un servidor, usted será capaz de detectar cuando algo es anormal. Eso es cuando usted está listo para comenzar a cavar más profundo para averiguar el "por qué" - que requerirá más específica de supervisión :)

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: