En el editor vi, el comando Shift+J permite unir la línea en la que se encuentra el cursor con la línea siguiente. Pero además, formatea el resultado eliminando todos los espacios al comienzo de la segunda línea, y añadiendo un espacio de separación entre ambas.
En este artículo se explica el procedimiento para cargar en un índice solr un fichero que contiene un conjunto de documentos en formato XML. Para ello utilizaremos la utilidad Logstash, que forma parte del paquete SiLK de análisis de ficheros de log.
La manera más sencilla de comprobar si alguna de las tablas de una base de datos necesita ser reparada es utilizar el comando mysqldump con la opción “–no-data” para realizar un volcado de la estructura de la base de datos:
Casi todos los sistemas tienen un teclado que incluye una tecla “Impr Pant” (o “PrtScr”) que permite copiar al portapapeles una captura de pantalla. El contenido del portapapeles se puede pegar posteriormente en cualquier utilidad gráfica como “paint” o “gimp” para proceder a su edición. Pero normalmente esta tecla no funciona en el interior de un sistema operativo cliente ejecutándose dentro de una máquina virtual de VirtualBox, porque la pulsación es interceptada por el sistema operativo anfitrión.
En este artículo se presentan varias posibles alternativas para solventar este problema.
El tamaño de bloque de un sistema de ficheros (filesystem block size) es número mínimo de bytes que son leídos o escritos en el disco cada vez que se realiza una operación de entrada/salida. Este parámetro puede ser relevante a la hora de optimizar el rendimiento de determinadas aplicaciones, como por ejemplo una base de datos.
En este artículo explicamos como determinar este y otros parámetros de un sistema de ficheros en un servidor Linux.
El comportamiento por defecto de la aplicación ant cuando se compila un proyecto Java, es compilar sólamente los ficheros “.java” que han sido modificados. Sin embargo, en ocasiones podemos observar que cada vez que se ejecuta, ant compila todos los ficheros “.java” del proyecto. En este artículo se explica una posible razón de este comportamiento y cómo evitarlo.
Solr es un motor de búsqueda que permite realizar operaciones de búsqueda muy elaboradas sobre conjuntos de documentos. Cada documento de una colección solr es un conjunto de pares (campo,valor). Los documentos pueden ser de distintos tipos, y cada tipo de documento se define como el conjunto de campos que puede contener, y el tipo de datos de cada una de ellos.
Así, en una colección solr que almacenara información sobre libros publicados, cada documento recogería los datos de un determinado libro, y podría incluir campos ‘titulo’, ‘autor’, ‘fecha de publicación’, etc.
En las versiones de solr anteriores a la 4.3, al crear una colección para almacenar determinado tipo de documentos era necesario incluir un fichero de configuración ‘schema.xml’ en el que se definian los nombres de los campos y sus tipos de datos.
A partir de la versión 4.3 se introdujo la posibilidad de crear colecciones con esquema gestionado (“managed schema”), también conocidas como colecciones sin esquema (“schema-less”). En una colección de este tipo, cuando se insertan documentos en una colección, solr añade automáticamente a la configuración de la colección las definiciones de los campos que encuentra, determinando el tipo de datos que contienen a partir de los valores que encuentra en los primeros documentos en los que aparece el nuevo campo.
Esta funcionalidad hace muy sencillo crear una nueva colección a partir de un conjunto de datos de los que no se conoce con exactitud su contenido. Sin embargo, en ocasiones es necesario realizar ajustes a la configuración del esquema elaborado automáticamente. Para ello, hay que convertir la colección “schema-less” a una colección de “esquema clásico”, como se explica en este artículo.
En primer lugar, para obtener el paquete de instalación debemos rellenar el formulario en la página http://lucidworks.com/products/silk/#download_form. Una vez enviado el formulario, recibiremos en la dirección de email que hemos introducido un mensaje con el enlace para la descarga.
El paquete descargado en nuestro caso se llama SiLK-1.5.zip y ocupa 290 Mb
Para realizar la instalación, basta con descomprimir el fichero zip en un directorio de nuestra elección. Una vez descomprimido, podemos ver que el paquete contiene tres directorios, para cada uno de los componentes principales de SiLK:
El motor de búsqueda solr utilizado por SiLK se ejecuta en una máquina virtual Java, por lo que debemos disponer de un entorno de ejecución de Java (JRE) previamente instalado y operativo. Alternativamente podemos instalar el kit de desarrollo de java (JDK), que además del JRE, contiene también un compilador y otras herramientas.
En un sistema Linux Debian, la instalación se puede realizar fácilmente con el comando apt-get:
|
1 2 3 |
# apt-get install default-jdk |
A continuación comprobamos la versión de java instalada con la opción “-version”:
|
1 2 3 4 5 6 |
# java -version java version "1.7.0_85" OpenJDK Runtime Environment (IcedTea 2.6.1) (7u85-2.6.1-6+deb8u1) OpenJDK 64-Bit Server VM (build 24.85-b03, mixed mode) |
El motor de búsqueda solr de ejemplo incluido en el paquete SiLK se ejecuta con los comandos:
|
1 2 3 4 |
$ cd SiLK-1.5/solr-4.10.3/SiLK $ java -jar start.jar |
Con esto, solr comienza a ejecutarse y queda a la espera de conexiones en el puerto 8983. Desde un navegador web, accedemos a la url “http://SERVIDOR:8983/solr”, y accedemos al frontend de solr:
Como podemos ver, la instancia de solr ya contiene la definición de algunas colecciones de ejemplo. Entre ellas:
El componente LogStash de SiLK se encuentra en el directorio “SiLK-1.5/solrWriterForLogStash/logstash_deploy”
Para ejecutar logstash, debemos preparar previamente un fichero de configuración “logstash_apache.conf” con tres secciones: input, filter y output.
En esta sección se indican los ficheros de entrada a logstash.
|
1 2 3 4 5 6 7 8 9 10 11 |
input { file { path => "/path-al-directorio-de-ficheros-de-log/access.log" exclude => ["*.gz","*.zip","*.tgz"] type => "apache-access" sincedb_path => "apachelogs.sincedb" start_position => "beginning" } } |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
filter { grok { type => "apache-access" patterns_dir => "./patterns" # See the following URL for a complete list of named patterns # logstash/grok ships with by default: # https://github.com/logstash/logstash/tree/master/patterns # # The grok filter will use the below pattern and on successful match use # any captured values as new fields in the event. pattern => "%{COMBINEDAPACHELOG}" } if ("_grokparsefailure" in [tags]) { drop{} } date { type => "apache-access" # Try to pull the timestamp from the 'timestamp' field (parsed above with # grok). The apache time format looks like: "18/Aug/2011:05:44:34 -0700" match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ] } mutate{ #timestamp is a field used in LWS. Need to delete it here remove_field => [ "timestamp"] } } |
|
1 2 3 4 5 6 7 8 9 10 11 12 |
output { stdout { debug => true codec => "rubydebug"} lucidworks_solr_lsv133 { collection_host => "localhost" collection_port => "8983" collection_name => "logstash_logs" field_prefix => "event_" force_commit => false flush_size => 100 idle_flush_time => 1 } } |
Con este fichero de configuración, podemos ejecutar logstash con los comandos:
|
1 2 3 4 |
$ cd SiLK-1.5/solrWriterForLogStash/logstash_deploy $ java -jar logstash-1.3.3-flatjar.jar agent -f logstash_apache.conf -p . |
Típicamente, el fichero que se especifica en la sección input del fichero de configuración es un fichero de log de accesos “vivo”, sobre el que apache está registrando las solicitudes de acceso que se van recibiendo. Cuando logstash termina de procesar el contenido del fichero, continúa ejecutándose, y va procesando los nuevos registros conforme apache los va escribiendo en el fichero.
Si lo que queremos es procesar un fichero de log y que logstash finalice su ejecución cuando termine de procesarlo, deberemos cambiar la configuración de la sección input para que los datos a procesar se lean desde stdin:
|
1 2 3 4 5 6 7 |
input { stdin { type => "apache-access" } } |
y ejecutar logstash de la siguiente forma:
|
1 2 3 |
$ java -jar logstash-1.3.3-flatjar.jar agent -f logstash_apache.conf -p . < access.log |
Para acceder a banana, basta con visitar desde un navegador la url:
|
1 2 3 |
http://localhost:8983/banana |
si todo funciona correctamente, veremos el panel de control por defecto “Basic Dashboard with Pointers”:
Si estamos utilizando una instancia de solr que se ejecuta en otro servidor, o en un puerto distinto del puerto por defecto 8983, deberemos editar el fichero de configuración :
|
1 2 3 |
SiLK-1.5/solr-4.10.3/SiLK/banana-webapp/webapp/config.js |
En dicho fichero, deberemos especificar la url de acceso a solr, incluyendo el nombre completo del servidor y el puerto en el que da servicio.
A continuación podemos comenzar a definir y configurar paneles en los que se presentarán de forma gráfica las estadísticas que nos interesa obtener. Para no partir de cero, podemos descargar de github algunos ejemplos.
—
A diferencia de otros lenguajes de programación, como C++ o Java, PHP es un lenguaje interpretado. Esto significa que cada vez que se ejecuta un script escrito en PHP, el intérprete debe convertir las sentencias contenidas en el código fuente del script en sentencias de bajo nivel directamente ejecutables por la máquina.
En el caso de un servidor web, los scripts que generan el código HTML de las páginas que son entregadas a los clientes pueden ser ejecutados cientos o miles de veces cada día. Para evitar que el intérprete tenga que ejecutarse cada vez, es habitual implementar un mecanismo por el cual el opcode generado la primera vez que se invoca al script se guarda, y es reutilizado en sucesivas ejecuciones del mismo script.
Hasta la versión 5.4 de PHP, este mecanismo de cache estaba implementado por distintas extensiones, de entre las cuales la más popular es probablemente APC (Alternate oPcode Cache). La versión 5.5 de PHP incluye en la distribución base el “Zen opcode cache”, que sustituye a la extensión APC.
En este artículo se exponen las características de esta nueva implementación, y la manera de configurarla.
La distribución base del intérprete PHP incluye un función json_decode que hace muy sencillo el proceso de ficheros en formato JSON. Pero esta función trabaja sobre un string que debe haber sido completamente en memoria. Esto puede ser un problema si se trabaja con ficheros de varios cientos de megabytes, o incluso de más de un gigabyte, como es el caso en determinados escenarios (por ejemplo, cuando se procesan datos geográficos en formato GeoJSON). En este artículo se explica el uso de una librería “jsonstreamingparser” para PHP, que permite procesar los objetos contenidos en el fichero conforme se van leyendo, evitando un consumo excesivo de los recursos de memoria disponibles. Seguir leyendo »