Pular para o conteúdo principal

Alertas pelo Telegram usando Oracle Cloud Control 12c

O objetivo deste post é demonstrar como realizar a configuração de alertas através do Telegram dentro da ferramenta de monitoramento Oracle Cloud Control 12c usando Oracle Linux Server.

Para começar, será preciso instalar e configurar a ferramenta Telegram messenger CLI. Não entrarei em detalhes de como instalar e configurar está ferramenta, pois existem vários posts na internet ensinando.Caso tenha algum problema, mande uma mensagem que tentarei ajudar.


Criando os scripts no sistema operacional
Vamos para configuração dos nosso alertas. Dentro do sistema operacional em que a ferramenta de monitoramento está em execução, foram criados dois scripts. Segue o nome e descrição deles:

func_alerts.fn => contém as funções básicas do Telegram CLI que serão usadas na integração com o Telegram.
critical_alert.sh => Script de integração com o Cloud Control. Ele será chamado dentro da ferramenta de monitoramento da Oracle e importa as funções criadas no func_alerts.fn

O uso das funções contidas no func_alerts.fn é bem simples. Basta importar o script e chamar as funções com seus parâmetros. O parâmetro 1 é o nome do usuário do Telegram e o 2 é mensagem ou o arquivo dependendo da função que vai usar.

Exemplo de uso no prompt do Linux

source /home/oracle/telegram/func_alerts.fn
send_telegram @thiagocastro "Mensagem de teste"



Código das Funções

func_alerts.fn

#=========================================
#FUNCOES PARA USO DO TELEGRAM
#========================================+
function send_telegram(){
/u01/tg/bin/telegram-cli -W -e "msg $1 $2"
}

function send_telegram_file(){
/u01/tg/bin/telegram-cli -W -e "send_file $1 $2"
}

function user_info(){
/u01/tg/bin/telegram-cli -W -e "user_info $1"
}

function send_location(){
/u01/tg/bin/telegram-cli -W -e "send_location $1 $2 $3"
}




critical_alert.sh

#============================================
#Script para integração com Cloud Control
#============================================

#consulta de usuarios cadastrados no grupo Banco de dados e criacao do array
usuarios=($(mysql --column-names=FALSE -u usuario -p senha -h IP -e "CONSULTA COM OS USUARIOS DO TELEGRAM"))

#importa as funcoes para envio de mensagem Telegram
source /home/oracle/telegram/func_alerts.fn

#Loop para enviar as mensagens para os usuário que retornaram da consulta
for ((x=0; x < ${#usuarios[*]}; x++))
do
       send_telegram ${usuarios[$x]} "$TARGET_NAME  - $MESSAGE - $EVENT_REPORTED_TIME"
done





Obs: No script critical_alert.sh as variáveis $TARGET_NAME, $MESSAGE e $EVENT_REPORTED_TIME são passadas quando o script é chamado através da ferramenta Cloud Control. Para mais detalhes acesse a documentação


Criando a notificação no Cloud Control

Aqui iremos criar o método de notificação. Faremos referência ao script já criado no sistema operacional. Para isso acesse.

Acesso Configurar > Notificações > Métodos de Notificação


Selecione "Comando do SO" e depois clique no botão ao lado. Abaixo grifado.





Preencha as informações de acordo com o local que você criou o script critical_alert.sh. Depois faça o teste com o botão "Testar Comando do SO".



Caso o teste seja realizado com sucesso, você receberá uma mensagem como a listada abaixo.




Após testar e salvar sua tela com notificações ficara assim:



Agora que já temos a notificação configurada é só adicionar as suas regras de incidentes que já existem ou criar um nova.

Configurar > Incidentes > Regras de Incidente




Espero que tenha ajudado!






Comentários

Postagens mais visitadas deste blog

Configurando a política de retenção de backups no RMAN

                       Configurando a politica de reten çã o de backups no RMAN        O objetivo deste post é explicar como podemos configurar a reten çã o de backups na poderosa ferramenta de backup do bando de dados Oracle RMAN. Podemos configurar nossa pol í tica tendo por base dois tipos: janela de recupera çã o (recovery window) ou redundãncia (redundancy). Abaixo iremos abordar os dois tipos.       Para identificar qual dos dois tipos o RMAN está usando, use: RMAN> show retention policy; Política baseada em redundância CONFIGURE RETENTION POLICY TO REDUNDANCY 1; Política baseada em janela de recuperação CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS; ·        Política baseada em redund â ncia ( REDUNDANCY )       De uma maneira bem simples e objetiva, o par â metro REDUNDANCY especifica quantos backups full ou incremental level 0 de cada datafile o RMAN vai manter, os demais são considerados obsoletos. Veja o exemplo abaixo

Permissões necessárias para criar triggers no Oracle

Há pouco tempo passei por um problema durante a criação de uma trigger de LOGON na versão 12c do banco de dados Oracle. Estava com alguns problemas em uma aplicação que tinha uma trigger de Logon. A trigger em si era bem simples, vou por o código mais abaixo, o problema é que ela estava criada dentro do usuário SYSTEM. Provavelmente foi a maneira mais fácil e preguiçosa de criar o objeto, uma vez que o SYSTEM já possui todas as permissões necessárias para criação. Porém isso não uma boa prática. Então resolvi tirar do SYSTEM e jogar para o usuário dono dos objetos da aplicação. Quando fui tentar criar o objeto no SCHEMA dono dos objetos da aplicação, recebi um erro com falta de permissões: ORA-01031: insufficient privileges . O erro ocorreu porque estava esquecendo de conceder a role ADMINISTER DATABASE TRIGGER para o usuário. Em resumo, as permissões necessárias para criação de uma trigger: CREATE TRIGGER - para criar uma trigger no seu próprio esquema (SCHEMA) CREATE AN

ORA-01623 ORA-00312 - Removendo redo logs

Após realizar um restore de um ambiente de Oracle RAC para um single instance usando snapshot de storage, tentei recriar os redo logs recebi o seguinte erro durante a exclusão de um grupo de discos. SQL> alter database drop logfile group 2; ORA-01623: o log 2 é o log atual para a instância UOW (thread 1) - não é possível eliminar ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.1638.1051804433' ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.981.1051804433' O erro quer dizer que o grupo de redo pertence a outra thread. Quer dizer que ele pertence a outra instância do ambiente RAC. Como no meu caso não precisarei mais dela, basta usar o comando: SAL> alter database disable thread 2; Database altered.   Usei o SQL abaixo para gerar os comandos para excluir os redo logs SQL> select distinct 'alter database drop logfile group '||(group#)||';' from v$log where thread#=2; 'ALTERDATABASEDROPLOGFILEGROUP'||(G