Charla dada en el Codemotion España que se celebró en Madrid el 21 y 22 /11/2014
Como tiene gifs animado, es recomendable descargar la presentación
Trata sobre el uso de herramientas de sistemas para hacer debugging
1. Top Bug
Codemotion Madrid España 2014
Alejandro E. Brito Monedero - @ae_bm
2. Sobre mi
Trabajo como sysadmin / devops / SRE / lector
de mensajes de error / título tonto aquí
Miembro de Madrid DevOps, Postgres España,
Python Madrid y muchos más meetups de los
que puedo asistir
Más info en http://bit.ly/1sT7bLw
Charla inspirada por
http://youtu.be/UxFq16IG_k0
6. Un poco de teoría aburrida
¿Por qué?
Hay que saber como actuar para cuando
lleguen las crisis. Si, llegarán
Si vis pacem, para bellum
7. Un poco de teoría aburrida
¿Qué hacer? / ¿Qué hago?
Mantener la calma
No caer en el quedar inmóvil / huir
Evitar ser trigger happy / disparar primero y
preguntar después
8. Un poco de teoría aburrida
¿Qué hacer? / ¿Qué hago?
Mantener la calma
No caer en el quedar inmóvil / huir
Evitar ser trigger happy / disparar primero y
preguntar después
11. Un poco de teoría aburrida
¿Cómo? / El arma secreta
El método científico
Descripción del problema
Hipótesis
Predicción
Prueba (experimental / observacional)
Análisis
12. Un poco de teoría aburrida
¿Cómo? / El arma secreta
Una técnica que uso para formular hipótesis
es pensar en como puede estar
implementado el sistema o como yo lo
hubiera implementado
13. Un poco de teoría aburrida
Uno de los principales obstáculos
El efecto observador / heisenbugs
15. Loadout
Código fuente
La fuente última (no pun intended)
A veces es tan feo o complejo que es
preferible estar abordo del Event Horizon,
puede ser como estar en la dimensión de los
cenobites
Se puede usar la técnica del print
16. Loadout
Logs
Según como estén, si es que están, pueden
ser un valioso aliado
Dependen del equipo de desarrollo, ¡sí tu!
No el de atrás
¡Nada como los stacktraces! Nadie nunca ha
dicho esto
17. Loadout
Estado general del sistema
htop: Top pero más bonito / ajustable
atop: Sirve para capturar a esos procesos
de muy corta duración
vmstat: Ver casi todo el estado del sistema
iotop: Como top pero para el IO
sar: Información de actividad del sistema
18. Loadout
lsof
Siglas de list open files
Todo (casi) en unix es un fichero
Al saber que ficheros tiene abiertos un
proceso se puede ver si escribe en algún log
o si tiene conexiones de red, en este
apartado también se podría usar ss o
netstat
19. Loadout
lsof
También sirve para saber que procesos tienen
directorios o ficheros abiertos
lsof -n -p <pid>
lsof <fichero>
lsof +D <directorio>
lsof -n -i 4TCP@<ip>:<puerto>
20. Loadout
Tcpdump / tshark / wireshark
Las herramientas para saber que pasa en la
red
El antídoto contra la gente que no
documenta sus APIs
21. Loadout
Tcpdump / tshark / wireshark
No sirve con SSL a menos que se tenga la
llave privada y no se este usando perfect
forward secrecy. También se puede usar un
proxy que haga de MITM o quitar / degradar
SSL
22. Loadout
Tcpdump / tshark / wireshark
En la máquina siendo analizada (a veces
puede ser util usar la opción -B
tcpdump -n -p -i <iface> -s 0
-w <capture file> <pcap filter>
En la máquina desde la que se hace el
análisis
wireshark <capture file>
23. Loadout
strace
Para cuando se entra en territorios hostiles
Para hacer tracing de llamadas al sistema y
señales
Existe una versión para hacer tracing a nivel
de la biblioteca de C llamada ltrace
24. Loadout
strace
Puede hacer tracing sobre procesos hijos del
proceso estudiado
Permite ver el tiempo que tardan las
llamadas al sistema
Pero el proceso siendo estudiado se ejecuta
más lento
30. Loadout
Escribir tus propias herramientas
Quitarse el trabajo manual
Procesar de maneras no imaginadas la data
que ya tenemos
31. Loadout
Herramientas para gente grande
Implica saber más de sistemas operativos
Por ahora no he sentido la necesidad de
usarlas más allá que para pruebas
Por ejemplo: dtrace, SystemTap, ftrace, ...
34. Historias de batallas
Caso 1
Postfix no inicia
/var/log/mail.log sólo muestra 'ERROR'
Por experiencia sabemos que muchos
errores son problemas de permisos
Sabemos que postfix está dividido en
múltiples procesos
35. Historias de batallas
Caso 1
Para descartar el problema de los permisos
usamos strace
Cambiamos el script de inicio para que llame
a postfix con la opción -ff
Revisamos los ficheros que creó strace
buscando las llamadas al sistema que no
terminaron correctamente
36. Historias de batallas
Caso 1
Encontramos una llamada a open que
referencia a un fichero dentro de
/var/spool/postfix falló por un problema de
permisos
Comparamos los atributos del fichero en una
máquina que no presenta el problema
Tiene permisos distintos
37. Historias de batallas
Caso 1
Cambiamos los permisos para que sean
iguales que en el sistema control
Postfix inicia correctamente
38. Historias de batallas
Caso 2
La aplicación X no funciona
Nadie sabe donde guarda los logs
Sabemos que el log puede ser una conexión
a algo como syslog o un fichero
Nada que haga referencia a la aplicación
en /var/log
39. Historias de batallas
Caso 2
No saben que es syslog
Sabemos que la aplicación esta programada
en un lenguaje interpretado
Con pgrep buscamos procesos con el
interprete que se está utilizando
Con el PID listamos con lsof los ficheros que
tiene abierto el proceso
40. Historias de batallas
Caso 2
Conseguimos que el log estaba
guardándose en /tmp
El log indica cual es el problema con la
aplicación
41. Historias de batallas
Caso 3
Una aplicación web tiene un performance de
pena
El sistema recibe peticiones HTTP, revisa en
una BD y publica mensajes en un broker
Los desarrolladores piden más HW y
máquinas, culpan al broker de ser un cuello
de botella
42. Historias de batallas
Caso 3
Hay otra aplicación que usa el broker y no va
tan lento, descartamos esa opción
Sabemos por experiencia que usualmente la
gente no sabe usar las BBDD
Pensamos que seria interesante saber que
queries se están enviando a la BD
43. Historias de batallas
Caso 3
Revisar las queries desde la BD es
complicado dado el despliegue actual
Desde el frontal web lanzamos tcpdump para
capturar el tráfico de la app a la BD
Con wireshark revisamos la captura y vemos
muchas queries a las tablas del schema
44. Historias de batallas
Caso 3
Comentamos al equipo de desarrollo que el
ORM sux
Cambian la configuración del ORM para que
no haga siempre las consultas al esquema
El desempeño de la aplicación se multiplica
por 10 sin agregar más HW o máquinas
45. Historias de batallas
Caso 4
La aplicación web no sirve los ficheros que
se le piden
¿Por qué esto no lo hace el servidor web si
están en el filesystem?
Los ficheros están en el filesystem pero la
aplicación web no los encuentra
46. Historias de batallas
Caso 4
Hay que averiguar donde la app esta
buscando
Es engorroso usar strace en aplicaciones
donde los procesos son creados y destruidos
de forma continua
sysdig permite filtrar eventos por nombre de
proceso y por acción
47. Historias de batallas
Caso 4
Usamos sysdig con un filtro que sólo vea los
eventos de filesystem generados por los
procesos X, que hayan tenido errores y cuyo
nombre de fichero sea similar a Y
48. Historias de batallas
Caso 4
Revisamos la captura y vemos que la app
buscaba el nombre del fichero solicitado
agregándole parámetros al nombre
Se elimina el bug
49. Lecciones para llevar
Las herramientas vienen y van, lo importante
es el plan de acción, el mindset:
“Es un error capital teorizar antes de tener
datos. Sin darse cuenta, uno empieza a
deformar los hechos para que se adapten a
las teorías, en lugar de adaptar las teorías a
los hechos” Sherlock Holmes - Arthur Conan
Doyle
50. Lecciones para llevar
Mantener la cabeza fría
No olvidar el principio de presunción de
inocencia
Usar la imaginación para saber como puede
estar hecho el sistema
Es bueno saber “un poco” de sistemas
operativos y de la arquitectura de la aplicación
51. Referencias y créditos
Man 2 <syscall>
Internets
Brendan Gregg
http://www.brendangregg.com/index.html
@brendangregg
http://goo.gl/DDfgGq
http://goo.gl/I1XKzU