@torresdyl
2018-02-23T19:15:57.000000Z
字数 3444
阅读 1493
storm
kafka
Hola a todos.
Sobre los pasos de test y despliegue, existen unos pasos a seguir.
Botón derecho sobre el pom.xml, ejecutar este comando de Maven:
assembly:assembly
para generar el JAR sin dependencia de Apache Storm y con los ficheros de configuraciones extraídos aparte (log4j2.xml
y radius.cfg
), porque ahora la aplicación prioriza los ficheros externos a los dentro del JAR; lo pongo así para facilitar el mantenimiento.
Se va a generar 3 JARs y dos ficheros de configuración. Lo que necesitamos es StormRadius-exclude-storm.jar
.
Antes de arrancar la aplicación, tiene que comprobar el estado de zookeeper y kafka.
ZooKeeper está en la máquina de Control (192.168.104.196
). Ahora está arrancado como un servicio. Verifica con:
systemctl status zookeeper
O:
ps aux | grep zoo
Luego, tenemos que ir a la máquina de proxy (192.168.104.197
). Aquí está el servicio de servidor de kafka
y se tiene que arrancar el conector de fichero de Kafka.
systemctl status kafka
, o ps aux | grep server
. Si no está arrancado, tiene que systemctl start kafka
.ps aux | grep standalone
. Nota: el conector "standalone" no se tiene que arrancar como servicio porque no hay manera de parar el servicio(falta ExecStop
para ejecutar). Es mejor ejecutarlo manualmente:
cd /opt/kafka
bin/connect-standalone.sh config/connect-standalone.properties config/connect-file-source.properties
Si quieres, también puedes redirigir la salida de consola y los errores a un fichero con añadir esta parte al final del comando de arriba: > /opt/kafka/logs/producer-file.log 2>&1 &
Subir el JAR y los ficheros de config a la máquina de process (192.168.104.198
), en la ruta:
/opt/StormRadius/
Arrancar storm con:
storm jar StormRadius-exclude-storm.jar <nombre_completo_de_la_clase_principal>
El nombre completo de la clase principal depende. Si arrancamos la parte de radius, es:
es.acuntia.storm.radius.topology.AcustatsTopology
En caso de Apache, es:
es.acuntia.storm.apache.topology.ApacheTopology
Si queremos probar radius, tenemos que arrancar el generador de log de radius en la máquina de proxy.
cd /opt/radiusApp
java RadiusSimulator 10 10 0 5 real.log
para generar las líneas de log en /opt/radiusApp/real.log
.
Si lo que arrancamos es apache, simplemente echo
líneas de log al fichero:
cd /opt/radiusApp
echo "......." >> real.log
(reutilizamos este fichero real.log
para las dos cosas, y el tópico es el mismo, para no cambiar las cosas todo el rato)
Importante: resetear el offsets de Kafka producer
El fichero
/opt/kafka/config/connect-file-source.properties
incluye la definición del fichero de origin y el tópico a escuchar cuando se lanza el productor de Kafka File Connector.
...
file=/opt/radiusApp/real.log
topic=apache <o radius>
...
Si arrancamos desde la clase principal de radius, tenemos que tener en cuenta de que el generador de log de radius limpia el fichero cada vez que lo ejecutamos. En otra palabra, la posición de lectura/escritura se resetea a 0 en cada ejecución. Pero, Kafka gestiona la posición, o, el dicho "offset", en un fichero, y siempre lee las líneas nuevas desde la posición de "offset". En
radius.cfg
he puesto:
# 1: from beginning 0: from lastest
KAFKA_FROM_BEGINNING=0
Lo configuro así, porque si ponemos
1
, va a intentar a leer desde el principio infinitas veces. Por lo cual es mejor no leer desde el principio.
Por eso, tenemos que resetear el offset cada vez que arrancamos el simulador de log.
Se observa que en el fichero/opt/kafka/config/connect-standalone.properties
, existe una claveoffset.storage.file.filename=/tmp/connect.offsets
que define dónde guardar el offset. Simplemente borrarlo va a resetear el offset a 0.
rm -rf /tmp/connect.offsets
Y luego, rearrancar
- el jar de storm,
- elconnect-standalone.sh
,
- y el generador de log, en este orden.