Reparar todas las tablas de MySQL en un sistema Vicidial

28 Nov

El domingo pasado recibí el correo de un cliente: su sistema de marcación predictiva con vicidial había tenido fallas eléctricas durante el fin de semana, ocasionando que las tablas de MySQL se corrompieran y que el sistema quedara inservible (al menos lo relacionado con la marcación predictiva).

Tras cerca de una hora reparé todas las tablas usando unos comandos simples como los que siguen:

/etc/init.d/mysql stop
cd /var/lib/mysql/asterisk
myisamchk -r *.MYI
/etc/init.d/mysql start

Sin embargo, me percaté que al hacer esto, estaba solo reparando las tablas una por una. El sistema tenía 4 núcleos, por lo que era posible hacer mucho más trabajo al mismo tiempo (4 tareas a la vez) en vez de ir una por una.

El sistema terminó de manera habitual tras el paso de 1 1/2 hrs. Para evitar que tanto tiempo se perdiera en nuevas ocasiones, decidí crear un script en bash que reparara todas las tablas de manera simultánea (limitándose a 1 proceso por cada núcleo del sistema), y me quedó el código así:

#!/bin/bash

# Editar estos valores:
## CORES 		debe ser igual al número de núcleos en el sistema 
##				(revisar el comando "cat /proc/cpuinfo")
## MYSQLDBDIR	debe ser igual a la carpeta de MySQL que contiene la BD
##				que debamos reparar (default: "/var/lib/mysql/asterisk")

CORES=4
MYSQLDBDIR=/var/lib/mysql/asterisk

# Enlistar los archivos
FILES=`ls $MYSQLDBDIR/*.MYI`
RUNS=0
for i in $FILES
do
	SALIR=0
	while [ $SALIR -eq 0 ]
	do
		# Obtener la cantidad de procesos en el sistema
		PROCS=`ps -eF|grep myisamchk|egrep -v "grep"|wc -l`

		# Ejecutamos el while los procesos activos sean menor a CORES
		if [ $CORES -gt $PROCS ]
		then
			echo `date +"%X"` Revisando/Reparando tabla $i
			myisamchk -r $i &
			# Descansamos 1 segundo
			sleep 1
			SALIR=1
		else
			# Esperamos 3 segundos
			sleep 3
		fi
	done

done

# Ya se terminaron de correr todas las instrucciones de reparación,
# pero existe la posibilidad de que algunas de ellas aún estén ejecutándose.
# Revisamos para ver si hay procesos corriendo y avisar al usuario
while [ $SALIR -eq 0 ]
do
	# Obtener la cantidad de procesos en el sistema
	PROCS=`ps -eF|grep myisamchk|egrep -v "grep"|wc -l`
	if [ $PROCS -gt 0 ]
	then
		echo `date +"%X"` Hay $PROCS procesos corriendo. Esperando 10s...
		sleep 10
	else
		echo "No hay procesos corriendo"
		SALIR=1
	fi
done
echo `date +"%X"` Fin. Ya puedes reiniciar MySQL

Los siguientes pasos son algo obvios:

  1. Hay que guardar este script como un archivo checar.sh
  2. Editamos el archivo y cambiamos el número de cores de nuestro sistema, así como la ubicación de la carpeta de MySQL que contiene los archivos de la BD
  3. Darle permisos de ejecución (chmod 755 checar.sh)
  4. Ejecutarlo: ./checar.sh
El script correrá varios procesos en paralelo para revisar cada uno una tabla. Mientras más núcleos tenga nuestro procesador, más rápido el script aprovechará los recursos para crear la reparación.
Espero les sirva.
¡Suerte!

 

Advertencia: Aunque este script puede ayudarnos a reparar nuestras tablas en caso de algún problema (falla eléctrica, corrupción del sistema de archivos, fallo en el disco duro, etc) no hay nada más seguro que respaldar nuestra información periódicamente. Siempre ten a la mano copias de seguridad de aquella información crítica, ya que no podemos hacernos responsables por la pérdida de información causada por el mal uso de las directivas que se muestran en este artículo. Úsalo bajo tu propio riesgo.

Como agregar contextos personalizados en todos los servidores de un cluster con Vicidial

13 Oct

Hoy me di a la tarea de implementar un plan de llamadas personalizado en un cluster de Vicidial: mi cliente no quería que existiera la posibilidad de que los agentes marcaran manualmente desde su X-Lite, y al tratarse de un entorno de múltiples servidores, a la larga resultaría complicado mantener por separado cada uno de los archivos extensions.conf de los servidores.

