Monitorización de bases de datos Oracle

También puedes configurar el inicio de sesión para bases de datos multi-tenant. Esto se realiza normalmente en la configuración utilizando un usuario especial y con el prefijo C##. La asignación de permisos es un poco diferente que para los usuarios normales, ya que tienes que especificarlos para todos los contenedores actuales y para todos los contenedores futuros:

Con el inicio de sesión estándar puedes utilizar instancias normales o incluso todas las instancias de una base de datos. Sin embargo, hay casos especiales en los que necesitas datos de acceso individuales para instancias concretas. Por ello, en el archivo de configuración tienes las tres opciones siguientes para especificar usuarios:

Estas variables permiten aún más opciones aparte del nombre de usuario y la contraseña. También puedes determinar si el usuario es un SYSDBA o un SYSASM, en qué combinación de dirección y puerto escucha la instancia, e incluso qué alias TNS (TNSALIAS) debe utilizarse. Sin embargo, estas especificaciones son siempre -a diferencia del usuario y la contraseña- opcionales. Además del ejemplo anterior, una configuración puede tener este aspecto

Algunas explicaciones sobre el ejemplo anterior:

En algunos casos, puede que no quieras incluir instancias concretas en la monitorización. Esto puede deberse a que sólo sea un campo de juego para desarrolladores, o por otras razones. Para simplificar al máximo la configuración en situaciones individuales, tienes varias opciones para excluir total o parcialmente una o varias instancias:

Ya lo habrás adivinado: el orden en que se procesan estos parámetros determina el resultado. De hecho, las entradas se procesan por instancia exactamente en secuencia, como se muestra en la tabla anterior. Por lo tanto, si se establece la variable ONLY_SIDS, ya no se evalúa SKIP_SIDS ni se comprueba si la variable EXCLUDE_<SID> se establece en ALL para esta instancia. Si no se establece ONLY_SIDS, el sistema procede según la secuencia. En caso de duda -es decir, como comportamiento por defecto-, la instancia se monitorizará en consecuencia.

A continuación se muestra un ejemplo en el que se establecen todas las variables y cómo es el comportamiento:

Como la lista positiva de la primera línea siempre tiene prioridad, las líneas segunda y tercera ya no se evalúan. Sólo la cuarta línea (la última) se tendrá en cuenta más adelante, ya que aquí la instancia sólo se evaluará parcialmente.

En la práctica, sólo tiene sentido utilizar una de las variables para determinar el número de instancias que se van a monitorizar.

Como has aprendido en la sección anterior, no sólo es posible desactivar completamente las instancias, sino también monitorizarlas sólo parcialmente. Los requisitos operativos son diversos, y resulta especialmente práctico cuando no es deseable que determinadas secciones de larga duración se incluyan en todo, o cuando sólo se necesita información básica de las instancias de prueba, por ejemplo. Para restringir globalmente las secciones, establece directamente las variables correspondientes -para restringir sólo determinadas instancias puedes introducir la variable EXCLUDE_<SID>, de la que ya has aprendido en la sección anterior-. Las variables globales son:

Por tanto, el mecanismo te permite establecer un valor por defecto en el archivo de configuración y sobrescribirlo para instancias individuales según sea necesario. Así, por ejemplo, una configuración podría tener este aspecto

Como puedes ver en el ejemplo, sólo se consulta la sección instance para las instancias ASM y se especifica un conjunto mínimo para las secciones asíncronas en todas las instancias regulares. Además, en la instancia INST1 se omitirán las secciones síncronas undostat y locks. Puesto que las secciones síncronas no se especifican explícitamente, se consultan todas las secciones síncronas de todas las demás instancias. A su vez, en la instancia INST2 sólo se consultan tres de las cuatro secciones asíncronas, ya que jobs se excluyó adicionalmente. Y, por último, el caché de 10 minutos se reduce a 5 minutos (300 segundos), ya que es tiempo suficiente para obtener todos los datos.

Por ejemplo, si sólo quieres locks de la consulta sincrónica, especifica toda la lista sincrónica y simplemente omite locks:

Lo mismo se aplica a las otras tres variables en las que se pueden determinar las secciones.

