Solucionando problemas do Console do operador

2
2
O UIM 20.3.3 eliminou a dependência do CABI (CA Business Intelligence) para o processamento das telas do OC nativo: página inicial, página de exibição de grupos, página de exibição de dispositivos e página de exibição de tecnologias de monitoramento (probes). Os painéis e relatórios personalizados e prontos para uso ainda são processados por meio do CABI, ou seja, eles dependem do CABI. Contudo, as telas do console do operador nativo não dependem mais do CABI (Jaspersoft) e são processadas por meio de HTML5. Para obter mais informações sobre as telas do OC nativo que usam HTML5, consulte o artigo Configurando e exibindo dados de monitoramento ou a seção Removendo a dependência do CABI (Console do operador nativo) do artigo UIM 20.3.3.
OC (Operator Console - Console do operador) sendo instalado no hub principal, e não no servidor do UMP
Sintoma:
Estou atualizando o ambiente 8.51, 9.02, 9.2 ou 20.1 para 20.3 e o programa de instalação do Console do operador (OC) está tentando instalar o OC no hub principal em vez de fazê-lo no servidor do UMP. Como posso resolver esse problema?
Solução:
O Console do operador procura o probe wasp e, em seguida, procura um arquivo. Se ele encontrar o arquivo no hub principal, o OC será instalado no hub principal. E não é possível alterar o destino da instalação para o servidor do UMP.
Se o programa de instalação do OC tentar implantar o OC no hub principal, cancele a atualização e siga o procedimento a seguir.
Esse processo também funcionará se o OC já tiver sido instalado no hub principal.
  1. Faça backup do arquivo wasp.cfg que está disponível no hub principal.
  2. Execute o programa de desinstalação do wasp.
  3. Na lista de pacotes instalados do controlador, verifique se existem pacotes relacionados ao UMP/OC. (Consulte a Etapa 4 para obter a lista de pacotes que devem ser removidos.)
    1. Se existirem pacotes, vá para a Etapa 4 e desinstale-os usando o utilitário do probe.
    2. Caso contrário, vá para a Etapa 11 e exclua a pasta wasp.
  4. No IM, clique no probe principal do controlador do robô para realçá-lo (não abra a UI).
    primary robot controller probe
  5. Pressione Ctrl-p para abrir o utilitário do probe.
  6. Use o retorno de chamada inst_pkg_remove do probe do controlador para remover os pacotes do UMP/OC. Ou seja, o wasp inst_pkg_remove. Localize o pacote inst_pkg_remove na lista suspensa.
  7. Na seção de pacote, digite o pacote que deseja excluir.
    primary robot controller probe
  8. Use o utilitário do probe para remover os seguintes probes:
    • wasp_service_wrapper
    • nisapi_wasp
    • UMP
    • ump_operatorconsole
    • wasp_alarmviewer_api
    • policy-management-ws
    • mcs-ui-app-portlet
    • ump_cabi
    • ump_accountadmin
    • ump_dashboard
    • adminconsoleapp
    • uimhome
    • uimesdplatelemetry
    • mps
    • WASP
  9. Se você receber um erro ao clicar no botão Executar (ícone de reprodução), implante o probe novamente no hub principal e execute o pacote inst_pkg_remove.
  10. Verifique se você removeu os aplicativos abrindo a UI do controlador e acessando a guia Status, Pacotes instalados.
    primary robot controller probe
  11. Remova a pasta wasp do sistema de arquivos.
  12. Implante os pacotes wasp, adminconsoleapp, uimhome e uimesdplatelemetray no hub principal novamente.
  13. Se o arquivo wasp.cfg anterior precisar ser reutilizado, apague os aplicativos web do UMP/OC da seção de aplicativos web do arquivo .cfg e substitua-o.
  14. Ative o probe wasp.
  15. Execute o programa de instalação do OC novamente. Ele deve encontrar o servidor do UMP. Na captura de tela a seguir, a configuração tem dois servidores do UMP e o programa de instalação selecionou o servidor secundário do UMP. Permita que o programa de instalação seja executado nele.
    primary robot controller probe
  16. Depois que a instalação do OC estiver concluída no UMP secundário, desative o robô no OC que agora é secundário.
  17. Execute novamente o programa de instalação do OC para atualizar o UMP principal.
    primary robot controller probe
  18. Ative o robô do OC secundário.
  19. Verifique se a implantação está funcionando em ambos os servidores.
