Català   English  

Diferencia entre revisiones de «SNPServices»

De Guifi.net - Wiki Hispano

(Actualizar traducciones)
Línea 385: Línea 385:
 
He aprendido la causas aquí: http://www.webhostingtalk.com/showthread.php?t=950165
 
He aprendido la causas aquí: http://www.webhostingtalk.com/showthread.php?t=950165
  
−
=== Migración de un servidor a otro ===
 
−
Si quieres migrar un servidor de gráficas a otro servidor manteniendo las gráficas es tan simple como configurar el snpservices con el mismo ID que el antiguo y copiar los ficheros .rrd de ''/var/lib/snpservices/rrdb'' de la máquian vieja a la nueva.
 
  
−
Si la máquina nueva funciona con una arquitectura (por ejemplo, antes 32bits y ahora 64bits), los ficheros .rrd deben ser reconvertidos. Para ello hay que convertir el .rrd a XML y volver a crear el fichero .rrd a partir del XML.
 
  
−
En la máquina de 32bits ejecutamos esto:
+
Si durant la migració al nou servidor s'ha canviat -respecte l'antic- l'adreça IP, el número de node, etc. cal actualitzar el servei a la pàgina corresponent de [http://www.guifi.net].
−
:rrdtool dump fichero_32bits_.rrd > fichero.xml
+
  
−
Copiamos el fichero a la nueva máquina de 64bits y ejecutamos:
+
=== Migración del servicio SNPServices a otra máquina ===
 +
 
 +
El servicio SNPServices almacena datos históricos de los nodos que monitoriza. A la hora de migrar el servicio a otra máquina (por ejemplo, o una nueva) es conveniente mantener este histórico de gráficos, en vez de comenzar desde cero. Para hacerlo correctamente hay que seguir los siguientes pasos:
 +
 
 +
* Instalar el servicio SNPServices en el nuevo servidor. Se recomienda utilizar la distribución [[Cloudy]], que automatiza el proceso y permite hacerlo a través del navegador web.
 +
* Copiar la carpeta /var/lib/snpservices/rrdb (donde se guardan los datos históicos) del servidor antiguo al nuevo. Una vez copiada hay que asegurarse de que la carpeta pertenece al usuario del servidor web, con el siguiente comando:
 +
:chown -R www-data:www-data /var/lib/snpservices
 +
* Configurar el SNPServices del servidor nuevo utilizando el mismo identificador de servicio (ID) que tenía el servidor antiguo.
 +
* Parar el servidor antiguo. Al cabo de unos minutos el servidor nuevo ya estará monitorizando los nodos y generando las gráficas.
 +
 
 +
==== Migración entre diferentes arquitecturas ====
 +
 
 +
Si la máquina nueva usa una arquitectura distinta a la antigua (por ejemplo, ahora 64 bits y antes 32) los ficheros .rrd deben ser convertidos. Para ello hay que transformar los ficheros .rrd al formato XML y, luego, devolverlos al formato .rrd. Para ello, habrá que seguir los pasos anteriores, añadiendo lo siguiente:
 +
 
 +
* En la máquina antigua, antes de copiar la carpeta /var/lib/snpservices/rrdb, ejecutar:
 +
:rrdtool dump fichero.rrd > fichero.xml
 +
* Luego, tras copiar la carpeta al nuevo servidor, ejecutar:
 
:rrdtool restore fichero.xml
 
:rrdtool restore fichero.xml
  
−
Y queda generado el fichero .rrd
+
Y el fichero .rrd resultante quedará convertido al formato correcto.
  
 
== Véase también ==
 
== Véase también ==

Revisión de 18:42 14 oct 2015

SNPServices es un servicio de gráficas.

El sistema de monitorización de la red se realiza mediante 3 sistemas principales. El esquema general se puede consultar en Monitor.

Configuración de servidor Cliente SNPServices

El cliente SNPServices recoge información de su red mas cercana. La almacena y se la entrega al servidor web en modo de gráficas que incrusta en el entorno de guifi.net. Esta configuración es la que realizaras si quieres servir gráficos a la zona donde estas. Es muy probable que lo montes en el servidor proxy que tengáis, pero podría ser dedicado. El procedimiento lo encontrarás aquí http://es.wiki.guifi.net/wiki/Servidor_de_gr%C3%A1ficas

Servidor WEB

El servidor web de guifi, única ente que accede a las bases de datos del sistema. Para montar un servicio WEB idéntico a www.guifi.net, o sea, un entorno de desarrollo se realiza mediante este procedimiento: Preparando el entorno de desarrollo.

