tcc rogerio pontual projeto baseado no nagios

64
PROJETO BASEADO NO NAGIOS PARA MONITORAÇÃO DE AUTORIZADORES DE TEF Trabalho de Conclusão de Curso Engenharia da Computação Rogério Pereira Pontual Orientador: Prof. Sérgio Murilo Maciel Fernandes ESCOLA POLITÉCNICA DE PERNAMBUCO

Upload: ricardo-zorek-daniel

Post on 08-Nov-2015

96 views

Category:

Documents


58 download

DESCRIPTION

Material Excelente para TI

TRANSCRIPT

  • PROJETO BASEADO NO NAGIOS PARA MONITORAO DE AUTORIZADORES DE TEF

    Trabalho de Concluso de Curso Engenharia da Computao

    Rogrio Pereira Pontual Orientador: Prof. Srgio Murilo Maciel Fernandes

    ESCOLA POLITCNICA DE PERNAMBUCO

  • Monografia apresentada como requisito parcial para obteno do diploma de Bacharel em Engenharia da Computao pela Escola Politcnica de Pernambuco Universidade de Pernambuco.

    Rogrio Pereira Pontual

    PROJETO BASEADO NO NAGIOS PARA MONITORAO DE AUTORIZADORES DE TEF

    Recife, junho de 2009.

  • Agradecimentos

    Agradeo primeiramente a meus pais, Fausto Falco Pontual e Marcina Pereira Pontual, por proporcinarem uma boa educao que me permitiu chegar a este ponto satisfeito com seu resultado.

    Agradeo a todos os professores de Computao da Universidade de Pernambuco que contribuiram com a minha formao acadmica.

    Ao professor Srgio Murilo Maciel Fernandes, pelo estmulo ao raciocnio crtico no desenvolvimento deste projeto e por sua orientao cujo resultado foi a produo de um texto mais cientfico.

    Por fim, aos meus amigos da POLI e de outras pocas pelas conversas que me apoiaram reafirmando ou com crticas construtivas a respeito de decises acadmicas ou profissionais.

  • iv

    ESCOLA POLITCNICA DE PERNAMBUCO

    Resumo Os sistemas de Transferncia Eletrnica de Fundos (TEF) pertencem

    categoria de sistemas de misso crtica uma vez que suas falhas tm como potencial um grande prejuzo financeiro ou de reputao. So os sistemas responsveis pela autorizao de pagamentos, principalmente com carto magntico ou com chip, que processam desde a captura dos dados da transao at ao envio dos comprovantes.

    Dentre as ferramentas de suporte, de modo geral, vale destacar as de monitorao que, quando construdas e utilizadas com eficcia, notificam os administradores de sistema sobre alguma suspeita de mau funcionamento, ou ainda, fornecem informaes detalhadas aos engenheiros de planejamento de capacidade.

    Motivado por uma necessidade real de uma empresa local fornecedora de softwares de TEF, pelo alto valor comercial e nvel de especializao dessas ferramentas, neste projeto desenvolvida uma ferramenta potencialmente de baixo custo, o Vigilante TEF (VTEF), para monitorao para Autorizadores de TEF. Este sistema de TEF que decide em ltima instncia a aprovao das transaes.

    O VTEF tem o propsito de identificar eventos que virtualmente afetam a alta disponibilidade do Autorizador de TEF. Isto ser feito pela deteco de erros e clculo de mtricas de estabilidade e desempenho.

    Para observao e tratamento destes eventos utilizado o servidor de monitorao Nagios, por conta de sua disponibilidade bibliogrfica e por ser um software open source, gratuito e reconhecido pela imprensa especializada. Alinhado com os objetivos do projeto, apresenta as seguintes caractersticas:

    Permite identificao de ocorrncias atravs de interface grfica;

    Notifica alertas atravs de email ou celular;

    Apresenta uma plataforma estvel, com dez anos em desenvolvimento;

  • v

    ESCOLA POLITCNICA DE PERNAMBUCO

    Abstract The Electronic Funds Transfer (EFT) systems belong to the category of

    mission critical systems since its failures have the potencial of a big financial loss or reputation damage. These systems are responsible for payment authorization made mainly with magnetic or smart cards. Their processing goes from the transaction data capturing to the formatting and transmission of the sale/payment receipt.

    Its worthy to highlight the monitoring tools, among the support tools used with this systems, because they notify systerm administrators about suspected bad system behaviour or because they give detailed information to capacity planning engineers. These benefits are achieved only when they are built and used effectively.

    This project is motivated by a actual need of a local company that sells EFT software, as well as by the high commercial value and high especialization of these tools. This project develops a low cost tool, the Vigilante TEF (VTEF), proper to EFT Authorizers monitoring. This EFT system is the last one in the chain and is responsible for the transactions approval.

    The VTEF has the purpose of identifying events that can affect the EFT Authorizer high availability. This will be done by detecting erros and calculating performance and stability metrics.

    The VTEF will use the Nagios monitoring software in order to observe and handle these events. Some of the reasons for this are the spread out bibliography related to Nagios and the fact that its a free open source software recognized by the especialized press. Besides this, aligned with immediate and future project targets, it presents the following features:

    It allows the identification of incidents through a web graphical user interface;

    It notifies alerts through email or cellphone messages;

    Its a mature plataform with ten years of development;

  • vi

    ESCOLA POLITCNICA DE PERNAMBUCO

    Sumrio RESUMO....................................................................................................................................................... IV

    ABSTRACT ..................................................................................................................................................... V

    SUMRIO ..................................................................................................................................................... VI

    SUMRIO ..................................................................................................................................................... VI

    NDICE DE FIGURAS .................................................................................................................................... VIII

    TABELA DE SMBOLOS E SIGLAS ................................................................................................................... IX

    CAPTULO 1 INTRODUO ...........................................................................................................................10

    1.1 OBJETIVO ........................................................................................................................................11

    1.2 ESTRUTURA DO TRABALHO ...................................................................................................................12

    CAPTULO 2 NAGIOS .....................................................................................................................................13

    2.1 VISO DE IMPLANTAO .....................................................................................................................14

    2.2 VISO OPERACIONAL .........................................................................................................................15

    2.2.1 Instalao Bsica ............................................................................................... 15

    2.2.2 Configurao Bsica ........................................................................................... 16

    2.2.3 Visualizao Bsica ............................................................................................ 18

    2.2.4 Execuo ............................................................................................................ 20

    CAPTULO 3 TRANSFERNCIA ELETRNICA DE FUNDOS ...............................................................................21

    3.1 DEFINIO ......................................................................................................................................21

    3.2 ARQUITETURA E TRANSAES...............................................................................................................22

    CAPTULO 4 DESENVOLVIMENTO DO PROJETO ............................................................................................26

    4.1 PLANEJAMENTO ................................................................................................................................26

    4.2 ESPECIFICAO DOS REQUISITOS ...........................................................................................................29

    4.2.2 Introduo ......................................................................................................... 29

    4.2.3 Descrio Geral .................................................................................................. 30

    4.2.4 Requisitos No Funcionais de Interface ............................................................... 32

    4.2.5 Requisitos Funcionais ......................................................................................... 33

    4.2.6 Requisitos No Funcionais Adicionais.................................................................. 43

    4.3 MODELAGEM ESTRUTURAL E DE DADOS ..................................................................................................44

    4.3.1 Modelo Estrutural .............................................................................................. 44

    4.3.2 Modelo de Dados ............................................................................................... 45

    4.4 CDIGO FONTE .................................................................................................................................47

    4.5 ARQUIVOS DE CONFIGURAO DA MONITORAO ....................................................................................49

    4.6 PLANO DE TESTES ..............................................................................................................................50

    CAPTULO 5 RESULTADOS E IMPACTOS ........................................................................................................55

  • vii

    ESCOLA POLITCNICA DE PERNAMBUCO

    5.1 EXECUO DOS CASOS DE TESTE ...........................................................................................................55

    5.2 ANLISE DOS RESULTADOS DO PROJETO ..................................................................................................58

    5.3 IMPACTOS DA FERRAMENTA .................................................................................................................59

    CAPTULO 6 CONCLUSO E TRABALHOS FUTUROS .......................................................................................60

    BIBLIOGRAFIA ..............................................................................................................................................61

    APNDICE A SCRIPTS DE TESTE .....................................................................................................................63

  • viii

    ESCOLA POLITCNICA DE PERNAMBUCO

    ndice de Figuras Figura 1. Checagem Passiva Remota [1] ................................................................. 15

    Figura 2. Cardinalidade/multiplicidade das declaraes dos objetos bsicos .......... 17

    Figura 3. Diagrama UML de Implantao da arquitetura de TEF ............................. 22

    Figura 4. Sequncia de mensagens ISO8583 para concluso com sucesso ........... 24

    Figura 5. Sequncia de mensagens ISO8583 para concluso pela Sonda .............. 25

    Figura 6. Sequncia de mensagens ISO8583 para concluso com Desfazimento .. 25

    Figura 7. Diagrama UML de Colaborao da Verificao Passiva ........................... 30

    Figura 8. Diagrama UML de Implantao do VTEF .................................................. 31

    Figura 9. Diagrama UML de Classes (Mdulos) do VTEF ........................................ 44

  • ix

    ESCOLA POLITCNICA DE PERNAMBUCO

    Tabela de Smbolos e Siglas TEF Transferncia Eletrnica de Fundos

    NSCA - Nagios Service Check Acceptor (Aceitador de Verificaes de Servios do Nagios)

    CPU Central Processing Unit (Unidade Central de Processamento)

    TCP Transmission Control Protocol (Protocolo de Controle de Transmisso)

    IP Internet Protocol (Protocolo de Internet)

    PoS Point of Sale (Ponto de Venda PDV)

    SQL Structured Query Language (Linguagem Estruturada de Consulta)

    API Application Program Interface (Interface de Programa de Aplicao)

    SGBD Sistemas de Gerenciamento de Banco de Dados

    TMR Tempo Mdio de Resposta

    TPPS Transaes Processadas por Segundo

    TPS Transaes por Segundo

  • 10

    ESCOLA POLITCNICA DE PERNAMBUCO

    Captulo 1 Introduo

    Um dos desafios da Engenharia atingir o equlibrio ideal no apenas entre custo e qualidade, ou agilidade de produo e novas caractersticas, mas tambm entre otimizao e segurana. Porm, existe uma categoria de software na qual o desempenho pode ser to importante quanto a confiabilidade. Tratam-se dos sistemas de misso crtica, caracterizados principalmente pelo potencial de impacto causado por uma falha. So vidas perdidas, no caso de uma pane em um sistema de controle areo, prejuzos financeiros ou de reputao, quando de um sistema de comrcio eletrnico ou de outro que viabiliza o pagamento de uma compra.

    Os sistemas de TEF (Transferncia Eletrnica de Fundos) so aqueles que efetuam a autorizao de pagamentos, principalmente com carto magntico ou com chip, e so responsveis desde a captura dos dados da transao at ao envio dos comprovantes. Devido necessidade de alta disponibilidade e rapidez nas operaes, a arquitetura desses sistemas evoluiu a ponto de envolver, fim a fim, vrios componentes de hardware e software.

    Uma pesquisa da Dataquest [1] aponta um alto crescimento na indisponibilidade, no planejada, de servios de misso crtica, mesmo com a melhoria dos hardwares, dos processos de desenvolvimento e das ferramentas de suporte. Dentre essas ferramentas, vale destacar as de monitorao que, quando construdas e utilizadas com eficcia, notificam os administradores de sistema sobre alguma suspeita de mau funcionamento, ou ainda, fornecem informaes detalhadas aos engenheiros de planejamento de capacidade.

    Alguns dos fatores que podem influenciar negativamente o grau de adeso dessas ferramentas so o alto custo do software e o nvel de especializao [2] destas. Em ambientes complexos de infra-estrutura, as falhas podem advir de vrias reas e de diversos modos em cada uma delas: em hardware, em configurao de Rede, em sistemas de Banco de Dados, por esgotamento instantneo ou persistente de recursos, por erros de aplicao/programao, dentre outros [3].

    H uma frase clssica na Administrao, um velho adgio, que resume esse contexto dizendo que voc no consegue gerenciar aquilo que voc no consegue medir. Logo, como forma de contribuir para soluo deste problema, neste projeto de monografia ser desenvolvida uma ferramenta, potencialmente de baixo custo, para monitorao de Autorizadores de TEF. O Autorizador o software que decide, em ltima instncia, sobre a aprovao da transao enviada pelo Servidor de TEF,

  • 11

    ESCOLA POLITCNICA DE PERNAMBUCO

    contendo, esta, os dados do meio de pagamento do cliente (ex: carto de crdito), capturados no caixa de uma loja.

    Ser adotado o Nagios como servidor de monitorao, com o qual a ferramenta dever se integrar, por conta de sua disponibilidade bibliogrfica e por ser um software open source, gratuito e reconhecido pela imprensa especializada [4]. Alm disso, alinhado com os objetivos do projeto, imediatos ou futuros, apresenta as seguintes caractersticas:

    Permite identificao de ocorrncias atravs de interface grfica;

    Notifica alertas atravs de email ou celular;

    Apresenta uma plataforma estvel, com dez anos em desenvolvimento;

    Suporta plugins para extenso do alcance da monitorao.

    1.1 Objetivo Servios de misso crtica precisam ser monitorados preventivamente de

    modo que sejam emitidos alertas em situaes de risco. Eles requerem, em geral, uma resposta rpida e segura quanto anlise de casos e correo de bugs.

    A proposta que a ferramenta do projeto, o Vigilante TEF, permita a notificao quase instantnea de informaes pertinentes a eventos no domnio de negcio do TEF, ou relacionados a erros de infra-estrutura, que possam sugerir ou apontar o impacto negativo no funcionamento do Autorizador de TEF.

    Para enviar os dados desses eventos, em virtude da facilidade de integrao com o Nagios, ser utilizado um de seus programas complementares, o NSCA, de modo a viabilizar os seguintes requisitos funcionais da ferramenta:

    Notificar erros, ocorridos no Autorizador TEF, no processamento de regras de negcio relacionados a mdulos como por exemplo de acatamento de cheque, cartes pr-pagos, pagamento de ttulos, etc.

    Notificar erros, ocorridos no Autorizador TEF, classificados por tipo de API e que identifique a origem levando em considerao uma arquitetura em cluster;

    Calcular periodicamente indicadores de estabilidade do ambiente operacional, com base na frequncia e resultado das mensagens do protocolo de aplicao especficas do TEF.

    natural que, como todo software do tipo servidor, sem operador humano, o AutorizadorTEF utilize arquivos de log para registrar as inconsistncias. Todavia, se

  • 12

    ESCOLA POLITCNICA DE PERNAMBUCO

    esse arquivo contm pouca informao, isso dificulta o diagnstico do erro e, por outro lado, havendo excesso, aumenta o custo de entrada e sada da aplicao e eleva a importncia dos cuidados com gerenciamento dos logs, principalmente com relao limpeza e backups. Dada essa condio, as notificaes de monitorao propostas pelo projeto visam diminuir a dependncia com relao aos arquivos de log na deteco de erros do aplicativo e de infra-estrutura.

    1.2 Estrutura do trabalho Este trabalho est organizado da seguinte maneira: os trs primeiros

    captulos abrangem os temas relacionados ao contexto do desenvolvimento da ferramenta; o quarto apresenta a metodologia de desenvolvimento adotada; no quinto so exibidos e avaliados os resultados. Por ltimo, na concluso, aborda-se de maneira geral se os objetivos foram atingidos e so sugeridos trabalhos futuros. O propsito de cada captulo descrito a seguir:

    Captulo 2: Apresenta o Nagios, software servidor utilizado para tratar, acompanhar e notificar os eventos da monitorao.

    Captulo 3: Expe uma introduo ao TEF: sua arquitetura, protocolo de comunicao e fluxos que definem as transaes eletrnicas.

    Captulo 4: Define o planejamento para desenvolvimento do projeto e apresenta os artefatos de sua execuo.

    Captulo 5: Avalia o resultado dos testes planejados e analisa os impactos nas fbricas de software e de servios.

    Captulo 6: Recapitula a proposta e os resultados do projeto e fala dos possveis trabalhos futuros.

    Outro aspecto para melhorar a legibilidade do texto foi a adoo de um tipo diferente de letra para facilitar a percepo dos termos contidos em arquivo de configurao ou em cdigo fonte. A mesma abordagem foi aplicada ao nome dos arquivos ou diretrios, por exemplo, /usr/local/nagios o diretrio padro de instalao do Nagios.

  • 13

    ESCOLA POLITCNICA DE PERNAMBUCO

    Captulo 2 NAGIOS

    Nagios(R) um software livre, gratuito, com maturidade na plataforma Linux/Unix, para monitorao de redes, aplicaes e recursos computacionais tais como CPU, memria e espao em disco. Em termos gerais sua funo principal realizar verificaes configurveis de hosts e servios, locais ou remotos, e quando houver algo de errado nestes, permitir a notificao aos administradores de sistema e gerentes atravs de aviso sonoro, e-mail, pager ou mensagens de celular.

    Sua principal vantagem, explorada em detalhes a seguir, que ele no foi construdo como uma pea monoltica de software, pretendendo dispor de todas caractersticas (features) de monitorao necessrias a uma ou mais categorias de aplicaes ou equipamentos. Em vez disso, alm de sua licena, GNU General Public License Version 2, dar condies legais para modificao de seu cdigo fonte, sua estrutura modular permite a interoperabilidade com outras aplicaes atravs de integraes simples, e consequentemente, a extenso de sua funcionalidade para atender a demandas especficas. No obstante, no so poucas as opes embutidas (built-in) no Nagios. Sua instalao contm em torno de dez arquivos de configurao somando ao todo mais de cem parmetros ou diretivas abrangendo vrias etapas da monitorao, verificao, deteo de falha, ao corretiva, at a notificao. Algumas de suas caractersticas prontas so [5]:

    a. Monitorao de servios de rede (SMTP, POP3, HTTP, NNTP, PING, etc.); b. Monitorao de recursos de hosts (carga do processador, espao livre em disco,

    etc.); c. Checagem paralela de servios; d. Habilidade de definir hierarquia de hosts e servios permitindo a distino entre

    aqueles que esto fora / indisponveis e os no alcanveis; e. Notificao de grupo de contatos quando um problema ocorrer ou for resolvido; f. Habilidade de definir manipuladores de eventos para disparar resolues pr-

    ativas;

    g. Rodzio automtico de arquivo de log; h. Interface web opcional para visualizao de estados e administrao.

    Essa seria sua viso pragmtica ou utilitria porm para tirar proveito de seu potencial e saber como melhor aplic-lo monitorao de servios de TEF, faz-se

  • 14

    ESCOLA POLITCNICA DE PERNAMBUCO

    necessrio abordar outros aspectos, cada um numa viso prpria, que respondem as questes abaixo:

    Viso de Implantao: Quais as interfaces de integrao com os demais componentes da soluo?

    Viso Operacional: Quais os procedimentos ou conhecimentos necessrios para instalar, configurar, executar e comear a utiliz-lo?

    Entretanto, antes de responder a essas questes, algumas observaes devem ser feitas. Apesar do Nagios possuir meios de monitorar mquinas Linux/Unix, servidores Netware, impressoras de rede e roteadores/switches, este estudo est delimitado integrao com mquinas Windows, onde roda atualmente o servio Autorizador de TEF, utilizado na validao da soluo final proposta. Sabe-se tambm que a disponibilidade de aplicaes distribudas depende do bom estado geral dos equipamentos e fluxos de rede. Contudo, estes no sero monitorados diretamente, mas atravs do reflexo de seu mau funcionamento neste servio.

    2.1 Viso de Implantao Existem dois modos de monitorar um servio ou host com o Nagios: ativamente

    ou passivamente. As checagens ativas so iniciadas por seu daemon e executadas em base regular, enquanto que as passivas so iniciadas por processos externos, locais ou remotos, cujos resultados so submetidos de forma arbritrria para o processamento do Nagios. Logo, a checagem passiva deve ser utilizada em pelo menos duas ocasies:

    Para eventos de natureza assncrona e que no podem, portanto, ser monitorados eficientemente realizando polling do seu estado, a exemplo de timeout de conexo TCP/IP ou outros erros de programas.

    Quando um servio ou host est localizado atrs de um firewall cuja regra probe o recebimento de conexes para a finalidade em questo.

    Para realizar os dois tipos de checagens remotamente, o Nagios dispe de dois addons, que so softwares para estender sua capacidade de monitorao e integr-lo a outras aplicaes: so eles o NRPE (Nagios Remote Plugin Executor) e o NSCA (Nagios Service Check Acceptor).

    Segue abaixo um detalhamento do NSCA j que neste projeto, apesar de serem executadas verificaes sncronas, este addon foi suficiente como meio de reportar os eventos de monitorao ao Nagios.

  • 15

    ESCOLA POLITCNICA DE PERNAMBUCO

    NSCA

    Figura 1. Checagem Passiva Remota [5]

    Toda checagem passiva se inicia em um processo (programa ou script), geralmente remoto, que executa um programa chamado send_nsca passando como parmetro os dados do item monitorado (send_nsca_win32.exe quando distribudo no projeto NSCA Win32Client do Nagios EXCHANGE [6]). Este ento envia via TCP/IP os dados para o NSCA que formata uma mensagem do tipo PROCESS_SERVICE_CHECK_RESULT e a escreve no Arquivo de Comando Externo (External Command File) cuja implementao de um pipe nomeado, na prtica funcionando como uma fila, e que criado pelo Nagios na sua inicializao e removido na finalizao.

    2.2 Viso Operacional

    2.2.1 Instalao Bsica

    O procedimento de instalao e configurao bsica dos releases Nagios 3.x bem definido no Guia de Instalao Rpida da documentao oficial [5] para as distribuies Linux Fedora Core 6, openSUSE 10.2 e Ubuntu 6.10 (no experimento foi utilizado o Ubuntu 8.04 para o qual o guia tambm foi vlido). Ao final das instrues o resultado ser um ambiente com:

    Nagios e os plugins oficiais instalados em /usr/local/nagios;

    Nagios configurado como monitor de alguns recursos do localhost (carga de CPU, espao livre em disco, etc.);

    Interface web acessvel por http://localhost/nagios.

    Depois disso necessrio instalar o NSCA e seu respectivo mdulo cliente: O NSCA conforme manual NSCA_Setup.pdf [7]; O send_nsca_win32 baixando o binrio send_nsca_win32_bin.zip [8];

  • 16

    ESCOLA POLITCNICA DE PERNAMBUCO

    2.2.2 Configurao Bsica

    Intuitivamente a configurao de sistemas de monitorao pode ser vista como um meio de associar a hosts, ou servios, uma ao inicial, que um comando de verificao executado em certos momentos, e uma ao final, que so medidas de alerta ou corretivas, baseadas no estado resultante desta verificao.

    Com o Nagios no diferente mas vai alm possibilitando a definio de vrios tipos de particularidades: na verificao, a exemplo de um critrio de deteco de falha para evitar alarmes falsos, na notificao dos contatos sobre quais eventos estes precisam ser informados, dentre vrias outras.

    Quanto forma, a configurao realizada atravs de arquivos de texto puro, situados por padro em /usr/local/nagios/etc/, utilizando uma linguagem muito simples composta por trs tipos de declaraes:

    TIPO DE DECLARAO SINTAXE

    Variveis =

    Macros $$=

    Definio de Objeto define { ...

    }

    Variveis so opes de configuraes pr-definidas que afetam o modo de operao do processo deamon ou dos CGIs da interface web e que so situadas respectivamente no arquivo de configurao principal (nagios.cfg) ou no de CGI (cgi.cfg).

    As macros so parmetros que podem ser definidos pelo usurio e so declaradas nos arquivos de recursos, definidos pela varivel resource_file, que por padro apenas o resources.cfg.

    Por ltimo, objetos so todos elementos envolvidos na lgica de monitorao ou notificao [5]. Aqueles que so obrigatrios e necessrios so declarados como exemplos pela instalao rpida. No arquivo templates.cgi encontra-se demonstraes da aplicao do conceito de herana, pela diretiva use, na qual um host ou servio adquire as caractersiticas de um outro objeto abstrato.

    Na documentao encontra-se a definio das dezenas de variveis que regulam vrios aspectos comportamentais do Nagios. As macros so poucas e podem

  • 17

    ESCOLA POLITCNICA DE PERNAMBUCO

    ser analisadas, utilizadas ou declaradas sob demanda. J os objetos, compem a idia central da monitorao. Segue uma descrio para cada tipo de objeto essencial monitorao, e as possveis associaes entre eles representadas pelo diagrama UML da figura 2.

    TIPO DE OBJETO ESSENCIAL

    DESCRIO

    hostgroup Agrupamento de hosts para facilitar a viso pela interface web do estado de seus integrantes

    host Dispositivo fsico na rede (servidor, estao de trabalho, roteador, impressora, etc.) a monitorar

    servicegroup Agrupamento de servios com finalidade anloga ao hostgroup

    service Um elemento operacional de um host (um processo, funcionalidade ou recurso) e junto a este compe os possveis alvos de monitorao.

    contact Identifica uma pessoa que precisa ser notificada quando ocorre algum problema

    contactgroup Agrupamento de responsveis por um ou mais hosts ou servios

    command Define como executar um programa ou script que pode ser usado para checagem, notificao e tratamento de eventos (medida reativa)

    timeperiod Controla quando hosts e servios devem ser monitorados e o perodo em que os contatos podem ser notificados

    Figura 2. Cardinalidade/multiplicidade das declaraes dos objetos bsicos

  • 18

    ESCOLA POLITCNICA DE PERNAMBUCO

    Nota-se na figura 2 que um host ou servio verificado por um comando e possui um grupo de contatos responsveis que recebem notificaes na ocorrncia de eventos escolhidos em suas diretivas. Os dois timeperiods so perodos de ativao, um para verificao e outro para notificao. Por fim, demonstrado que a cardinalidade de um servio para host de 0 para N, ou seja, que permitido declarar a verificao apenas de host, onde no interessaria nenhum de seus servios, ou a verificao de um servio para ser executada em um ou mais hosts.

    2.2.3 Visualizao Bsica

    A interface grfica da web disponibiliza fundamentalmente pginas, cujas imagens encontram-se no Anexo A, que exibem o estado corrente dos hosts e servios em monitorao mas tambm prov vrias outras funcionalidades tais como:

    Ferramentas de tendncias e dados histricos;

    Agendamento de downtime;

    Ativao ou desativao de checagens de servios ou notificaes;

    Meios para examinar as configuraes atuais;

    Ferramentas de mapeamento grfico do ambiente;

    Ferramentas para obter o status do daemon do Nagios.

    O menu principal, os links e contedos das pginas so organizados de forma intuitiva tal que durante a navegao j se percebe o propsito de cada opo. Nesta seo so destacados os dados das pginas que usam uma terminologia definida pelo Nagios, ou por uma de suas regras, e que esto relacionados ao momento em que os administradores precisam visualizar a situao presente dos hosts e servios (item A). Em seguida, analisada criticamente a implementao da interface do ponto de vista do desempenho (item B).

    A) Estado na terminologia Nagios As verificaes do Nagios podem ser realizadas, em cima de hosts e/ou

    servios, por intermdio de plugins ou passivamente pela integrao do NSCA.

    Os hosts checados podem ficar em um dos trs estados: UP (Ativo), DOWN (Inativo) ou UNREACHABLE* (indeterminado ou inalcanvel, quando o host no qual dependa, declarado com a diretiva parent, est inativo). As verificaes dos plugins, por sua vez, retornam os resultados OK, WARNING (alerta), UNKNOWN (desconhecido) ou CRITICAL (crtico).

  • 19

    ESCOLA POLITCNICA DE PERNAMBUCO

    Como o Nagios traduz esses resultados nos estados, depende de duas etapas. Na primeira etapa o resultado mapeado a um estado preliminar, que pode ser alterado pelo processamento da segunda etapa, de acordo com a tabela abaixo:

    RESULTADO DO PLUGIN ESTADO PRELIMINAR

    OK UP

    WARNING UP ou DOWN

    UNKNOWN DOWN

    CRITICAL DOWN

    Na segunda, se o estado preliminar for DOWN, o Nagios tentar determinar se o estado do host de fato DOWN ou UNREACHABLE. A distino entre esses dois estados importante porque permite ao administrador determinar a causa de um problema de rede mais rapidamente. A tabela abaixo apresenta a regra, baseada no estado do host pai, para definir o estado final do host aps a verificao.

    ESTADO PRELIMINAR

    ESTADO DO HOST PAI ESTADO FINAL DO HOST

    DOWN Pelo menos o de um pai UP DOWN

    DOWN Todos pais so DOWN ou UNREACHABLE

    UNREACHABLE

    J a definio do estado de um servio determinada unicamente pelo resultado do plugin. No entanto, preciso saber que tanto para este como para um host esses estados no so tomados como verdadeiros de imediato pois existe o conceito de tipo de estado que pode ser SOFT ou HARD.

    O estado assume o tipo SOFT nas seguintes situaes: Quando uma verificao resulta em estado no OK e esta no foi realizada o

    nmero de vezes especificado na diretiva max_check_attempts. No caso dos hosts, o no OK o que no UP.

    Quando um servio ou host se recupera de um erro SOFT. Por exemplo, aps a primeira verificao o servio est em UNKOWN e na segunda est OK. Este OK fica marcado ainda como SOFT.

    O estado assume o tipo HARD nas demais situaes que so:

  • 20

    ESCOLA POLITCNICA DE PERNAMBUCO

    Quando uma verificao resulta em estado de erro e j foi executada tantas vezes quanto definido em max_check_attempts.

    Quando a transio de estado ocorre de um erro para outro (ex: WARNING para CRITICAL).

    Quando uma verificao de servio resulta em estado de erro e seu host correspondente est DOWN ou UNREACHABLE.

    Quando um host ou servio se recupera de um estado HARD. Quando o resultado de uma verificao passiva recebido ao menos que a

    varivel passive_host_checks_are_soft esteja habilitada.

    B) Implementao A renderizao de seu contedo dinmico baseada em CGI, que uma

    tecnologia de programas escritos em C, cuja limitao de desempenho aplica-se apenas a um cenrio de vrias requisies simultneas, sendo improvvel ao contexto do projeto porque as empresas dificilmente possuem vrios administradores de sistema ou de redes, para a mesma infra-estrutura. Ainda que este fosse o caso, seria necessrio haver uma sincronizao de refresh na tela destes.

    Logo, as requisies dos links so tratadas por esses CGIs, que por padro no Nagios requerem que o usurio esteja autenticado ao servidor web hospedeiro. A tabela abaixo contempla aqueles fundamentais percepo do estado corrente.

    NOME DO CGI FUNO

    status.cgi O mais importante porque oferece uma viso geral e detalhada do estado de todos objetos monitorados

    tac.cgi Viso area de toda atividade de monitorao destacando os problemas tratados e os que precisam de ateno

    config.cgi Exibe detalhes de configurao dos objetos

    cmd.cgi Envia comandos ao processo do Nagios

    2.2.4 Execuo

    Nagios instalado como servio e as explicaes de como execut-lo so detalhadas no tpico Starting and Stoping Nagios [5]. Alm disso importante ler tambm o tpico Verifying Your Configuration j que o Nagios finaliza em caso de erro de configurao. necessrio executar manualmente os deamons de suporte s verificaes ativa e passiva remotas, o NRPE e o NSCA, cujos procedimentos so encontrados nas respectivas documentaes [9,7].

  • 21

    ESCOLA POLITCNICA DE PERNAMBUCO

    Captulo 3 Transferncia Eletrnica de Fundos

    3.1 Definio Os sistemas de engenharia podem ser definidos atravs de sua estrutura

    fsica ou lgica. Porm, outras vezes, prefere-se abord-los de forma mais pragmtica, por sua finalidade e funcionalidades. As diferentes definies de Transferncia Eletrnica de Fundos, ou simplesmente TEF, encontradas na internet [10][11][12][13], geralmente se enquadram na segunda alternativa e se referem ao ato de efetuar qualquer tipo de transao financeira com o propsito de autorizar uma instituio a realizar um crdito ou dbito em uma conta bancria.

    O TEF tipificado legalmente nos Estados Unidos atravs do Ato Regulatrio E (Regulation E), a fim de estabelecer os direitos e deveres dos consumidores. Seu conceito destaca tambm os meios tecnolgicos, no qual, TEF significa qualquer transferncia de fundos iniciada atravs de um terminal eletrnico, um telefone ou um computador, para solicitar ou autorizar uma instituio financeira a debitar ou creditar uma conta de um consumidor [14]. Neste mesmo Ato, o conceito inclui os seguintes tipos de transferncias:

    i. Realizada por PDV (Ponto de Venda), que o conjunto hardware e software de Automao Comercial responsvel pelo registro dos itens do pagamento e pela integrao com o Emissor de Cupom Fiscal (ECF);

    ii. Transferncias de caixas de atendimento automtico;

    iii. Depsitos ou saques diretos de fundos;

    iv. Transferncias iniciadas por telefone;

    v. Transferncias resultantes de transaes com carto de dbito.

    O projeto se concentrar nos itens (i) e (v), os quais ocorrem com frequncia no cotidiano do consumidor brasileiro, principalmente no caso dos clientes de grandes varejistas, como supermercados. Esta frequncia, devido popularizao dos meios de pagamento eletrnicos, exige do sistema caractersticas de alta disponibilidade e desempenho, uma vez que proporcionalmente intensidade do fluxo de compras, alguns segundos de atraso no processamento do pagamento de cada cliente podem representar minutos na medida em que a fila dos caixas for aumentando. Supondo, por exemplo, uma fila de 22 pessoas para dois caixas, se cada um destes atrasar 30 segundos, e o tempo de atendimento dos dois caixas for

  • 22

    ESCOLA POLITCNICA DE PERNAMBUCO

    o mesmo, as 21 e 22 pessoas da fila tero esperado 300 segundos (6 minutos) a mais para serem atendidos. Esta situao se agrava ainda mais quando o sistema fica fora do ar, ou quando o tempo de totalizao do cupom da compra, mais o tempo de pagamento, excede o tempo de chegada de um novo cliente fila.

    3.2 Arquitetura e Transaes De modo a minimizar a probabilidade dessas incovenincias, que diminuem o

    ndice de satisfao do consumidor, a arquitetura dos sistemas de TEF evoluiu de modo que todos recursos tecnolgicos para concretizao da venda sejam pr-alocados (dedicados) [15], eliminando o tempo de preparao para processar as transaes. Essa arquitetura representada pela figura abaixo:

    Figura 3. Diagrama UML de Implantao da arquitetura de TEF

    Observa-se que o PDV, auxiliado pelo programa clienteTEF, realiza a captura dos dados do carto do consumidor atravs do Pinpad, e envia a transao contendo estes dados mais os dados do pagamento. O servidor de TEF uma aplicao que funciona como um gateway para que as transaes cheguem ao Autorizador de TEF. Sua funo validar as mensagens recebidas de sua aplicao cliente, formatada em protocolo privado definido pela empresa fornecedora, e convert-la para uma transao ISO 8583, que um protocolo padro internacional utilizado por redes administradoras de cartes, nacionais e internacionais. Esta mensagem ISO 8583 enviada ao Autorizador de TEF, que a processa e deve respond-la de imediato no mesmo protocolo e canal de comunicao se a transao foi aprovada com sucesso. No caso

  • 23

    ESCOLA POLITCNICA DE PERNAMBUCO

    em que ela no aprovada, o AutorizadorTEF responde no campo cdigo de resposta, do protocolo, qual foi o motivo da negao da transao [16].

    De maneira a viabilizar toda sorte de servio financeiro, ou operao eltrnica financeira, realizada no caixa, os tipos de transaes enviadas para o Servidor TEF, e para o AutorizadorTEF, so:

    Pagamento: pagamento de fatura, resultando na transferncia financeira da conta do varejista para a conta do cedente do boleto ou da consessionria de luz, telefone, etc.;

    Compra/Venda: o portador do carto paga por bens ou servio prestado, afetando o saldo de sua conta bancria ou de crdito;

    Estorno: o varejista cancela a transao realizada anteriormente pelo portador do carto, para que a administradora de carto no faa a cobrana na fatura;

    Consulta: transao sem custo ao consumidor que retorna informaes associadas a uma compra ou pagamento passado ou futuro (ex: limite de crdito ou juros de um pagamento); Alm destes, existem outros tipos como as transaes que adicionam crditos a

    uma conta de celular pr-pago (E-Top-Up) ou as de Cashback, na qual o portador realiza um saque em sua prpria conta atravs do caixa da loja. Essas e as demais devem ser classificadas em um dos tipos acima para que a ferramenta do projeto as identifique na monitorao. No caso dessas duas, por exemplo, a E-Top-Up pode ser considerada como um pagamento e a Cashback como uma compra, para efeito de monitorao.

    Outro aspecto do TEF relevante ao entendimento dos resultados do Vigilante TEF o do gerenciamento do status de cada transao, quanto ao seu estgio de processamento, realizado pelo Servidor e Autorizador de TEF. Para compreend-lo necessrio conhecer quais mensagens ISO 8583 enviadas para cada tipo de transao, nos respectivos cenrios em que so requisitadas. Nesse sentido, valido esclarecer as seguintes questes, com relao a cenrios de exceo, que justificam o envio de algumas mensagens do padro ISO:

    Devido possibilidade de falhas fsicas ou lgicas na transmisso das mensagens, qual deve ser a ao do ServidorTEF caso a resposta do Autorizador no seja recebida ou recebida com atraso (timeout)?

    Caso a resposta seja uma aprovao, o saldo do consumidor j est comprometido mesmo quando o PDV no recebe a resposta, que contm os comprovantes para impresso?

  • 24

    ESCOLA POLITCNICA DE PERNAMBUCO

    Com o objetivo de tratar essas questes, de acordo com o padro ISO 8583:87, toda transao de venda, pagamento ou estorno, que afetam o saldo do consumidor, apenas concluda (com sucesso) se o ServidorTEF, ao receber uma resposta de aprovao da transao em questo, enviar com sucesso uma mensagem de confirmao (automatica) para o AutorizadorTEF. No entanto, se o ServidorTEF envi-la e esta confirmao no for recebida ou processada pelo AutorizadorTEF, a transao ficar com status confirmada/concluda no ServidorTEF porm com status pendente de confirmao no AutorizadorTEF.

    Essa situao requer a utilizao de outro tipo de mensagem definida pelo protocolo ISO, com propsito de contigenciamento, que a sonda. Esta mensagem uma consulta peridica que o AutorizadorTEF faz ao ServidorTEF sobre o status de uma determinada transao que ficou pendente. De outro modo, caso o ServidorTEF no tenha enviado a confirmao, por alguma falha de processamento, a transao ficar pendente no prprio e exigir um procedimento manual da equipe de suporte, contratada pelo varejista, para resoluo da pendncia utilizando uma ferramenta de retaguarda (backoffice). Nesta ferramenta, o usurio tem a opo de confirmar a venda (ou pagamento ou estorno), finalizando-a com sucesso caso seja recebida e processada pelo AutorizadorTEF, ou revert-la, fazendo com que o ServidorTEF envie um outro, e ltimo tipo, de mensagem de exceo que o desfazimento (reversal).

    As transaes ISO8583 que demandam a confirmao para concluso, porque afetam o saldo do consumidor, so chamadas de transaes de 3 pernas (neste tipo so includas as de compra, pagamento e estorno). Nas sees a seguir, so apresentados diagramas que representam a troca de mensagens nos cenrios discutidos acima e se aplicam a todas transaes de 3 pernas. Ao lado de cada mensagem encontra-se o status da transao (A: Em Andamento, P: Pendente, C: Concluda, D: Desfeita), no respectivo sistema de TEF, ao receber ou enviar a mensagem.

    Fluxo de Compra com sucesso

    A figura 4 representa as mensagens ISO8583 transmitidas entre um ServidorTEF e um AutorizadorTEF para concluso de uma transao de compra com sucesso.

    Figura 4. Sequncia de mensagens ISO8583 para concluso com sucesso

  • 25

    ESCOLA POLITCNICA DE PERNAMBUCO

    Fluxo de Confirmao atravs de Sonda

    A figura 5 representa o cenrio em que a mensagem de sonda ISO8583 confirma uma compra quando a mensagem de confirmao no foi recebida ou processada no AutorizadorTEF.

    Figura 5. Sequncia de mensagens ISO8583 para concluso pela Sonda

    Fluxo de Desfazimento de Transao

    A figura abaixo representa o cenrio em que a mensagem de confirmao no foi enviada e o estado da transao continuou pendente no ServidorTEF. A sonda no resolve neste caso porque ela no est com status confirmada no ServidorTEF ento se o consumidor no levou a mercadoria ou fez outro pagamento, a loja pode desfazer a transao e consequentemente no ser cobrada do consumidor.

    Figura 6. Sequncia de mensagens ISO8583 para concluso com Desfazimento

  • 26

    ESCOLA POLITCNICA DE PERNAMBUCO

    Captulo 4 Desenvolvimento do Projeto

    Este captulo apresenta a metodologia e o desenvolvimento do projeto, abrangendo desde o planejamento, o qual foi definido como um guia para execuo do projeto, at o relato do progresso, expondo o que foi produzido neste desenvolvimento.

    4.1 Planejamento O planejamento realizado consiste na adoo de uma metodologia baseada na

    abordagem iterativa incremental do RUP [17], um modelo de processo de desenvolvimento. Desse modelo foram selecionadas apenas as atividades de engenharia de software que, intuitivamente e baseado em experincia de projetos anteriores do autor, so necessrias execuo deste por apenas uma pessoa, a qual assume diversos papis, tais como analista, desenvolvedor e testador.

    O modelo Waterfall [18] (em cascata), utilizado como contra-exemplo, um processo de desenvolvimento composto pelas fases de Requisitos, Design, Codificao e Testes, no qual cada uma dessas fases executada sequencialmente, sempre nessa ordem e aps a concluso da anterior, considerando todo escopo do projeto.

    Sabe-se que a abordagem desse modelo possui riscos inerentes e isso evidenciado pelo artigo de David Parnas [19], cuja traduo de parte do texto a seguinte:

    Muitos dos detalhes [dos sistemas] somente se tornam conhecidos por ns medida que progredimos na sua implementao [do sistema]. Algumas coisas que aprendemos invalidam nosso design e ns precisamos retroceder.

    Sendo assim, a idia de definir um processo para o desenvolvimento deste projeto vem no sentido de mitigar o risco desse tipo de retrocesso que gera mudanas e retrabalhos desnecessrios. Desse modo, decidiu-se pela adoo da estratgia iterativa incremental do RUP porque, atravs dela, o projeto dividido em subprojetos, que so executados, em iteraes, um aps o outro. Logo, em cada iterao so executadas todas as atividades de engenharia de software demandadas por um projeto as quais, no RUP, so organizadas em workflows.

  • 27

    ESCOLA POLITCNICA DE PERNAMBUCO

    Neste projeto foram selecionados os workflows bsicos de Requisitos, Anlise e Design, Implementao e Testes para compor cada iterao de modo que a construo de um subconjunto do sistema possa se dar com base nas lies aprendidas no desenvolvimento de um subconjunto anterior. Em cada workflow foi gerado um artefato, que pode ser um documento, um modelo, arquivos de cdigo fonte (ou de configurao) ou um relatrio.

    A esses artefatos foram atribudas finalidades para avanar em questes especficas do projeto. Essas finalidades so descritas abaixo e distribudas em duas iteraes.

    A. Documento de Especificao de Requisitos

    1 Iterao Definir o raio ou alcance da monitorao quanto aos aspectos da aplicao

    que precisam ser monitorados;

    Definir o formato da mensagem dos eventos de monitorao em conformidade com a interface do Nagios e que contenha tambm a identificao da thread e do host para o caso de uma arquitetura em cluster ou algum outro tipo de redundncia;

    Classificar os erros que sero monitorados por tipo de API ou recurso utilizado pelo Autorizador TEF (ex: sistema de arquivos local ou distribudo, banco de dados de conexo ou transacional, redes X.25 ou TCP/IP, etc.);

    Definir as informaes especficas de cada evento de API como parmetros e contexto de execuo;

    Definir as mtricas mais relevantes ao negcio do TEF no que concerne monitorao do Autorizador;

    Definir o componente que ser responsvel pela gerao dessas mtricas;

    2 Iterao Especificar novas mtricas para monitorao;

    Refinar as informaes especficas dos eventos de monitorao que se deseja obter/notificar;

    B. Modelo Estrutural e de Dados

    1 Iterao Projetar o componente de integrao entre Autorizador TEF e o Nagios; 2 iterao

  • 28

    ESCOLA POLITCNICA DE PERNAMBUCO

    Projetar o mecanismo de deteco de mudana na configurao do Autorizador TEF;

    C. Cdigo Fonte

    1 Iterao Implementar o gerador de mtricas selecionando uma de cada tipo, aquelas

    cujos clculos possuem maior diferena entre si; 2 Iterao

    Concluir implementao do gerador de mtricas;

    Converter o componente de verificao passiva (send_nsca.exe) para DLL Windows de forma que possa ser integrado ao Autorizador por linkedio.

    D. Arquivos de Configurao da Monitorao

    1 Iterao Configurar o Nagios para realizar as verificaes ativas e tratar o resultado das

    passivas;

    Configurar a integrao dos programas participantes do processo de monitorao;

    2 Iterao Organizar os resultados das verificaes;

    Configurar o Nagios para realizar as notificaes por email.

    E. Plano de Testes

    1 Iterao Criar scripts para simulao de eventos de monitorao;

    Elaborar um roteiro de testes para validao do processo de gerao, envio e processamento de eventos de monitorao (erros de API e mtricas de TEF), abragendo as implementaes e a configurao do Nagios;

    Executar a sequncia de testes projetada e fazer as devidas correes; 2 Iterao

    Complementar o plano com testes de novas mtricas;

    Reexecutar os testes aps refinamento dos requisitos e implementao;

    Reportar o resultado dos testes atravs de traces, grficos, tabelas ou imagens capturadas da interface web.

  • 29

    ESCOLA POLITCNICA DE PERNAMBUCO

    Cada um destes artefatos foi produzido na execuo do planejamento do projeto e so expostos a seguir com exceo do resultado dos testes que avaliado no prximo captulo. Os cdigo fonte e dos arquivos de configurao so apresentados nos termos de sua estrutura e aspectos mais artificiosos.

    4.2 Especificao dos Requisitos Histrico de Reviso

    Verso Perodo Descrio

    1.0 1a Iterao

    Draft com todas sees incluindo os requisitos funcionais: - Captura de Erros - Identificao de Erros de API de Infra-Estrutura - Identificao de recurso redundante - Clculo de Mtricas de Estabilidade - Visualizao dos Eventos

    1.1 2a Iterao Refinamento dos requisitos: - Clculo de Mtricas de Estabilidade e de Desempenho - Visualizao dos Eventos

    4.2.2 Introduo

    Propsito

    A Anlise de Requisitos divide-se na identificao de problemas que se deseja solucionar, na avaliao desses problemas e na sintetizao dos que se deseja resolver atravs do sistema. O resultado desse processo o que est especificado atravs dos requisitos funcionais, que definem o que o software faz para atender s necessidades do usurio, e os no funcionais, tambm chamados de requisitos de qualidade, que versam sobre aspectos como segurana, confiabilidade, usabilidade, etc. Nesta especificao os funcionais so classificados de acordo com a prioridade de implementao (alta, mdia ou baixa).

    Alm do detalhamento dos requisitos, neste artefato so apresentadas informaes que contornam a idia geral do Vigilante TEF (VTEF), o software a ser desenvolvido neste projeto. Dentre outras, inclui-se o escopo do projeto, as interface de interao do VTEF, o diagrama de implantao para contextualizao do software no ambiente operacional.

  • 30

    ESCOLA POLITCNICA DE PERNAMBUCO

    Escopo do Projeto O VTEF um software para monitorao, de Autorizadores TEF. Suas

    funcionalidades incluem a monitorao indireta de switches, roteadores, array de discos e demais equipamentos utilizados pelo Autorizador TEF. A deteco de toda falha ser realizada atravs do impacto desta infra-estrutura no Autorizador TEF, ou seja, atravs dos erros recebidos por este. Consequentemente so considerados como alvos de monitorao o Autorizador TEF e sua mquina hospedeira.

    4.2.3 Descrio Geral

    Caractersticas do Produto

    Figura 7. Diagrama UML de Colaborao da Verificao Passiva

    A figura 7 representa um fluxo operacional do VigilanteTEF cujo objetivo, alm de computar mtricas com base no histrico de transaes financeiras, de intermediar o tratamento dos eventos enviados pelo Autorizador para o NSCA. Eventos estes que alimentam a base de dados do Nagios para que os administradores de infra-estrutra (redes, banco de dados, sistema operacional, etc.) sejam notificados de anormalidades impactantes no Autorizador.

    O fluxo comea com uma mensagem ISO8583 enviada pelo ServidorTEF, em consequncia de uma transao iniciada em um PDV. O Autorizador, ao receb-la, cria

  • 31

    ESCOLA POLITCNICA DE PERNAMBUCO

    uma thread para seu processamento que, pelo porte e propsito da aplicao, acessa informaes persistentes, local ou remotamente, executando uma funo de Entrada ou Sada (E/S). Esta funo pode retornar um erro que deve ser capturado pelo Autorizador e enviado para o servidor de monitorao atravs do VTEF e do NSCA.

    O fluxo finaliza com a execuo dos mdulos do Nagios, responsveis pela coleta do evento at sua notificao e gravao para verificao quase imediata ou posterior pela interface web.

    Classificao dos Usurios

    O projeto tem, como potenciais beneficiados, os usurios seguintes: Administradores de Redes Administradores de Bancos de Dados Administradores de Sistema Staff de Suporte do Servidor ou Autorizador TEF Gerentes de Infra-Estrutura

    Ambiente Operacional

    Figura 8. Diagrama UML de Implantao do VTEF

  • 32

    ESCOLA POLITCNICA DE PERNAMBUCO

    O VTEF um mdulo implementado no NSCA utilizado para filtrar e processar resultados de verificaes passivas enviados ao daemon do NSCA, relativos ao domnio de negcio do TEF. O NSCA, e consequentemente o VTEF, executam na mesma mquina Linux do servidor Nagios. Uma biblioteca que implementa o mesmo protocolo do send_nsca.exe carregada pelo AutorizadorTEF. O executvel no utilizado para se comunicar com o NSCA dado que a criao de um processo, a cada envio de evento, possui um custo de processamento mais alto do que simplesmente esperar pela chamada de envio.

    Premissas e Pr-Requisitos

    As premissas para viabilizao operacional do VTEF, que no dependem do projeto, so: a) Atendimento aos requisitos de sistemas recomendados para o ambiente do

    Nagios;

    b) Funcionamento correto das features (caractersticas) declaradas pelo Nagios; c) O fornecedor do Autorizador TEF responsvel pela replicao dos dados do

    SGBD Transacional para o SGBD de Monitorao realizando os procedimentos cabveis de equivalncia de modelos e transformao de dados;

    4.2.4 Requisitos No Funcionais de Interface

    Interfaces com Usurio

    O VTEF no possui interface com usurio, grfica ou de linha de comando, cuja finalidade seja um meio de executar um caso de uso. O carregamento de seu mdulo e sua execuo so de total responsabilidade do NSCA.

    H, no entanto, um meio de parametrizao de seu comportamento atravs da tabela de configurao detalhada no artefato de Modelo de Dados. O log de erros escrito nas sadas de console stdout e stderr uma outra interface que pode ser utilizada pelo administrador de sistemas.

    Interfaces de Comunicao

    A comunicao do Autorizador TEF com o VTEF se d atravs de conexo TCP/IP com o NSCA e por meio de mensagens claras ou criptografadas, dependendo do parmetro encryption_method escolhido nos arquivos nsca.cfg e send_nsca.cfg.

    O protocolo de aplicao utilizado o mesmo do NSCA, composto simplesmente por apenas dois tipos de mensagens e com os propsitos especficos de:

  • 33

    ESCOLA POLITCNICA DE PERNAMBUCO

    a) Verificao de Servio \t\t\t\n

    b) Verificao de Host \t\t\n

    Onde os caracteres precedidos de \ so de escape e os tokens entre possuem a seguinte definio:

    : Nome do host na configurao do Nagios : Nome do servio na configurao do Nagios : caractere 0 (para OK), 1 (WARNING) ou 2 (CRITICAL). : Dados especficos de cada evento

    Interfaces de Software

    A interface do VTEF utilizada no NSCA, alterando o cdigo fonte original distribudo pelo Nagios. Outra interface disponibilizada para o Autorizador no cliente do NSCA, o send_nsca, composta por funes exportadas na DLL contendo controle de excluso mtua, com as quais possvel enviar o resultado de uma verificao.

    Interfaces de Hardware

    No se aplica pois o acesso ao hardware ocorre apenas indiretamente pelo uso de API do sistema operacional para sistemas de arquivos, threads, mutex, redes e banco de dados.

    4.2.5 Requisitos Funcionais

    RF01 - Captura de Erros

    Descrio

    Primeiramente faz-se necessrio explicar em qual sentido utilizada a palavra erro. Para efeito prtico, o conceito de erro adotado nesta especificao, de seu cdigo que representa uma falha no sistema, falha esta que pode ser de ordem de design, fsica ou de interao[20].

    As falhas de design no dependem nem de uma falha de hardware, nem e codificao. Analisemos o exemplo de timeout de conexo com banco de dados, comum a quase toda lista de fluxos de exceo de aplicativos com memria persistente. A implementao de uma aplicao desse tipo e do SGBD podem estar corretas, mas mesmo assim, no havendo pelo menos uma conexo livre para utilizao, a aplicao

  • 34

    ESCOLA POLITCNICA DE PERNAMBUCO

    receber um erro indicando que a conexo no foi bem sucedida. Outro exemplo de erro por timeout seria quando um comando SQL enviado mas a capacidade de processamento do SGBD est comprometida com outras requisies. Ou ainda, para o caso de qualquer aplicao conectada por TCP, enviando uma mensagem no momento em que a rede est bastante congestionada, a depender da quantidade de bytes escrita na pilha (camada) do protocolo, tambm ir ocasionar um erro de timeout. Nota-se como esse tipo de erro est mais relacionado a uma impreciso de projeto do que propriamente de sua implementao, ou seja, mais ao subdimensionamento de recursos do que a uma estrutura fsica ou lgica.

    H tambm as falhas fsicas decorrentes de um erro na construo ou produo do hardware utilizado, ou at mesmo devido a sua deteriorao ou interferncia devido a algum campo magntico.

    Por fim h as falhas derivadas de interao maliciosa ou por engano de entrada. Instalao ou configurao de ambiente inadequados pertencem a essa classe de falhas. Exemplos desta podem ser um roteador X25 configurado para utilizar um user data diferente, que um identificador da chamada X25, ou a no criao no banco de dados de um objeto, como uma tabela, necessrio ao modelo de dados.

    Definido o conceito de erro, necessrio por fim observar que nem todo erro tratvel pois existem aqueles que provocam uma finalizao anormal (abend) de aplicaes escritas em linguagem C.

    Como primeiro passo antes do tratamento ou remoo de uma falha, que compreendem seu diagnstico e adoo de medidas corretivas, o Autorizador TEF deve realizar a deteco de erros capturando todo erro tratvel e enviando um evento correspondente para o servidor de monitorao atravs do VTEF.

    Prioridade

    Requisito Essencial Prioridade Alta.

    RF02 - Identificao de Erros de API de Infra-Estrutura

    Descrio

    A identificao inequvoca de uma situao de erro possui 3 pr-requisitos:

    i) Identificao da biblioteca/API a que est associado o cdigo que representa o erro;

    ii) A preciso e clareza da descrio deste erro; iii) A associao unvoca deste cdigo a uma descrio, ou seja, a localizao

    exata da descrio correspondente ao cdigo.

  • 35

    ESCOLA POLITCNICA DE PERNAMBUCO

    Em algumas linguagens de programao, a exemplo do Java, a maioria dos comportamentos inexperados so chamados de excees e identificados por seu nome. Por outro lado, o processo de identificao de erro do projeto atenta apenas para a maneira de representao de erros por cdigo, no formato numrico, destinado principalmente programao com linguagem C. Alm disso quanto ao item ii), no foram reescritas ou traduzidas as descries, para melhorar o significado.

    A lista de cdigos de erro de uma API de infra-estrutura (redes, banco de dados, sistema operacional, etc.) geralmente definida por seu fabricante/autor, e diferentes autores podem utilizar faixas de cdigo com valores que se sobrepem, impossibilitando a descoberta do erro apenas atravs de seu cdigo. Caso a API seja definida por um consrcio ou organizao que estabelea um padro de facto, as chances disso ocorrer so bem menores mas infelizmente no a realidade para tecnologias mais antigas e que no possuem foco em portabilidade, como a linguagem C.

    Alm disso, h ainda dois outros atributos de API que podem levar divulgao de uma lista com cdigos diferentes para a mesma situao de erro: o nmero e sistema operacional da verso. Isso porque por menor que seja a diferena de uma verso para outra, ela pode passar a retornar outros cdigos para tratamento de erros novos ou legados mesmo devido a uma evoluo mnima na implementao ou porque tenha sido portada para outra plataforma.

    Dadas as condies acima, em consequncia, para se obter a descrio de um erro necessrio conhecer o fabricante, a verso e o sistema operacional da API que gerou o cdigo de erro. Mas no pra por a, para concluir a anlise, na prtica, existem pelo menos duas maneiras de organizar uma lista de cdigos. A Microsoft adota uma lista para seu conjunto de APIs, chamada de System Error Codes, que dividida em faixas numricas objetivando evitar que o mesmo cdigo seja utilizado por APIs com finalidades distintas. J no Linux um cdigo pode ser utilizado por diversas APIs e o esclarecimento de seu significado dado pelo contexto e pela documentao, e por conta disto, faz-se necessrio notificar tambm o nome da funo da API que retornou o cdigo.

    Em vista disso, o evento de erro enviado ao VTEF contm um mnemnico para informar o tipo de API, o cdigo original do erro e o nome da funo geradora (este por conta da organizao dos cdigos no Linux), enquanto que, a verso propriamente dita da API incluindo seu nome, fabricante, numerao e sistema operacional devem ser identificados por outro meio, dissociado do VTEF, atravs de uma ferramenta de Gerncia de Correes/Mudanas como o Mantis, por exemplo. Esta deciso foi tomada por dois motivos:

  • 36

    ESCOLA POLITCNICA DE PERNAMBUCO

    i) Incluir estas informaes no evento tornaria a notificao burocrtica obrigando o programador a conhecer detalhes da implementao e da biblioteca para codificao da chamada, infringindo o princpio de encapsulamento.

    ii) Idealmente, o VTEF, ao receceber os dados de um evento de erro, deveria ser capaz de identificar univocamente o erro, conhecer seu significado (descrio) e sugerir aes para sua correo. Contudo, tanto o mapeamento do significado quanto as sugestes sero consideradas como trabalhos futuros. Por hora, atribui-se empresa que implementou o Autorizador TEF a responsabilidade sobre o conhecimento da verso utilizada para determinada API no sentido de viabilizar a identificao do problema atravs da documentao do autor da API, uma vez que so conhecidos o tipo da API, onde ocorreu o erro (funo geradora) e seu cdigo original. Em resumo, os dados dos eventos de erro, que deve ser enviado pelo

    Autorizador TEF, assumem o seguinte formato (em ASCII):

    Onde XXX so 3 caracteres correspondentes ao mnemnico do tipo de API, o nome da funo da API que gerou o erro, NNNNNN so 6 caracteres numricos do cdigo, HHHHH so 5 caracteres do cdigo convertido em hexadecimal. O mnemnico pode assumir os seguintes valores:

    ARQ: Sistema de Arquivo Padro THR: Thread do Sistema Operacional SCO: Sincronizao de Concorrncia TCP: Redes TCP X25: Redes X.25

    ABD : Acesso a Banco de Dados

    Alm disso, nota-se que o evento traz tambm informaes para localizao do erro no cdigo fonte do Autorizador onde o arquivo que contm a chamada funo, o nmero da linha da chamada neste arquivo, uma string informando quais parmetros de entrada foram passados para a funo e deve apontar qual fluxo da aplicao foi executado j que a mesma funo pode ser chamada em contextos distintos. Prioridade

    Requisito Essencial Prioridade Alta

    ERR:XXX,,NNNNNN,0xHHHHH\ COD.FONTE:,,,

  • 37

    ESCOLA POLITCNICA DE PERNAMBUCO

    RF03 - Identificao de recurso redundante

    Descrio

    Devido criticidade da finalidade do Autorizador TEF, a arquitetura desse sistema requer a adoo de estratgias de alta disponibilidade cuja principal prtica a utilizao de recursos redundantes.

    Se o recurso puder ser identificado na descrio do erro ou pelo conhecimento do Autorizador TEF, quando o prprio responsvel pelo mecanismo de contingncia no qual um dos recursos redundantes acionado, ento essa informao deve ser adicionada no campo do requisito acima.

    Um Autorizador TEF coorporativo, que atende apenas ao movimento das lojas de uma empresa, possivelmente no se utiliza de um mecanismo de balanceamento ou de contingncia para alta disponibilidade. Logo, em casos deste tipo, o identificador do recurso redundante nunca estar presente nos dados do evento.

    Prioridade

    Requisito Essencial Prioridade Baixa

    RF04 - Clculo de Mtricas de Estabilidade e de Desempenho

    Descrio

    Para evitar eficientemente as falhas em um sistema no basta saber dos erros que lhe afetam explicitamente. Complementarmente, importante conduzir uma avaliao contnua do comportamento do sistema com respeito combinao de eventos que possa levar a um estado errneo ou diminuio da qualidade de servio. Isto , atuar de forma preditiva como meio de consolidar a estabilidade, desempenho e dependabilidade do sistema [20].

    Visando corroborar com esta linha de atuao, mtricas no domnio de negcio de TEF e a utilidade destas na identificao de possveis correlaes so descritas abaixo (quando a transao de venda citada, leia-se venda ou pagamento):

    i. ndice dirio elevado de cancelamento (estorno) por loja: Uma vez que essa transao ocorre com baixa frequncia, uma loja que se destaque neste aspecto pode demonstrar um indcio de fraude. Por parte dessas tentativas pode surgir um certo volume de transaes negadas. Logo, esta mtrica no deve incluir apenas os cancelamentos efetivos;

    ii. ndice dirio elevado de cancelamento (efetivo ou no): Apresenta a soma dos percentuais do ndice de cancelamento por loja;

  • 38

    ESCOLA POLITCNICA DE PERNAMBUCO

    iii. ndice dirio elevado de sondas: a sonda uma transao de contingncia quando uma transao de trs pernas no confirmada ou desfeita, ou seja, permanece com status pendente. Isto pode ser causado pelo mau funcionamento da infra-estrutura do Servidor TEF ou do Autorizador TEF, ou at mesmo dessas aplicaes, que levam a uma perda de uma das pernas da transao financeira. Como a sonda enviada para um endereo que no tem a obrigatoriedade de ser o mesmo da origem da transao pendente, esta mtrica no agrupada por endereo de destino da sonda.

    iv. ndice dirio elevado de sondas sem resposta, por endereo de destino: Por questes contratuais, o varejista ou a empresa do Servidor TEF tem o dever de resolver as pendncias (confirmar ou desfazer as transaes pendentes). A sonda a responsvel por consultar o Servidor TEF sobre o status da transao que continua pendente no Autorizador TEF. Se no h resposta, necessrio notificar os administradores da rede local para verificar se os pacotes esto saindo da rede. Caso positivo, deve-se abrir um chamado tanto para o provedor de rede quanto para o responsvel pelo gerenciamento do Servidor TEF;

    v. ndice dirio elevado de desfazimento por loja: Desfazimento uma transao referente a uma compra (ou pagamento ou cancelamento) para informar que esta compra no ser confirmada, ou seja, que houve desistncia da efetivao da operao. Alm da desistncia do cliente no PDV, pode ocorrer quando a 1 ou 2 perna no foi processada com sucesso no Servidor TEF. importante tambm que esta mtrica inclua todas tentativas de desfazimentos, no apenas os efetivos, uma vez que esse tipo de transao pode ser gerada automaticamente pelo Servidor TEF, havendo a possibilidade de falha na implementao deste mecanismo;

    vi. ndice dirio elevado de desfazimento (efetivo ou no): Apresenta a soma dos percentuais do ndice de desfazimento por loja;

    vii. ndice dirio de timeout de envio por cada tipo de transao, exceto a sonda (venda, consulta, cancelamento e desfazimento): A ausncia do envio da 2 perna um problema mais relacionado ao Autorizador TEF do que quanto infra-estrutura do ambiente do Servidor de TEF ou da comunicao com este. Pode representar uma falha no tratamento da mensagem de entrada (1 perna), no cdigo fonte da montagem da 2 perna ou na infra-estrutura do Autorizador TEF (limite de threads excedido, sistema de arquivo sem espao, problema no acesso ao banco de dados, etc.);

    viii. ndice dirio elevado de negao por cada tipo de transao (exceto a sonda), por loja: Um alto percentual de negaes, para um total de transaes relevante, pode indicar uma no conformidade especificao na

  • 39

    ESCOLA POLITCNICA DE PERNAMBUCO

    implementao do Servidor TEF, ou do Autorizador TEF, implicando a continuidade da ocorrncia das negaes caso nenhuma medida seja tomada. A negao causada por m configurao de um dos sistemas tambm uma possibilidade. Um outro motivo que pode causar a negao ocorre quando o contedo de um campo do protocolo no respeita uma regra de negcio. Por exemplo, o nmero de um boleto de pagamento deveria vir formatado com a linha digitvel enquanto que em vez disso enviado o cdigo de barras. Este e outros erros podem ocorrer por alguma falha de hardware ou de software no PDV ou seus perifricos, da a importncia de calcular esta mtrica por cada loja;

    ix. ndice dirio elevado de negao por cada tipo de transao: Apresenta a soma dos percentuais do ndice de negao por loja;

    x. Tempo mdio de resposta (TMR) elevado da transao de venda, cada minuto, ou nmero mximo de transaes: A venda a transao mais importante do TEF e precisa ser rpida o suficiente para no incomodar os clientes no caixa. Um valor alto deste tempo indica uma possvel demanda por redimensionamento ou otimizao do sistema atravs de ajustes de desempenho (tunning) do SGBD, melhoria da implementao do framework do Autorizador TEF (pool de threads por exemplo), ou dependendo da disponibilidade financeira e tecnolgica, pela melhoria dos hardwares do servidor de aplicao, de banco de dados ou dos equipamentos de rede. Outro aspecto desta mtrica sua periodicidade. Ela calculada cada minuto, porm se ocorrerem mais transaes do que um nmero mximo estipulado, 600 transaes por exemplo, neste minuto, a mdia calculada em cima destas 600 transaes. Isto feito para evitar o desvio na mtrica pela quantidade excessiva de transaes j que isto provoca um aumento no TMR;

    xi. Tempo mdio de resposta elevado incluindo todo tipo de transao exceto a sonda, cada minuto (TMR-Geral): Apesar da maior relevncia da transao de venda, necessrio monitrar o desempenho das demais transaes, apesar de menos frequentes (questione-se pela sua prpria experincia quantos estorno voc realizou com seu carto). Alm disso, essa mtrica traz o total de transaes que ocorreram no perodo permitindo comparar com a quantidade de vendas informada no ndice anterior (TMR-VendaPgto);

    xii. Quantidade elevada de transaes de venda por segundo (TPPS-VendaPgto): O pico de atividade representa uma das virtuais causas do baixo desempenho no processamento de transaes. O administrador tem a opo de zerar o TPPS notificado atravs de um comando de shell script;

  • 40

    ESCOLA POLITCNICA DE PERNAMBUCO

    xiii. Quantidade elevada de transaes por segundo (TPPS-Geral): Tem prposito semelhante da mtrica anterior porm capta o excesso de transaes indepedentemente de seu tipo (as sondas no entram na soma). As transaes utilizadas nessas mtricas devem estar salvas em um SGBD

    de Monitorao, contendo a replicao das transaes salvas pelo Autorizador TEF no SGBD Operacional, evitando a concorrncia entre as threads do VTEF com as decorrentes do movimento de loja. O VTEF, cada intervalo de poucos minutos (configurvel), acessa o banco de dados de Monitorao e calcula essas mtricas (ndices, totalizadores e mdias). Apenas devido ao curto espao de tempo da mtrica TPPS, o intervalo de sua verificao configurado em um parmetro prprio.

    Alm destas mtricas seria possvel calcular outras, tais como o ndice dirio elevado de cancelamento efetivo, porm a ocorrncia desta transao por acidente ou erro caracteriza um defeito grotesco j que para efetivar um cancelamento so necessrias 6 mensagens (3 pernas da venda mais 3 pernas do cancelamento). Essa mtrica poderia sugerir algum comportamento do consumidor (frequente devoluo de produtos) ou do operador do caixa (erro de digitao do valor da transao, por exemplo). As medidas com este propsito esto fora do escopo do trabalho.

    Definidas as mtricas, so especificados com detalhe os clculos de cada uma:

    i. ndice dirio elevado de cancelamento (estorno) por loja = contagem das transaes de estorno da loja no dia / contagem das transaes de venda da loja no dia;

    ii. ndice dirio elevado de cancelamento = contagem das transaes de estorno da empresa no dia / contagem das transaes de venda da empresa no dia;

    iii. ndice dirio elevado de sondas por endereo de destino = contagem das sondas no dia para o destino / contagem das transaes realizadas pelo destino da sonda, no dia, que podem ficar pendentes (venda ou cancelamento);

    iv. ndice dirio elevado de sondas sem resposta = contagem das sondas com status em andamento no dia para o destino / contagem das sondas no dia para o destino;

    v. ndice dirio elevado de desfazimento por loja = contagem das transaes de desfazimento da loja no dia / contagem das transaes de 3 pernas (venda e cancelamento) da loja, no dia, sem incluir as que ainda esto em andamento;

    vi. ndice dirio elevado de desfazimento (efetivo ou no) = contagem das transaes de desfazimento da empresa no dia / contagem das transaes de 3 pernas da empresa, no dia, sem incluir as que ainda esto em andamento;

  • 41

    ESCOLA POLITCNICA DE PERNAMBUCO

    vii. ndice dirio de timeout de envio por cada tipo de transao, exceto a sonda = contagem das transaes, do tipo em questo, com status em andamento ocorridas no dia / contagem do mesmo tipo de transao com status diferente de em andamento, no dia;

    viii. ndice dirio elevado de negao por cada tipo de transao, exceto a sonda, por cdigo de resposta = contagem agrupada por cdigo de resposta, das transaes negadas (cdigo de resposta diferente de 00), do tipo em questo, com status concluda ocorridas no dia/ contagem destas transaes com status diferente de em andamento, no dia;

    ix. ndice dirio elevado de negao por cada tipo de transao = contagem das transaes negadas da empresa, ocorridas no dia, do tipo em questo e com status concluda, / contagem destas transaes com status diferente de em andamento, no dia;

    x. TMR elevado de venda, cada minuto ou nmero mximo de transaes = soma do tempo de resposta das transaes de venda, que ocorreram no perodo ou das primeiras at o nmero mximo (parmetro), e que no esto com status em andamento / quantidade destas transaes;

    xi. TMR elevado das transaes (exceto a sonda), cada minuto ou nmero mximo de transaes = soma do tempo de resposta das transaes, que no seja uma sonda, que ocorreram no perodo, ou das primeiras at o nmero mximo, e que no esto com status em andamento / quantidade destas transaes;

    xii. TPPS de venda = contagem das transaes de venda que ocorreram no minuto, agrupadas por segundo;

    xiii. TPPS geral = contagem das transaes que ocorreram no minuto, agrupadas por segundo;

    Aps o clculo dessas mtricas o VTEF opta pelo envio de eventos associados a um resultado que pode ser OK, de alerta (WARNING) ou crtico (CRITICAL), de acordo com os thresholds definidos no modelo de dados. Por exemplo: se o ndice de desfazimento for no momento at 15%, enviada uma mensagem com resultado OK, entre 15 e 30% resulta em alerta e acima de 30% uma situao crtica.

    Prioridade

    Requisito Essencial Prioridade Mdia

    RF05 - Visualizao das Mtricas

    Descrio

    As mtricas de cancelamento e desfazimento efetivos dirios de cada loja devem ser exibidas em seus prprios objetos de servio no Nagios, para que estejam sempre visveis os eventos ocorridos em cada loja. O mesmo se aplica as mtricas de negao de transaes especficas. Assim o formato da diretiva service_description, que identifica um objeto de servio, deve seguir o padro

  • 42

    ESCOLA POLITCNICA DE PERNAMBUCO

    TEF. Canc.Loja NNNN/dia onde a sigla da empresa e NNNN o cdigo de uma de suas lojas. Por exemplo, TEF.LBSA Canc.Loja0120/dia | 2% (4/200) exibe um ndice de 2% das transaes (4 de um total de 200) sendo canceladas na loja 0120 da LBSA, Lojas Brasileiras SA.

    As demais estatsticas podem ser exibidas agregando-as por empresa e declarando apenas um objeto de servio para cada uma delas. Por exemplo: TEF.LBSA Perc.Sonda/dia | 4% (6/150) exibe o percentual de sondas da LBSA.

    Alm disso, para melhorar a visualizao dos eventos, o Nagios permite o agrupamento de servios, separando-os em links e telas distintas. Logo, as mtricas so agrupadas da seguinte maneira (onde aplica-se aos tipos de transao de Consulta, Cancel., Desfaz. e Venda). Grupo -MetricasPorLoja Este grupo agregada as mtricas cujos resultados so exibidos separadamente para cada loja. So includas tambm as mtricas que totalizam os resultados das lojas. - TEF. Perc.Cancel.Lj-NNNN/dia - TEF. Perc.Desfaz.Lj-NNNN/dia - TEF. Perc.Cancel/dia - TEF. Perc.Desfaz /dia - TEF. Perc.Neg..Lj-NNNN/dia - TEF. Perc.Neg./dia - TEF. Perc.Neg..Lj-NNNN/dia - TEF. Perc.Neg./dia Grupo -MetricasPorEndereco - TEF. Perc.SondaSemResposta/dia - TEF. Perc.Sonda/dia (porque agrega informao anterior) - TEF. Perc.TO..Lj-NNNN/dia - TEF. Perc.TO./dia Grupo -MetricasDesempenho - TEF. TMR-Venda/min/maxTrs - TEF. TMR-Geral/min/maxTrs - TEF. TPPS-Venda/min - TEF. TPPS-Geral/min Prioridade

    Requisito Essencial Prioridade Mdia

  • 43

    ESCOLA POLITCNICA DE PERNAMBUCO

    4.2.6 Requisitos No Funcionais Adicionais

    Desempenho

    O desempenho do VTEF no to crtico, tendo em vista que no executa na mquina do Autorizador TEF, mas deve ser rpido o suficiente para processar as mtricas em sua devida periodicidade considerando um fluxo mximo de 100 TPPS durante 1 minuto (6000 transaes) e uma quantidade mxima de 1 milho de transaes na base de dados, j incluindo as 6000. Essa meta estabelecida para o requisito de sistema mnimo de uma mquina com processador de 2.0Ghz e 1GB de memria RAM, ou seja, com a mesma configurao da destinada aos testes da verso do VTEF resultante deste projeto.

    Confiabilidade

    O Nagios permite a implantao de uma arquitetura em cluster para dar maior disponibilidade ao servio de monitorao. A princpio esta arquitetura no ser utilizada, para efeitos prticos de testabilidade, porm, elencada com trabalho futuro. Esta arquitetura torna-se relevante, principalmente, a partir da percepo do valor que os sistemas de monitorao tm na continuidade do operacional do Varejo.

    Segurana

    Em sua primeira verso no ser utilizada criptografia j que no sero trafegados dados sensveis dos clientes nas mensagens de evento.

    Interoperabilidade

    A clareza e simplicidade da interface da DLL send_nsca proporcionam virtualmente a integrao com qualquer Autorizador TEF da plataforma Windows. Para atender a sistemas de outras plataformas, necessrio converter o programa send_nsca para seu respectivo formato de biblioteca dinmica (.so no Linux). J a integrao das bases de dados deve ser realizada atravs da replicao e eventual transformao dos dados do SGBD Transacional do Autorizador TEF para o SGBD de Monitorao definido pelo VTEF, mais especificamente no layout da tabela log_tef, definida na seo 4.3.2 - Modelo de Dados.

  • 44

    ESCOLA POLITCNICA DE PERNAMBUCO

    4.3 Modelagem Estrutural e de Dados O propsito deste artefato ajudar na descrio e no entendimento do

    sistema identificando suas aes e dados que so manipulados.

    4.3.1 Modelo Estrutural

    Foi elaborado um modelo orientado a objetos com UML, em virtude de uma maior familiaridade com este paradigma na fase de modelagem. Na fase de implementao, cada classe foi mapeada, no modelo estrutural do programa procedural, para um mdulo, no sentido de um conjunto de funes correlatas, mais especificamente relacionadas com algum tipo de dado ou processamento em comum.

    Figura 9. Diagrama UML de Classes (Mdulos) do VTEF

    Alm da classe, que corresponde a um mdulo neste modelo, foram utilizados trs outros elementos do UML dependncia, associao, interface e realizao aos quais foram atribudos os seguintes significados:

    Dependncia

    A seta tracejada entre classes indica que um mdulo chama uma ou mais funes de outro mdulo. Neste diagrama, o Gerador de Estatsticas do VTEF realiza chamadas camada de acesso a dados (DAL, Data Access Layer), que por sua vez

  • 45

    ESCOLA POLITCNICA DE PERNAMBUCO

    utiliza a API de SQL implementada na biblioteca dinmica unixODBC. Os outros dois casos so a utilizao de seu gerenciador de drivers para instnciar o driver do PostgreSQL e a chamada ao mdulo do NSCA para o envio do resultado da verificao.

    Associao

    No sentido em que um mdulo responsvel pelo instanciamento, disponibilizao, ou acesso a outro, que o caso do DriverManager que carrega o driver especfico do PostgreSQL. Um outro sentido para associao quando um mdulo abstrai a chamada a outro atravs de uma interface padronizada, que um dos principais objetivos do ODBC em qualquer aplicao, para que no sejam utilizadas funes especficas das implementaes dos fabricantes que podem variar de um SGBD para outro. No caso deste modelo, tanto o controle da conexo como a execuo dos comandos so iniciados ou disparados pela SqlAPI da biblioteca unixODBC acessando uma interface genrica padronizada do ODBC.

    Interface e Realizao

    Simbolizados por um crculo e uma reta, representam a necessidade de implementao, ou de reuso de componentes, que abstraia os detalhes da variao de implementao, ou seja, que um mdulo possa utilizar uniformemente um outro de modo independente da plataforma ou sistema. O driver PostgreSQL atua na realizao da interface de Driver ODBC que padroniza as assinaturas (prottipos) das funes dos drivers especficos para um SGBD.

    4.3.2 Modelo de Dados

    Ao fim da 2 iterao, o modelo composto por apenas duas tabelas:

    i. log_tef: contm os registros das transaes ISO8583.

    ii. config_vtef: contm um registro das configuraes para cada estabelecimento.

    Considerando que as duas tabelas no possuem relacionamento no foi necessrio utilizar o Modelo de Entidade e Relacionamentos (MER) para descrever os dados do sistema.

    A estrutura de cada tabela foi definida usando a modelagem fsica, aplicando os termos do SGBD adotado para o desenvolvimento, o PostgreSQL 8.3. Todas as colunas so de preenchimento obrigatrio (NOT NULL) e as chaves primrias so indicadas com a sigla PK.

  • 46

    ESCOLA POLITCNICA DE PERNAMBUCO

    i. log_tef

    Nome da Coluna Tipo de Dado Comentrio

    nsu_aut (PK) numeric(9,0) NSU da transao gerado pelo Autorizador.

    nu_iso_trans numeric(4,0) Identificador do Tipo de Mensagem (MTI) da transao ISO8583 (ex: 0200,0400,0420,etc.). nu_pcode numeric (6,0) Cdigo de Processamento definido para o tipo da servio (ex: 330657 para recarga de celular).

    cd_status_trans char (1) Cdigo de status de progresso da transao (A: andamento, P: pendente, C: concluda).

    cd_tipo_trans char (1) Tipo da transao mapeado pelo autorizador pela combinao do nu_iso_trans com o nu_pcode (V: Venda/Pagamento, C: Consulta, D: Desfazimento, E: Estorno, S:Sonda).

    dh_trans_aut timestamp Data hora da transao no Autorizador.

    nu_tempo_resposta numeric(6, 3) Segundos e milsimos de segundo do tempo de resposta da transao, ou seja, a diferena da hora entre o envio da 2 e o recebimento da 1 perna.

    cd_resposta char (2) Cdigo de resposta da transao (00 indica sucesso, os demais so cdigos de erro).

    cd_empresa char (5) Cdigo que identifica, no cadastro do Autorizador, o estabelecimento (empresa) de onde partiu a transao.

    cd_loja char (4) Cdigo que identifica, no cadastro do Autorizador, a loja de onde partiu a transao. nu_endereco_ip char(15) Endereo IP do Servidor TEF (destino da sonda).

    ii. config_vtef

    Nome da Coluna Tipo de Dado Comentrio

    cd_empresa (PK) char(5) Cdigo que identifica o estabelecimento no cadastro do Autorizador.

    id_empresa char (10) Identificador da empresa. Pode ser uma sigla, nome ou cdigo.

    limite_warn_ numeric(6,3) Valor/Threshold da mtrica que dispara evento de verificao passiva com resultado de alerta (WARNING).

    limite_crit_ numeric(6,3) Valor/Threshold da mtrica que dispara evento de verificao passiva com resultado crtico (CRITICAL).

    nu_max_trs_tmr integer Nmero mximo de transaes para evitar calcular o TMR com distoro.

  • 47

    ESCOLA POLITCNICA DE PERNAMBUCO

    Esta tabela possui ao todo 38 colunas. Destas, 36 so referentes ao threshold, de alerta ou criticidade, dos eventos enviados para cada tipo de mtrica computada pelo VTEF (36/2 mtricas no total).

    4.4 Cdigo Fonte Objetivando evitar o overhead da criao de processo o executvel

    send_nsca.exe foi convertido para DLL Windows. Com isso, foi substituda a funo main pela DllMain, chamada apenas no carregamento e liberao da DLL, e exportada uma funo que inicia o processamento do envio de eventos ao NSCA. Neste processo, o parmetro ul_reason_for_call, da DllMain, que pode assumir os valores DLL_PROCESS_ATTACH, DLL_PROCESS_DETACH, DLL_THREAD_ATTACH, DLL_THREAD_DETACH, no foi tratado uma vez que esta DLL no demanda nenhum pr-processamento no carregamento da DLL em memria ou na sua liberao, sua ao concentrada inteiramente na funo exportada. Na assinatura desta funo, cada flag/argumento de execuo do send_nsca.exe foi mapeado como um parmetro, assumindo a seguinte forma: /* hostaddr: Endereo IP do NSCA * port: Porta TCP do NSCA * to_sec: Segundos antes de ocorrer timeout * config_file: Caminho do arquivo de configurao */ __declspec(dllexport) void envia_nsca(char *hostaddr, int port,

    int to_sec, char *config_file);

    O VTEF foi implementado como um mdulo do NSCA (servidor) e dividido em dois submdulos: um para funes relacionadas ao domnio de negcio do TEF, o clculo das mtricas, e outro unicamente para ler as transaes do banco de dados. Semelhante a uma arquitetura de trs camadas com a diferena de que a camada de apresentao pertence a outro software, ao Nagios que exibe os eventos na sua interface web.

    O mdulo de gerao das mtricas foi estruturado de maneira que as funes de clculo sejam executadas respeitando trs aspectos de requisitos e abordando outros dois de programao. Cada um destes aspectos justifica um ou mais argumentos de suas assinaturas, conforme comentrios a seguir:

    i. Executada para um determinado estabelecimento (empresa) em consonncia com o modo de agrupamento (aspecto de Requisito, argumento: pc_id_estab);

    ii. O valor da mtrica considerado crtico ou de alerta a depender dos thresholds (Requisito, limite_crit e limite_warn);

  • 48

    ESCOLA POLITCNICA DE PERNAMBUCO

    iii. Cada mtrica exibida individualmente na interface web do Nagios, cada uma no seu prprio objeto de servio (Requisito, pc_str_servico);

    iv. As funes foram reusadas para o clculo de mtricas semelhantes precisando apenas informar como selecionar as transaes (Implementao, pc_strsql);

    v. As funes utilizam uma mesma conexo pr-estabelecida com o banco de dados (Implementao, hDbc); Assinaturas das funes de clculo:

    Observa-se que as funes de clculo no retornam nenhum dado do evento de monitorao, nem mesmo o valor da mtrica. Isto porque elas prprias enviam esse valor no evento cujo procedimento encapsulado em outra funo do prprio NSCA.

    Essas funes, e as demais do VTEF, so executadas por apenas uma thread. Ela criada na inicializao no NSCA para execuo do VTEF e responsvel por carregar inicialmente as configuraes de threshold e depois gerar periodicamente todas mtricas. Foi decidido o uso de apenas uma thread j que as mtricas de TMR e TPPS possuem um requisito temporal mais exigente, no mximo computada de minuto a minuto, enquanto que para as mtricas dirias o intervalo mnimo de 5 minutos. Logo, caso futuramente se deseje diminuir a periodicidade destas mtricas dirias, ou caso o processamento demore mais por sobrecarga significativa na mquina do SGBD, o VTEF no depender do algoritmo de escalonamento do sistema operacional para garantir a regularidade no cumprimento

    //Calcula o TPPS de venda ou geral void VTEF_calc_TPPS(char *pc_strsql,

    double limite_crit, double limite_warn, char * pc_id_estab, char * pc_str_servico, SQLHDBC hDbc);

    // Calcula o TMR de venda ou geral selecionando no mximo um certo // num. de transaes que tenham ocorrido at um determinado momento // (fim do intervalo de 1 minuto ou menos) void VTEF_calc_TMR(double limite_crit, double limit