O painel do CABI não está sendo exibido no OC
Sintoma:
Os painéis do CABI não são exibidos no OC para todos os usuários com todos os tipos de navegador. A mensagem de erro informando a
ausência do componente do sistema
é exibida na UI do OC. O wasp.log do OC é o seguinte:
DEBUG [https-jsse-nio-443-exec-7, com.firehunter.ump.utils.ProbeAddress] Unable to get port_list for robot : null ERROR [https-jsse-nio-443-exec-7, com.ca.cabi4uim.controllers.CABIController] Unable to initialize cabi probe client: Unable to communicate with any of the possible cabi probes: cabi,cabi_external
Os detalhes do ambiente são os seguintes:
  • O UIM 20.3 com o ump_operatorconsole v2.06 e o CABI v4.30 estão em robôs separados.
  • HTTPS está ativado no OC e no CABI.
  • Os painéis do UIM CABI estão funcionando bem com um logon direto para o CABIJS.
Solução:
Estas etapas podem ajudar a resolver o problema:
  • Faça download de robot_update_9.32.zip do índice do hot fix do CA Unified Infrastructure Management e importe-o para o arquivo do UIM.
  • No robô do CABI, implante robot_update_9.32.
  • No robô do OC, siga estas etapas:
    • Desative o probe wasp.
    • Renomeie ...\Nimsoft\probes\service\wasp\webapps\cabi.
    • Renomeie ...\Nimsoft\probes\service\wasp\work.
    • Implante o robot_update_9.32.
    • Implante ump_cabi 4.22 e confirme se a data modificada para ...\Nimsoft\probes\service\wasp\webapps\cabi.war foi atualizada.
    • Ative o probe wasp.
A página inicial do OC não está carregando
Sintoma:
Ao efetuar logon no OC 20.3, a página inicial do OC não é carregada.
Solução:
Não feche a página nem clique em qualquer outra opção. Aguarde até que a página inicial do OC seja completamente carregada; ela será carregada após algum tempo.
O OC está redirecionando para a página de logon do CABI
Sintoma:
A página inicial do OC não estava carregando quando eu efetuava logon no OC 20.3. E, quando eu clicava na opção Relatórios no painel esquerdo, era redirecionado para a página de logon do CABI.
Solução:
Permita que a página inicial do OC seja carregada completamente antes de selecionar qualquer outra opção. O OC e o CABI são aplicativos web diferentes/separados. Para que o JasperServer crie uma sessão para o CABI, o processo de carregamento da página inicial permite que isso aconteça. Ao selecionar a opção Relatórios antes que a página inicial do OC seja carregada, você será redirecionado
inesperadamente
para a página de logon do CABI. Após o carregamento da página inicial, a sessão é armazenada em cache e o redirecionamento para a página de logon do CABI não ocorre mais. Se a sessão do OC ficar ociosa por 15 a 20 minutos, o tempo limite da sessão do CABI pode se esgotar. Nesse caso, selecione a página inicial e permita que ela seja carregada novamente.
OC tentando se instalar no servidor CABI
Sintoma:
No meu ambiente, durante a atualização para 20.3.1, a instalação do OC estava tentando instalar o OC no servidor do CABI. Não houve tentativa de instalação no UMP (nem mesmo no hub principal, como documentado acima). Durante a instalação, a lista suspensa não estava listando nenhum servidor no qual eu pudesse instalar o OC. Não era me dada nenhuma opção; por exemplo, o programa não estava permitindo instalar no servidor do UMP. Ele estava tentando instalar apenas no servidor do CABI.
Solução:
Como solução alternativa, é possível seguir estas etapas:
  • Antes de iniciar a instalação do OC, desligue o robô do CABI.
  • Inicie a instalação do OC. A lista suspensa agora permite que você selecione o servidor do UMP em que é possível instalar o OC.
Os grupos, as contas e os SLAs do SLM não estão visíveis no OC
Sintoma:
Após a atualização para 20.3.x, os grupos, as contas e os SLAs do SLM não ficam visíveis no OC. Tenho vários SLAs e várias contas, e eles estão no banco de dados.
Solução:
Se houver um alarme de SLA com warning_severity = null, esse problema poderá ocorrer. Isso gera um erro que impede que o navegador recupere a lista do SLM (no OC) com as contas e os grupos. Como solução alternativa, siga estas etapas:
  1. Execute a seguinte consulta no banco de dados:
    select sla_id from S_SLA_ALARM where warning_severity is null
  2. Copie o sla_id e execute a seguinte consulta de atualização:
    update S_SLA_ALARM set warning_severity =0 where sla_id =<from the first query>
    Repita a operação para todas as ocorrências de warning_severity com valor null e substitua por 0.
  3. Efetue logoff e logon novamente.
    O problema deve ser resolvido.
Erro de acesso a dados no Console do operador
Sintoma:
Ao acessar o Console do operador no UIM 20.3.2, vejo o erro de acesso a dados. O UIM 20.3.2 e o CABI estão configurados corretamente. Além disso, ao carregar a página inicial, não vejo nenhum conteúdo do CABI (erro de acesso a dados) e recebo erros 404 na guia Rede.
Solução:
Esse é um problema de conteúdo. O erro de acesso a dados está ocorrendo porque o CABI está com painéis ausentes. Implante ou reimplante os seguintes pacotes no robô do CABI:
  • uim_core_dashboard
  • uim_unified_reporter
Auditando logons do Console do operador
Sintoma:
Atualizei para o UIM 20.3.2. Desejo monitorar os logons de usuários externos no Portal. Existe uma maneira de coletar logs de auditoria do Console do operador que mostrem os logons com marcas de data e hora dos usuários da conta e dos usuários do barramento? Além disso, existe uma maneira rápida de ver a data do último logon dos usuários da conta?
Solução:
No 20.3.x, agora a tabela User_ passou a ser CM_User_. Ela funciona da mesma maneira. As entradas nessa tabela são criadas toda vez que qualquer usuário (usuário nimbus ou usuário da conta) efetua logon no OC pela primeira vez. No entanto, os campos loginDate e lastLoginDate não são atributos na nova tabela. A alternativa é monitorar o wasp.log com logmon em relação aos logons do OC, conforme descrito no Artigo da base de conhecimento. Embora a base de conhecimento ainda faça referência ao UMP, o wasp.log registra as tentativas de logon.
Exemplos:
  • O administrador efetua logon no OC
    wasp.log
    Dec 23 12:36:13:261 DEBUG [http-nio-80-exec-17, com.fr.ump.auth.NmsAuth] Login from request user {userId=10159, screenName=
    administrator
    , [email protected], locale=en_US, firstName=administrator, middleName=null, lastName=} Dec 23 12:36:13:403 DEBUG [http-nio-80-exec-17, com.fr.ump.auth.NmsAuth] User prin [email protected]cf24917(administrator) found for 10159
  • O usuário da conta efetua logon:  (
    ipxxxxx
    )
    wasp.log
    Dec 23 12:45:47:211 DEBUG [http-nio-80-exec-12, com.nimsoft.nimbus.probe.service.wasp.db.DbPreparedStatement] Query pNJt took: 0.001s Dec 23 12:45:47:211 DEBUG [http-nio-80-exec-12, com.nimsoft.nimbus.probe.service.wasp.auth.LoginModule] ippma03 logged in. Dec 23 12:45:47:211 DEBUG [http-nio-80-exec-12, com.firehunter.ump.auth.NmsAuth] User:
    ipxxxxx
    , NimBUS login milliseconds: 129 Dec 23 12:45:47:215 DEBUG [http-nio-80-exec-12, com.firehunter.ump.auth.NmsAuth] Login from request user {userId=10161, screenName=ipxxxxx, [email protected], locale=en_US, firstName=dicjiod, middleName=null, lastName=dsmopc}