¿Cuál es entonces la mejor manera para crear contextos de plan de llamadas que aparezcan en TODOS los servidores instalados en un cluster de Vicidial sin tener el problema de replicar manualmente los cambios?

La respuesta viene con las últimas versiones de Vici (2.2+) ya que bajo Admin -> System settings viene un espacio interesante donde podemos agregar planes de llamadas personalizados: el Custom Dialplan Entry.

Custom Dialplan Entry para Vicidial

Sin embargo, hay un problema, y es que todo lo colocado en esta caja se escribe dentro del contexto [vicidial-auto], por lo que si decidimos ingresar contextos por separado, romperiamos la funcionalidad del plan de llamadas automático de Vici, pero el truco es más sencillo de lo que se cree. Solo tenemos que iniciar y terminar nuestro bloque con las siguientes líneas:

[codesyntax lang=»bash»]

include => vicidial-auto2

; Este es mi contexto personalizado
[agentes]
exten => _ZXXX,1,Dial(SIP/${EXTEN})
; Fin de mi contexto personalizado

[vicidial-auto2]

[/codesyntax]

¿Qué logramos hacer con esto? Hacemos que nuestro cluster genere todos los contextos personalizados que metamos en medio de nuestras lineas, pero además, no rompemos la funcionalidad de Vici porque la línea de include => vicidial-auto2 hace que la inclusión del contexto [vicidial-auto2] sea transparente, de manera que no rompemos ninguna de las funcionalidades del sistema, y evitamos tener que administrar una linea de comandos para que la exportación de la configuración sea más transparente.

Este truco me sacó de un problema que sé que a la larga, se habría perdido el control de la administración tarde o temprano.

¡Suerte!

6 razones por las cuales tu campaña en Vicidial podría no funcionar

28 Sep

Como se ha visto, recientemente hemos tenido mucho movimiento sobre Vicidial, que es una suite open source para instalar un callcenter completo sobre Linux. Pues bien, es bastante común que dado lo complejo que resulta este sistema cometamos errores y que por lo tanto nuestras campañas de marcación predictiva no saquen llamadas al exterior. Aquí recopilo algunos de los errores más comunes al momento de hacer marcación predictiva hacia el exterior:

  • Las campañas tienen el horario incorrecto. Muchas veces, las pruebas las hacemos en las noches y movemos la hora de las llamadas para entender por que no salen. Primer paso: asegurémonos de que la hora de la campaña sea la correcta y que estemos haciendo pruebas dentro del horario REAL en que se supone que nuestras campañas deben de correr.
  • No hay leads disponibles para marcar. Asegurémonos que las listas que tenemos dadas de alta para nuestra campaña tengan leads con los status de marcación válidos. Normalmente, marcamos a los NEW (nuevos leads), NA (No Answer) y B (Busy). Si nuestra lista está llena de leads que no tienen estos status, no se marcará hacia ellos. Agreguemos los nuevos status que queramos dentro de la campaña para ser válidos de remarcarles o bien, importemos nuevos leads para reintentar la operación.
  • No hay leads en el hopper. Si mandamos llamadas demasiado rápido o tenemos muchos agentes, lo más probable es que nos agotemos el hopper realmente rápido. Lo ideal es que nuestro hopper level (a nivel de campaña) esté ubicado en al menos 2.5 veces el número de agentes que podemos tener en línea en un momento dado. Este error es fácil de encontrar ya que nos aparecen indicaciones al hacer login como agente, asi que no debería ser problema localizar de que se trata.
  • Las llamadas no están saliendo a pesar de tener agentes en línea. Esto me pasó recientemente: todos los problemas de arriba habían sido verificados, pero había 5 agentes en línea y ninguno recibía llamadas. El problema fue de que tenía yo creada una campaña de marcación automática con agentes remotos (para enviar mensajes pre-grabados) y esto ocasionó que nos termináramos la cantidad de troncales disponibles para marcar al exterior (aunque nunca se usaron). Moraleja: asegúrate que bajo System Settings, el valor de Max Vicidial Trunks sea más grande que la cantidad total de agentes que tengas en un momento dado, y en caso de que así sea, asegúrate de no tener agentes remotos activos que tengan múltiples lineas de salida activadas. Al parecer, Vicidial reserva lineas aún para los agentes remotos que no las están usando.
  • Las llamadas no enlazan: dan un timeout y la interfaz de agente se queda esperando en estado «ringing». Comúnmente es ocasionado por enlaces digitales que NO son ISDN, como R2 modificado. Algunos proveedores dan mensajes grabados en early media audio dando grabaciones como «el número que marcó no existe». Normalmente, una persona escucharía esto y sabría que hacer, pero un sistema piensa que la llamada nunca se contestó y por lo tanto, ocurre un timeout porque 1) nunca obtuvimos ring y 2) nunca nos contestaron. La única solución es cambiar de enlace o cambiar a marcación manual, de manera que nuestros agentes puedan catalogar por ellos mismos el estado de las llamadas.
  • Las llamadas se cortan a los pocos segundos y nunca se enlazan a los agentes. Descubrí que si en la marcación automática haces un ANSWER antes de enviar un DIAL (es decir, sin un ringing de por medio), Vicidial nunca te enlaza las llamadas y te las marca como NA (No Answer). Lo correcto es que siempre debe haber un ringing antes de que la llamada sea contestada. Con eso evitarás que se marque pero nunca comunique a los agentes.

