Administro un webservice y es muy importante para mi empresa detectar y avisar si alguno de los servicios está caído, y también si alguna de las operaciones que realiza está tardando en responder. Hasta ahora había una aplicación web separada (incluido el front-end y el backend) solo para solicitar operaciones aleatorias a esos puntos finales cada 15 minutos, pero lo encontré complicado ya que requiere mantener una aplicación web completa solo para este propósito, y conozco muchos servicios web gratuitos. eso debería hacer el trabajo.
Configuré AWS Healthchecks para reemplazar la aplicación web de sondeo y funciona perfecto para la parte del tiempo de actividad, ahora mi pregunta viene con la parte del tiempo de respuesta.
Todos esos servicios API de verificación de estado parecen estar preparados para solicitudes no muy complejas, por lo que debería ser responsabilidad de la API ofrecer un punto final de "estado" para los servicios de verificación de salud e incluir en ese estado "OK" cosas como la latencia de la base de datos o debería ser el "verificador de salud". "¿El responsable de realizar solicitudes complejas? ¿Qué enfoque es más correcto?
¡Gracias!
Respuesta1
Probablemente no debería monitorear el rendimiento de la base de datos a través de las rutas de verificación de estado de la aplicación; pueden ocurrir algunos casos peligrosos. Supongamos que utiliza ASG dentro de AWS y utiliza las comprobaciones de estado de LB para determinar si el ASG debe rotar las máquinas. Si comienza a tener contención en la base de datos (no relacionada con su aplicación), su ASG comenzará a eliminar nodos. Por lo tanto, no sólo tendrá una base de datos de bajo rendimiento, sino que también tendrá un ASG agotado.
Normalmente, el rendimiento debe controlarse fuera del rango de salubridad. Usamos mucho statsd y agregamos todas nuestras métricas, aplicaciones y bases de datos para que podamos graficar y alertar en base a eso.
También tenga en cuenta que a medida que escala, la velocidad de su verificación de estado también aumentará: tenemos algunos servicios que reciben miles de solicitudes de verificación de estado por segundo, y si cada una de ellas realiza una consulta sintética costosa, nuestra capa de datos se desconectaría. .
La lógica también se vuelve más compleja a medida que agrega capas de almacenamiento en caché: ¿qué debería devolver el punto final de verificación de estado si la base de datos está en buen estado pero su caché KV no?
En general, si bien el monitoreo de extremo a extremo es fundamental para una estrategia de monitoreo efectiva, recomiendo encarecidamente el monitoreo fuera de banda para las métricas de consulta existentes que fluyen a la base de datos; son representativas del rendimiento real del usuario y le proporcionarán una métrica cuantificable para cómo se está desempeñando realmente el estado de su aplicación.