Suporte Nível 1. Atualmente o Servidor de aplicação adotado é o GlassFish 2.x e o Postgres 8.x.

Transcrição

1

2 Suporte Nível 1 Todos os chamados devem ser abertos através do suporte@tibox.com.br, o qual registra automaticamente o chamado em nosso sistema e todos os colaboradores da TiBox recebem essa informação. Atualmente o Servidor de aplicação adotado é o GlassFish 2.x e o Postgres 8.x. Se o Glassfish ficar indisponível basta efetuar a abertura do chamado junto a TiBox enviando a descrição do problema e o log que está em /usr/local/include/glassfish/domains/domain1/logs/server.log. Após a abertura do chamado é válido reiniciar o Glassfish executando o comando a seguir no terminal: service glassfish restart Se o Postgres ficar indisponível basta avaliar se o processo está em execução, enviar as informações sobre o problema e status do Postgres para o do suporte. Caso o processo estiver inativo, executar o comando a seguir no terminal: service postgresql restart

3 Restart do Ambiente Caso o servidor precise ser desligado por algum motivo, existe um processo para efetuar este desligamento, abaixo estão os passos a serem seguidos e os comandos a serem executados. Primeiramente é necessário parar o servidor de aplicação Glassfish, para isso é necessário executar o seguinte comando: service glassfish stop Após parar o Glassfish é necessário parar o Banco de Dados PostgreSQL através do comando: service postgresql stop Após isto o servidor poderá ser desligado e para isso é necessário executar o comando: halt Quando o servidor for ligado novamente todos os serviços vão ser iniciados automaticamente.

4 Espaço em disco. Em alguns casos o Glassfish pode encher a unidade de logs e por não conseguir mais gerar logs ele para, para isto é necessário verificar a unidade /usr/local/include/glassfish/domains/domain1/logs e ver qual o tamnaho da mesma, será necessário verificar também se há espaço livre no disco do servidor. Caso seja usado o LVM será necessário verificar o espaço livre na partição /usr pois o glassfish suas configurações e seus logs ficam dentro desta unidade. Caso o serviço do glassfish esteja parado será necessário efetuar o comando: service glassfish start porém caso não haja espaço em disco o glassfish não irá iniciar. O Ideal é sempre conferir o serviço do PostgreSQL e também o serviço do Glassfish, caso estejam parados é necessário iniciar primeiro o serviço do PostgreSQL com o comando service postgresql start e depois o commando para iniciar o glassfish service glassfish start em ambos os casos será necessário entrar em contato com a Tibox pois há um script para a limpeza dos logs antigos e caso o mesmo não esteja rodando corretamente será necessário analizar.

5 A plataforma Allert permite a gestão do tráfego de rede de seus Clients, tornando uma ferramenta de comunicação eficaz voltada para o ambiente corporativo. Abaixo segue a imagem ilustrando uma configuração possível de nossa plataforma. Allert Center Filial 1 2 Mb/s poucos colaboradoreṣ... 1k 1k 1k 1k 1k 1k Módulo de Controle de Carga 100 Mb/s Rede Interna n colaboradores... 4 Mb/s adsl 512 kb usuários externos 1k Filial 2 muitos colaboradoreṣ... 7k 7k 7k 7k 7k 7k proxy replicador 5k 5k 5k 5k 5k 5k Topologia

6 O Client devido a grande variedade de máquinas que pode ser instalado, pode ser considerado o ponto crítico da plataforma. Sempre que houver um problema em um determinado Client, é fundamental a compactação do diretório %appdata%/allert da máquina com o problema e abrir o chamado no suporte anexando o diretório compactado. Abaixo segue todas as formas que o farol poderá apresentar para o usuário. Online: O Client se autenticou com sucesso e está em execução. - Isto significa que o client está funcionando corretamente e aguardando o tempo determinado para efetuar a consulta no servidor. Requisição: O Client está consultando o web service em busca de novos alertas a serem exibidos. - Após esta consulta o client começará a efetuar o download caso haja algo a ser baixado para o mesmo, caso não haja nada para ser feito o download ele voltará para o estado Online. Download: O Client está efetuando o download do conteúdo dos alertas que serão exibidos, skins novas e configurações. Status do Client

7 Aguardando autenticação: Foi enviado ao servidor os dados do Client e o mesmo está aguardando o sucesso/falha. - Caso este farol apareça para o usuário será necessário aguardar, pois existem 3 possibilidades a acontecerem após este farol. 1 O Farol ficará com sua cor normal notificando que está Online. 2 O Farol apresentará um ponto de interrogação informando que não conseguiu se autenticar com o server e está. 3 O Farol ficará em cinza informando que não conseguiu encontrar o servidor e está Offline. Falha na autenticação: O usuário não está cadastrado no sistema ou usuário ou licença estão inativos. - Caso apareça este sinal de interrogação será necessário conferir o usuário de rede logado no computador e verificar se o mesmo está presente na lista de destinatários do Allert. Status do Client

8 Offline: o client só fica nesse status antes de logar ou se houver um problema na rede, onde o Client não consegue se comunicar com o Web Service. - Caso apareça o farol cinza é necessário executar o comando ping na url do servidor, para checar se o computador está chegando até o server corretamente. Testando assim a resolução do nome do servidor e também se o servidor está no ar. Modo reunião: O usuário clicou em modo reunião e o Client não exibirá alertas durante esse período. - Assim que o prazo especificado pelo publicador acabar o player voltará ao recebimento normal de alertas Online. Erro Download: O Client falhou ao efetuar o download de algum conteúdo, pode ser um problema de rede ou o conteúdo não está mais presente no servidor. - Isto pode ocorrer caso o cliente esteja efetuando o download de um determinado conteudo e o publicador pare a publicação deste alerta em específico, aparecerá esta seta em vermelho e na proxima checagem ele verificará que o alerta não está mais em vigencia e voltará para o status Online. Status do Client