Configuración de servidor MASTER SNPServices

Este servicio solo es alcanzable desde el cliente SNPServices. Solo existe un servicio como este y esta en la central de GUIFI.NET. Desde aquí se crea el archivo CNML que se lo cede a los clientes SNPServices. Esta información se necesita para que los servicios SNPServices locales hagan sus comprobaciones de los sistemas cercanos. Básicamente SNPServices sirve recopilar información general de la red que esta en la BBDD de GUIFI. Cuando un cliente SNPServices le pide información de su red, el servidor se la concede en formato CNML.

Instalacion del servicio SNPServices mediante GIT

Nota: Este método de instalación depende de que el repositorio esté actualizado y a fecha de 07/11/2012 no lo está. 
Me ha sido mas fácil la instalación mediante apt-get install.

El servicio SNPServices Master y Cliente se instala del mismo modo. La diferencia entre ambos es que usan procedimientos diferentes en la ejecución de sus tareas. También alguno común.

Para instalarlo se hace así:

  1. Nos creamos una cuenta en el repositorio Gitorious
  2. Clonamos el servicio snpservices para poder enviar nuestras mejoras
  3. Lo descargamos 
cd /var/www/html
git clone git://gitorious.org/guifi/snpservices.git

También se puede descargar mediante repositorio. Véase Configurar Repositorio apt guifi.

Una vez configurado el repositorio, descargamos servicio. 

# apt-get install snpservices

Si quieres instalar el servicio SNPServices para servir gráficas sigue los pasos aquí: Servidor de gráficas.

A partir de ahora configuraremos el servicio SNPServices Master para servir datos a los clientes SNPServices.

Configuración del servicio SNPServices Master

Se crea un alias que apunte a nuestra carpeta donde hemos instalado el servicio 

 Alias /snpservices /var/www/html/snpservices

Creas la carpeta /tmp y le das permisos de escritura 

mkdir /tmp
chmod a+rw snpservices/tmp

Crea el servicio en la base de datos usando esta dirección 

http://yourserver/snpservices

te saldrá una pagina así: 

ERROR: No service specified
CNML services
Version: 2.0
USAGE:
index.php?call=[service][&parameter[=value]]

services: help version phpinfo serverinfo [service]
  help
...sigue...

si fueras un cliente, el procedimiento continua cambiando el servidor root al que te conectas modificando el archivo /common/config.php. Es por esto que nos sale el error "ERROR: No service specified", pero en este caso nosotros somos el root y aquí tenemos que poner uno que representa al servidor web. Para guifi tenemos un valor reservado. Si quieres contactar con el servidor root, debes de pedirlo en los foros abiertos en las listas de desarrollo. Para cualquier entorno podría valer con poner otro servidor de gráficas.

Tenemos un archivo llamado common/config.php.template que nos servirá de plantilla.

Configuración del archivo config.php

Aquí se configura el directorio raiz del servicio SNP. Esta variable es usada en varios sitios. 

<?php

// snp_pat: full directory where snp services are located
$snp_path='/var/www/html/snpservices';

Este es el numero de nodo que nos ha dado el servidor web al crear el servicio SNP Cliente: 

// SNPGraphServerID: Default Graph Server ID
$SNPGraphServerId = 6579;

Servicio root. El root de nuestro servidor guifi actual es la pagina web www.guifi.net: 

// rootZone: which is the ROOT zone
$rootZone = ****; (valor reservado por seguridad)

Aquí la dirección desde donde se enlaza a los servicios mediante web. Esta variable es usada en varios archivos de configuración: 

// SNPDataServer_url: without ending backslash, the url where the data is
$SNPDataServer_url = 'http://guifi.net';

Configuración del servicio MRTG creador de gráficas. Aquí le diremos donde almacenar los datos. Tienes que crear el directorio mrtg en /snpservices/mrtg: 


// MRTGConfigSource: mrtg csv data
// As a input, could be either a local (to be created from
// cached CNML file, or remote

El programa cnml2mrtfcsv es el servicio SNPService principal y busca en la BBDD del servidor web los cambios que han habido. Si ha cambiado algo desde la ultima actualización, genera de nuevo el archivo CNML. Se tiene que modificar a la ruta que tengamos nosotros, normalmente dentro de ./graphs 

$MRTGConfigSource='http://proves.elserrat.guifi.net/snpservices/graphs/cnml2mrtgcsv.php';

