El documento es una presentación de Alejandro E. Brito Monedero sobre su experiencia como sysadmin y devops, centrada en el manejo de crisis en sistemas y las herramientas útiles para la resolución de problemas. Describe diversas técnicas y herramientas técnicas, como strace y sysdig, usadas para diagnosticar problemas en sistemas y aplicaciones, respaldadas por ejemplos de casos reales. Se concluye con lecciones sobre la importancia de mantener la calma y actuar basándose en datos reales en lugar de teorías previas.

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

3. Sobre mi

4. Plan de operaciones
Un poco de teoría aburrida
Loadout
Historias de batallas
Lecciones para llevar
Referencias y créditos
Preguntas

5. Un poco de teoría aburrida

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

9. Un poco de teoría aburrida
Pasar de esto

10. Un poco de teoría aburrida
A esto

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

14. Loadout

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

25. Loadout
strace
strace [-S <sortby>] -c -p <pid>
strace -o <fichero> [-T] [-ff]
[-s <strsize>] [-e <expr>]
-p <pid>

26. Loadout
sysdig
Herramienta de exploración a nivel de
sistema
Es como un tcpdump sobre el flujo de
llamadas a sistema
Extensible con lua

27. Loadout
sysdig
No genera tanto overhead como strace
Crea un módulo para el kernel
No se puede tener más de una instancia en
ejecución

28. Loadout
sysdig
Necesita privilegios de root
Se ha ganado mi <3 por su capacidad de
usar filtros y chisels
Sólo sirve en Linux

29. Loadout
sysdig
sysdig -w <capture file>
[-s <len>] <filtro>
sysdig -r <capture file>
[-c <chisel> <args>]

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, ...

33. Historias de batallas

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

52. Referencias y créditos
http://oi52.tinypic.com/iyodxs.jpg
http://i.giphy.com/fDzM81OYrNjJC.gif
http://i.giphy.com/110VRbH47qa2Jy.gif
http://upload.wikimedia.org/wikipedia/commons/3/3c/Displacement_roll_with_instruct
ion_diagram.PNG
http://upload.wikimedia.org/wikipedia/commons/1/18/AIM-54_6_Pack.jpg
http://i.giphy.com/GlMN2r04gXTgs.gif
https://upload.wikimedia.org/wikipedia/commons/0/00/F-14_VF-
111_launching_Phoenix_1991.jpeg
https://upload.wikimedia.org/wikipedia/commons/d/d3/Rainbow_bug.png
http://upload.wikimedia.org/wikipedia/commons/4/4e/Plaque_Commemorating_Battl
e_of_Harlem_Heights,_near_Riverside_Church.jpg
http://i.giphy.com/6rgpEGDP0Rv3i.gif

53. Preguntas

54. ¡Gracias!