pandora fms: plugin enterprise de oracle

Pandora FMSManual Administrador

Monitorización Oracle en entornos Unix

Manual Administrador Monitorización Oracle en entornos Unix

© Artica Soluciones Tecnológicas 20052012

Índice de contenido1Histórico de cambios..........................................................................................................................32Introducción........................................................................................................................................43Matriz de compatibilidad ...................................................................................................................54Documentación a entregar por el Área que requiere la monitorización.............................................65Módulos del plugin ............................................................................................................................7

5.1.Monitorización multiinstancia...................................................................................................85.2.Pre-condiciones automáticas a la monitorización......................................................................85.3.Parametrización del plugin........................................................................................................9

5.3.1.Localización del fichero oratab..........................................................................................95.3.2.Log de información y errores.............................................................................................95.3.3.“Saltar” comprobaciones por defecto..............................................................................105.3.4.Bloque de configuración de una instancia.......................................................................10

5.3.4.1.Configuración del listener y servicios......................................................................105.3.4.2.Precondiciones a la monitorización..........................................................................11

5.3.5.Reinicio del listener.........................................................................................................115.3.6.Monitorización de SID específicos..................................................................................11

5.3.6.1.Monitorización de un SID específico (sid)...............................................................125.3.6.2.Monitorización de SID específicos (only_sid).........................................................125.3.6.3.Monitorización de SID específicos (skip_sid).........................................................125.3.6.4.Asignación de estos tokens ......................................................................................12

5.3.7.Monitorización de volúmenes de disco de una instancia.................................................13

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



18/06/12 Juanma Nuevos módulos v2r1


17/09/13 Mario P Cambio en código v2r3

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

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

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.

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

• 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. Precondiciones 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

http://www.hoopoes.com/cs/oracle_tune.shtml

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 oratabEn 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}

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

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 listenerEn 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: yyyymmdd hh:mi:ssReinicios 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íficosEs posible limitar el número de instancias a las que se les van a hacer los chequeos a nivel general.

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

3. skip_sid

5.3.7. Monitorización de volúmenes de disco de una instanciaEl 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 ORATABEn 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_oratabonly_sid pandora01only_sid AST1oracle_home /oracle/product/11.0.1

5.3.9. Monitorización de volúmenes de disco sueltosEl 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

5.3.10. Credenciales de accesoNecesarias para usar el plugin.

user syspassword 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 logsPor 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_loglog_pattern ORA*

5.3.13. Monitorización vía SQLUna 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 xxxxcustom_query_type generic_data custom_query_sql_begin

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_datacustom_query_condition /var/oracle/conditional\ scriptcustom_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.

5.3.14. Creación de módulos manuales para los logsDado 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:

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:

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.

• 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;

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

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.inetoracle.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.

pandora fms: plugin enterprise de oracle

Technology

sid especfico sid

monitorizacin multiinstancia

sid especficos skip

mdulos base en

fichero oracle

juanma nuevos mdulos

juanma primera versin

una instancia