TERMO DE REFERÊNCIA Contratação de Solução de Gerenciamento de aplicação e banco de dados, alinhada as melhores práticas ITIL e com console unificada. Constituída de licenças de direito de uso perpétuo de software, do direito à atualização, da manutenção e suporte técnico, dos serviços de instalação, customização, implantação, da transferência de tecnologia e do treinamento de acordo com as condições constantes neste Termo de Referência. versão 1.0 1 1
1. OBJETO Contratação de Solução de Gerenciamento de Aplicação e banco de dados, alinhada as melhores práticas ITIL e com console unificado. Constituída de licenças de direito de uso perpétuo de software, do direito à atualização, da manutenção e suporte técnico, dos serviços de instalação, customização, implantação, da transferência de tecnologia e do treinamento de acordo com as condições constantes neste Termo de Referência. 2. ESCOPO DO PROJETO A contratação visa atender as necessidades de Gerenciamento de desempenho de Aplicações e Banco de Dados hospedados no Datacenter da PCRJ, sob responsabilidade da Diretoria de Operações da IplanRio. 3. PRAZOS 3.1 O prazo do contrato será de 24 (vinte e quatro) meses, contados a partir da data da assinatura do mesmo, podendo ser prorrogado nos termos do art. 57, inciso II da Lei 8.666/93. 3.2 O prazo de entrega das Licenças Perpétuas será de até 05 (cinco) dias corridos, contados a partir da assinatura do Contrato. 3.3 A contratada deverá prestar suporte técnico e atualização tecnológica das licenças durante o prazo de vigência do contrato. 3.4 O prazo máximo para os serviços de instalação, customização, implantação, da transferência de tecnologia e do treinamento será de 12 (doze) meses, contados a partir da entrega das Licenças, como previsto no item 3.2. 4. REQUERIMENTOS TÉCNICOS OBRIGATÓRIOS 4.1. CARACTERÍSTICAS GERAIS DA SOLUÇÃO 4.1.1. A Solução deve ser implementada em uma das seguintes plataformas: 4.1.1.1. Windows Server 2008 ou superior; 4.1.1.2. Red Hat Enterprise Linux 5 e superior; 2 2
4.1.1.3. VSphere 5 ou superior 4.1.2. Todos os componentes de software da solução oferecida, com exceção do sistema operacional e banco de dados, deverão ser fornecidos por um único fabricante, não sendo aceitos, portanto, qualquer tipo de consórcio ou subcontratação. 4.1.3. Todos os módulos que compõem a Solução de Gerenciamento de Aplicação e Banco de Dados devem ser fornecidos e implementados com a possibilidade de alta disponibilidade. 4.1.4. A solução deverá ser instalada e licenciada de forma modular, sem dependência de um determinado módulo ou obrigatoriedade de instalar todos os módulos. 4.1.5. Deverá possuir integração automática das soluções, independentemente da ordem de sua implantação, oferecendo flexibilidade durante o processo de implantação; 4.1.6. Deverá possuir interface centralizada para um controle de todas as funcionalidades e opções de configuração das soluções; 4.1.7. Arquitetura web baseada em padrões webservices, facilitando a manutenção e integrações futuras com outras soluções aderentes a webservices; 4.1.8. Possuir ponto único de coleta de todas as informações originadas pelos clientes; 4.1.9. Para todos os repositórios de dados devem ser fornecidas as respectivas licenças de uso e garantia de upgrade por 24 (vinte e quatro) meses a contar do aceite de entrega dos softwares e licenças. 4.1.10. Caso a Solução necessite de um banco de dados externo, este deverá ser um dos seguintes SGBDs: MS SQL Server 2008 ou mais recente; 4.1.11. Este banco de dados deverá possuir estrutura relacional; 4.1.12. O banco de dados deve ser pré-configurado com a instalação da Solução. 4.1.13. Prover uma arquitetura escalável, possibilitando o crescimento da Solução em conjunto com o aumento do número de aplicações de Banco de dados gerenciados e da complexidade dos Serviços de Negócio. 4.1.14. A Solução deverá permitir, a customização de Relatórios e Dashboard, para o idioma português. Salvo os produtos complementares como Sistemas Operacionais e Banco de Dados, que não sofrem a mesma exigência. 3 3
4.1.15. A Solução, com todos seus componentes de software, deve possuir a capacidade de atribuição de níveis diferenciados de permissões de acesso e privilégios, conforme o perfil dos usuários (administradores, somente consulta, consulta e alteração). 4.1.16. Deve ser possível a criação de grupos de usuários, de modo que seja possível atribuir permissões de acesso e privilégios a eles. 4.1.17. Caso o acesso a Solução necessite de licença, devem ser fornecidas, no mínimo, 10 (dez) licenças de acessos simultâneos para administração e 50 (cinquenta) licenças de acesso simultâneo para operação da Solução. 4.1.18. Caso a Solução, ou algum de seus módulos, não suporte licenças concorrentes aceitar-se-á fornecimento de licenças nomeadas na razão de 3:1 (ex: substituir o atendimento de 10 licenças concorrentes por 30 licenças nomeadas). 4.1.19. A Solução que implementa mecanismo de licenças concorrentes deve permitir o cadastramento de usuários potenciais no mínimo dez vezes o número de acessos simultâneos para aquela funcionalidade, por exemplo: se para determinada funcionalidade têm-se 10 acessos concorrentes, então deve autorizar que no mínimo 100 usuários possam concorrer a este tipo de acesso. 4.1.20. A Solução deve utilizar o Microsoft Active Directory para a autenticação e autorização de usuários; 4.1.21. A autenticação quando realizada via pedido de conta e senha deve utilizar um protocolo seguro. 4.1.22. A Solução deve permitir que aplicativos externos acessem o repositório de dados mantido por ela. 4.1.23. A solução proposta deverá conter a documentação completa sobre a estrutura do banco de dados e a mesma deverá ser fornecida junto com a Solução. 4.1.24. Todos os dispositivos de software que compõem a solução proposta deverão estar hospedados no ambiente interno do Datacenter da PCRJ, não podendo ser fornecidas quaisquer informações coletadas a agentes externos e não podendo a Solução exigir, para seu pleno funcionamento, o uso de serviços externos ou endereçamento ip que não o privado. 4 4
4.1.25. A Solução deve possuir interface web com acesso via protocolo HTTP e HTTPS para a console de operação. 4.1.26. A Solução deve permitir que múltiplas consoles sejam executados simultaneamente. 4.1.27. Todas as capacidades exigidas nesta especificação técnica devem ser compatíveis com a infraestrutura e aplicações existentes no Datacenter da PCRJ, não sendo necessária a aquisição de nenhum equipamento ou software adicional aos fornecidos com a Solução. 4.1.28. Viabilidade de análise de tendências dos dados coletados; 4.1.29. Viabilidade de geração de relatórios (off line) com interação total do usuário e monitoração on line. 4.1.30. Permitir identificar o fluxo de uma transação, partindo de uma ação do browser até uma query executada no banco, ou pelo caminho inverso, partindo-se de uma query no banco até a ação do browser que a disparou. 4.2. DO AMBIENTE A SER MONITORADO 4.2.1. Solução única e integrada devendo suportar os seguintes ambientes: 4.2.1.1Sistema Operacional Microsoft Windows XP, 2000 Server, 2003 Server, Vista, Windows 7, Windows 2008 Server e Windows 2008R2 Server; Red Hat Enterprise 5, Red Hat Enterprise Linux AS/ES 4, AS/ES 5.x e AP/Server 6.x; Vmware Vsphere 5 ou superior e Microsoft Hiper-V; Novel SUSE Linux Enterprise Server versões 9, 10 e 11; Oracle Linux versões 4 e 5; 4.2.1.2. Banco de Dados Oracle Database Server Enterprise Edition em RAC; Oracle Database Server versões 9.2, 10.2, 11.1, 11gR2 e superior; MySQL versão 5 ou superior; Microsoft SQL Server versões 2000, 2005 e 2008, incluindo 2008R2 e superior. 4.2.1.3. Servidor de Aplicação ColdFusion 8.0, 9.0 ou superior; JBoss Application Server versões 4.2, 5.0 e 5.1; 5 5
JBoss EAP versões 4.3, 5, 6 e superior;. Microsoft.NET Framework 2.0, 3.0, 3.5 e 4.0. Oracle WebLogic 11g 4.2.1.4. Servidor de Virtualização VMware ESX Server 4 e VMware vcenter Server 4 e 5; Microsoft Hyper-V rodando em Windows 2008 Server R2. Red Hat Enterprise Virtualization (RHEV) 4.2.2. Infraestrutura de Servidores a ser atendida. 4.2.2.1. Servidores de Banco de Dados (físicos e/ou virtuais) 4.2.2.1.1. 12 (doze) servidores físicos Oracle 4.2.2.1.2. 40 (quarenta) servidores físicos SQL Server 4.2.2.1.3. 20 (vinte) servidores físicos MySql 4.2.2.2. Servidores de Aplicação (físicos e/ou virtuais) 4.2.2.2.1. 24 (vinte e quatro) Servidores fisicos JAVA com 66 (sessenta e seis) Máquinas virtuais; 4.2.2.2.2. 01 (um) Servidores físico.net com 07(SETE) Máquinas virtuais; 4.2.2.2.3. 03 (três) Servidores físicos Codefusion com 18 (dezoito) Máquinas virtuais; 4.2.2.2.4. 07 (sete) Servidores físicos CITRIX, sem máquinas virtuais. 4.2.3. Protocolos de comunicação utilizados: SMTP/SMPTS, IMAP/IMPAS, HTTP/HTTPS, ICA, SSL, NTP, POP/POPS, XML, WS, DNS. 4.3. DO TRATAMENTO DOS DADOS 4.3.1. Todas as estatísticas monitoradas deverão ser armazenadas, podendo ser consultadas quando conveniente. 4.3.2. A solução deverá possuir repositório central para os dados coletados. 4.3.3. O período de armazenamento das estatísticas deverá ser configurável por, no mínimo, 5 (cinco) anos. 4.3.4. A solução deverá ser capaz de gerar uma linha de base para cada item monitorado: 6 6
4.3.4.1. Esta linha de base deverá representar o comportamento habitual estatístico de um dado com base em informações coletadas anteriormente, que caracterizam uma série histórica; 4.3.4.2. O período de amostragem estatística; 4.3.4.3. A linha de base estatística deverá ser calculada com base na hora do dia e dia da semana. 4.3.5. A solução deverá permitir a exportação dos dados em arquivos PDF e em separados por vírgula, formato CSV. 4.4. DOS ALERTAS E EVENTOS 4.4.1. A solução deverá ser capaz de enviar alertas por e-mail, sms e traps SNMP para destinatários ou grupos de destinatários predefinidos. 4.4.2. Deverá ser possível configurar pelo menos as seguintes métricas: 4.4.2.1. Porcentagem de disponibilidade; 4.4.2.2. Tempo de resposta máximo; 4.4.2.3. Tempo médio de reparo; 4.4.2.4. Tempo médio entre falhas; 4.4.2.5. Tempo máximo de parada. 4.4.3. Deverá ser possível a configuração de limiar superior e/ou inferior de qualquer métrica presente no sistema. 4.4.4. Deverá ser possível a configuração de diferentes limiares para diferentes horários do dia e diferentes dias da semana. 4.4.5. A solução deverá permitir a configuração para gerar alertas caso: 4.4.5.1. O limiar de qualquer métrica seja desrespeitado; 4.4.5.2. Ocorram desvios de comportamento estatístico (linha de base) no tempo de resposta medido; 4.4.5.3. Ocorram desvios de comportamento estatístico (linha de base) em qualquer métrica monitorada; 4.4.5.4. Ocorrência de um número pré-determinado de eventos; 4.4.5.5. Ocorrência de um padrão de texto específico em um arquivo de log de um servidor monitorado. 4.4.6. A solução deverá possuir previsão de janelas de manutenção, que é a definição de datas e horários onde itens monitorados estarão indisponíveis propositalmente, situação na qual a solução não deverá emitir alertas. 4.4.7. As janelas de manutenção deverão poder ser configuradas como periódicas (diária, semanal ou mensal) ou individuais. 4.4.8. A solução deverá permitir o escalonamento de eventos, avisos e alarmes. 4.4.9. Deverá ser possível a execução de filtro de eventos por data, hora, tipo de evento, endereço IP de origem, endereço IP de destino, URL, aplicação, classe, método, tempo de resposta, dentre outros. 4.4.10. Deverá ser possível a emissão de alertas e execução de ações corretivas em caso de queda de processos e/ou serviços. 7 7
4.4.11. Deverá ser possível o agrupamento de recursos de forma a indicar indisponibilidade do grupo somente quando todos os recursos estiverem indisponíveis (Ex. Cluster de servidores). 4.4.12. Deverá possibilitar que as informações referente a transação sejam, a partir de uma violação (alarme), enviadas e compartilhadas com outras áreas (tais como desenvolvedores ou testadores) de forma automática por email, contendo detalhes da transação, tais como, fluxo da execução, diagrama UML, detalhes do usuário final, componentes, classes, métodos, queries disparadas, mensagens de log. 4.4.13. Os alertas deverão ser enviados em frequência definida aos destinatários até que um dos eventos abaixo acorra: 4.4.13.1. A causa do alerta seja eliminada; 4.4.13.2. O problema seja confirmado. 4.5. DA CORRELAÇÃO DE EVENTOS 4.5.1. A solução deverá permitir o correlacionamento de eventos gerados pela monitoração. 4.5.2. O correlacionamento deverá permitir a indicação de que aplicações serão afetadas, diante de um evento verificado pela monitoração. 4.5.3. O correlacionamento deverá indicar problemas de desempenho e/ou disponibilidade e os serviços afetados. 4.5.4. A solução deverá permitir o mapeamento de dependências entre componentes de infra-estrutura. 4.5.5. A solução deverá permitir a análise de causa raiz dos problemas, baseada na dependência do item anterior. 4.5.6. A solução deverá apontar a causa raiz dos problemas, através da analise de eventos, pacotes de rede e threads. 4.6. DA CONSOLE 4.6.1. Deverá possuir interface web, com acesso via protocolo HTTP e HTTPS. 4.6.2. A autenticação do usuário deverá ser realizada via usuário e senha. 4.6.3. O protocolo HTTPS é obrigatório para a autenticação quando realizada via usuário e senha. 4.6.4. Deverá permitir múltiplos acessos simultâneos. 4.6.5. O acesso à console deverá ser suportado pelos seguintes navegadores: 4.6.5.1. Mozilla Firefox ; 4.6.5.2. Safari 5.1.7; 4.6.5.3. Google Chrome; 4.6.5.4. Microsoft Internet Explorer versões 6, 7, 8 e 9. 8 8
4.6.6. A solução deverá possuir aplicativos para IOS e Android, para acesso pelos dispositivos mobile: Ipad, Iphone e Android. 4.6.7. Deverá permitir o relacionamento dos componentes do ambiente operacional utilizados por cada item monitorado de modo a possibilitar uma visão abrangente do desempenho e da disponibilidade. 4.6.8. Deverá permitir, por meio de gráficos, o acompanhamento em tempo real de estatísticas coletadas. 4.6.9. Deverá permitir a fácil criação de dashboards com visões gerenciais e operacionais que reflitam a monitoração executada para as áreas de negócio, operacional, desenvolvimento e teste. 4.6.10. Deverá permitir a visualização do estado dos itens monitorados, por meio de cores ou ícones diferentes para os diversos estados. 4.6.11. Deverá ter capacidade de apresentar o estado dos itens monitorados por período por meio de gráficos. 4.6.12. Deverá prover um ponto único de configuração, que permita o cadastramento dos itens a serem monitorados, dos limiares e ações a serem executadas nos servidores diretamente na console. 4.6.13. Deverá armazenar as regras de monitoração, limiares e ações a serem executadas. 4.6.14. A console deverá propagar para os agentes automaticamente e de forma segura as regras de monitoração, limiares e ações a serem executadas. 4.7. QUANTO A FORMA DE COLETA 4.7.1. AGENTES DE SERVIDOR 4.7.1.1. Deverá possuir capacidade de executar programas ou scripts que retornem um valor numérico, que deverá ser armazenado como estatística (monitor customizado). 4.7.1.2. A periodicidade de amostragem deverá ser configurável, com um intervalo mínimo de, pelo menos, 1 minuto entre as simulações realizadas pelo agente ativo. 4.7.1.3. Deverá ser capaz de executar uma ação (programa ou script) caso algum dos eventos ocorra: 4.7.1.3.1. Um indicador desrespeitar seu limiar configurado; 4.7.1.3.2. Um serviço monitorado não responder. 4.7.1.4. Deverá possuir a capacidade de executar ações, mesmo sem contato com a console central, baseando-se na última configuração válida. 4.7.1.5. As configurações dos eventos e das ações a serem executadas para cada um deverão ser efetuadas por meio da console de gerenciamento. 4.7.1.6. Deverá implementar comunicação com a console central via TCP/IP. 9 9
4.7.1.7. Deverá possuir atualização (upgrades) dos agentes a partir da console central. 4.7.2. SISTEMA OPERACIONAL 4.7.2.1. Deverá possuir capacidade de monitorar o estado de serviços e processos. 4.7.2.2. Deverá possuir capacidade de monitorar os arquivos de log e eventos de sistema. 4.7.2.3. Deverá possuir capacidade de monitoração de indicadores de uso de: 4.7.2.3.1. Processador 4.7.2.3.1.1. Percentual de tempo de ocupação em modo de usuário; 4.7.2.3.1.2. Percentual de tempo de ocupação em modo de sistema; 4.7.2.3.1.3. Percentual de tempo disponível; 4.7.2.3.1.4. Para cada coleta, deverão ser armazenados, no mínimo, os 5 processos que mais estão consumindo recursos do processador. 4.7.2.3.2. Disco 4.7.2.3.2.1. Percentual de tempo de ocupação de escrita; 4.7.2.3.2.2. Percentual de tempo de ocupação de leitura; 4.7.2.3.2.3. Percentual de tempo de ocupação total; 4.7.2.3.2.4. Comprimento atual de fila de disco. 4.7.2.3.3. Memória 4.7.2.3.3.1. Percentual de memória física livre; 4.7.2.3.3.2. Percentual de uso da memória física; 4.7.2.3.3.3. Percentual de memória total livre; 4.7.2.3.3.4. Percentual de uso da memória total; 4.7.2.3.3.5. Quantidade de falhas de página por segundo. 4.7.3. BANCO DE DADOS 4.7.3.1. Deverá possuir, no mínimo, 3 tipos de coletas: 4.7.3.1.1. Completa - Por padrão ( default ), possibilitar a coleta de todas as informações previstas para o banco de dados, tendo a opção de escolher quais informações deseja ser coletada. 4.7.3.1.2. Por disponibilidade - possibilitar a coleta de informações que indicam que o banco de dados está on-line, permitindo incluir mais indicadores, além dos pré-definidos. 4.7.3.1.3. Por relatório - possibilitar a coleta de informações necessárias para a emissão de relatórios básicos. 4.7.3.2. Permitir a investigação de atividades e performance, 10 10
4.7.3.2.1. Cache Activity and Performance Gráfico do resumo da Instance - Mostrar o percentual de hits do cache e permitir o drilldown no gráfico de resumo de cache; Gráfico do resumo de Cache - Mostrar o hit ratios do buffer, dicionário de dados e biblioteca de caches; Gráfico do detalhamento do Buffer Cache - Mostrar o numero de: consistent gets, database block gets e physical reads; Gráfico do detalhamento do Data Dictionary Cache - Mostrar o número de Get Misses e Gets; Gráfico do detalhamento do Library Cache - Mostrar o número de pins e reloads; Gráfico do Buffer Activity - Mostrar o número de indicadores do buffer cache activity; Gráfico do Global Buffer Hit Ratio - Mostrar a sobrecarda do buffer cache hit ratio. 4.7.3.2.2. Comunicação Gráfico do TNS Availability - Mostrar o percentual de disponibilidade do Oracle listener service; Gráfico do tráfico do SQL*NET - Mostrar a razão (in bytes/second) dos dados transferidos dos processos do cliente para o servidor e a razão do retorno desta informação (servidor - cliente); Gráfico do Tempo de Resposta - Mostrar os recentes tempo de respostas das queries típicas. 4.7.3.2.3. Database Files e Tablespaces Gráfico do resumo de I/O da Tablespace - Mostrar o percentual de transações de entrada/saída de cada tablespace. Gráfico do resumo do I/O do Datafile - Mostrar o percentual de I/O dos 10 maiores datafiles utilizados para cada tablespace; Dados de atividades de I/O do Datafile - Mostrar a atividade física absoluta da atividade de I/O de cada datafiles que compõe o Oracle instance. Grafico de atividades de I/O da undo tablespace Mostrar o quanto de atividade de disk sorts é realizada. Gráfico do DB Filespace - Mostrar a utilização de espaço do Oracle database filesystem. Gráfico de utilização de espaço da Tablespace - Mostrar a quantidade de espaço livre de cada tablespace. Gráfico de atividade de I/O da Temporary Tablespace - Mostrar o quanto de atividade de disk sorts é realizada. 11 11
Dados de Extents - Mostrar informações do tamanho máximo e número provável de extents disponíveis. 4.7.3.2.4. Atividades de I/O Gráfico do resumo de I/O da Tablespace - Mostrar o percentual de leituras e gravações de cada tablespace. Gráfico do resumo de I/O do Datafile Mostrar o percentual de leituras e gravações de todos os Datafiles; Gráfico de medida de I/O do Datafile Mostrar o percentual de leituras e gravações para o Datafile selecionado; Tabela de atividades de I/O do Datafile Mostrar as atividades físicas absolutas de I/O de cada datafile que compõe a instance Oracle; Gráfico das atividades de I/O na Tablespace Temporária Mostrar o custo das atividades geradas por disk sort. 4.7.3.3. Permitir visualização centralizada dos bancos de dados ORACLE, SQL SERVER e MySQL ("single point of access"), utilizando repositório em servidor específico da solução para armazenar as coletas de informações. Esta estrutura deve preservar os servidores monitorados de execuções de processos extras e centralizar a administração, a distribuição e a consolidação das informações; 4.7.3.4. Possuir a funcionalidade de monitoramento e gerenciamento de desempenho integrado em uma única solução, com a funcionalidade de gerenciamento de administração; 4.7.3.5. Possibilitar a gerência de espaço. Oferecer manutenção preventiva, detecção de problemas, solução e planejamento de capacidade para vários bancos de dados Oracle, MySQL e SQL Server. 4.7.3.6. Analisar declarações SQL e identificar as declarações ineficientes; 4.7.3.7. Auxiliar na otimização e correção, com o auxílio da própria ferramenta, eventuais problemas detectados, permitindo o ajuste de parâmetros de otimização de desempenho; 4.7.3.8. Possuir administração centralizada de usuários, "roles" e permissões de objetos, como proprietário do controle e mantenedor da base de usuários e permissões; 4.7.3.9. Obter diagnóstico do banco de dados, detectando problemas de desempenho do SGBD; 4.7.3.10. Possuir interface do tipo "wizards" para execução de tarefas rápidas e fáceis; 4.7.3.11. Preservar a integridade do SGBD e seus dados; 4.7.3.12. Possuir interface para possibilitar a navegação entre as telas e fácil acesso às funcionalidades disponíveis, sem necessidade de conhecimento de programação por parte do usuário; 12 12
4.7.3.13. Funcionalidades obrigatórias e específicas de gerenciamento de monitoração e de desempenho; 4.7.3.14. Armazenar dados para as transações, inclusive declarações SQL, com opções de periodicidade para a coleta; 4.7.3.15. Identificar as mudanças do ambiente, através de relatórios de analise de tendência, baseados em desvio de baseline de performance das aplicações, e correlacioná-las com a performance do banco de dados; 4.7.3.16. Permitir análises detalhadas da eficiência dos componentes com a finalidade de otimizar o desempenho do ambiente; 4.7.3.17. Auxiliar na detecção e correção de problemas de desempenho em aplicações, analisando as mensagens de erro, tempo de resposta e volumetria das declarações SQL, identificando qual a camada da aplicação possui o maior tempo de resposta, através de relatórios do tipo: CNS Breakdown (Client, Network e Server), analisando o impacto em ambientes críticos; 4.7.3.18. Fornecer informações sobre os estado do SGBD e os dados que ele controla, quanto a disponibilidade dos mesmos; 4.7.3.19. Possuir uma Interface GUI de fácil entendimento e compreensão - mostrar graficamente todos os componentes críticos do banco de dados em uma ÚNICA TELA e de forma bem interativa, permita identificar gargalos de performance. Os elementos mostrados na tela deverão ser coloridos e possuir movimentações que representam a situação dos componentes; 4.7.3.20. Permite visualizar todos os componentes críticos do Oracle RAC em uma única tela; 4.7.3.21. Visão gráfica detalhada dos bancos de dados e possibilidade de realizar drill down para diagnóstico do problemas no nível da instância. 4.7.3.22. Possuir também uma visualização gráfica do fluxo, ilustrando a velocidade em que cada dado é movimentado entre os componentes (incluindo o node e cluster). 4.7.3.23. Fornece medições detalhadas de desempenho e alarmes customizados para ambientes RAC. 4.7.3.24. Permitir visualização de atividades, monitoração e indicativo de quais objetos estão sendo monitorados, em tempo real, para Instances, Database, Tables, Tablespaces, Conexões e Bufferpool; 4.7.3.25. Monitorar a utilização dos recursos do sistema e identificar seus maiores consumidores (I/O em disco, processos, CPU, memória, espaço em disco etc.); 4.7.3.26. Administrar as conexões de usuário: verificar o consumo de recurso e o nível de isolamento por conexão e permitir o cancelamento de conexões; 13 13
4.7.3.27. Possuir mecanismos de alerta visual e ou sonoro para situações de anormalidades (baseado em "threshold"); 4.7.3.28. Possibilitar os usuários efetuarem drill down no detalhamento das informações em busca da fonte do problema de performance. Permitir a calibração do processo que estabelece a "baseline" normal das atividades possibilitando o envio automático de mensagens, alerta visual ou sonoro aos administradores. 4.7.3.29. Permitir a visualização de comandos SQL e o status do ambiente com, no máximo, três cliques, contados a partir da tela principal, na análise das anormalidades detectadas pelos mecanismos de alerta; 4.7.3.30. Possibilitar a análise de resultados de modificações introduzidos no banco de dados, a partir de comparações de estatística anterior e posterior às alterações; 4.7.3.31. Fornecer métricas de ajuste; 4.7.3.32. Possibilitar mapear um serviço detalhadamente, com a finalidade de identificar a localização exata de problemas, com visualização drill down (árvore de expansão) e mecanismos de alertas; 4.7.3.33. Possibilitar efetuar o drill down, no mínimo, nos seguintes componentes:. Sessões do banco de dados;. Atividades do banco de dados;. Utilização de Memória;. Armazenamento do Disco;. Cluster;. ASM (Automatic Storage Management);. Alarm Log 4.7.3.34. Gerar relatórios HTML ou PDF e ter a possibilidade de comparação entre os dois formatos na mesma tela gráfica, sem ajustes de tela, como redimensionamento; 4.7.3.35. Gerar relatórios customizados por tipo de comando SQL, por instancia de banco de dados, encadeamento com transações especificas da aplicação através de uma ferramenta tipo Data Mining (DMI), que deve fazer parte da Solução; 4.7.3.36. Possuir visualização de impacto nas transações e aplicação quando a performance dos comandos sql estiverem acima do limite aceitável de tempo de resposta; 4.7.3.37. Combinar características de criação de fluxo de trabalho com pesquisa textual em arquivos e agendamento, para possibilitar a otimização das tarefas manuais. Exemplo aplicável, política de backup: monitoração centralizada em interface única, verificação da conclusão do processo de backup e tomadas de decisões sobre ações pré-definidas; 4.7.3.38. Possuir classificação de lista de objetos por uma coluna selecionada; 14 14
4.7.3.39. Fornece uma representação visual de fluxos de processos dentro de Clusters de Aplicação Real, permitindo a observação da atividade em tempo real; 4.7.3.40. Diagnosticar o banco de dados Oracle RAC a partir de três perspectivas chaves: (No nível de nó individual, No cluster, como um banco de dados único, Da carga, latência e sobrecarga do interconector); 4.7.3.41. Identificar gargalos e fornecer capacidade extensiva para analisar detalhadamente e entender a raiz de um problema de desempenho; 4.7.4. SERVIDOR WEB E DE APLICAÇÕES 4.7.4.1. A solução não deverá requerer modificações nas aplicações monitoradas, nem a implementação de APIs. 4.7.4.2. A solução deverá monitorar o tempo de resposta das aplicações Web e Java EE: Microsoft.NET, PHP, JBoss, Tomcat, ColdFusion e Oracle WebLogic Server, e visualizar o inter-relacionamento de todas as camadas das aplicações no mesmo gráfico, inclusive os acessos ao Mainframe (Unisys). 4.7.4.3. A solução deverá permitir a monitoração de múltiplas instâncias do servidor de aplicação (.NET e Java EE) e/ou do servidor web em um mesmo servidor físico (diferentes portas para cada instância). 4.7.4.4. A solução deverá realizar a captura e demonstração do caminho percorrido pelas transações ao longo das camadas J2EE,PHP e.net monitoradas da aplicação, não devendo interromper o fluxo devido a mudança de tecnologia, tais como JAVA para.net ou PHP para JAVA. 4.7.4.5. A solução deverá monitorar a performance das aplicações web desenvolvidas em.net e Java, independentemente da metodologia e implementação adotada ou dos frameworks utilizados (ex: Servlet, JSP, JNDI, JDBC, EJB 3, Struts, Velocity, Hibernate, JSF, Spring). 4.7.4.6. A solução deverá monitorar o tempo de resposta, erros de acesso e inatividade dos servidores. 4.7.4.7. A solução deverá monitorar 100% das transações Java e.net, identificando todos os usuários, não deve ser amostragem. 4.7.4.8. A solução deverá monitorar o uso recursos de processamento e de memória da Máquina Virtual Java e instância.net 4.7.4.9. Permitir a visualização do código fonte dos componentes que mais impactam a performance de uma transação Java e.net em produção, através de engenharia reversa (decompilação) em tempo real; 4.7.4.10. A solução deverá permitir a produção de diagramas UML para cada transação individual, possibilitando a validação da arquitetura. 15 15
4.7.4.11. A solução deverá monitorar e gerenciar o desempenho do.net e a disponibilidade com métricas de todos os componentes da aplicação, incluindo da experiência do usuário final e do banco de dados. 4.7.4.12. A solução deverá identificar problemas de memória e de desempenho da aplicação.net e Java EE correlacionando-os com o código SQL executado. 4.7.4.13. A solução deverá reduzir o tempo de resolução de problemas através de detalhada coleta de métricas da camada da aplicação.net e Java EE. 4.7.4.14. A solução deverá realizar trace individual da sessão problemática do usuário para realizar diagnóstico detalhado da performance da aplicação.net e Java EE, no mesmo grafico. 4.7.4.15. A solução deverá mostrar contadores de desempenho incluindo os padrões Windows (CPU, memória, ASPNET) e customizados. 4.7.4.16. A solução deverá alertar ao usuário quando qualquer processo exceder valores de acordo com período de tempo. 4.7.4.17. A solução deverá emitir alertas quando o processo w3svc do.net consumir 80% ou mais de CPU. 4.7.4.18. A solução deverá identificar e mostrar exceções específicas da aplicação.net. 4.7.4.19. A solução deverá ser capaz de realizar instrumentação dos requests por segundo, identificar ocorrências da aplicação IIS como paradas, falhas e reinícios. 4.7.4.20. A solução deverá monitorar o comportamento da utilização de memória pelo servidor de aplicação.net e Java EE, bem como o processo de gerenciamento de memória denominado Garbage Collection. 4.7.4.21. Deverá detalhar o tempo resposta das transações, apresentando os tempos parciais de métodos de classes Java,.Net e requisições ao banco de dados. 4.7.4.22. A solução deverá realizar comparação de forma automática de uma transação com uma nova versão disponibilizada ou um baseline gerado, possibilitando visualizar as alterações de comportamento em diferentes níveis de granularidade, tais como API, Web request, métodos, queries, exceptions. 4.7.4.23. A solução deverá permitir análise de transações fim-a-fim, entre os servidores J2EE e.net, inclusive do lado do usuário, permitindo identificar problemas de performance relacionados a componentes AJAX/JavaScript, applets, entre outros. 4.7.4.24. A solução deverá permitir a integração com IDEs Eclipse e Microsoft Visual Studio, possibilitando a utilização em ambiente de desenvolvimento, teste e produção para rápida contextualização do componente a ser analisado. 16 16
4.7.4.25. A solução deverá permitir a visualização do código fonte dos componentes que mais impactam a performance de uma transação, realizando a decompilação em tempo real. 4.7.4.26. A solução deverá realizar a monitoração de transações assíncronas, identificando o seu fluxo ao longo dos componentes da infraestrutura. 4.7.4.27. A solução deverá monitorar transações Batchs, que são disparadas automaticamente, através de um agendamento prévio, sem a interferência de uma ação do usuário, demonstrando o seu comportamento e o seu fluxo, bem como o seu comportamento ao longo da infraestrutura (usuário, servidor, JVM, classes, métodos). 4.7.4.28. Deverá disponibilizar, no mínimo as seguintes informações : 4.7.4.28.1. Processos agregados - Mostrar a agregação de componentes, tais como: JVM, JMS, JSP/servlets, Web Services, thread pools, pool de conexão JDBC, JCAs, EJBs, JTA, e web application. 4.7.4.28.2. Processo JVM - Mostrar o fabricante do Java VM, versão, arquitetura, detalhamento da métrica on thread CPU usage, heap usage, e informações do garbage collection para JVM. 4.7.4.28.3. Processo Thread Pools - Listar todos os thread pools e resumo do estado atual de cada pool, incluindo health e uso de thread. Mostrar dados do pool size e queue size para o pool selecionado. 4.7.4.28.4. Processo JDBC Connection Pools - Listar todos os pools de conexões JDBC no processo selecionado e resumos do status. Mostrar também o dados do use time e wait time para o pool de conexão selecionada. 4.7.4.28.5. Processo JCA Connection Pools - Listar todas os pools de conexoes JCA selecionado e resumo de status do pool usage, waiters, e faults. Mostrar dados do use time and wait time da fonte de dado selecionado. 4.7.4.28.6. Process Servlets/JSPs - Mostrar os servlets dentro da JVM selecionada e resumo do status, numero de requisições ativas e tempo dos serviços. 4.7.4.28.7. Processo EJBs - Mostrar o número de beans de cada bean type, incluindo entity beans, stateful session beans, stateless session beans e messagedriven beans. Mostrar também a agregação de cada bean type. 4.7.4.28.8. Processo Entity Beans - Listar todas as entity beans o processo atual e resumos do estado atual de cada bean incluindo status, passive rate e counts. 4.7.4.28.9. Processo Stateless Session Beans - Listar todas as stateless session beans do processo atual e resumo do estado atual de cada bean incluindo vários contadores. 17 17
4.7.4.28.10. Processo Stateful Session Beans - Listar todas as stateful session beans do processo atual e resumo do estado atual de cada bean incluindo vários contadores. 4.7.4.28.11. Processo Message Driven Beans - Listar todas as message driven beans do processo atual e resumo do estado atual de cada bean incluindo vários contadores. 4.7.4.28.12. Processo JTA - Mostrar o atual JTA runtime statistics, incluindo o número de transações ativas, numero de transações nomeadas por servidor, total de transações, número acumulado de transações e dados de rollback. 4.7.4.28.13. Processo JMS - Mostrar o atual JMS runtime statistics, incluindo messages expired, queued, enqueued, recovered, discarded, pagedout, pagedin, active handlers e active connections. 4.7.4.28.14. Processo Aplicação - Listar o pool the JDBC conexão, servlets, Web services, health status, número de EJBs e web application. 4.7.4.28.15. Processo Web Application - Listar todas as aplicações web para o processo selecionado e resumo do status de cada aplicação, incluindo process request time, session activation time, the number of requests, sessions e servlets. 4.7.4.28.16. Processo Aplicação Web Services - Listar todos os web services do processo selecionado e fornecer detalhes de cada serviço de operação, estatística do servidor e dados da aplicação. 4.7.4.28.17. Processo Aplicação Web Service - Listar o resumo do status web service, incluindo metricas de requisições e número de falhas. 4.7.4.28.18. Aplicação - Listar o status e nome do componente para cada EJB, web service, JDBC connection pools, servlets e web application monitorado. 4.7.4.28.19. Aplicação EJBs - Mostrar o número de beans para cada bean type, incluindo entity beans, stateful session beans, stateless session beans e message driven beans. 4.7.4.28.20. Aplicação JDBC Connection Pools - Listar todos os pools de conexão JDBC dentro da aplicação selecionada e resumo do status. Mostrar também o dados do use time e wait time para o pool de conexão selecionada. 4.7.4.28.21. Aplicação Web Applications - Listar todos os web applications e resumos de status de cada aplicação, incluindo servidores, process request time, session activation time, quantidade de requisições, sessions e servlets. 4.7.4.28.22. Aplicação Entity Beans - Listar todos os entity beans dentro da aplicação selecionada e resumo do estado atual para cada bean, incluindo health status e pool usage. 18 18
4.7.4.28.23. Aplicação Stateless Session Beans - Listar todas os stateless session beans dentro Servidor Oracle atual e resumo do estado atual de cada bean, incluindo health status e pool usage. 4.7.4.28.24. Aplicação Stateful Session Beans - Listar todos os stateful session beans dentro da aplicação corrente e resumo do estado atual de cada bean, incluindo o health status e pool usage. 4.7.4.28.25. Aplicação Message Driven Beans - Listar todas as message driven beans dentro da aplicação corrente e resumo do estado atual de cada bean, incluindo o health status e pool usage. 4.7.5. DO AMBIENTE VIRTUALIZADO 4.7.5.1. Deve oferecer monitoramento de performance para auxiliar no planejamento de capacidade, cobranças internas ("chargeback") e gerenciamento de serviços através da mesma console única; 4.7.5.2. Possuir mecanismos de Geração de Relatórios e Relatórios prontos que possam ser gerados através de "wizards" e "Drag and Drop"; 4.7.5.3. Possuir repositório único para coletar mais métricas, visões, dados de capacidade e de performance do ambiente virtualizado; 4.7.5.4. Gerar relatórios nos formatos: PDF, xml, Excel, CSV e Imagem; 4.7.5.5. Ser capaz também de monitorar os ambientes físicos em conjunto com virtual para identificação de problemas correlacionados; 4.7.5.6. Oferecer portais com informações que podem ser customizados em questão de poucos minutos; 4.7.5.7. Os portais possam ser customizados através de simples "Drag and Drop" e a URL compartilhada entre os usuários; 4.7.5.8. Mostrar informações essenciais de forma imediata ("at a glance") e que podem ser facilmente entendidas. 4.7.5.9. Possuir Modelos de Cenários que ajudam planejar e otimizar os ambientes virtuais com as seguintes informações: a. Capacidade atual; b. Utilização e Métricas; c. Modelagem e previsões de demanda com precisão; d. Alertas sobre os gargalos relacionados à capacidade usando alarmes e aconselhamento de especialistas que oferecem as melhores ações para remediar problemas. Por exemplo: em quantos dias o "datastore" estará cheio; e. Otimiza o ambiente baseado na capacidade em todos os níveis da infraestrutura virtual; 4.7.5.10. Solução dever ser flexível, robusta e com arquitetura facilmente escalável; 19 19
4.7.5.11. Oferecer análise de Impacto e de Capacidade: prover dados necessários para tomada de decisões sobre capacidade e impacto. Deve mostrar dados "limpos" ao administrador de quais VMs estão consumindo mais recursos. 4.7.5.12. Auxiliar o Planejamento Capacidade de ambiente heterogêneos: VMware e Microsoft Hyper-V. 4.7.5.13. Deverá ser fácil de Usar, Gerenciar e Administrar: a. Download e configuração rápidas; b. Emitir relatórios, alertas e modelagem imediatamente após a instalação; Oferecer Respostas Rápidas às questões de Capacidades - FAQts ("facts"): a. Facilmente oferecer as informações mais atualizadas e apuradas às questões comuns sobre a capacidade; b. Oferecer informações de acesso rápido através da interface simplificada para planejamento de capacidade de acordo com a realidade do ambiente - "in-context"; c. Exemplo de FAQt: Quais máquinas virtuais estão com pouco espaço livre, mostrando os maiores consumidores de imediato. 4.7.5.14. A solução deverá gerar gráficos via interface web com quaisquer estatísticas coletadas pelo sistema, inclusive dados de memória, disco, processador e tempo de resposta de aplicações, informados pelos agentes ativos de usuário. 4.7.5.15. A solução deverá monitorar as mudanças virtuais de recursos, dinâmicamente sem a necessidade de configuração adicional. 4.7.6. EXPERIÊNCIA DO USUÁRIO FINAL 4.7.6.1. A solução de monitoramento da experiência do usuário final deverá permitir a melhoria da experiência do usuário final reduzindo o tempo de resolução (MTTR) através de portais/páginas web. 4.7.6.2. A solução de monitoramento da experiência do usuário final deverá, possuir integração nativa com a monitoração Java e.net, permitindo o drilldown a partir da URL até a classe e método da transação. 4.7.6.3. A solução de monitoramento da experiência do usuário final deverá, permitir a monitoração dos acessos ao Mainframe (Unisys), correlacionando com a performance das transações e suas camadas; 4.7.6.4. A solução de monitoramento da experiência do usuário final deverá determinar se o objetivos de desempenho são alcançados. 4.7.6.5. A solução de monitoramento da experiência do usuário final deverá coletar dados de todo tráfego das aplicações web. 20 20