Como siempre, habrá muchas otras cosas que puedan pasar, pero en este caso estas son las más comunes. Conforme nuestra experiencia vaya aumentando, iremos ampliando la lista.

¡Suerte!

Terminado el curso de Vicidial

12 Sep

Durante los últimos 4 días estuve en Tampa, FL tomando un curso acerca de Vicidial, una suite open source con marcador predictivo para call centers basados en Asterisk. El curso fue impartido por Matt Florell, el creador del software, y durante las horas que estuvimos en el salón de clases pude aprender y corroborar muchos detalles interesantes sobre este sistema que aunque lleva varios años en el mercado, pocos se han dado a la tarea de conocerlo.

El curso se divide en 2 partes: el Manager y el Admin. Durante el curso de Manager se da una explicación a detalle de como utilizar la interfaz web de Vicidial: como se crean campañas de entrada y salida, como se cargan registros, como se configuran carriers para enviar las llamadas, como podemos controlar la distribución de llamadas entre los agentes, etc. Todas y cada una de las opciones de las más de 200+ que hay para alterar en la suite fueron vistas y explicadas. A pesar de que en la interfaz web es posible leer la documentación HTML que viene con el software, muchas veces las cosas no se comprenden tan bien como cuando puedes debatirlas, y este fue uno de los casos. Inclusive las explicaciones ayudaron a visualizar escenarios que no habiamos contemplado, pero que pueden resultar muy útiles para cualquier callcenter.

En la segunda parte del curso se vieron detalles mucho más técnicos: como instalar el sistema, como hacer troubleshooting, cuales son las causas comunes de que un sistema de estos falle (el famoso time synchronization error o el there are no available sessions), así como muchas otras características avanzadas que el mortal promedio no ocupa, como el uso de los APIs, la captura extendida de números telefónicos, etc. Al final terminamos con una instalación de Vicidial en cluster (lo que ofrece máxima escalabilidad al sistema) y corrimos pruebas de rendimiento para comprobar que todo estuviera bien y supiéramos hasta donde podemos llegar con él. En general, un curso muy teórico y con mucha información. Debo reconocer que mis favoritos fueron los últimos dos días, pues fue cuando realmente tuve oportunidad de jugar con el sistema.

Vicidial hoy en día es un producto que deja muy por atrás a toda la competencia, tanto en funcionalidades como en precio. Aquellos que han probado el módulo de callcenter de Elastix puedo decirles fácilmente que no tiene nada que ver con Vicidial: Elastix fue pensado como un PBX para empresa, no como medios para un callcenter, y Vici está muy por encima en funcionalidades. ¿Acaso el precio podría hacer la diferencia? No, porque es el mismo que con el resto del open source: ¡gratis!, así que tampoco es necesaria una inversión millonaria en sistemas como Avaya o Cisco que a pesar de ser propietarias, se quedan cortos en características.

En mi opinión personal, el único problema que le veo a un software como Vici es precisamente su mayor fortaleza: el grado de complejidad que tiene lo hace para alguien sin conocimientos resulte una tarea muy complicada el tratar de echar a andar una campaña con él. Sin embargo, una vez que se libra esa curva de aprendizaje, los que ahora lo conocemos sabemos que es bastante sencillo de ocupar, y que pueden hacerse cosas geniales con él. Repetiré lo que les digo a mis alumnos del curso de Asterisk: el límite de lo que puedes hacer, es la capacidad del administrador.

Para más información sobre este software, visiten vicidial.org. Si requierieras apoyo profesional para una implementación de Vicidial para un callcenter, por favor utiliza nuestro formulario de contacto.

¡Suerte!