Aquí almacenamos los datos mrtg que recojamos. La carpeta data no esta creada por defecto. La tenemos que crear mediante mkdir data desde el directorio snpservice: 

//$MRTGConfigSource='../data/guifi_mrtg.csv';

Configuración para la creación de archivo CNML: 


// CNMLSource: url for CNML node query, use sprintf syntax
// MySQL-drupal source
//$CNMLSource='http://proves.elserrat.guifi.net/guifi/cnml/%s/node';
// Cached CNML source (prefered)

Aquí almacenamos los datos CNML que recojamos: 

$CNMLSource='http://proves.elserrat.guifi.net/snpservices/common/qnodes.php?nodes=%s';
$CNMLData='../data/guifi.cnml';

Configuración de herramienta rrdtool. transforma tdatos en archivos .rrd para poder ser exportados. No hace falta hacer nada aquí. 


// rrdtool parameters
$rrdtool_path='/usr/bin/rrdtool';
$rrddb_path='/home1/comesfa/mrtg/logs/';
$rrdimg_path='/home1/comesfa/mrtg/images/';

// which version does have this server? 
// currently supported versions are:
// 1.2
// 1.3
$rrdtool_version = "1.3";

Configuración de entorno MRTG. No hace falta hacer nada aquí. 


// mrtg local header
$rrdtool_header='# PathAdd: /usr/local/rrdtool-1.2.12/bin
# LibAdd: /usr/local/rrdtool-1.2.12/lib/perl/5.8.8/i386-linux-thread-multi
HtmlDir: %s
ImageDir: %s 
LogDir: %s
LogFormat: rrdtool
ThreshDir: %s
Forks: 12
';

// mrtg ping template
$mrtg_ping_template ='Title[%s_ping]: Temps del ping de %s 
PageTop[%s_ping]: <H1>Latència %s</H1>
     <TABLE
     <TR><TD>System:</TD>     <TD>%s</TD></TR>
     <TR><TD>Maintainer:</TD> <TD>guifi@guifi.net</TD></TR>
     <TR><TD>Description:</TD><TD>ping</TD></TR>
     <TR><TD>IP:</TD>         <TD>%s</TD></TR>
     </TABLE>
Target[%s_ping]: `/etc/mrtg/ping.sh %s`
MaxBytes[%s_ping]: 2000
Options[%s_ping]: growright,unknaszero,nopercent,gauge
LegendI[%s_ping]: Perduts %
LegendO[%s_ping]: Temps mig
Legend1[%s_ping]: Temps max. en ms
Legend2[%s_ping]: Temps min. en ms
YLegend[%s_ping]: RTT (ms)
';

$mrtg_traffic_template='Target[%s_traf]: %s:public@%s:
SetEnv[%s_traf]: MRTG_INT_IP="%s" MRTG_INT_DESCR="%s"
MaxBytes[%s_traf]: 104857600
Title[%s_traf]: Trànsit a %s de %s
PageTop[%s_traf]: <H1>Trànsit a %s de %s</H1>
     <TABLE>
     <TR><TD>System:</TD>     <TD>%s</TD></TR>
     <TR><TD>Maintainer:</TD> <TD>guifi@guifi.net</TD></TR>
     <TR><TD>Description:</TD><TD>%s</TD></TR>
     <TR><TD>Max Speed:</TD>  <TD>100.0 Mbytes/s</TD></TR>
     </TABLE>
';


?>

Arrancamos y actualizamos datos

Para arrancar y actualizar datos se hace mediante un comando llamado refresh.sh. Más adelante configuraremos para que refresque solo. Primero lo ejecutaremos manualmente.

Lo he arrancado y me da el siguiente error: 

root@webserver:/var/www/guifi/snpservices/common# ./refresh.sh 
Getting CNML file
Error redaing CNML source\nroot

Esto es porque no hay configurado algún parámetro. Entramos en refresh.sh y este nos envia a refresh.cnml.php.

refress.sh llama a dos archivos php. 

root@webserver:/var/www/guifi/snpservices/common# cat refresh.sh 
#!/bin/bash
# Refreshing CNML local file (optional)
php refresh_cnml.php

Configurar refresh.cnml.php

Veamos ahora el archivo de configuracion refresh.cnml.php

Si queremos ejecutar este archivo lo hacemos mediante la llamada a php. Aquí vemos que error genera y podremos ir a ver donde está ocurriendo.