El alias TNS es un nombre fácil de usar para una conexión a una base de datos. TNS son las siglas de la tecnología de red de Oracle Substrato de red transparente. Un alias TNS permite establecer una conexión a una instancia de base de datos sin tener que introducir cada vez los detalles completos de la conexión (como el nombre del host, el número de puerto o el nombre del servicio). Los alias TNS se definen en el archivo tnsnames.ora. La sección sobre Cartera Oracle contiene un ejemplo de cómo definir un alias TNS.

TNS_ADMIN es una variable del entorno que apunta al directorio en el que se encuentran los archivos de configuración de Oracle, como sqlnet.ora y tnsnames.ora. Por defecto, TNS_ADMIN está configurado por Oracle como $ORACLE_HOME/network/admin. En el archivo de configuración, puedes asignar una ruta diferente a TNS_ADMIN, como en el siguiente ejemplo para una instalación específica de Oracle:

Sólo si la variable no está configurada, el plugin de agente la establece en /etc/check_mk/.

Por motivos de seguridad, el plugin de agente mk_oracle ya no ejecuta binarios de Oracle bajo el usuario root. Esto afecta a los programas sqlplus, tnsping y -si está disponible-crsctl. En su lugar, mk_oracle, por ejemplo, cambia al propietario del archivo $ORACLE_HOME/bin/sqlplus antes de ejecutar sqlplus. Esto garantiza que los programas de Oracle sólo sean ejecutados por un usuario sin privilegios y evita así que un usuario malintencionado de Oracle sustituya un binario como sqlplus y lo ejecute como usuario root.

La ejecución de programas de Oracle por parte de un usuario sin privilegios puede provocar problemas al utilizar un monedero de Oracle, ya que este usuario no podrá acceder a los archivos específicos del monedero. El usuario sin privilegios necesita permisos para leer los archivos $TNS_ADMIN/sqlnet.ora y $TNS_ADMIN/tnsnames.ora, para ejecutar la carpeta del monedero y para leer los archivos de la carpeta del monedero. No deberías tener problemas con los derechos de acceso siempre que hayas cambiado el grupo de los archivos y directorios como se describe al final de la sección sobre el monedero de Oracle.

El plugin de agente te ayuda con el diagnóstico y comprueba si hay problemas para acceder a los archivos mencionados y los muestra en la prueba de conexión. El procedimiento exacto para diagnosticar y corregir los derechos de acceso se encuentra en la Base de conocimientos de Checkmk.

Al igual que en Linux, también puedes definir no sólo un inicio de sesión estándar para el plugin de agente de Windows, sino también datos de acceso individuales para instancias concretas. Por tanto, tienes las mismas tres opciones para especificar los usuarios:

Además, aquí también se pueden especificar más opciones aparte del nombre de usuario o la contraseña - estas entradas adicionales también son opcionales, sin embargo, cada entrada debe rellenarse si se utiliza. Así, por ejemplo, una configuración puede tener este aspecto

Algunas explicaciones sobre el ejemplo anterior:

Incluso en Windows, no siempre se desea incluir determinadas instancias. Las razones para ello ya se han descrito en la sección dedicada a Linux. Dos de los tres parámetros que conoces de Linux también se pueden utilizar con Windows:

El proceso se realiza para cada instancia en el orden que se muestra en la tabla anterior. Así, primero se comprueba si la instancia está en ONLY_SIDS, y sólo después si se van a excluir determinadas secciones. Si la variable EXCLUDE_<SID> se establece en ALL, no se ejecutará ninguna sección.

A continuación se muestra un ejemplo en el que cada variable aparece una vez:

Observa que ONLY_SIDS es una lista, mientras que EXCLUDE_INST1 es una cadena que contiene secciones separadas por espacios.

La especificación de las secciones que realmente se van a obtener se hace de la misma forma que en Linux, y lo que sigue es sólo un ejemplo para una configuración de Windows:

Por ejemplo, si sólo quieres locks de la consulta sincrónica, especifica toda la lista sincrónica y omite simplemente locks:

Lo mismo ocurre con las otras tres variables en las que se determinan las secciones.

Por motivos de seguridad, el plugin de agente mk_oracle.ps1 sólo ejecuta los binarios de Oracle como administrador si estos programas sólo pueden ser modificados por administradores. Los administradores en Windows son la cuenta LocalSystem y los miembros del grupo integrado Administrators. Esto se aplica a los programas sqlplus.exe, tnsping.exe y -si están disponibles-crsctl.exe. El plugin de agente mk_oracle.ps1 no ejecuta ninguno de estos programas si los usuarios sin privilegios tienen uno de los permisos Write, Modify o Full control para el archivo. De esta forma se evita el riesgo de seguridad que supone que usuarios sin privilegios ejecuten programas como administrador.

Si es necesario, modifica los derechos de acceso eliminando los permisos mencionados de los usuarios no administrativos para los programas. El plugin de agente te ayuda con el diagnóstico y comprueba si los usuarios no administrativos tienen acceso a los archivos mencionados y los muestra en la prueba de conexión. El procedimiento exacto para diagnosticar y corregir los derechos de acceso se encuentra en la Base de conocimientos de Checkmk.

Si no te es posible ajustar los permisos de los programas de Oracle de forma segura, puedes permitir que usuarios individuales y grupos ejecuten los programas:

Sólo si no hay otra forma de garantizar la monitorización de Oracle, puedes desactivar el check de derechos de acceso como última opción.

Sin embargo, también existe otra forma de ejecutar el Plugin de agente, sin derechos de administrador. Puedes personalizar la ejecución del Plugin de agente y ejecutarlo bajo el grupo local de Windows Users, por ejemplo. Para ello, edita el archivo de configuración check_mk.user.yml del agente de Windows, por ejemplo, de esta forma

En las ediciones comerciales, puedes hacer que la Agent bakery cree estas entradas con la regla de agente Run plug-ins and local checks using non-system account.

Una vez que hayas licenciado y activado ADG, no necesitas hacer ningún cambio en la configuración del plugin de agente, ya que puedes leer desde una instancia en espera en cualquier momento sin tener que interrumpir la sincronización con la instancia primaria.

Si las instancias no tienen ADG, el usuario con el que se van a obtener los datos de monitorización de las instancias en espera necesita el rol SYSDBA. Este permiso permite al usuario obtener al menos parte de los datos, aunque falle la instancia primaria y la instancia en el servidor de espera aún no se haya cambiado de MOUNTED a OPEN.

Asigna el permiso al usuario autorizado a recuperar los datos de las instancias.Importante: El funcionamiento puede diferir del ejemplo siguiente. Aquí el rol se asigna al usuario tal y como se creó en el ejemplo de configuración inicial:

Para que el plugin de agente pueda consultar los datos en el servidor en espera en caso de error, crea el usuario en la instancia primaria y, a continuación, copia el archivo de contraseñas en el servidor en espera. Por último, en el archivo de configuración del Plugin, establece el rol del usuario en SYSDBA:

Ten en cuenta que especificar un host, un puerto o un alias TNS es opcional, y puede omitirse. Además, el plugin de agente debe estar instalado, por supuesto, en el host de la instancia primaria, así como en los hosts de las instancias en espera.

Por parte de Checkmk, es necesario -independientemente de si utilizas ADG o DG- personalizar los servicios y asignarlos a un host de clúster. Los correspondientes check plugin ya han sido preparados hasta el punto de que también pueden configurarse como servicios de clúster. Crea un host de clúster en Checkmk y añádele como nodos los hosts individuales de Oracle en los que se ejecutan las instancias primaria y en espera. A continuación, asigna los siguientes servicios a este host de clúster:

De este modo, ya no tendrás que preocuparte de la instancia de la que proceden los datos, y habrás garantizado una monitorización sin fisuras de los servicios mencionados, incluso en caso de conmutación de la instancia primaria.

También tiene sentido configurar los servicios del clúster para un RAC. Además de los servicios que asignes al host de clúster en un Data Guard (Activo), asigna también los siguientes servicios al host de clúster para garantizar una monitorización sin interrupciones en caso de conmutación:

La forma más sencilla de conectar un SQL de este tipo es utilizar el complemento de comprobación Base de datos Oracle: Custom SQLs check plugin. Para ello, crea primero el archivo MyCustomSQL.sql en el directorio de configuración del agente en el host en el que se va a ejecutar el SQL.

A continuación se muestra un archivo ficticio que ilustra la sintaxis:

El ejemplo muestra, por un lado, que puedes definir cualquier número de sentencias en un archivo de este tipo. Por otro, la sintaxis es muy similar a la de un check local, especialmente en lo que respecta a las métricas. En detalle, esta sintaxis es mucho más potente en este caso, porque puedes generar una salida de varias líneas, que luego se procesa en el servidor Checkmk como un servicio. En principio, todas las líneas son opcionales y no es necesario rellenarlas.

Las palabras clave posibles son detalladas:

Ahora que has definido tu primer SQL, muy sencillo, dáselo a conocer al plugin de agente mk_oracle. Esto se hace mediante el conocido archivo de configuración, que puedes ampliar según convenga:

Con la primera opción (SQLS_SECTIONS) determinas qué secciones individuales quieres que se ejecuten. Ten en cuenta que sección significa aquí una parte de la salida del plugin de agente, y no una parte de una instancia de base de datos. En el ejemplo, sólo hemos especificado una sección (mycustomsection1) y la hemos descrito con más detalle directamente después. Cada sección es en realidad una pequeña función llamada por el plugin de agente.

En esta función puedes determinar más detalles y especificar para qué instancias (SQLS_SIDS) se aplica esta sección. Además, también defines dónde se encuentra el archivo con las sentencias SQL (SQLS_DIR), y el nombre de este archivo (SQLS_SQL).

Esta sencilla configuración es suficiente para poder ver el resultado en Checkmk. Para ello, realiza un descubrimiento de servicios y activa el nuevo servicio. Después verás este nuevo servicio con los demás servicios en la vista general del host:

Si tienes problemas para conectarte a una o varias instancias de un servidor Oracle, lo primero que puedes hacer es comprobar los parámetros básicos. Si inicias el plugin de agente con la opción -t, se mostrarán los detalles de una conexión. Ten en cuenta que, previamente, hay que proporcionar al plugin de agente las rutas a su archivo de configuración y a los datos en caché del plugin. En la salida se han omitido las secciones ficticias para facilitar la lectura.

El siguiente ejemplo corresponde a un servidor Linux con systemd, en el que el plugin de agente se ejecuta de forma asíncrona cada 60 segundos:

En un servidor Linux con xinetd, llama en su lugar a mk_oracle para la prueba de conexión de la siguiente forma:

Como es más probable que esta llamada se realice en caso de error, también recibirás más información: tanto la cadena de conexión que se utilizó para la conexión como los 100 primeros caracteres del mensaje de error que se devolvió durante el intento de conexión. Con ayuda de esta información, puedes identificar rápidamente problemas sencillos de configuración y corregirlos en consecuencia.

El plugin de agente no acepta ningún parámetro en Windows. Por eso, para probar la conexión aquí, limita temporalmente las secciones a recuperar a instance y activa la opción DEBUG:

A continuación, ejecuta manualmente el plugin de agente. De nuevo, obtendrás información sobre cómo el plugin intenta acceder a las instancias. La salida puede ser, por ejemplo, la siguiente:

Si no se puede encontrar el error comprobando una simple conexión, el siguiente paso es crear un archivo de registro, que registre todos los pasos del plugin de agente. Tampoco olvides aquí las variables del entorno necesarias. En el siguiente ejemplo, también se ha omitido la salida de las secciones para mejorar la legibilidad.

Aquí está la llamada para un servidor Linux con systemd, en el que el plugin de agente se ejecuta de forma asíncrona cada 60 segundos:

Aquí está la llamada de mk_oracle para el registro en un servidor Linux con xinetd:

Puedes utilizar el archivo de registro generado para identificar con gran precisión en qué línea del script se ha producido el problema.

El registro en Windows funciona de forma similar a la prueba de conexión descrita anteriormente. Si la conexión en sí es estable, puedes volver a añadir las secciones reales al archivo de configuración y obtener así una salida de registro completa.

Si no puedes llegar al problema, ni siquiera con la ayuda del registro, como última opción el plugin de agente proporciona la salida completa de todos los pasos para el análisis de errores. Esta salida es, por tanto, el método más completo, y sin duda el más difícil de leer, para llegar a la causa de un problema, por lo que sólo debe utilizarse como último recurso.

A continuación se muestra un ejemplo de depuración en un servidor Linux con systemd, en el que el plugin de agente se ejecuta de forma asíncrona cada 60 segundos:

He aquí la llamada de mk_oracle para depurar en un servidor Linux con xinetd:

Importante: En esta salida no se enmascaran los datos sensibles, como las contraseñas, por lo que todo es legible en texto plano.

En Windows existe una funcionalidad similar. Sin embargo, como no puedes pasar ningún argumento al plugin de agente, tendrás que activar el rastreo manualmente: