pandora fms: plugin enterprise de oracle
DESCRIPTION
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=272TRANSCRIPT
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
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
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
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
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
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
• 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
Page 8
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}
Page 9
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
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.
Page 11
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
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
Page 13
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
Page 14
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.
Page 15
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:
Page 16
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
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
• 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
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
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.
Page 21