Este es el archivo. Primero carga una configuración común en el archivo config.php. Sino busca la plantilla config.php.template: 

<?php

  if (file_exists("config.php")) {
    include_once("./config.php");
  } else {
    include_once("config.php.template");
  }

  $minX = 999;
  $minY = 999;
  $maxX = -999;
  $maxY = -999;

  $members = array();

Intenta abrir archivo ya creado. Tenemos que modificar la ruta donde almacena esta informacion. Compara la fecha de actualización anterior y la actual para decidir si hacer un refresco completo o no. si todo esta actualizado, ejecuta exit() y acaba. 

  $hlastnow = @fopen($SNPDataServer_url."/guifi/refresh/cnml", "r")
    or die('Error reading last timestamp\n');
  $last_now = fgets($hlastnow);
  fclose($hlastnow);

  $hlast= @fopen("/tmp/last_update.cnml", "r");
  if (($hlast) and ($last_now == fgets($hlast))) {
    fclose($hlast);
    echo "No changes.\n";
    exit();

Si está mal configurado estos parámetros, tendremos el siguiente error: 

root@webserver:/var/www/guifi/snpservices/common# php refresh_cnml.php 
Getting CNML file
Error reading last timestamp
root@webserver:/var/www/guifi/snpservices/common#

Aquí es cuando empieza la búsqueda de cambios.

El primer open abre un archivo de la web con los contenidos. Éstos son comparados con el archivo que tenemos en /tmp. Si son diferentes, realiza una descarga y lo actualiza. 

echo "Getting CNML file\n";
  $hcnml = @fopen($SNPDataServer_url."/guifi/cnml/".$rootZone."/detail", "r")
    or die ('Error redaing CNML source\n');
  $wcnml = @fopen("../data/guifi.cnml.tmp", "w");
  while (!feof($hcnml)) {
    $buffer = fgets($hcnml, 4096);
    fwrite($wcnml,$buffer);
  }
  fclose($hcnml);
  fclose($wcnml);
  exec ("/bin/cp ../data/guifi.cnml.tmp ../data/guifi.cnml");

  $hlast= @fopen("/tmp/last_update.cnml", "w") or die('Error!');
  fwrite($hlast,$last_now);
  fclose($hlast);
?>
                  
  }

Si esta mal configurado, recibiremos este error. Tambien puede identificar falta de recursos para Apache. Mira el log de Apache: 

root@webserver:/var/www/guifi/snpservices/common# php refresh_cnml.php 
Getting CNML file
Error redaing CNML source\n
root@webserver:/var/www/guifi/snpservices[Sat May 22 00:39:01 2010] [notice] child pid 14787 exit signal Segmentation fault (11)/common#

El sistema dentro de la web que crea el archivo CNML es un proceso de un modulo de Drupal del sistema guifi. Lo encontraras en /sites/all/modules/guifi/guifi_cnml.inc.php.

Ahora tenemos dentro de /data dos archivos iguales llamados guifi.cnml y guifi.cnml.tmp con los contenidos encontrados. También actualiza datos en /tmp/last_update.cnml que se usara nuevamente en la próxima actualización.

Prueba de servicio

Un cliente con servicio SNPService usará el servicio SNPService Master recien creado para preguntar información acerca un nodo de esta manera: 

http://www.guifi.net/snpservices/graphs/cnml2mrtgcsv.php?server=6558

Esto nos devuelve un archivo CNML como este: 

46491,#VicPuigsacalm2Rd1,10.138.48.51,wlan1;VicVcPgsclm2Rd1CPE0,Planned
38297,#VicCnvntCrmltsRd1,10.138.160.39,ath0;Vic-1-NOVcCnvntCrmltsRd1CPE0,Working
45489,#Vic11Set38Rd1,10.138.168.170,wlan1;Vic-1-NOVc11St38Rd1CPE0,Planned
44406,#Vic11set40Rd2,10.138.101.4,ath0;Vic-1-NO11st40Rd2CPE0,Working
33929,#Vic11setembre25Rd1,10.138.22.87,wifi0;Vic-1-NOVc11stmbr25Rd1CPE0,Working
18809,#VicAGrifollRd2,10.138.14.104,6,Working
40356,#VicAlbergCanongeRd2,10.138.10.80,Lan/Lan;Vic-1-NOVclbrgCnngRd2CPE0,Working
22068,#VicAlemanyRd1,10.138.14.135,wifi0;Vic-1 NOVclmnyRd1CPE0,Working
30303,#VicAlemanyRd2,10.138.14.201,wifi0;Vic-1 NOVclmnyRd2CPE0,Planned
36620,#VicAlinaRd2,10.138.10.72,wlan1;Vic-1-NOVclnRd2CPE0,Working
7211,#VicAngladaRd1,10.138.10.73,Lan/Lan;VicAngladaRadio1-0,Working
19857,#VicAnnaBRd2,10.138.11.62,wifi0;VicVcnnBRd2CPE0,Working
14203,#VicAnnaMaxenchsRd1,10.138.22.41,wifi0;VicVcnnMxnchsRd1CPE0,Working
13655,#VicAnnaPratRd1,10.138.11.51,;VicVcnnPrtRd2CPE0,Working
17035,#VicAnnaSolerRd3,10.138.22.196,6,Working

