Pandora FMS
Manual Administrador
Monitorización Oracle en entornos Unix
Manual Administrador Monitorización Oracle en entornos Unix
© Artica Soluciones Tecnológicas 2005­2012
Índice de contenido...
1 HISTÓRICO DE CAMBIOS
Fecha Autor Cambio Versión
29/09/11 Juanma Primera versión v1r1
13/12/11 Juanma Nueva funcionalidad...
2 INTRODUCCIÓN
Este documento tiene como objetivo la descripción de la monitorización de sistemas Oracle basados 
en   Uni...
eventos) o de tipo numérico (para hacer gestión del rendimiento). 
3 MATRIZ DE COMPATIBILIDAD 
La matriz de compatibilidad...
4 DOCUMENTACIÓN A ENTREGAR POR EL ÁREA QUE REQUIERE LA 
MONITORIZACIÓN.
Para la correcta monitorización de Oracle es neces...
5 MÓDULOS DEL PLUGIN 
El plugin monitoriza “por defecto” los siguientes puntos:
• Escaneo de tablespace para obtener espac...
• Enqueue waits
• Free buffer waits
NOTA: Conviene destacar que si la base de datos a monitorizar no tiene configurada alg...
abortará la monitorización. Estas condiciones son a dos niveles:
• A nivel general: Se verificará acceso al fichero de con...
5.3.3. “Saltar” comprobaciones por defecto.
Se pueden "saltar" las comprobaciones por defecto usando el token de configura...
Esto definirá el nombre del listener, en este ejemplo “LISTENER_RHGE0208”. Debe ser el nombre 
exacto del listener que que...
Para esto se cuenta con los siguientes tokens: sid, only_sid y skip_sid.  
5.3.6.1. Monitorización de un SID específico (s...
3. skip_sid
5.3.7. Monitorización de volúmenes de disco de una instancia
El sistema intentará “autodetectar” los volúmenes...
5.3.10. Credenciales de acceso
Necesarias para usar el plugin. 
user sys
password pandoraA01 AS SYSDBA
Nota: el uso de con...
select round ((ficheros_act/ficheros_max)*100) ratio 
from (select count(*) ficheros_act from dba_data_files), 
(select va...
5.3.14. Creación de módulos manuales para los logs
Dado que el módulo de log de errores no reporta información hasta que n...
Las condiciones de disparo son especiales, ya que nos interesará tener un timethreshold corto, por si 
llegan más eventos,...
6 REQUISITOS
Los requisitos para que funcione correctamente esta monitorización son los siguientes:
• Instalar el agente d...
• El usuario que ejecuta el agente de Pandora FMS debe pertenecer al grupo de explotación de 
la base de datos para poder ...
7 INSTALACIÓN
Copiar el plugin al directorio de plugins del agente, o distribuirlo con file collections. Lo mismo con 
el ...
8 USO CON POLÍTICAS
El uso de este scripts con políticas es sencillo, se basa en hacer una política que contenga el plugin...
Próxima SlideShare
Cargando en…5
×

Pandora FMS: Plugin enterprise de Oracle

446 visualizaciones

Publicado el

Se trata de un plugin enterprise que permite monitorizar bases de datos de Oracle. Con este plugin se pueden monitorizar todas las bases de datos en general o seleccionando una por instancia. Para más información visite la siguiente pagina web: http://pandorafms.com/index.php?sec=Library&sec2=repository&lng=es&action=view_PUI&id_PUI=272

Publicado en: Tecnología
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
446
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
11
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Pandora FMS: Plugin enterprise de Oracle

  1. 1. Pandora FMS Manual Administrador Monitorización Oracle en entornos Unix
  2. 2. Manual Administrador Monitorización Oracle en entornos Unix © Artica Soluciones Tecnológicas 2005­2012 Índice de contenido 1Histórico de cambios..........................................................................................................................3 2Introducción........................................................................................................................................4 3Matriz de compatibilidad ...................................................................................................................5 4Documentación a entregar por el Área que requiere la monitorización.............................................6 5Módulos del plugin ............................................................................................................................7 5.1.Monitorización multiinstancia...................................................................................................8 5.2.Pre-condiciones automáticas a la monitorización......................................................................8 5.3.Parametrización del plugin........................................................................................................9 5.3.1.Localización del fichero oratab..........................................................................................9 5.3.2.Log de información y errores.............................................................................................9 5.3.3.“Saltar” comprobaciones por defecto..............................................................................10 5.3.4.Bloque de configuración de una instancia.......................................................................10 5.3.4.1.Configuración del listener y servicios......................................................................10 5.3.4.2.Precondiciones a la monitorización..........................................................................11 5.3.5.Reinicio del listener.........................................................................................................11 5.3.6.Monitorización de SID específicos..................................................................................11 5.3.6.1.Monitorización de un SID específico (sid)...............................................................12 5.3.6.2.Monitorización de SID específicos (only_sid).........................................................12 5.3.6.3.Monitorización de SID específicos (skip_sid).........................................................12 5.3.6.4.Asignación de estos tokens ......................................................................................12 5.3.7.Monitorización de volúmenes de disco de una instancia.................................................13
  3. 3. 1 HISTÓRICO DE CAMBIOS Fecha Autor Cambio Versión 29/09/11 Juanma Primera versión v1r1 13/12/11 Juanma Nueva funcionalidad v1r4 22/12/11 Juanma Nueva funcionalidad v1r5 13/03/12 Juanma Nueva funcionalidad v1r7 18/06/12 Juanma Nuevos módulos v2r1 25/07/12 Juanma Nueva funcionalidad v2r2 17/09/13 Mario P Cambio en código v2r3 Page 3
  4. 4. 2 INTRODUCCIÓN Este documento tiene como objetivo la descripción de la monitorización de sistemas Oracle basados  en   Unix.   Se   han   elegido   una   serie   de   módulos   “base”   en   base   a   nuestra   experiencia   en  monitorización de sistemas y las necesidades de algunos de nuestros clientes.   También se han  añadido todas las especificaciones recogidas en diferentes entornos de producción real, tomando  especificaciones reales de administradores de bases de datos. Para la extracción de la información  se  utiliza: • Un fichero de configuración externo donde se define toda la parametrización del plugin.  Este fichero de configuración puede hacer llamadas (includes) a otros ficheros. • Un fichero de variables de entorno parametrizado por instacia. Este fichero se encuentra en  el directorio $ORACLE_HOME/dbs/orauser_$SID.  • Se utiliza el software ya instalado en el sistema (SQLplus, lsnrctl, ficheros de alertas de  Oracle, etc), para la monitorización realizada por el plugin sin tener que instalar librerías o  utilidades de terceros. Opcionalmente se podrá usar el fichero ORATAB si no se configuran  las instancias a monitorizar directamente en el fichero de configuración del plugin. • Se utiliza un parser de log existente (el de pandora) para procesar los logs de alertas de  Oracle. El patrón a buscar se podrá parametrizar mediante un  token  en el fichero de  configuración del plugin. La detección de los ficheros de log de alertas  será automática para  cada instancia. • Se realiza una autodetección de SID, instancias y tablespaces en el sistema, aunque se puede  suprimir, y/o forzar SID concretos por parte del administrador, configurando diferentes  tokens en el fichero de configuración del plugin. • Se realizan una serie de chequeos básicos “por defecto”, aunque se pueden suprimir o  personalizar. • Se dispone de una interfaz “abierta” para especificar consultas SQL libres, permitiendo  modelar todo tipo de consultas SQL que se realizan con otras herramientas o de forma  manual por los administradores.  Se proveen algunas consultas habitualmente usadas por  administradores en todo el mundo, y que ofrecen información importante de rendimiento. • El sistema se integra con el agente Unix y con la capacidad de distribuir colecciones de  ficheros, de forma que se puede distribuir el plugin por un lado y las colecciones de ficheros  de forma individual ­por agente­ y/o por política. Cabe destacar que como el resto de monitorización con Pandora FMS, el plugin de monitorización  Oracle se puede usar para recoger información de tipo “cadena de texto” (para tratarlo como  Page 4
  5. 5. eventos) o de tipo numérico (para hacer gestión del rendimiento).  3 MATRIZ DE COMPATIBILIDAD  La matriz de compatibilidad para el plugin se muestra a continuación: Sistemas donde se ha probado • Solaris 10 Sparc, Oracle 11g • Linux RHEL 5, Oracle 10.x y Oracle 11.x Sistemas donde debería funcionar • Solaris 10 Sparc o superior, Oracle 11g o  superior • Linux RHEL 5 o superior, Oracle 10.x,  Oracle 11.x o superior Page 5
  6. 6. 4 DOCUMENTACIÓN A ENTREGAR POR EL ÁREA QUE REQUIERE LA  MONITORIZACIÓN. Para la correcta monitorización de Oracle es necesario que el Área técnica envíe cierta información  que será incluida en los ficheros de configuración. Esta información es la siguiente: • Usuario y password con acceso al motor Oracle vía SQLplus. Dicho usuario debe tener  permiso para leer en todas las tablas del sistema (ver punto siguiente) y estar en el grupo de  sistema de Oracle. • Nombre de la instancia de la BBDD (Oracle SID). • En   caso   de   utilizarse   el   fichero   ORATAB:   Verificar   que   existe   un   fichero  /var/opt/oracle/oratab (o en otra ruta como /etc/oratab)  correcto y con los paths y SID  correctos. • Si desea monitorizar algún otro componente que no venga definida “por defecto” será  necesario que provea el código SQL para realizar esa monitorización, así como un ejemplo  del dato de salida, especificando si es numérico, o tipo cadena, etc). • Si la variables de entorno de DBA (como el PATH a los binarios SQLplus y lsnrctl) no estan  exportadas como variables de entorno el plugin requerirá acceso al fichero de variables de  entorno $ORACLE_HOME/dbs/orauser_$ORACLE_SID de cada instancia y por último se  podrá indicar explícitamente en el fichero de configuración del plugin. Page 6
  7. 7. 5 MÓDULOS DEL PLUGIN  El plugin monitoriza “por defecto” los siguientes puntos: • Escaneo de tablespace para obtener espacio libre. • Escaneo de tablespace para obtener estado . • Escaneo de filesystems de Oracle montados sobre el sistema (en base a un prefijo y al  nombre de la instancia (SID). • Verificación de conexión a la BD (mediante una query (Select) y obteniendo una fecha). • Verificación de servicios dado un listener (solo a nivel de instancia). • Verificación de proceso Pmon de cada SID . • Verificación del estado general del listener (para todas las instancias). • Parseo de errores buscando una expresión regular en el log de alertas. El log de alertas  depende de cada instancia, y su ubicación exacta se autodetecta. Se necesita el plugin para  parser logs de Pandora para procesar estos logs. Adicionalmente   también   monitoriza   los   siguientes   parámetros   de   rendimiento,   tal   como  recomiendan muchos administradores expertos de Oracle para diferentes tipos de entornos: • Dictionary Cache Hit Ratio • Library Cache Hit Ratio • DB Block Buffer Cache Hit Ratio • Latch Hit Ratio • Disk Sort Ratio • Rollback Segment Waits • Dispatcher Workload • Active sessions • Concurrent parallel sessions • Redo log write time • Redo log buffer space wait Page 7
  8. 8. • Enqueue waits • Free buffer waits NOTA: Conviene destacar que si la base de datos a monitorizar no tiene configurada alguna de las  estadísticas   antes   mencionadas   entonces   los   módulos   correspondientes   figurarán   como   no  inicializados en la consola de Pandora FMS. Ninguno de los parámetros de rendimiento tiene asociada por defecto ningún tipo de evento, y se  pueden asignar umbrales para asignarles alertas. Todos esos módulos vienen parametrizados en el fichero “oracle.conf” que viene en el paquete del  plugin. Esos módulos son SQL, que se puede consultar en el fichero y que pueden ser eliminados,  modificados o ampliados por un administrador de Oracle. Se puede encontrar más información acerca de estas queries y otras, recomendadas por diversas  comunidades de administradores de Oracle en el siguiente enlace: http://www.hoopoes.com/cs/oracle_tune.shtml 5.1. Monitorización multiinstancia El plugin además de realizar una monitorización a nivel general de todas las instancias permite  monitorizar varias instancias  de una forma más específica.  De esta forma el plugin permite una configuración más flexible: • Monitorización a nivel general: Por una parte se realizarán la monitorización por defecto,  explicada en el punto anterior. • Monitorización   a   nivel  instancia:  Además   se  podrá   configurar  la   monitorización  por  instancia específica. NOTA:  Cabe   destacar   que   la   monitorización   a  nivel   instancia   tiene   prioridad  sobre   la  monitorización general  ya que se considera que es más específica. Esto evitará que se generen  módulos duplicados en el caso de que se configure la misma instancia para chequeos generales y en un   bloque de configuración de instancia (ver en el punto siguiente) del fichero de configuración. Para que los módulos de los distintas instancias no se machaquen la notación que utilizarán los  módulos será: ORA_{SID}_{Comprobación} 5.2. Pre­condiciones automáticas a la monitorización Para evitar que se generen módulos de error duplicados se han establecido unas condiciones que  deben ser satisfechas antes de proceder a los chequeos. Si estas condiciones no se satisfacen se  Page 8
  9. 9. abortará la monitorización. Estas condiciones son a dos niveles: • A nivel general: Se verificará acceso al fichero de configuración, que el binario de SQLplus  está disponible, el estado del listener (si no está deshabilitada la verificación del listener) y  el proceso pmon está corriendo (si no está deshabilitado). • A nivel de instancia: Se verificará si existe un script que condicione la monitorización de la  instancia correspondiente, se verifica el proceso  pmon  para dicha instancia (si no está  deshabilitado), se verifica el estado del listener y sus servicios (si no está deshabilitada la  verificación del listener). 5.3. Parametrización del plugin El plugin se utiliza mediante la configuración en un fichero externo de configuración.  NOTA: Es extremadamente importante tener en cuenta que los archivos de configuración pensados para  el plugin en UNIX deben estar editados y almacenados con retornos de carro tipo “UNIX” y que si se   usan retornos de carro tipo “WINDOWS” el plugin no funcionará adecuadamente. Existen algunos chequeos específicos que tienen sus propios “tokens” de configuración, que se  describen a continuación: 5.3.1. Localización del fichero oratab En caso de utilizarse. Recordemos que el fichero oratab guarda la información de las instancias y  el directorio home de dicha instancia. Por defecto el script asume que el fichero oratab está ubicado  en: /var/opt/oracle/oratab Si el fichero oratab no estuviera en dicha ubicación, se puede especificar una alternativa en el  fichero de configuración. oratab /etc/oratab  Esto hará que busque el fichero oratab en una ubicación alternativa. En este ejemplo el directorio  /etc. 5.3.2. Log de información y errores. Todas las acciones realizadas por el plugin se registrarán en un fichero de log cuyo nombre estará  parametrizado de la siguiente forma: /tmp/pandora_ora_{SID} Page 9
  10. 10. 5.3.3. “Saltar” comprobaciones por defecto. Se pueden "saltar" las comprobaciones por defecto usando el token de configuración adecuado:  skip_listener_status  skip_tablespace_free  skip_tablespace_status  skip_oracle_fs  skip_connect_check  skip_alert_log  skip_pmon Estos  tokens  se aplicarán a nivel general o a nivel de instancia. Esto permitirá hacer flexible la  monitorización.   Por   ejemplo,   supongamos   que   en   oratab   tenemos   configurada   la   instancia  “hpsacert” y en un bloque de configuración de instancia (ver a continuación) también. Si queremos  realizar un parseo específico sobre la log de alertas de esta instancia y no sobre las demás entonces  deberemos de omitir el token skip_alert_log (ver a continuación) en el bloque de configuración de  instancias. Como se dijo anteriormente la monitorización a nivel de instancia tiene prioridad sobre  la general por lo que se ejecutará un parseo específico para esta instancia.   5.3.4. Bloque de configuración de una instancia. Para realizar la configuración específica de una instancia se debe de utilizar los tokens siguientes: instance_begin  instance_name xxxxxx  <tokens de configuración> instance_end Sobre este bloque se pueden utilizar los tokens explicados anteriormente y de esta forma elegir si el  chequeo correspondiente se realizará o no. Además se podrán utilizar solo dentro de este bloque los siguientes tokens:   5.3.4.1. Configuración del listener y servicios Para que el plugin monitorice el estado de los servicios a través del listener, hay que configurar  ambos valores, el  nombre del listener  y el  nombre de cada uno de los servicios.  Para ello  utilizaremos la siguiente sintaxis de configuración: listener_name LISTENER_RHGE0208 Page 10
  11. 11. Esto definirá el nombre del listener, en este ejemplo “LISTENER_RHGE0208”. Debe ser el nombre  exacto del listener que queremos monitorizar. Por otro lado, hay que especificar el servicio o los servicios que queremos comprobar que estén  escuchando en ese listener, eso se hace con los siguientes tokens de configuración: service OIM  service OIMXA  service OIMXDB  service OIM_XPT NOTA: Si existen varios listener en una máquina, deberemos configurar estos tokens en cada uno de los   bloques de configuración de instancia. 5.3.4.2. Precondiciones a la monitorización Se puede condicionar la monitorización de una instancia a si un script devuelve 1. Para ello dentro  del bloque de instancia se puede utilizar el token conditional_monitoring.  Por ejemplo: conditional_monitoring /var/plugin oracle/conditional script NOTA: Se debe poner la ruta completa del script. En caso de que la ruta o el nombre del script tenga   espacios se deben enmascarar. 5.3.5. Reinicio del listener En caso de que la comprobación del listener (ya sea como chequeo global o como chequeo de  instancia) y que no responda se podrá habilitar un script para que se ejecute e intente reiniciar el  listener. Cada vez que se ejecute este script se guardará en un fichero /tmp/{sid}_listener_restart el  número de reinicios del listener. Este contador se reseteará cada 24 horas. El formato de este  fichero es el siguiente: RefDate: yyyy­mm­dd hh:mi:ss Reinicios totales: xx RefDate contendrá la fecha en la que se reseteó el contador de reinicios del listener. 5.3.6. Monitorización de SID específicos Es posible limitar el número de instancias a las que se les van a hacer los chequeos a nivel general.  Page 11
  12. 12. Para esto se cuenta con los siguientes tokens: sid, only_sid y skip_sid.   5.3.6.1. Monitorización de un SID específico (sid) En los parámetros comunes para todas las instancias se puede configurar este parámetro: Ejemplo: sid <nombre instancia> Con ello todos los chequeos a nivel general se realizarán solo sobre esta instancia no teniendo en  cuenta las demás instancias configuradas. 5.3.6.2. Monitorización de SID específicos (only_sid) Esta directiva sirve para limitar el número de instancias a monitorizar. Mediante el token only_sid  se fuerza al sistema a monitorizar ese SID (o varios si se introducen varias lineas).  Ejemplo: only_sid pandora01 Con esta llamada, de todos los SID que tenga la BBDD, solo monitorizará la instancia “pandora01”. 5.3.6.3. Monitorización de SID específicos (skip_sid) Si con la directiva only_sid xxxx limitábamos el número de instancias objetivo, la directiva skip_sid  sirve para justo lo contrario. Con ella la instancia (o instancias) marcadas no se incluirán en los  chequeos globales.  Ejemplo: skip_sid pandora01 Con esto no se incluirá en los chequeos globales la instancia “pandora01”. 5.3.6.4. Asignación de estos tokens  Debido a que estos tokens no son compatibles entre sí la forma de asignarlos será la siguiente y  prevalecerá uno sobre el otro: 1. sid 2. only_sid Page 12
  13. 13. 3. skip_sid 5.3.7. Monitorización de volúmenes de disco de una instancia El sistema intentará “autodetectar” los volúmenes en base a un “prefijo” y al nombre de cada  instancia monitorizada. Para ello usamos la directiva volume_preffix para definir el prefijo de todos  los volúmenes de Oracle. Por ejemplo: volume_preffix /aplicaciones/oracle Si uno de los SID es “hpsacert”, automáticamente detectará todos los volúmenes de disco montados  en un path que contenga “aplicaciones/oracle”  y que tenga “pandora01” en su nombre, como por  ejemplo: /aplicaciones/oracle/arc_pandora01 /aplicaciones/oracle/rdbms_pandora01 5.3.8. No utilización del fichero ORATAB En algunas instalaciones de Oracle (por ejemplo de tipo RAC) no se dispone de un fichero ORATAB  que refleje las distintas instancias que se van a monitorizar por lo que no se hará uso de este  fichero.   De   esta   forma   se   indicará   explícitamente   mediante   tokens  only_sid  en   el   fichero   de  configuración los Sids de las instancias a monitorizar y la variable $ORACLE_HOME. Por ejemplo: skip_oratab only_sid pandora01 only_sid AST1 oracle_home /oracle/product/11.0.1 5.3.9. Monitorización de volúmenes de disco sueltos El sistema intenta “autodetectar” los volúmenes Oracle, según el punto anterior. Si no es capaz de  detectarlo, o el administrador quiere incluir volúmenes “sueltos”, se pueden  monitorizar usando la  directiva volume. Por ejemplo: volume /var  volume /oracle Page 13
  14. 14. 5.3.10. Credenciales de acceso Necesarias para usar el plugin.  user sys password pandoraA01 AS SYSDBA Nota: el uso de conexión como SYSDBA es opcional, la misma linea podría ser así (si el usuario tiene  permisos para las tablas y vistas especiales que se necesitan). user oracle  password oracle Tomar buena nota de que aquí no se usa el modo “full” y de que se usa un tipo de dato numérico. 5.3.11. Parseador de logs Por   defecto   se   utiliza   el   plugin   de   parseo   de   logs   localizado   en   el   ruta  /etc/pandora/plugins/grep_log  pero se puede modificar la ruta mediante el token  logparser. Por  ejemplo: logparser /var/opt/PandoraFMS/etc/pandora/plugins/grep_log 5.3.12. Procesado de los logs de alerta  Para procesar los logs de alerta de Oracle se deberá omitir la directiva skip_alert_log y configurar la  directiva log_pattern como una expresión regular. Por ejemplo para buscar en el log de alerta el  mensaje ORA­: #skip_alert_log log_pattern ORA­* 5.3.13. Monitorización vía SQL Una de las características mas potentes del plugin es la posibilidad de especificar su propia orden  SQL para obtener el valor. Veamos algunos ejemplos: custom_query_begin  custom_query_name NUM_MAX_FICHEROS  custom_query_sid xxxx custom_query_type generic_data  custom_query_sql_begin  Page 14
  15. 15. select round ((ficheros_act/ficheros_max)*100) ratio  from (select count(*) ficheros_act from dba_data_files),  (select value ficheros_max from v$parameter where name='db_files');  custom_query_sql_end  custom_query_end Custom_query_sid  (Opcional) define un SID para esta consulta SQL y solo la ejecutará para esa  instancia. Si no se especifica, se ejecutará para todas las instancias. Custom_query_type  debe ser un tipo válido en Pandora, por ejemplo generic_data para datos  numéricos o async_string para cadenas de texto.  Custom_query_mode  valdrá   “full”   cuando   queremos   obtener   toda   la   salida   (por   ejemplo   un  listado). Siempre que usemos el modo “full” deberíamos usar un tipo de datos de tipo cadena  (async_string). Custom_query_description es opcional y sirve para enviar una descripción con el módulo. Custom_query_condition <script> si este script devuelve 1 se ejecutará la query de este bloque  en caso contrario no. Se debe poner la ruta completa y enmascarar los espacios. Veamos un ejemplo que utiliza una consulta SQL para obtener valores discretos: custom_query_begin  custom_query_name SQL_SESS_CONCURRENTES  custom_query_type generic_data custom_query_condition /var/oracle/conditional script custom_query_description Devuelve el porcentaje de sesiones concurrentes. custom_query_sql_begin  select round ( (sesiones*100)/value )  from (select count(*) sesiones from v$session), v$parameter ;  custom_query_sql_end  custom_query_end Tomar buena nota de que aquí no se usa el modo “full” y de que se usa un tipo de dato numérico. En el paquete del plugin se distribuye un script (pmon_ASM_test) que permite verificar si el proceso  pmon_+ASM está corriendo y que se puede utilizar con la directiva custom_query_condition. En caso  afirmativo devolverá 1 sino devolverá 0.  Page 15
  16. 16. 5.3.14. Creación de módulos manuales para los logs Dado que el módulo de log de errores no reporta información hasta que no hay un error, habrá que  crear el módulo manualmente. El nombre del módulo es siempre dependiente de la instancia de  BBDD. Los nombres de instancia de BBDD nos aparecerán en la monitorización del agente en varios  sitios, por ejemplo: En este caso la instancia de la BBDD se llama “hpsacert”, para ello entonces crearemos un nuevo  módulo, manualmente, de la siguiente manera: Y seguidamente crearemos una alerta. Antes de asignar la plantilla de alerta, debemos estar seguros  de que tenemos una plantilla de alerta que envía un evento cuando recibimos algo en el módulo.  Esto se hace con una plantilla similar a la que sigue: Page 16
  17. 17. Las condiciones de disparo son especiales, ya que nos interesará tener un timethreshold corto, por si  llegan más eventos, que siempre serán diferentes y susceptibles de ser enviados. No obstante le  pondremos un tiempo mínimo para evitar una tormenta de eventos repetidos. Ya finalmente, asignaremos el módulo de alerta de log a la plantilla de error en logs: Page 17
  18. 18. 6 REQUISITOS Los requisitos para que funcione correctamente esta monitorización son los siguientes: • Instalar el agente de Pandora FMS. • Tener un Oracle instalado en la máquina donde se va a monitorizar, con las herramientas  básicas (SQLplus, lsnrctl).  • Especificar el nombre del listener de Oracle que se quiera monitorizar así como el nombre  de cada servicio que se quiera monitorizar en el listener por cada una de las instancias  reflejadas en el fichero de configuración. Imprescindibles ambas cosas para monitorizar el  listener a nivel instancia. • Es necesario que el usuario con el que se ejecuta el agente de Pandora FMS, que es el  usuario que ejecutará el plugin, tenga acceso a los siguientes recursos de Oracle: ◦  SQLplus  ◦  lsnrctl (correctamente configurado) ◦ Todas las variables de entorno del DBA exportadas para el usuario que ejecuta el  plugin. Este usuario también es necesario que pertenezca al grupo de sistema de  Oracle. ◦  Ficheros log de alertas (obtenidos dinámicamente para cada instancia). ◦ El PATH a los binarios SQLplus y lsnrctl debe estar disponible para el plugin: ▪ Si se realiza una monitorización sobre una única instancia se puede exportar  como variable de entorno. ▪ El   plugin   buscará   esta   variable   en   el   fichero   de   variables   de   entorno  $ORACLE_HOME/dbs/orauser_$ORACLE_SID   y   en   caso   de   encontrarlas   las  cargarás. ◦ Las variables $ORACLE_HOME y $ORACLE_SID deben estar disponibles para el  plugin. En caso de utilización del fichero ORATAB se extraerán de este fichero. En  caso de que no se use este fichero se podrá indicar explícitamente en el fichero de  configuración del plugin o por último estar cargadas como variables de entorno en  el caso de monitorización monoinstancia. • Para realizar la monitorización el plugin llamará a SQLplus para hacer diversas queries SQL  obteniendo la información.  • El plugin debe poder escribir ficheros temporales en el path /tmp • Habrá que suministrar la lista de volúmenes de disco a monitorizar y en caso de realizarse la  monitorización de listeners la lista de listeners y servicios asociados. Page 18
  19. 19. • El usuario que ejecuta el agente de Pandora FMS debe pertenecer al grupo de explotación de  la base de datos para poder acceder al fichero tnsnames.ora. 6.1. Requisitos de acceso a la BBDD El plugin requiere un usuario y un password para la conexión a la BBDD, ese usuario debe tener  privilegios suficientes para consultar algunas de las tablas del sistema, para obtener información.  El usuario que se provee puede ser "normal" o utilizar una conexión como SYSDBA, en cualquier  caso esto se especifica en el parámetro "password" del fichero de configuración del plugin.  Preparación de la base de datos. Es necesario disponer de un usuario con privilegios de acceso para  algunas de las tablas. En este ejemplo se detalla como dar acceso a ciertas tablas que utiliza el  plugin por defecto, para el usuario "pandora" con password "pandora". El plugin hará las conexiones  siempre a la maquina local (localhost).  CREATE USER pandora IDENTIFIED BY pandora; GRANT CREATE SESSION TO pandora; GRANT SELECT any dictionary TO pandora; GRANT SELECT ON V_$SYSSTAT TO pandora; GRANT SELECT ON V_$STATNAME TO pandora; GRANT SELECT ON gv$sysstat TO pandora; GRANT SELECT ON v$sesstat TO pandora; GRANT SELECT ON V_$INSTANCE TO pandora; GRANT SELECT ON V_$LOG TO pandora; GRANT SELECT ON SYS.DBA_DATA_FILES TO pandora; GRANT SELECT ON SYS.DBA_FREE_SPACE TO pandora; GRANT SELECT ON V_$parameter TO pandora; GRANT SELECT ON dba_tablespaces TO pandora; GRANT SELECT ON dba_data_files TO pandora; GRANT SELECT ON dba_free_space TO pandora; . . (otros GRANT necesarios, para todas la tablas usadas en el fichero de configuración del plugin) . . -- -- if somebody still uses Oracle 8.1.7... GRANT SELECT ON sys.dba_tablespaces TO pandora; GRANT SELECT ON dba_temp_files TO pandora; GRANT SELECT ON sys.v_$Temp_extent_pool TO pandora; GRANT SELECT ON sys.v_$TEMP_SPACE_HEADER TO pandora;     GRANT SELECT ON sys.v_$session TO pandora;  Page 19
  20. 20. 7 INSTALACIÓN Copiar el plugin al directorio de plugins del agente, o distribuirlo con file collections. Lo mismo con  el archivo conf. La llamada desde el agente será similar a esta, pero usando los paths donde esté  instalado el plugin y el conf. module_plugin perl /var/opt/PandoraFMS/etc/pandora/plugins/oracle.pl /var/opt/PandoraFMS/etc/pandora/collections/fc_23/oracle.conf Page 20
  21. 21. 8 USO CON POLÍTICAS El uso de este scripts con políticas es sencillo, se basa en hacer una política que contenga el plugin  (pandora_oracle.pl) y un fichero de configuración por cada agente. De forma que la llamada al  plugin de la política, use la variable $HOSTNAME para sustituirla en tiempo de ejecución por el  hostname (completo) de la máquina. Este es un ejemplo: Si   la   maquina   se   llama   ilp0x068.tsm.inet,   tendremos   que   subir   un   fichero   con   nombre  ilp0x068.tsm.inet­oracle.conf tal y como se ve en la siguiente captura de pantalla: El contenido del .conf es específico para cada sistema, pero todos los .conf se copian a todos los  sistemas asociados a la política. De forma que aunque por permisos solo el usuario que ejecuta el  agente de pandora puede leer esos .conf (donde van las contraseñas de acceso a los oracle) es  más que recomendable que se utilicen usuarios de solo lectura y que dichos usuarios tengan acceso  sólo en local. Page 21

×