Feda /dev/ - No Javascript allowed | Página 1986

Kaledros #59551 2h

#59550 ¿Y para qué necesitas saber que el servicio A ha recibido un error cuando sólo necesitas saber que se ha lanzado en el servicio C? ¿Y si el servicio C lo que hace es broadcastear un mensaje faulty y hace que diecisiete servicios lancen error de parsing? Todo eso es ruido.

1 respuesta

wdaoajw #59552 1h

#59551 porque al final el servicio A lanza un error. Un error provocado por el servicio C, pero un error.

Si tú tienes un SLO en el servicio A y tu servicio lanza errores te come el error budget igualmente por mucho que "la culpa" no era tuya. Que sea ruido o no es relativo y dependerá de muchas cosas, ese error puede ser mitigado? Si el servicio C falla podemos activar un killswitch con un workaround?

Al final, si tu cliente te consume a ti, y le tiras un error en la cara, el no sabe si es por A por B o por C, pero te aseguro que TU deberías querer saber si le estás tirando errores a tus clientes

4 1 respuesta

Lifecasi0 #59553 1h

Estoy de acuerdo con wdaoakw. Nunca hay que silenciar errores en el downstream, la monitorización se nos va, los SLOs dejan de tener sentido, y es una mala practica.

JuAn4k4 #59554 1h

#59536 cada servicio monitorizacion independiente y desde su punto de vista.

Kaledros #59555 1h

#59552 Vale, lo he dicho mal, he hablado de loggear cuando me refería a lanzar alertas. Obviamente un servicio debe loggear que ha recibido un error, pero lanzar una alerta por cada sitio por donde pasa el error es lo que me parece que confunde y da problemas a la hora de identificarlo.

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales