 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introducción
Checkmk ofrece opciones completas para la monitorización de bases de datos Oracle. Con el plugin de agente no solo podéis recuperar los tablespaces de una base de datos o sus sesiones activas, sino también muchos otros tipos de métricas. En el Catálogo de plugins de check encontrarás una lista completa de las opciones de monitorización con nuestros plugins de check. Añadimos nuevos plugins y actualizamos los existentes con regularidad, por lo que siempre vale la pena echar un vistazo al catálogo. Entre otros, Checkmk puede monitorizar los siguientes valores:
Para poder monitorizar las bases de datos, solo se requiere el plugin de agente además del agente en el servidor de la base de datos.
Actualmente se admiten los sistemas operativos Linux, Solaris, AIX y Windows.
El plugin de agente para Linux, Solaris y AIX se llama mk_oracle y para Windows mk_oracle.ps1.
No se requiere ningún software adicional para la monitorización, ni en el servidor Checkmk ni en el servidor de la base de datos.
Muchos de los pasos para configurar la monitorización son los mismos para Linux y Windows. Por este motivo, describiremos primero los pasos generales, luego los pasos específicos para el grupo de sistemas operativos correspondiente y, por último, Agent bakery en las ediciones comerciales.
2. Configuración inicial
Los archivos de configuración con contenido de ejemplo que se presentan en este y en los siguientes capítulos se pueden encontrar en el servidor Checkmk, ya sea a través de la línea de comando o de la interfaz web de Checkmk. En Checkmk Raw, selecciona « Setup > Agents » y, en las ediciones comerciales, « Setup > Agents > Windows, Linux, Solaris, AIX > Related ». En todas las ediciones encontrarás entradas de menú para los diferentes sistemas operativos. Los archivos de configuración se encuentran en la caja « Example Configurations ».
2.1. Crear un usuario de la base de datos
En principio, la primera configuración es rápida y solo requiere tres pasos.
El primer paso, por supuesto, es tener un usuario que también tenga permiso para consultar las bases de datos.
Si no utilizas Real Application Cluster (RAC), crea un usuario en cada base de datos que se vaya a monitorizar.
El acceso a una instancia varía en función del sistema operativo instalado.
En Linux, por ejemplo, puedes hacerlo configurando siempre primero la instancia relevante como variable del entorno en la que se va a crear un usuario.
Normalmente, primero se cambia al usuario oracle,
pero esto puede variar en función de la configuración:
root@linux# su - oracle
oracle@linux$ export ORACLE_SID=MYINST1A continuación, inicia sesión en la instancia y crea un usuario para la monitorización.
Para obtener todos los datos, se requieren los siguientes permisos.
En el siguiente ejemplo, el usuario recién creado se llama checkmk.
También puedes especificar cualquier otro nombre que desees:
sqlplus> create user checkmk identified by myPassword;
sqlplus> grant select_catalog_role to checkmk;
sqlplus> grant create session to checkmk;
sqlplus> connect checkmk/myPassword
sqlplus> exitPuedes averiguar exactamente cómo funciona el inicio de sesión en una instancia específica en la documentación de Oracle.
Bases de datos multi-tenant
También puedes configurar el inicio de sesión para bases de datos multi-tenant.
Esto se suele hacer en la configuración utilizando un usuario especial y con el prefijo C##.
La asignación de permisos es un poco diferente a la de los usuarios normales, ya que debes especificarlos para todos los contenedores actuales y para todos los contenedores futuros:
sqlplus> create user c##checkmk identified by myPassword;
sqlplus> alter user c##checkmk set container_data=all container=current;
sqlplus> grant select_catalog_role to c##checkmk container=all;
sqlplus> grant create session to c##checkmk container=all;
sqlplus> exit2.2. Creación de la configuración
Después de crear un usuario, el siguiente paso es habilitar el plugin de agente para que pueda recibir esta información más adelante.
La forma más sencilla es definir los mismos datos de inicio de sesión para todas las instancias y establecer un valor por defecto en la configuración.
Ahora, en el host Oracle, crea un nuevo archivo de configuración mk_oracle.cfg para Linux, AIX, Solaris o mk_oracle_cfg.ps1 para Windows.
En el siguiente ejemplo se puede ver el archivo para sistemas tipo Unix:
# Syntax:
# DBUSER='USERNAME:PASSWORD'
DBUSER='checkmk:myPassword'Para Windows, este procedimiento es muy similar. Allí se establece la variable en un script de PowerShell:
# Syntax:
# $DBUSER = @("USERNAME","PASSWORD")
$DBUSER = @("checkmk","myPassword")El usuario estándar es todo lo que realmente necesita el plugin de agente. Todas las demás opciones que puedes configurar en sistemas tipo Unix o en Windows son opcionales.
2.3. Uso de Oracle Wallet
Como alternativa a especificar el usuario directamente y con una contraseña en un archivo de configuración, también puedes utilizar Oracle Wallet. Esto tiene la ventaja de que ya no es necesario almacenar los datos de acceso en un formulario sin cifrar en el servidor Checkmk y en el host Oracle. Así, aunque hayas definido los derechos de acceso al archivo de configuración en el host Oracle de forma adecuada, los datos de acceso han salido del servidor y se encuentran en el servidor Checkmk mientras utilices Agent bakery.
El Oracle Wallet, a su vez, almacena los datos de acceso cifrados en el host que se va a monitorizar, de modo que solo se pueden utilizar, pero no es necesario revelar explícitamente los datos de inicio de sesión. De este modo, Checkmk puede utilizar este wallet, de modo que solo el administrador de la base de datos (DBA) necesita conocer los datos de acceso. Crea, o pide al DBA que cree, un wallet en el servidor adecuado:
root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -createEl plugin de agente accederá a este archivo más tarde cada vez que se establezca una conexión con una instancia.
Para que también se puedan encontrar los datos de usuario necesarios, debes introducirlos una vez en el wallet.
En el siguiente ejemplo, añades el usuario checkmk para la instancia MYINST1:
root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -createCredential MYINST1 checkmk myPasswordPara que el plugin de agente sepa dónde buscar el wallet, debe encontrar dos archivos.
El primer archivo es sqlnet.ora, en el que se encuentra la información sobre la ubicación del wallet.
El segundo archivo,tnsnames.ora, define la dirección de la instancia para que también se pueda acceder a ella a través de su alias.
Para que el plugin de agente pueda acceder a estos archivos, puedes especificar la ruta en Linux, Solaris y AIX utilizando la variable del entorno TNS_ADMIN.
Esto resulta especialmente útil si los archivos ya existen.
Como alternativa, puedes crearlos explícitamente.
Windows incluso requiere que los especifiques manualmente.
Primero crea el archivo sqlnet.ora.
El plugin de agente busca alternativamente en este archivo los datos de inicio de sesión, por lo que aquí debe introducirse la ruta correcta al archivo de cartera que acabas de crear.
Asegúrate de que el parámetro SQLNET.WALLET_OVERRIDE está establecido en TRUE:
LOG_DIRECTORY_CLIENT = /var/log/check_mk/oracle_client
DIAG_ADR_ENABLED = OFF
SQLNET.WALLET_OVERRIDE = TRUE
WALLET_LOCATION =
(SOURCE=
(METHOD = FILE)
(METHOD_DATA = (DIRECTORY=/etc/check_mk/oracle_wallet))
)Ahora el plugin sabe qué credenciales debe utilizar.
Para que también acceda a la dirección correcta, crea tnsnames.ora como segundo archivo.
La sintaxis exacta se puede encontrar en la documentación de Oracle, pero a modo de ejemplo, el archivo podría tener este aspecto:
MYINST1
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = MYINST1_ALIAS)
)
)Con este paso, has creado los requisitos previos para eliminar los datos de acceso del archivo de configuración del plugin de agente.
En lugar de los datos de acceso, simplemente introduce una barra ( / ):
DBUSER='/:'Por supuesto, puedes añadir más datos de acceso al monedero más adelante.
A continuación, solo hay que modificar el archivo tnsnames.ora según sea necesario.
Por último, cambia los permisos de los archivos y directorios creados manualmente en esta sección para que los derechos de acceso en la ejecución estén configurados correctamente.
El plugin de agente ejecutado como root cambiará al propietario de los binarios de Oracle (como $ORACLE_HOME/bin/sqlplus) antes de ejecutarlos.
Por lo tanto, el grupo del propietario de los binarios de Oracle necesita, como mínimo, acceso de lectura a los archivos creados manualmente en /etc/check_mk/.
En el siguiente ejemplo, suponemos que el grupo es oinstall.
Los siguientes comandos cambian el grupo a oinstall:
root@linux# chgrp oinstall /etc/check_mk/sqlnet.ora /etc/check_mk/tnsnames.ora
root@linux# chgrp -R oinstall /etc/check_mk/oracle_walletEstos comandos garantizan que el grupo pueda leer el directorio oracle_wallet y su contenido:
root@linux# chmod g+x /etc/check_mk/oracle_wallet
root@linux# chmod -R g+r /etc/check_mk/oracle_walletLos permisos deberían tener un aspecto similar al siguiente:
root@linux# tree -ugpR /etc/check_mk
[drwxr-xr-x root root ] /etc/check_mk
├── [drwxr-x--- root oinstall ] oracle_wallet
│ └── [-rw-r----- root oinstall ] cwallet.sso
│ └── [-rw-r----- root oinstall ] cwallet.sso.lck
│ └── [-rw-r----- root oinstall ] ewallet.p12
│ └── [-rw-r----- root oinstall ] ewallet.p12.lck
├── [-rw-r--r-- root oinstall ] sqlnet.ora
├── [-rw-r--r-- root oinstall ] tnsnames.oraEl comando solo muestra los archivos y directorios en cuestión.
3. Configuración para Linux, Solaris, AIX
3.1. Plugin y rutas de configuración
En sistemas similares a Unix, Checkmk utiliza un plugin de agente uniforme. Por un lado, esto reduce el esfuerzo de mantenimiento, ya que no se duplican las consultas SQL y, por otro lado, solo tenéis que prestar atención a un único plugin de agente. En todos los sistemas compatibles, las rutas de los archivos para los agentes son iguales o muy similares. En concreto, necesitáis los siguientes directorios:
| Sistema operativo | Ruta del plugin | Ruta de configuración |
|---|---|---|
Linux, Solaris, AIX |
|
|
Linux con |
|
|
AIX |
|
|
3.2. Instalación del plugin de agente
Una vez que hayas creado un usuario en la configuración inicial y lo hayas guardado en el archivo de configuración, instala el plugin de agente.
Copia el archivo mk_oracle del directorio ~/share/check_mk/agents/plugins/ del servidor Checkmk al directorio de plugins del host Oracle descrito anteriormente.
|
El plugin de agente para sistemas tipo Unix |
Asegúrate de que el plugin de agente sea ejecutable y corrígelo si es necesario:
root@linux# cd /usr/lib/check_mk_agent/plugins/
root@linux# ls -lA
-rw-r--r-- 1 root root 120808 Jan 25 11:29 mk_oracle
root@linux# chmod +x mk_oracle
root@linux# ls -lA
-rwxr-xr-x 1 root root 120808 Jan 25 11:29 mk_oracle3.3. Opciones avanzadas
En la configuración inicial ya has aprendido las primeras variables para obtener datos de monitorización de sus instancias Oracle. Sin embargo, dependiendo del escenario de aplicación, rápidamente necesitarás más posibilidades para un mejor control individual de la monitorización de cada instancia. Encontrarás estas opciones en las siguientes secciones.
Configuración avanzada de usuarios
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 se requieren datos de acceso individuales para instancias específicas. Por lo tanto, en el archivo de configuración tienes las tres opciones siguientes para especificar usuarios:
| Parámetro | Descripción |
|---|---|
|
El valor predeterminado si no se han definido datos de acceso individuales para la instancia de la base de datos. |
|
Datos de acceso para una instancia de base de datos específica, en este caso para la instancia |
|
Datos de acceso especiales para la gestión automática del almacenamiento (ASM). |
Estas variables permiten además otras opciones además 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 opcionales, a diferencia del usuario y la contraseña.
Además del ejemplo anterior, una configuración puede tener el siguiente aspecto:
# Syntax
# DBUSER='USERNAME:PASSWORD:ROLE:HOST:PORT:TNSALIAS'
DBUSER='checkmk:myPassword'
DBUSER_MYINST1='cmk_specific1:myPassword1:SYSDBA:localhost:1521'
DBUSER_MYINST2='cmk_specific2:myPassword2::localhost::INST2'
ASMUSER='cmk_asm:myASMPassword:SYSASM'Algunas explicaciones sobre el ejemplo anterior:
Puedes definir cualquier número de datos de acceso individuales. Estos siempre tienen preferencia sobre los estándar.
Cada opción se separa de las demás mediante dos puntos (
:).Si se omite un campo opcional en medio de la cadena, se debe codificar un signo de dos puntos, como en la entrada
DBUSER_MYINST2, donde no se especificó ninguna función ni ningún puerto.Si después de un punto determinado no se necesitan más campos opcionales, puedes omitir los dos puntos, como en la entrada
ASMUSER, donde no se especificó ni el host, ni el puerto, ni el alias TNS.
Incluir o excluir instancias
En algunos casos, es posible que no desees incluir determinadas instancias en la monitorización. Esto puede deberse a que se trata solo de un entorno de pruebas para desarrolladores o a otras razones. Para que la configuración sea lo más sencilla posible en situaciones concretas, dispones de varias opciones para excluir total o parcialmente una o varias instancias:
| Parámetro | Descripción |
|---|---|
|
Aquí puedes determinar qué instancias se deben monitorizar. Una instancia se nombra mediante su identificador de sistema (SID). Se trata de una lista positiva, que ignora todas las instancias que no se enumeran explícitamente. Este parámetro es muy útil si el número de instancias que se deben monitorizar es menor que el número de instancias que se deben ignorar. |
|
A diferencia de |
|
Con este parámetro puedes excluir parcialmente una instancia excluyendo determinadas secciones de la instancia de la monitorización.
De este modo, defines una lista negativa de las secciones de una instancia.
También puedes excluir todas las secciones con el valor |
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 el orden que se muestra en la tabla anterior.
Por lo tanto, si se establece la variable ONLY_SIDS, SKIP_SIDS ya no se evalúa ni se comprueba si la variable EXCLUDE_<SID> está establecida en ALL para esta instancia.
Si ONLY_SIDS no está establecido, el sistema procede según la secuencia.
En caso de duda, es decir, como comportamiento predeterminado, la instancia se monitorizará en consecuencia.
A continuación se muestra un ejemplo en el que todas las variables están establecidas y cuál es el comportamiento:
ONLY_SIDS='INST1 INST2 INST5'
SKIP_SIDS='INST7 INST3 INST2'
EXCLUDE_INST1='ALL'
EXCLUDE_INST2='tablespaces rman'Dado que la lista positiva de la primera línea siempre tiene prioridad, la segunda y la tercera línea ya no se evalúan. Solo se tendrá en cuenta la cuarta (última) línea en una fecha posterior, ya que la instancia solo se va a evaluar parcialmente aquí.
En la práctica, solo tiene sentido utilizar una de las variables para determinar el número de instancias que se van a monitorizar.
Determinación de los datos que se deben recuperar
Como has aprendido en la sección anterior, no solo es posible desactivar instancias por completo, sino también monitorizarlas 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 solo se requiere información básica de las instancias de prueba, por ejemplo.
Para restringir secciones de forma global, configura las variables correspondientes directamente; para restringir solo determinadas instancias, puedes insertar la variable « EXCLUDE_<SID> », que ya has aprendido en la sección anterior.
Las variables globales son:
| Parámetro | Descripción |
|---|---|
|
Secciones que se deben consultar de forma sincrónica, es decir, cada vez que se ejecuta el agente. Dado que el intervalo de consulta es de 60 segundos por defecto, las consultas SQL utilizadas deben ejecutarse con la misma rapidez. Si no se especifica la variable, se consultan todas las secciones. |
|
Secciones que se deben consultar de forma asíncrona, es decir, solo cada x minutos.
El tiempo que los datos permanecen válidos viene determinado por la variable |
|
En este caso, para las secciones ASM se aplica el mismo mecanismo que en la descripción general de la variable |
|
En este caso, para las secciones ASM se aplica el mismo mecanismo que en la descripción general de la variable |
|
Esta variable se utiliza para determinar cuánto tiempo permanecen válidos los datos recuperados de forma asíncrona. Si no se especifica el valor de la variable, se utiliza un valor por defecto de 600 segundos (10 minutos). Asegúrate de que el intervalo de tiempo no sea inferior al intervalo en el que el agente Checkmk entrega los datos (60 segundos por defecto). De lo contrario, los datos pueden considerarse obsoletos y el agente no los entregará. |
|
Número de SID que se procesan en paralelo. El valor por defecto es 1. |
Por lo 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. Una configuración podría tener el siguiente aspecto, por ejemplo:
# DEFAULTS:
# SYNC_SECTIONS="instance sessions logswitches undostat recovery_area processes recovery_status longactivesessions dataguard_stats performance locks"
# ASYNC_SECTIONS="tablespaces rman jobs ts_quotas resumable"
# SYNC_ASM_SECTIONS="instance processes"
# ASYNC_ASM_SECTIONS="asm_diskgroup"
# CACHE_MAXAGE=600
SYNC_ASM_SECTIONS='instance'
ASYNC_SECTIONS='tablespaces jobs rman resumable'
CACHE_MAXAGE=300
EXCLUDE_INST1='undostat locks'
EXCLUDE_INST2='jobs'Como puedes ver en el ejemplo, solo 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.
Dado que las secciones síncronas no se especifican explícitamente, todas las secciones síncronas se recuperan de todas las demás instancias.
En la instancia INST2, por su parte, solo se consultan tres de las cuatro secciones asíncronas, ya que jobs se ha excluido adicionalmente.
Y, por último, la caché de 10 minutos se reduce a 5 minutos (300 segundos), ya que es tiempo suficiente para obtener todos los datos.
|
Si defines en el archivo de configuración qué secciones deseas recuperar y mediante qué método (también puedes cambiar una sección asíncrona a una sincrónica), debes especificar todas las secciones que deben ejecutarse en el área correspondiente. |
Por ejemplo, si solo deseas locks de la consulta sincrónica, especifica toda la lista sincrónica y omite simplemente locks:
# Just exclude 'locks' from sync sections:
SYNC_SECTIONS='instance sessions logswitches undostat recovery_area processes recovery_status longactivesessions dataguard_stats performance'Lo mismo se aplica a las otras tres variables en las que se pueden determinar las secciones.
Configuración del alias TNS y TNS_ADMIN
El alias TNS es un nombre fácil de usar para una conexión de base de datos.
TNS son las siglas de Transparent Network Substrate, la tecnología de red de Oracle.
Un alias TNS permite establecer una conexión con una instancia de base de datos sin tener que introducir cada vez todos los datos de 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 Oracle Wallet 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.
De forma predeterminada, Oracle establece TNS_ADMIN en $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:
export TNS_ADMIN=/opt/oracle/product/19c/dbhome_1/network/admin/Solo si la variable no está configurada, el plugin de agente la establece en /etc/check_mk/.
Derechos de acceso en la ejecución
Por motivos de seguridad, el plugin de agente mk_oracle ya no ejecuta binarios Oracle con el usuario root.
Esto afecta a los programas sqlplus, tnsping y, si está disponible,crsctl.
En su lugar, mk_oracle, por ejemplo, cambia el propietario del archivo $ORACLE_HOME/bin/sqlplus antes de ejecutar sqlplus.
Esto garantiza que los programas Oracle solo sean ejecutados por un usuario sin privilegios y, por lo tanto, evita que un usuario malintencionado de Oracle sustituya un binario como sqlplus y lo ejecute como usuario root.
 |
La ejecución de programas Oracle por parte de un usuario sin privilegios puede provocar problemas al utilizar una cartera Oracle, ya que es posible que este usuario no pueda acceder a los archivos específicos de la cartera.
El usuario sin privilegios necesita permisos para leer los archivos $TNS_ADMIN/sqlnet.ora y $TNS_ADMIN/tnsnames.ora, para ejecutar la carpeta de la cartera y para leer los archivos de la carpeta de la cartera.
No deberías tener ningún problema con los derechos de acceso siempre que hayas cambiado el grupo de los archivos y directorios tal y como se describe al final de la sección sobre Oracle Wallet.
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.
3.4. Monitorización de bases de datos remotas
En sistemas tipo Unix, no solo puedes recuperar instancias que se ejecutan localmente, sino también iniciar sesión en instancias remotas y recuperar las bases de datos que se ejecutan allí. Esto es ventajoso, por ejemplo, si no tienes acceso al sistema subyacente, pero deseas monitorizar la base de datos. También es posible monitorizar bases de datos remotas desde un host en el que se ejecuta el plugin de agente, pero no una base de datos Oracle.
Para monitorizar bases de datos remotas, deben cumplirse los siguientes requisitos en el host en el que está instalado el plugin de agente:
La biblioteca de acceso AIO de Linux está instalada. En Red Hat Enterprise Linux y distribuciones binarias compatibles, el paquete se llama
libaio.El Oracle Instant Client está instalado.
El programa
sqlplusya existe en la instalación o puede haberse instalado como paquete de extensión del cliente.
Como regla general, las condiciones ya se cumplen si hay una instalación de Oracle en el host. De lo contrario, instala los paquetes adecuados para hacerlo.
Para que el plugin de agente se conecte a la base de datos remota, primero almacena los datos de acceso en el archivo de configuración.
Estos son similares a los detalles de DBUSER, que ya has visto en la configuración avanzada de usuario.
Sin embargo, hay una serie de especificaciones adicionales obligatorias:
# Syntax:
# REMOTE_INSTANCE_[ID]='USER:PASSWORD:ROLE:HOST:PORT:PIGGYBACKHOST:SID:VERSION:TNSALIAS'
REMOTE_INSTANCE_1='check_mk:mypassword::myRemoteHost:1521:myOracleHost:MYINST3:11.2'
REMOTE_INSTANCE_myinst1='/:::myRemoteHost:1521::MYINST1:11.2:INST1'
REMOTE_ORACLE_HOME='/usr/lib/oracle/11.2/client64'En el ejemplo, se están configurando dos instancias remotas con dos líneas. Para que cada línea de texto sea única, se define un ID al final de cada variable. Estos se pueden elegir libremente, solo tienen que ser únicos para cada archivo de configuración. Como probablemente ya habrás notado, la especificación del puerto ahora va seguida de otros valores. Estos son en parte opcionales y en parte necesarios para establecer una conexión.
El primer valor nuevo PIGGYBACKHOST se establece en myOracleHost para la instancia MYINST3.
Esta especificación asigna los resultados de la consulta mediante el mecanismo piggyback al host especificado.
Si este está presente como host en Checkmk, los nuevos servicios aparecerán allí en lugar de en el host donde se ejecuta el plugin de agente o desde el que se han obtenido los datos.
No verás esta especificación en la segunda instancia MYINST1, ya que la asignación a otro host es opcional.
El segundo valor nuevo SID es el nombre de la instancia.
Dado que el plugin de agente no puede ver qué instancias se están ejecutando en el host remoto, se debe especificar una línea de configuración para cada instancia remota; por lo tanto, este valor es obligatorio y no opcional.
El tercer valor VERSION es obligatorio y también se debe al hecho de que muchos metadatos solo están disponibles si estás directamente en el host.
Por lo tanto, tampoco se puede omitir la especificación de la versión, ya que determina qué consultas SQL se pueden pasar a la instancia.
En el ejemplo, ambas instancias remotas utilizan la versión 11.2.
El cuarto y último valor TNSALIAS es de nuevo opcional y se puede utilizar si se accede a la instancia remota a través de Oracle Wallet o LDAP/Active Directory.
En el evento de que la instancia responda solo a un alias TNS específico, puedes especificar este alias aquí.
Para la segunda instancia remota, TNSALIAS tiene el valor INST1.
Para asegurarte de que también se encuentra el programa sqlplus, utiliza la variable REMOTE_ORACLE_HOME para especificar dónde se encuentra el cliente Oracle en el host que ejecuta el plugin de agente.
Solo entonces estarán disponibles todos los recursos necesarios para las consultas.
Al consultar instancias remotas, existen algunas restricciones y características especiales:
Dado que has introducido explícitamente las instancias remotas en el archivo de configuración, no puedes excluir estas instancias utilizando
SKIP_SIDSy, a cambio, no es necesario incluirlas utilizandoONLY_SIDS.Las instancias con el mismo nombre (
SID) no se pueden asignar al mismo host. Esto es especialmente relevante si estás recuperando instancias de varios hosts remotos y/o locales donde se utilizan nombres idénticos.
4. Configuración para Windows
4.1. Plugin y rutas de configuración
En Windows, PowerShell se utiliza como lenguaje de scripting para monitorizar bases de datos Oracle. La funcionalidad es similar a la del plugin de agente en sistemas tipo Unix, pero solo contiene una parte de esta. Para utilizar el plugin de agente en Windows, necesitas PowerShell versión 5.x o superior y también los siguientes directorios:
| Sistema operativo | Ruta del plugin | Ruta de configuración |
|---|---|---|
Windows |
|
|
4.2. Instalación del plugin de agente
Después de crear un usuario en la configuración inicial y guardarlo en el archivo de configuración, instala el plugin de agente.
Los plugins de agente para Windows se almacenan en el host durante la instalación del agente Checkmk para Windows.
En el host Oracle, copia el archivo mk_oracle.ps1 del directorio C:\Program Files (x86)\checkmk\service\plugins\ al directorio de plugins descrito anteriormente.
Alternativamente, puedes hacer referencia al archivo en la ruta de instalación actualizando el archivo de configuración del agente Checkmk.
4.3. Características especiales en Windows
Windows normalmente impide la ejecución de scripts de PowerShell si no han sido firmados. Ahora puedes solucionar este problema muy fácilmente modificando las directivas para ejecutar scripts de PowerShell para el usuario que está ejecutando el agente Checkmk:
PS C:\ProgramData\checkmk\agent\> Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine
PS C:\ProgramData\checkmk\agent\> Get-ExecutionPolicy -Scope LocalMachine
BypassEsta opción es útil si deseas probar durante un breve periodo de tiempo un script o la funcionalidad general del agente Checkmk. Para no comprometer la seguridad de tu sistema, revierte esta configuración en los servidores productivos una vez finalizadas las pruebas:
PS C:\Program\checkmk\agent\> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
PS C:\Program\checkmk\agent\> Get-ExecutionPolicy -Scope LocalMachine
RemoteSignedEs comprensible que no quieras cambiar las directrices cada 60 segundos. Por lo tanto, establece una excepción permanente solo para los scripts relevantes. El archivo de configuración del plugin de agente también debe añadirse a las excepciones. Para facilitar la lectura, en este ejemplo se ha omitido completamente la salida:
PS C:\ProgramData\checkmk\agent\> Unblock-File -Path .\plugins\mk_oracle.ps1
PS C:\ProgramData\checkmk\agent\> Unblock-File -Path .\config\mk_oracle_cfg.ps14.4. Opciones avanzadas
En la configuración inicial ya has aprendido las primeras variables para obtener datos de monitorización de tus instancias Oracle. Sin embargo, dependiendo del escenario de aplicación, pronto necesitarás más opciones para poder controlar mejor y de forma individual la monitorización de cada instancia. Las opciones que también están disponibles en Windows se describen en las siguientes secciones.
Configuración avanzada de usuarios
Al igual que en Linux, no solo puedes definir un inicio de sesión estándar para el plugin de agente de Windows, sino también datos de acceso individuales para instancias individuales. Por lo tanto, dispones de las mismas tres opciones para especificar usuarios:
| Parámetro | Descripción |
|---|---|
|
El valor predeterminado si no se han definido datos de acceso individuales para la instancia de base de datos. |
|
Datos de acceso para una instancia de base de datos específica, en este caso para la instancia |
|
Datos de acceso especiales para la gestión automática del almacenamiento (ASM). |
Además, aquí también se pueden especificar otras opciones además del nombre de usuario o la contraseña; estas entradas adicionales también son opcionales, pero cada entrada debe rellenarse si se utiliza. Una configuración podría tener el siguiente aspecto, por ejemplo:
# Syntax
# DBUSER = @("USERNAME", "PASSWORD", "ROLE", "HOST", "PORT")
# Default
# DBUSER = @("", "", "", "localhost", "1521")
$DBUSER = @("checkmk", "myPassword", "SYSDBA", "localhost", "1521")
@DBUSER_MYINST1 = @("cmk_specific1", "myPassword1", "", "10.0.0.73")
@DBUSER_MYINST2 = @("cmk_specific2", "myPassword2", "SYSDBA", "localhost", "1531")
@ASMUSER = @("cmk_asm", "myASMPassword", "SYSASM")Algunas explicaciones sobre el ejemplo anterior:
Puedes definir cualquier número de datos de acceso individuales. Estos siempre tienen preferencia sobre los estándar.
Cada opción se define en una lista. El orden de las entradas no es arbitrario, por lo que no se puede cambiar.
Cuando un campo opcional permanece sin cambios, pero se va a editar un campo siguiente, ambos campos deben especificarse correctamente, como en la entrada «
DBUSER_MYINST2», donde «HOST» sigue estando establecido en «localhost», aunque solo se va a cambiar «PORT».Si los campos opcionales ya no son necesarios después de un cierto punto, se pueden omitir, como en la entrada
ASMUSER, en la que solo se especificó el rol del usuario.Si no se va a asignar ninguna función especial al usuario, pero se va a personalizar
HOSToPORT, simplemente introduce un par de comillas invertidas/comillas dobles ("") en esta posición.
Activación y desactivación de instancias
Incluso en Windows, no siempre se desea incluir determinadas instancias. Las razones 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:
| Parámetro | Descripción |
|---|---|
|
Aquí puedes determinar qué instancias deben monitorizarse. Una instancia se nombra mediante su identificador de sistema (SID). Se trata de una lista positiva, que ignora todas las instancias que no se enumeran explícitamente. Este parámetro es muy útil si el número de instancias que deben monitorizarse es menor que el número de instancias que deben ignorarse. |
|
Dado que el |
El procesamiento 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, solo entonces, si se deben excluir determinadas secciones.
Si la variable EXCLUDE_<SID> está establecida en ALL, no se ejecutará ninguna sección.
A continuación se muestra un ejemplo en el que se muestra cada variable una vez:
$ONLY_SIDS = @("MYINST1", "MYINST3")
$EXCLUDE_INST1 = "tablespaces rman"
$EXCLUDE_INST3 = "ALL"Ten en cuenta que ONLY_SIDS es una lista, mientras que EXCLUDE_INST1 es una cadena que contiene secciones separadas por espacios.
Determinación de los datos que se van a recuperar
La especificación de las secciones que se van a recuperar realmente se realiza de la misma manera que en Linux, y lo siguiente es solo un ejemplo para una configuración de Windows:
# DEFAULTS:
# $SYNC_SECTIONS = @("instance", "sessions", "logswitches", "undostat", "recovery_area", "processes", "recovery_status", "longactivesessions", "dataguard_stats", "performance", "locks")
# $ASYNC_SECTIONS = @("tablespaces", "rman", "jobs", "ts_quotas", "resumable")
# $SYNC_ASM_SECTIONS = @("instance", "processes")
# $ASYNC_ASM_SECTIONS = @("asm_diskgroup")
# $CACHE_MAXAGE = 600
$SYNC_ASM_SECTIONS = @("instance")
$ASYNC_SECTIONS = @("tablespaces", "jobs", "rman", "resumable")
$CACHE_MAXAGE = 300
$EXCLUDE_INST1 = "undostat locks"
$EXCLUDE_INST2 = "jobs' |
Si definís en el archivo de configuración qué secciones deseás recuperar y mediante qué método (también podés cambiar una sección asíncrona a una sincrónica), debés especificar todas las secciones que deben ejecutarse en el área correspondiente. |
Por ejemplo, si solo deseas locks de la consulta sincrónica, especifica toda la lista sincrónica y omite simplemente locks:
# Just exclude 'locks' from sync sections:
$SYNC_SECTIONS = @("instance", "sessions", "logswitches", "undostat", "recovery_area", "processes", "recovery_status", "longactivesessions", "dataguard_stats", "performance")Lo mismo se aplica a las otras tres variables en las que se determinan las secciones.
Derechos de acceso en la ejecución
Por motivos de seguridad, el plugin de agente mk_oracle.ps1 solo ejecuta los binarios de Oracle como administrador si estos programas solo 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á disponible,crsctl.exe.
El plugin de agente mk_oracle.ps1 no ejecuta ninguno de estos programas si los usuarios no administrativos tienen uno de los permisos Write, Modify o Full control para el archivo.
Esto evita el riesgo de seguridad de que usuarios sin privilegios ejecuten programas como administrador.
|
Puedes averiguar en qué versión de parche de Checkmk se realizó este cambio en Werk #15843. |
Si es necesario, cambia los derechos de acceso eliminando los permisos mencionados anteriormente 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 es posible ajustar los permisos para los programas Oracle de forma segura, puedes permitir que usuarios y grupos individuales ejecuten los programas:
# Oracle plugin will allow users and groups in the list to have write access to the Oracle binaries
$WINDOWS_SAFE_ENTRIES=@("NT AUTHORITY\Authenticated Users", "<Domain>\<User>")Solo si no hay otra forma de garantizar la monitorización de Oracle, puedes desactivar la comprobación de derechos de acceso como última opción.
|
Si desactivas la comprobación de derechos de acceso, el plugin de agente ya no se ejecutará de forma segura. |
# Oracle plugin will not check if the used binaries are write-protected for non-admin users
$SKIP_ORACLE_SECURITY_CHECK=1Sin embargo, también hay 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 la siguiente manera:
plugins:
enabled: yes
execution:
- pattern: $CUSTOM_PLUGINS_PATH$\mk_oracle.ps1
async: yes
group: Users
run: trueEn las ediciones comerciales, puedes crear estas entradas con Agent Bakery con la regla de agente Run plug-ins and local checks using non-system account.
4.5. Monitorización de bases de datos remotas
Actualmente no es posible monitorizar bases de datos remotas utilizando el plugin de agente de Windows. Por lo tanto, si deseas monitorizar bases de datos remotas, necesitas un host con un sistema operativo compatible con Unix.
5. Configuración con Agent Bakery
La configuración se puede simplificar considerablemente en las ediciones comerciales con Agent Bakery, ya que se evitan los errores de sintaxis en los archivos de configuración y se pueden implementar más fácilmente las adaptaciones a entornos cambiantes. La principal diferencia con respecto a una configuración manual es que solo es necesario trabajar en el host Oracle en la línea de comandos si deseas realizar configuraciones especiales específicas de Oracle. Puedes realizar la configuración con Agent Bakery para Linux, Solaris, AIX y Windows.
Sin embargo, no es posible configurar todas las funciones del plugin de agente con Agent Bakery, por ejemplo, si se trata de funciones que requieren una intervención importante y conocimientos especializados profundos. Por lo tanto, las consultas SQL personalizadas no se pueden configurar en Agent Bakery.
A través de Setup > Agents > Windows, Linux, Solaris, AIX y el menú « Agents > Agent rules », encontrarás la página con el conjunto de reglas « Oracle databases (Linux, Solaris, AIX, Windows) ». Crea una nueva regla con « Add rule ». Aquí encontrarás todas las opciones disponibles para configurar el plugin de agente:
Muchas opciones te resultarán familiares de la configuración manual. Tal y como se describe allí, hay opciones que no están disponibles para todos los sistemas operativos. El título de estas opciones indica para qué sistemas operativos se pueden utilizar.
5.1. Configuración de usuarios
En la configuración más sencilla para un sistema operativo tipo Unix, la regla tendrá un aspecto similar al siguiente:
En Agent bakery también tienes la opción de crear usuarios estándar y excepciones para casos concretos. Las opciones, separadas en el archivo de configuración con dos puntos (para Linux y similares) o como entradas de la lista (para Windows), las encontrarás en Login Defaults como opciones individuales que podrás rellenar según tus necesidades. Por supuesto, también puedes utilizar Oracle Wallet aquí cambiando simplemente Authentication method por Use manually created Oracle password wallet.
La configuración de la gestión automática del almacenamiento (ASM) se realiza de forma análoga a través de la opción Login for ASM y las excepciones para instancias específicas se introducen en Login for selected databases, tal y como se describe en la configuración avanzada para usuarios de Linux, Solaris, AIX y Windows.
5.2. Opciones avanzadas
La siguiente tabla lista las opciones restantes en el conjunto de reglas Oracle databases (Linux, Solaris, AIX, Windows), junto con una referencia a dónde encontrar una descripción de la opción:
| Opción | Descripción |
|---|---|
Host uses xinetd or systemd (Linux/AIX/Solaris only) |
Esta opción debe estar activada para sistemas tipo Unix con |
Instances to monitor |
Esta opción resume varias opciones del archivo de configuración con las que puedes incluir o excluir instancias para Linux, Solaris, AIX o Windows. |
Add pre or postfix to TNSALIASes (Linux/AIX/Solaris only) |
Esta opción te permite ampliar el alias TNS de forma global o para una instancia específica. |
Sections - data to collect |
Todas las secciones disponibles se listan en esta opción y se pueden configurar individualmente a nivel global.
Por lo tanto, corresponden a las variables |
Exclude some sections on certain instances |
Si no deseas utilizar |
Cache age for background checks |
Especifica aquí cuánto tiempo deben permanecer válidas las secciones asíncronas. El valor por defecto es 600 segundos (10 minutos). |
Sqlnet Send timeout |
Esta opción se añade al archivo |
Remote instances (Linux/AIX/Solaris only) |
Configura las instancias remotas con esta opción. Contiene todos los elementos de la configuración que ya conoces. Para especificar el ID de la variable, a través de Unique ID puedes seleccionar entre varias opciones. Solo tienes que asegurarte de que el ID sea único dentro de la configuración. |
ORACLE_HOME to use for remote access (Linux/AIX/Solaris only) |
Aquí puedes determinar dónde encuentra el plugin de agente el programa |
TNS_ADMIN to use for sqlnet.ora and tnsnames.ora (Linux/AIX/Solaris only) |
Si los dos archivos se encuentran en un directorio distinto de |
sqlnet.ora permission group (Linux/AIX/Solaris only) |
Introduce aquí el grupo Linux del usuario sin privilegios propietario de los binarios Oracle para que este usuario pueda leer el archivo |
Oracle binaries permissions check (Windows only) |
Aquí puedes configurar la comprobación de derechos de acceso para los binarios de Oracle permitiendo a usuarios y grupos individuales no administrativos ejecutar los programas. Solo debes desactivar la comprobación si sabes lo que estás haciendo. Encontrarás más información sobre este tema en la sección Derechos de acceso en la ejecución para Windows. |
6. Instancias en clúster
6.1. Bases de datos en espera
Oracle admite las denominadas bases de datos en espera, que pueden realizar tareas específicas y que suelen ser simples copias de las bases de datos de producción o primarias. Estos conceptos de bases de datos también requieren mecanismos de monitorización especiales. Encontrarás más información sobre estos mecanismos en las secciones siguientes.
Con Active Data Guard (ADG)
Una vez que hayas licenciado y activado ADG, no es necesario realizar 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 principal.
Sin Active Data Guard (DG)
Si las instancias no tienen ADG, el usuario con el que se deben recuperar los datos de monitorización de las instancias en espera necesita el rol SYSDBA.
Este permiso permite al usuario recuperar al menos parte de los datos, incluso si la instancia primaria falla y la instancia del servidor en espera aún no se ha cambiado de MOUNTED a OPEN.
Asigna el permiso al usuario que está 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:
sqlplus> grant sysdba to checkmk;Para permitir que el plugin de agente pueda consultar los datos en el servidor en espera en caso de error, crea el usuario en la instancia principal y, a continuación, copia el archivo de contraseñas al servidor en espera.
Por último, en el archivo de configuración del plugin, establece el rol del usuario en SYSDBA:
# Syntax:
# DBUSER='USER:PASSWORD:ROLE:HOST:PORT:TNSALIAS'
DBUSER='checkmk:myPassword:sysdba'Ten en cuenta que especificar un host, puerto o alias TNS es opcional y se puede omitir. Además, el plugin de agente debe estar instalado en el host de la instancia principal, así como en los hosts de las instancias en espera.
Configuración de los servicios de clúster
En Checkmk, es necesario, independientemente de si usas ADG o DG, personalizar los servicios y asignarlos a un host de clúster. Los plugins de check correspondientes ya están preparados para que también se puedan configurar como servicios de clúster. Crea un host de clúster en Checkmk y añade los hosts Oracle individuales en los que se ejecutan las instancias primaria y en espera como nodos. A continuación, asigna los siguientes servicios a este host de clúster:
ORA .* RMAN BackupORA .* JobORA .* Tablespaces
Después de esto, ya no tendrás que preocuparte de la instancia de la que proceden los datos y habrás garantizado una monitorización perfecta de los servicios mencionados anteriormente, incluso en caso de conmutación de la instancia principal.
6.2. Real Application Cluster (RAC)
Dado que en un RAC hay un almacenamiento central para los datos, basta con crear el usuario para el plugin de agente una sola vez. Solo es necesario instalar y configurar el plugin de agente en cada nodo del clúster Oracle.
Importante: configura siempre los nodos del clúster tú mismo y no consultes el listener SCAN de Oracle. Esta es la única forma de garantizar que el acceso a través del plugin de agente funcione correctamente.
Configuración de servicios de clúster
También es recomendable configurar servicios de clúster para un RAC. Además de los servicios que asignas al host de clúster en un Data Guard (activo), también asignas los siguientes servicios al host de clúster para garantizar una monitorización sin interrupciones en caso de un cambio de switch:
ASM.* DiskgroupORA .* Recovery Area
7. Consultas SQL personalizadas (SQL personalizadas)
7.1. ¿Por qué consultas SQL personalizadas?
Con su plugin de agente, Checkmk ya ofrece un gran número de consultas SQL con las que podéis monitorizar vuestras instancias de base de datos. Para que se adapten al mayor número posible de requisitos técnicos y de contenido, se mantienen, por supuesto, en un formulario muy generalizado.
Para poder satisfacer los requisitos individuales de cada empresa para la monitorización de una base de datos específica, Checkmk ofrece la posibilidad de crear tus propias consultas SQL personalizadas (SQL personalizadas, por sus siglas en inglés) y recuperarlas con el plugin de agente. Estas consultas SQL personalizadas se reconocen y monitorizan automáticamente como servicios propios en la interfaz web.
|
Las consultas SQL personalizadas solo se pueden utilizar en Linux, Solaris y AIX. Esta opción no está disponible en Windows. |
7.2. Consultas SQL personalizadas simples
Escribir consultas SQL
La forma más sencilla de conectar una SQL de este tipo es utilizar el plugin de Oracle Database: Custom SQLs check.
Para ello, primero crea el archivo MyCustomSQL.sql en el directorio de configuración del agente en el host en el que se va a ejecutar la SQL.
A continuación se muestra un ejemplo que ilustra la sintaxis:
/*Syntax help in comments. The first word is alwyas the key word and ends with a ":"*/
/*details:Text to display in the service detail output*/
prompt details: Some details for the service output;
/*perfdata:METRIKNAME=CURRENTVALUE;WARN;CRIT;MAX METRIKNAME=CURRENTVALUE2;WARN;CRIT;MAX*/
prompt perfdata:MyMetricName1=10;15;20;30 MyMetricName2=16;15;20;30;
prompt perfdata:MyMetricName3=21;15;20;30 MyMetricName4=15;15;20;30;
/*long:Text to display in the long output of the service*/
prompt long: Here comes some long output for the service;
prompt long: Here comes some more long output for the service;
/*exit:Status of the service as a number*/
prompt exit:2;El ejemplo muestra, por un lado, que puedes definir cualquier número de sentencias en un archivo de este tipo. Por otro lado, la sintaxis es muy similar a la de un local check, especialmente en lo que respecta a las métricas. En detalle, esta sintaxis es mucho más potente aquí, porque puedes generar salidas de varias líneas, que luego se procesan 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 las siguientes:
details: Aquí puedes determinar qué se debe mostrar en el servicio generado Summary. Esta línea se introduce con la palabra clave y dos puntos. El resto de la línea es la salida.perfdata: Las métricas se pasan con esta palabra clave. Dentro de una línea, puedes crear cualquier número de métricas, cada una separada por un espacio. También puedes distribuir la salida de las métricas en varias líneas. Solo tienes que empezar siempre con la palabra claveperfdata:.long: Si el servicio debe tener una salida larga para el campo Details, puedes especificarlo aquí. También puedes utilizar esta palabra clave varias veces para crear varias líneas en Details.exit: Si la salida debe tener un estado determinado, puedes especificarlo aquí. Las asignaciones conocidas0,1,2,3están disponibles para los estados OK, WARN, CRIT, UNKNOWN.
|
No es necesario definir manualmente la palabra clave |
Configuración del plugin de agente
Ahora que has definido tu primer SQL, muy sencillo, haz que el plugin de agente mk_oracle lo conozca.
Esto se hace a través del conocido archivo de configuración, que puedes ampliar según corresponda:
SQLS_SECTIONS="mycustomsection1"
mycustomsection1 () {
SQLS_SIDS="INST1"
SQLS_DIR="/etc/check_mk"
SQLS_SQL="MyCustomSQL.sql"
}Con la primera opción (SQLS_SECTIONS) determinas qué secciones individuales deseas que se ejecuten.
Ten en cuenta que sección aquí significa una parte de la salida del plugin de agente, y no una parte de una instancia de base de datos.
En el ejemplo, solo hemos especificado una sección (mycustomsection1) y luego la hemos descrito con más detalle directamente a continuación.
Cada sección es en realidad una pequeña función llamada por el plugin de agente.
En esta función, puede determinar más detalles y especificar a qué instancias (SQLS_SIDS) se aplica esta sección.
Además, también define 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. A continuación, verás este nuevo servicio junto con los demás servicios en la vista general del host:
7.3. Opciones avanzadas
Las posibilidades de monitorización con consultas SQL personalizadas van, por supuesto, más allá del sencillo ejemplo mostrado anteriormente.
A continuación encontrarás una vista general de las variables disponibles que puedes utilizar en el archivo de configuración mk_oracle.cfg.
Para obtener una descripción detallada, también puedes llamar al plugin de agente mk_oracle con la opción --help.
|
Las variables que solo se pueden establecer fuera o dentro de una función de sección están marcadas como tales. Todas las demás se pueden definir en ambas secciones. Si se establecen fuera de una sección, se aplicarán globalmente a todas las secciones. |
| Variable | Breve descripción | Opcional |
|---|---|---|
|
Las funciones de sección autodefinidas que debe ejecutar el plugin de agente. |
No |
|
Las instancias que deben ejecutar la sección o secciones. |
No |
|
El nombre de la ruta del directorio en el que se almacenan los archivos con las consultas SQL personalizadas. |
No |
|
El archivo que contiene las sentencias SQL para una sección. |
No |
|
El nombre de la sección que evalúas con un plugin check propio para las consultas SQL personalizadas. |
Sí |
|
El separador de los elementos individuales en una línea de la salida, definido como un ID ASCII decimal.
Esta variable solo se puede utilizar junto con la variable |
Sí |
|
Especifica una parte del nombre del servicio generado.
Por defecto, el nombre del servicio se compone del SID y del nombre del archivo con las consultas SQL personalizadas.
El valor de esta variable sustituye al nombre del archivo en el nombre del servicio. |
Sí |
|
Realiza la misma tarea que |
Sí |
|
Define un usuario individual para una sección. |
Sí |
|
Define la contraseña del usuario definido con |
Sí |
|
Solo si el usuario definido con |
Sí |
|
Define un alias TNS individual para una sección. |
Sí |
7.4. Uso de tus propios plugins de check
Si las posibilidades de la sintaxis descrita anteriormente no son suficientes, también puedes utilizar la variable SQLS_SECTION_NAME para generar tus propios nombres de sección para una o varias consultas SQL y definir tu propio separador con SQLS_SECTION_SEP.
Sin embargo, esto requiere que también hayas escrito un plugin de comprobación adecuado y lo hayas incluido en tu site Checkmk.
Si has escrito un plugin de comprobación de este tipo, tienes total libertad para evaluar la salida de las secciones autodefinidas del plugin de agente y puedes seguir tu propio camino. Dado que este método es el más completo, y también el más difícil, solo se menciona aquí para completar la información. Se da por supuesto que sabes cómo escribir un plugin de comprobación basado en agentes e integrarlo en el site. A continuación, asignas las consultas SQL personalizadas con las variables a este plugin de comprobación.
8. Opciones de diagnóstico
En Linux, los diagnósticos se realizan llamando al plugin de agente mk_oracle con varias opciones.
Con mk_oracle --help puedes mostrar una vista general de todas las opciones disponibles.
8.1. Comprobación de conexiones
|
La prueba de conexión que se describe a continuación también comprueba si se han establecido los derechos de acceso necesarios durante la ejecución en Linux o Windows. Si faltan derechos de acceso, estos se muestran con sugerencias específicas para su rectificación. El procedimiento exacto para diagnosticar y corregir los derechos de acceso se puede encontrar en la base de conocimientos de Checkmk. |
Linux, Solaris, AIX
Si tienes problemas para conectarte a una o varias instancias en 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 muestran los detalles de una conexión.
Ten en cuenta que el plugin de agente debe disponer previamente de las rutas a su archivo de configuración y a los datos almacenados en caché del plugin.
En la salida se han omitido las secciones ficticias para facilitar la lectura.
El siguiente ejemplo es para un servidor Linux con systemd, en el que el plugin de agente se ejecuta de forma asíncrona cada 60 segundos:
root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -t --no-spool
---login----------------------------------------------------------------
Operating System: Linux
ORACLE_HOME (oratab): /u01/app/oracle/product/11.2.0/xe
Logincheck to Instance: XE
Version: 11.2
Login ok User: checkmk on ORA-SRV01 Instance XE
SYNC_SECTIONS: instance dataguard_stats processes longactivesessions sessions recovery_status undostat logswitches recovery_area performance
ASYNC_SECTIONS: tablespaces rman jobs ts_quotas resumable
------------------------------------------------------------------------En un servidor Linux con xinetd, llama a mk_oracle para la prueba de conexión de la siguiente manera:
root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -tDado que 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 primeros 100 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 de configuración sencillos y corregirlos en consecuencia.
Windows
El plugin de agente no acepta ningún parámetro en Windows.
Por lo tanto, para probar la conexión aquí, limita temporalmente las secciones que se van a recuperar a instance y activa la opción DEBUG:
# Syntax:
# $DBUSER = @("USERNAME", "PASSWORD")
$DBUSER = @("checkmk", "myPassword")
SYNC_SECTIONS = @("instance")
ASYNC_SECTIONS = @("")
DEBUG = 1A continuación, ejecuta el plugin de agente manualmente. De nuevo, obtendrás información sobre cómo el plugin intenta acceder a las instancias. El resultado podría ser similar al siguiente:
PS C:\ProgramData\checkmk\agent\plugins\> .\mk_oracle.ps1
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of DBVERSION software = xxx112020xxx
<<<oracle_instances>>>
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of inst_name = xxxXExxx
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of DBVERSION database = xxx112020xxx
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of the_section = sql_instance
2020-08-23T12:48:20.3930944+02:00 DEBUG:now calling multiple SQL
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of sql_connect in dbuser = checkmk/myPassword@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SID=XE))) as sysdba
<<<oracle_instance>>>
XE|FAILURE|...8.2. Registro
Linux, Solaris, AIX
Si no se encuentra el error al comprobar una conexión simple, el siguiente paso es crear un archivo de registro que registre todos los pasos del plugin de agente. No olvides aquí tampoco 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:
root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -l --no-spool
Start logging to file: /var/lib/check_mk_agent/log/mk_oracle.logAquí está la llamada de mk_oracle para registrar en un servidor Linux con xinetd:
root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -lPuedes utilizar el archivo de registro generado para identificar con gran precisión en qué línea del script se ha producido el problema.
Windows
El registro en Windows funciona de manera similar a la prueba de conexión descrita anteriormente. Si la conexión es estable, puedes volver a añadir las secciones reales al archivo de configuración y obtener así un registro completo.
8.3. Depuración
Linux, Solaris, AIX
Si no puedes localizar el 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 lo 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 solo 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:
root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -d --no-spoolAquí está la llamada de mk_oracle para la depuración en un servidor Linux con xinetd:
root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -dImportante: En esta salida, los datos confidenciales, como las contraseñas, no están ocultos. Por lo tanto, todo se puede leer en texto sin formato.
Windows
En Windows hay disponible una funcionalidad similar. Sin embargo, dado que no puedes pasar ningún argumento al plugin de agente, tendrás que activar el seguimiento manualmente:
PS C:\ProgramData\checkmk\agent\plugins\> Set-PSDebug -Trace 1
PS C:\ProgramData\checkmk\agent\plugins\> .\mk_oracle.ps18.4. Mensajes de error en los archivos de registro de Oracle
El usuario de la base de datos para la monitorización no suele requerir el rol « SYSDBA ».
Sin embargo, ten en cuenta que el plugin de agente « mk_oracle » puede generar mensajes de error (no relevantes para la monitorización) con bases de datos multi-tenant que pueden no escribirse en los archivos de registro de la base de datos Oracle debido a la falta del privilegio « SYSDBA ».
Esto puede provocar, por ejemplo, mensajes de error de Oracle del tipo « ORA-01031: insufficient privileges » en un archivo de registro de alertas.
9. Archivos y directorios
9.1. En el host Oracle bajo Linux, Solaris, AIX
| Ruta del archivo | Descripción |
|---|---|
|
El agente Checkmk que recopila todos los datos sobre el host. |
|
El plugin de agente Oracle en el directorio habitual para plugins de agente.
Ten en cuenta que el nombre de la ruta en AIX es ligeramente diferente: |
|
El archivo de configuración del plugin de agente.
De nuevo, AIX es diferente: |
|
El archivo de configuración necesario para Oracle Wallet. |
|
El archivo de configuración que contiene los alias TNS. Los archivos de ejemplo también se encuentran en la instalación de Oracle, pero como la ruta difiere de una instalación a otra, no se puede especificar de forma estandarizada. |
9.2. En el host Oracle en Windows
| Ruta del archivo | Descripción |
|---|---|
|
El agente Checkmk que recopila todos los datos sobre el host. |
|
El plugin de agente Oracle en el directorio habitual para plugins de agente. |
|
El archivo de configuración del plugin de agente. |
|
El archivo de configuración necesario para Oracle Wallet. |
|
El archivo de configuración que contiene los alias TNS. Los archivos de ejemplo también se encuentran en la instalación de Oracle, pero como la ruta varía de una instalación a otra, no se puede especificar de forma estandarizada. |
9.3. En el servidor Checkmk
| Ruta del archivo | Descripción |
|---|---|
|
El plugin de agente para sistemas tipo Unix, que recupera los datos en el host Oracle. |
|
Este plugin de agente para sistemas tipo Unix proporciona datos a un Oracle Cluster Manager. |
|
El plugin de agente para Windows, que recupera los datos en el host Oracle. |
|
A continuación se muestran archivos de configuración de ejemplo para sistemas similares a Unix en los archivos |
|
Un archivo de configuración de ejemplo para Windows. |