La configuración puede que no funcione. Para ver errores, pedir a apache que nos muestre su log: 

root@webserver:~# tail -f /var/log/apache2/*.log

Yo me he encotnrado este error: 

[Mon Oct 22 23:27:07 2012] [error] [client 192.168.1.40] PHP Warning:  DOMDocument::load(): 
Premature end of data in tag html line 3 in /var/www/drupal-6.26/snpservices/data/guifi.cnml, line: 149 in /var/www/drupal-6.26/snpservices/graphs/cnml2mrtgcsv.php on line 270

También este. Parece que al intentar cargar la zona, da un error Apache a causa de falta de memoria al cargar todos los datos en una variable. Para solucionarlo se tiene que modificar el límite de memoria para php dentro de /etc/php5/apache/php.ini. La variable se llama memory_limit = 128M. Si lo pones a -1 equivale a que no tenga limite [1]. 

==> /var/log/apache2/error.log <==
[Tue Oct 23 20:54:16 2012] [error] [client 192.168.1.44] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20 bytes) in /var/www/drupal-6.26/includes/database.mysqli.inc on line 150

De todas maneras, los recursos son limitados. Este mensaje en Apache identifica lo msimo. Falta de recursos. En mi caso, como no tengo más, hago una consulta mas pequeña para poder probar el error que me salía es este: 

[Sat May 22 00:39:01 2010] [notice] child pid 14787 exit signal Segmentation fault (11)

He aprendido la causas aquí: http://www.webhostingtalk.com/showthread.php?t=950165


Si durant la migració al nou servidor s'ha canviat -respecte l'antic- l'adreça IP, el número de node, etc. cal actualitzar el servei a la pàgina corresponent de [2].

Migración del servicio SNPServices a otra máquina

El servicio SNPServices almacena datos históricos de los nodos que monitoriza. A la hora de migrar el servicio a otra máquina (por ejemplo, o una nueva) es conveniente mantener este histórico de gráficos, en vez de comenzar desde cero. Para hacerlo correctamente hay que seguir los siguientes pasos:

  • Instalar el servicio SNPServices en el nuevo servidor. Se recomienda utilizar la distribución Cloudy, que automatiza el proceso y permite hacerlo a través del navegador web.
  • Copiar la carpeta /var/lib/snpservices/rrdb (donde se guardan los datos históicos) del servidor antiguo al nuevo. Una vez copiada hay que asegurarse de que la carpeta pertenece al usuario del servidor web, con el siguiente comando:
chown -R www-data:www-data /var/lib/snpservices
  • Configurar el SNPServices del servidor nuevo utilizando el mismo identificador de servicio (ID) que tenía el servidor antiguo.
  • Parar el servidor antiguo. Al cabo de unos minutos el servidor nuevo ya estará monitorizando los nodos y generando las gráficas.

Migración entre diferentes arquitecturas

Si la máquina nueva usa una arquitectura distinta a la antigua (por ejemplo, ahora 64 bits y antes 32) los ficheros .rrd deben ser convertidos. Para ello hay que transformar los ficheros .rrd al formato XML y, luego, devolverlos al formato .rrd. Para ello, habrá que seguir los pasos anteriores, añadiendo lo siguiente:

  • En la máquina antigua, antes de copiar la carpeta /var/lib/snpservices/rrdb, ejecutar:
rrdtool dump fichero.rrd > fichero.xml
  • Luego, tras copiar la carpeta al nuevo servidor, ejecutar:
rrdtool restore fichero.xml

Y el fichero .rrd resultante quedará convertido al formato correcto.

Véase también

Obtenido de «http://es.wiki.guifi.net/w/index.php?title=SNPServices&oldid=4247»
Herramientas personales