FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO
O uso da Stack ELK no Diagnóstico deProblemas em Sistemas SCADA em
Produção
Miguel António T. da Costa Leite
Mestrado Integrado em Engenharia Eletrotécnica e de Computadores
Orientador FEUP: Prof. Mário Sousa
Orientador Efacec: Engo João Rocha
21 de Janeiro de 2019
c© Miguel Leite, 2019
Resumo
A presente dissertação enquadra-se no Mestrado Integrado em Engenharia Eletrotécnica e deComputadores da Faculdade de Engenharia da Universidade do Porto, tendo sido desenvolvida naUnidade de Negócio de Automação da Efacec Power Solutions, S.A.
A evolução e digitalização nos sistemas SCADA na gestão de redes elétricas está aliada a umvolume de informação cada vez maior. Como tal, a análise dos dados gerados por cada dispositivotecnológico é preponderante para a deteção de eventos anormais no sistema, assim como para odiagnóstico de problemas do próprio sistema.
O ScateX# é a plataforma SCADA desenvolvida pela Efacec para a gestão de redes elétricas.Como sistema distribuído, caracteriza-se por possuir diferentes servidores com aplicações e tarefasespecíficas. Todas essas aplicações geram ficheiros no formato de log com informação sobre o seuestado como erros, acessos indevidos ou falhas no sistema.
Este projeto foca-se na identificação e recolha de diferentes ficheiros com eventos de logginge na sua análise e processamento. Posteriormente, tendo os dados estruturados, é possível desen-volver visualizações de informação considerada relevante para a monitorização e diagnóstico deproblemas por parte dos utilizadores. Para isso foi sugerido por parte da Efacec a utilização daplataforma Stack ELK, que através de vários módulos permite recolher e processar informação.
Para cumprir todos os requisitos do projeto, foi desenvolvida uma solução genérica para umainstalação típica do ScateX#. A mesma é capaz de recolher e processar eventos de logging dediferentes servidores. No entanto, os testes e validações do sistema apresentado foram realizadosnuma arquitetura mais simples dada a indisponibilidade de hardware.
Em suma, todos os objetivos do projeto foram alcançados. Após todo o processamento ne-cessário para estruturar a informação, os dados são armazenados e podem ser visualizados atravésdas dashboards construídas, possibilitando ao utilizador um rápido e eficiente diagnóstico de pro-blemas no sistema SCADA, o ScateX#.
i
ii
Abstract
The present thesis is part of the master’s degree in Electrical and Computer Engineering fromthe Faculty of Engineering of the University of Porto. The project was developed at AutomationBusiness Unit of Efacec Power Solutions, S.A.
The evolution of SCADA systems in the management of eletrical networks are associatedwith an increasing volume of information and data. As such, the analysis of the data generated byeach device or server is crucial for in order to detect abnormal events in the system, as well as toefficiently diagnose problems or errors.
ScateX# is Efacec’s SCADA solution for the electrical networks control and management. Asa distributed system, it is characterized by having different servers with specific applications andtasks. All those applications generate files in log format with valuable information about systemfailures, warnings or even improper access.
This project focuses on the identification and collection of different files with logging eventsand their analysis and processing. Subsequently, with the structured data it’s possible to buildvisualization mechanisms in order to monitor and properly diagnose events from the system. Forthis, it was suggested by Efacec the use of ELK Stack platform, which through modules allowsthe collection and processing of different forms of data.
In order to meet all the requirements of the project, a generic solution was developed that’scapable of collecting, processing and demonstrating throught visualization mechanisms all thedata that ScateX#, in a typical installation, generates. The system’s tests and validations wereperformed in a simpler architecture given the hardware unavailability.
In short, all project objectives have been achieved. After all the necessary processing to struc-ture the information, the data is stored and can be visualized through the built dashboards, enablingthe user to quickly and efficiently diagnose problems in the Efacec’s SCADA system, ScateX#.
iii
iv
Agradecimentos
Em primeiro lugar, agradeço aos meus pais e irmão por serem, em todos os momentos, osmeus verdadeiros pilares. Agradeço todo o apoio, paciência e esforços que fizeram por mim epara que pudesse ter sucesso em qualquer desafio. Às minhas avós, que fizeram parte da minhafeliz infância, e que sempre demonstraram o carinho e amor que têm por mim. Também à minhanamorada, a Joana, agradeço todo o apoio e carinho que sempre me demonstrou, sobretudo nodecorrer deste projeto e nas horas de maior cansaço.
Agradeço ao Eng. João Rocha, o meu orientador da dissertação, por todo o acompanhamentoe disponibilidade ao longo do período de estágio. Não só foi importante para o sucesso do projeto,mas também desempenhou um papel fundamental para que a minha integração na Efacec fossefácil. Também gostaria de deixar uma palavra de apreço ao Márcio Gonçalves por ter feito partedo meu percurso na Efacec e, tal como o João, ter contribuído para a minha integração na mesma.Sem eles seria, definitivamente, um processo mais complicado.
À Efacec Power Solutions, pela oportunidade de ter um primeiro contacto com o ambienteindustrial numa empresa tão prestigiada e com sucesso. A todos os colaboradores da Unidadede Negócio de Automação, em particular aos membro da divisão de ID/SCADA, por todas aspartilhas de experiências e apoio no decorrer do estágio.
Ao professor Mário Sousa, agradeço a preocupação e partilha de conhecimentos não só nodecorrer do projeto, mas também em todas as aulas durante o meu percurso académico.
À FEUP, por todos os anos de aprendizagem, oportunidades proporcionadas e por ser umainstituição de prestígio, da qual me orgulho de fazer parte.
Por fim, a todos os meus amigos que fiz ao longo do meu percurso académico, por o terem tor-nado cheio de experiências e com histórias para contar, e também aos amigos que nunca deixaramde o ser, e que com orgulho consegui e conseguirei manter ao longo da minha vida.
A todos, o meu sincero obrigado.
Miguel Leite
v
vi
Conteúdo
1 Introdução 11.1 Apresentação da Empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Revisão Bibliográfica 52.1 Sistemas SCADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 SCADA em Controlo Energético . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Segurança em sistemas SCADA . . . . . . . . . . . . . . . . . . . . . . 7
2.2 ScateX# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Arquitetura do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Análise de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.2 Data Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Análise e Gestão de Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.1 Estudo de Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Stack ELK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5.1 Filebeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.2 Logstash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.3 Elasticsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5.4 Kibana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Análise de Requisitos 293.1 hostMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Proposta de Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1 Necessidades de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 33
4 Implementação 374.1 Configuração Filebeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.1 filebeat.inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.2 output.logstash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Configuração Logstash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.1 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.2 Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.3 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Dashboards Kibana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
vii
viii CONTEÚDO
4.3.1 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3.2 RedHat 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3.3 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.4 ScateX# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Alertas e Notificações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5 Testes e Validações 59
6 Conclusões 636.1 Satisfação dos Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A Guia de Utilizador - Stack ELK 65A.0.1 Elasticsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65A.0.2 Logstash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66A.0.3 Kibana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66A.0.4 Filebeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.0.5 Winlogbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
B Diagrama UML de sequência 69
C Dashboards 71
Referências 77
Lista de Figuras
1.1 Unidades de Negócio da Efacec . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Presença Mundial Efacec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Arquitetura Geral de um sistema SCADA[1] . . . . . . . . . . . . . . . . . . . . 62.2 Comparação Gestão de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Vista Geral da Arquitectura do ScateX# [2] . . . . . . . . . . . . . . . . . . . . 102.4 Possível Arquitectura do ScateX# [2] . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Domínios da Data Science [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6 Processo Data Science [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 Big Data [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.8 Os 3 V’s do Big Data [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.9 Sequência do Processo de Data Mining [7] . . . . . . . . . . . . . . . . . . . . . 152.10 Exemplo de anomalia num conjunto de dados . . . . . . . . . . . . . . . . . . . 162.11 Arquitetura de Recolha e Análise de Dados - Stack ELK [8] . . . . . . . . . . . 222.12 Execução do processamento no Logstash [9] . . . . . . . . . . . . . . . . . . . . 232.13 Página Discover [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.14 Exemplo de Dashboard [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1 Integração do sistema baseado na Stack ELK no ScateX# . . . . . . . . . . . . . 35
4.1 Top erros tipo "ORA"por host . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2 Erros do tipo "ORA"em função do tempo . . . . . . . . . . . . . . . . . . . . . 464.3 Conexões à BD por aplicação em função do tempo . . . . . . . . . . . . . . . . 474.4 Conexões à BD por host em função do tempo . . . . . . . . . . . . . . . . . . . 474.5 Contagem de eventos do SO por hostname em função do tempo . . . . . . . . . 484.6 Gráfico circular dos processos por hostname . . . . . . . . . . . . . . . . . . . . 494.7 Tentativas de login por SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.8 Logins com sucesso por SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.9 Servidores Windows com mais erros de aplicações . . . . . . . . . . . . . . . . 514.10 Acessos aos servidores Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 514.11 Variação da contagem de erros com o tempo . . . . . . . . . . . . . . . . . . . . 524.12 Variação do no de alarmes com o tempo . . . . . . . . . . . . . . . . . . . . . . 534.13 Servidores com maior número de ocorrências de erros . . . . . . . . . . . . . . . 534.14 Mapa de Alarmes ScateX# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.15 Notificações por Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1 Sistema de Testes Stack ELK/ScateX# . . . . . . . . . . . . . . . . . . . . . . . 60
B.1 Diagrama UML de sequência do processo . . . . . . . . . . . . . . . . . . . . . 69
ix
x LISTA DE FIGURAS
C.1 Dashboard de monitorização de erros do Oracle . . . . . . . . . . . . . . . . . . 71C.2 Dashboard de monitorização de conexões à base de dados Oracle . . . . . . . . . 72C.3 Dashboard de monitorização de eventos e processos a correr no Red Hat 7 . . . . 72C.4 Dashboard de monitorização de acessos SSH aos servidores . . . . . . . . . . . 73C.5 Dashboard de monitorização dos eventos do Windows . . . . . . . . . . . . . . . 73C.6 Dashboard de monitorização aplicacional do ScateX# . . . . . . . . . . . . . . . 74C.7 Dashboard de monitorização dos alarmes do ScateX# . . . . . . . . . . . . . . . 74C.8 Dashboard geográfica de incidência de alarmes do ScateX# . . . . . . . . . . . . 75
Lista de Tabelas
2.1 Possíveis Ameaças de Segurança [12] . . . . . . . . . . . . . . . . . . . . . . . 82.2 Funcionalidades ScateX# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Comparação plataformas Análise de logs . . . . . . . . . . . . . . . . . . . . . . 202.4 Comparação plataformas Análise de logs . . . . . . . . . . . . . . . . . . . . . . 20
3.1 Requisitos do sistema a implementar . . . . . . . . . . . . . . . . . . . . . . . . 303.2 Requisitos de monitorização de segurança . . . . . . . . . . . . . . . . . . . . . 313.3 Requisitos de monitorização dos eventos do Sistema Operativo . . . . . . . . . . 313.4 Requisitos de monitorização dos eventos da base de dados Oracle . . . . . . . . 313.5 Requisitos de monitorização aplicacional relativos ao ScateX# . . . . . . . . . . 323.6 Tabela de controlo do volume de informação gerado por servidor . . . . . . . . . 34
4.1 Alarmes Implementados no Sistema . . . . . . . . . . . . . . . . . . . . . . . . 55
xi
xii LISTA DE TABELAS
Abreviaturas e Símbolos
UN Unidade de NegócioEPS Efacec Power SolutionsRTU Remote Terminal UnitPLC Programmable Logic ControllerSCADA Supervisory Control and Data AcquisitionLAN Local Area NetworkWAN Wide Area NetworkDMS Distributed Management SystemOMS Outage Management SystemEMS Energy Management SystemHMI Human-Machine InterfaceSO Sistema OperativoRBAC Role-Based Access ControlDM Data MiningBI Business InteligenceWKS WorkstationSAH Sistema de Arquivo HistóricoICCP Inter Control Center ProtocolSSH Secure ShellBD Base de Dados
xiii
Capítulo 1
Introdução
A presente dissertação representa o culminar da formação no Mestrado Integrado em Enge-
nharia Eletrotécnica e de Computadores, na área de Automação com especialização em Robótica
e Sistemas, da Faculdade de Engenharia da Universidade do Porto.
O projeto foi realizado em ambiente empresarial na Unidade de Negócio (UN) de Automação
da Efacec Power Solutions, S.A. (EPS), com início a 17 de Setembro de 2018 e fim a 18 de Janeiro
de 2019.
1.1 Apresentação da Empresa
O início da história da EPS remonta a 1905 aquando da fundação de "A Moderna"Sociedade
de Serração Mecânica. Desde então a empresa sofreu inúmeras reestruturações a nível de órgãos
sociais e estrutura de negócio.
Atualmente, a EPS assume-se como uma empresa fortemente exportadora, com presença mun-
dial em mais de 65 países, espalhados por todos os continentes, cuja missão passa por criar valor
com soluções de energia, ambiente e transportes que influenciem positivamente o dia a dia de
todos, através da integração de competências e tecnologias inovadoras. [13]
A EPS divide-se, ela própria, num grupo de empresas independentes que reúne todos os meios
de produção e tecnologias associadas a cada área de negócio, como ilustra a figura 1.1:
Figura 1.1: Unidades de Negócio da Efacec
1
2 Introdução
A Efacec destaca-se como sendo uma empresa exportadora, presente em todos os continentes.
Através das suas UN, oferece soluções desde a Produção até à Transmissão e Distribuição de
Energia.
• UN Transformadores - potência core, potência shell, subestações móveis;
• UN Aparelhagem - postos de transformação, distribuição primária/secundária;
• UN Automação - SCADA, Armazenamento, Smart Grid;
• UN Mobilidade - carregadores rápidos, ultra-rápidos, wireless;
• UN Energia - projetos chave-na-mão: centrais termoelétricas, hidroelétricas...
• UN Ambiente e Indústria - Estações de tratamento de água, efluentes...
A figura 1.2 demonstra o carácter internacional da EPS. A mesma apresenta volumes de en-
comendas na ordem dos 500Me, o que se traduz num valor de receitas de cerca de 430Me e um
EBITDA de 36Me. [14]
Figura 1.2: Presença Mundial Efacec[14]
Como já foi referido, o projeto foi realizado na UN de Automação. A unidade de Automação
tem como principal foco o desenvolvimento de soluções para gestão e controlo de redes elétricas,
sistemas ferroviários e de gestão de infraestruturas, de onde se destacam:
• Soluções para Redes Inteligentes
• Sistemas de Gestão de Redes (SCADA/DMS/EMS/OMS)
• Automação de Centrais de Geração de Energia
• Soluções de Automação, Proteção e Controlo de Subestações
1.2 Motivação 3
A UN divide-se ainda em diferentes equipas de trabalho, dependendo da área de atuação. O
corrente projeto decorreu na equipa de ID/SCADA, que se ocupa com a Gestão de Redes elétricas
através das suas soluções de Supervisão, Controlo e Aquisição de Dados (SCADA) para controlo
da transmissão, distribuição e produção de energia.
1.2 Motivação
Nos sistemas SCADA de centros de comando, as atividades de diagnóstico de erros e proble-
mas são geralmente morosas e pouco exatas, uma vez que estão sujeitas a erros. O número de
aplicações e variáveis no sistema ou o tipo de erros possíveis - software, hardware, comunicações
- afetam a eficácia das análises.
Todos os eventos que ocorrem dentro do sistema são reportados em ficheiros de log. No en-
tanto, o facto das fontes e formatos de informação desses ficheiros serem diferentes, não existindo
uma clara uniformização do texto, complica a tarefa de análise e gestão de erros. Ainda assim,
todos os ficheiros de log aplicacionais são indispensáveis para qualquer utilizador que queira fazer
um correto diagnóstico de erros.
Atualmente, na EPS, já existe uma aplicação desenvolvida cujo objetivo é monitorizar o
SCADA. Essa monitorização visa identificar problemas ou potenciais problemas através da pes-
quisa por palavras-chave. No entanto, a aplicação possui algumas limitações que devem ser col-
matadas.
Tendo em conta o crescimento das tecnologias de análises de logs, torna-se essencial para
um sistema SCADA coexistir com ferramentas de análise e visualização das diferentes fontes
de dados, de modo a permitir uma maior eficácia e objetividade no diagnóstico de problemas
aplicacionais.
1.3 Objetivos
A evolução nos sistemas SCADA e a crescente necessidade da digitalização em sistemas de
energia (produção, distribuição) resultam inevitavelmente num aumento do número de sensores,
atuadores e, consequentemente, do volume de dados.
Como tal, o corrente projeto tem como principais objetivos:
• Identificar fontes de dados relacionados com atividades de logging.
• Centralização dos dados num servidor.
• Processamento e estruturação de toda a informação.
• Desenvolvimento de mecanismos de ordenação e visualização dos eventos.
4 Introdução
Apenas cumprindo todos estes aspetos é possível atingir o principal objetivo de todo o projeto,
ou seja, tornar eficiente e exata toda a atividade de diagnóstico de falhas ou problemas. Para isso
sugere-se o recurso às ferramentas disponibilizadas pela Stack ELK onde é possível centralizar e
tratar todas as atividades de logging, assim como construir métodos de visualização dos mesmos.
Todas esses eventos reportados em ficheiros de log resultam de atividades e processos do
ScateX#, o sistema SCADA da Efacec. É um sistema distribuído, constituído por vários servidores
e postos de trabalho, com diferentes sistemas operativos e ligações a bases de dados. O registo de
erros, avisos ou mensagens informativas é feito em diferentes locais, dependendo se são da base
de dados, do próprio Sistema Operativo (SO) ou das aplicações SCADA.
1.4 Estrutura da Dissertação
A presente dissertação está dividida em seis capítulos que descrevem, de forma organizada e
sequencial, as diversas fases do projeto.
No capítulo 1, é feita a apresentação da empresa e descrito o tema do projeto assim como os
seus objetivos.
O capítulo 2 revela toda a análise técnica das áreas abordadas no decorrer do projeto, funda-
mentais para a execução do mesmo.
No capítulo 3 são apresentados os requisitos do projeto e definida a solução genérica para uma
instalação da plataforma na solução SCADA da Efacec.
Já o capítulo 4 descreve a implementação do software, começando no processo de recolha dos
eventos, até ao processamento e estruturação dos mesmos finalizando com a criação de mecanis-
mos de visualização e análise dos dados.
No capítulo 5 apresenta-se a arquitetura desenhada para validar o sistema e a integração da
plataforma com o ScateX#.
Por último, no capítulo 6 é feita uma avaliação global da implementação de todo o projeto
assim como a validação dos objetivos definidos através da Análise de Requisitos. São também
apresentadas oportunidades de trabalhos futuros que poderão melhorar ainda mais todo o processo
de diagnóstico de erros aplicacionais.
Capítulo 2
Revisão Bibliográfica
Neste capítulo é analisado todo o estado de arte relativo aos conteúdos e temas indispensáveis
para a execução do projeto em questão.
2.1 Sistemas SCADA
O termo SCADA remonta à década de 1960, aquando do início de uma das maiores revolu-
ções industriais dos tempos modernos. A evolução da tecnologia associada à indústria criou a
necessidade da existência de um sistema que pudesse controlar e monitorizar todos os dados dos
processos. Com o passar dos anos e dado o crescimento das tecnologias de comunicação, também
a aplicabilidade e robustez destes sistemas distribuídos cresceu.
Os sistemas SCADA consistem num sistema normalmente distribuído, baseado em aplicações
de software aliadas a um sistema de hardware, que têm como finalidade a monitorização, recolha
e processamento de dados.
Na área de gestão de redes elétricas, já é possível o acesso a dados de subestações e termi-
nais em "near real-time", que podem ser controlados e monitorizados remotamente por sistemas
DMS (Distributed Management System) ou OMS (Operations Management System) [15]. Como
sistema distribuído, é importante conhecer os componentes essenciais de modo a que seja possível
recolher, analisar e monitorizar dados. Como se pode observar através da figura 2.1, há uma clara
dependência entre componentes de um sistema SCADA.
5
6 Revisão Bibliográfica
Figura 2.1: Arquitetura Geral de um sistema SCADA[1]
Essa dependência pode ser exemplificada tomando como caso de uso a gestão de redes elé-
tricas. Ao nível do terreno, os dispositivos de medição e controlo são feitos normalmente por
Remote Terminal Inputs (RTU) e Programmable Logic Controllers (PLC) que medem e controlam
os sensores e atuadores, como por exemplo na leitura de valores de corrente de transformadores,
ou no fecho/abertura de disjuntores.
Para aceder a tais medições ou até a sinais de controlo, é indispensável uma rede de comunica-
ção que permita a passagem de informação entre nós de acesso. Diferentes classes de transporte de
protocolos de comunicação permitem que tal seja possível, como por exemplo por LAN ou WAN
[16]. Desse modo, a estação de controlo - Master do sistema distribuído - consegue ter acesso a
todos os dados que passem pelo sistema. A estação de controlo é a componente com finalidade
para o utilizador e está normalmente associada a uma interface Homem-Máquina que permite mo-
nitorizar/controlar todas as partes do sistema distribuído, dependendo das suas funcionalidades.
Finalmente, todos os dados recolhidos e tratados necessitam de uma capacidade de armazena-
mento associada. Essa tarefa é realizada pela base de dados, cujo acesso é importante que também
possa ser feito de vários pontos.
2.1.1 SCADA em Controlo Energético
Atualmente, os sistemas SCADA estão presentes na maioria dos processos industriais. Seja
na indústria alimentar, ou até no ramo de controlo energético, é crucial a presença de um sistema
que monitorize o estado dos sensores/atuadores e que permita uma interface de operações para o
utilizador.
Tendo em conta o âmbito empresarial da presente dissertação, destaca-se a monitorização nos
sistemas de geração, transmissão e distribuição de energia. Nesse setor, cada vez mais se verifica
a integração de funcionalidades com os próprios sistemas SCADA, como aplicações DMS, EMS
ou OMS.
2.1 Sistemas SCADA 7
Figura 2.2: Comparação Gestão de Sistemas
Como se pode verificar através da figura 2.2, todas as aplicações têm funcionalidades e finali-
dades muito específicas.
A integração de aplicações DMS/OMS com o SCADA permite, objetivamente, aumentar a
eficiência das tarefas dos utilizadores. Tal é possível devido ao facto das aplicações oferecerem
assistência aos operadores através da interface.
Por outro lado, as aplicações EMS servem o propósito da eficiência energética, aplicadas à
geração e/ou transmissão de energia.
2.1.2 Segurança em sistemas SCADA
Como é normal em qualquer tipo de sistema ou aparelho tecnológico, existem sempre aspetos
de segurança a considerar aquando da sua implementação. Também nos sistemas SCADA tal
acontece. Sendo um sistema distribuído, com vários pontos de acesso, e tendo em conta que lida
com uma quantidade enorme de dados (muitas vezes confidenciais), é comum surgirem problemas
de segurança.
Na tabela 2.1 são exemplificados alguns tipos de ameaças a que um sistema de controlo, su-
pervisão e aquisição de dados pode estar sujeito.
8 Revisão Bibliográfica
Ameaças Descrição
Autenticação SoftwareFalta de autenticação do sistema ou do utilizador,
permitindo acesso a utilizadores indevidosConfiguração Configurações básicas de proteção facilita o acesso a atacantes
Falta de encriptaçãoEncriptação não suficiente em qualquer comunicação entrecontroladores do sistema permite acesso indevido através
de Sniffing software de modo a descobrir credenciais
Política Acesso RemotoFalhas no acesso remoto permitem a utilizadores acesso via
backdoor assim como à rede de área local
Ataques aplicações WEBHMI e PLC’s conectados na rede a aplicações Web
podem sofrer ataques via script ou injeção SQLcaso o sistema não esteja protegido
MalwareO sistema ficará vulnerável a ataques caso
não existam medidas de proteção anti-malwareou proteção via firewall
Tabela 2.1: Possíveis Ameaças de Segurança [12]
2.2 ScateX#
O ScateX# é a solução SCADA desenvolvida pela Efacec para a gestão avançada de redes
elétricas. Para a Gestão da Distribuição, o ScateX# define-se como uma solução SCADA com
componentes DMS e OMS, que suporta ainda diversas funcionalidades, nomeadamente na gestão
de operações e informação, gestão de incidentes, supervisão e controlo. Como tal, a plataforma
está presente e atua em todos os nós que compõe o sistema, desde a sala de controlo até toda a
infraestrutura de comunicações e equipamentos presentes no terreno, sobre os RTU.
O facto de ser uma plataforma modular permite ajustar o sistema a cada tipo de projeto e
cliente, facilitando a sua integração em diferentes ambientes de trabalho.
Todas estas funcionalidades servem o objetivo de melhorar o reconhecimento de certas situa-
ções e a qualidade da informação no apoio à decisão, possibilitando também uma rápida e eficiente
intervenção no sistema, sempre que necessário, em tempo real. No quadro 2.2 estão sintetizados
os aspetos-chave da plataforma:
Funcionalidades
Interface gráfica de utilizadorAplicações de gestão de energia
Infraestrutura modularHistórico de sistema
Sistema de formação de operadoresElevados padrões de segurança
Serviços web de análise e monitorizaçãoTabela 2.2: Funcionalidades ScateX#
2.2 ScateX# 9
2.2.1 Arquitetura do produto
O ScateX# apresenta uma infraestrutura modular baseada em nós e servidores informáticos,
cada um com um conjunto de tarefas específicas:
• Servidor SCADA - É o nó central do sistema. Todas as interações do sistema passam pelo
servidor SCADA, onde é realizada a aquisição e processamento dos dados, para posterior
monitorização.
• Servidores DMS - Onde se encontram as aplicações de energia da plataforma. Qualquer
disparo na rede elétrica ou envio de medições por parte do servidor SCADA são enviados
para o servidor DMS de modo a serem monitorizados.
• Postos de trabalho (WKS) - Posto principal de operação sobre a rede elétrica, tal como
serviços de edição e navegação sobre os objetos da rede, logo interagem diretamente com
os servidores DMS do sistema. Também através das workstations é possível enviar controlos
para o terreno, sobre o servidor SCADA.
• Servidores de Sistema Arquivo Histórico (SAH) - O sistema de arquivo histórico permite
registar e armazenar dados e eventos de qualquer parte da rede, sejam dados relativos às
RTU, ou ações de utilizadores na rede.
• Servidores Inter-Control Center Communications Protocol (ICCP) - Os servidores ICCP
têm como objetivo integrar a tecnologia inerente à instalação do ScateX# com os centros de
controlo, onde muitas vezes não está a cargo da EPS.
• Servidores de Estudo - A interface de estudo do sistema permite, através de diferentes
cenários (real, simulação, engenharia), realizar operações sobre a rede de uma forma in-
terativa. Esta funcionalidade possibilita a análise posterior de determinado incidente num
contexto de estudo simulador, permitindo preparar e validar ordens de controlo ao nível do
terreno.
A interação entre todos os servidores tem como base um funcionamento por camadas. Na ca-
mada inferior, ao nível do terreno (subestação, posto de transformação, etc.), encontram-se todos
os dados de telemetria que devem ser recolhidos. Os processadores front-end executam o proces-
samento das comunicações remotas e o acesso aos dispositivos do sistema para fins operacionais
e de gestão.
Na camada imediatamente a seguir estão todas as aplicações de gestão de operações, nomea-
damente o processador SCADA, que recebe toda a telemetria recolhida e efetua o processamento
necessário, e o sistema de arquivo histórico que regista e armazena dados estatísticos, relatórios e
alertas relativos aos dados controlados pelo servidor SCADA.
10 Revisão Bibliográfica
Na camada seguinte encontram-se todas as aplicações EMS e OMS. As aplicações de energia
efetuam todos os cálculos matemáticos e lógicos, permitindo realizar operações como estimação
de estados e cálculo do fluxo de cargas, tudo através dos postos de trabalho. O controlo de inter-
rupções incorpora a previsão e análise da Qualidade de Serviço, assim como sistemas de análise
de indicadores que detetem anomalias no sistema (análise de chamadas, previsão de incidentes).
Finalmente, a camada superior da arquitetura realiza a interface com o utilizador, permitindo a
este enviar controlos, editar modelos de rede ou até realizar uma gestão operacional relativamente
a ocorrências planeadas ou não. Para isso, a plataforma ScateX# possui vários ambientes de tra-
balho: cenário real, cenário de estudo ou cenário de engenharia. Os diferentes cenários permitem
analisar e realizar operações em ambientes controlados, uma vez que a plataforma inclui a criação
de modelos da rede elétrica.
A figura 2.3 procura ilustrar a estrutura modular que caracteriza o ScateX#.
Figura 2.3: Vista Geral da Arquitectura do ScateX# [2]
A vertente de segurança dos sistemas SCADA não deve ser ignorada, dada a complexidade e
confidencialidade de certo tipo de dados. Desse modo, também o ScateX# está preparado ao nível
de segurança, incluindo controlos de acesso, áreas de responsabilidade, autenticação e auditorias,
além da segurança ao nível da rede recorrendo à encriptação e bloqueio de serviços através da
firewall.
A escalabilidade da plataforma permite que todos os nós informáticos possam correr em di-
ferentes sistemas operativos, o que torna possível a existência de inúmeras arquiteturas físicas,
desde sistemas singulares até sistemas com múltiplos servidores. Tal escalabilidade do produto é
uma vantagem no que diz respeito a eventuais estratégias de expansão e investimento que o cliente
possa ter.
2.2 ScateX# 11
Na figura 2.4 pode-se observar uma possível arquitetura física do ScateX#, onde se encon-
tram representadas todas as partes do sistema: servidores, processadores front-end e interfaces de
utilizador.
Figura 2.4: Possível Arquitectura do ScateX# [2]
12 Revisão Bibliográfica
2.3 Análise de Dados
Num mundo onde a digitalização é tema central e onde é notória a evolução no que diz res-
peito à disponibilidade de informação, termos como Data Science ou Big Data são cada vez mais
recorrentes.
A análise de dados, ou Data Science carece ainda de uma definição objetiva e consensual,
apesar da sua história remontar a 1962, quando John Tukey lançou The Future of Data Analysis:
Data analysis, and the parts of statistics which adhere to it, must... take on the charac-
teristics of science rather than those of mathematics... data analysis is intrinsically an
empirical science... How vital and how important... is the rise of the stored-program
electronic computer? In many instances the answer may surprise many by being ‘im-
portant but not vital,’ although in others there is no doubt but what the computer has
been ‘vital.’ [17]
Desde então que o termo tem sofrido diferentes interpretações e perspetivas. Apesar disso, a
Data Science é uma área de trabalho que se ocupa da recolha, preparação, análise, visualização e
gestão de grandes quantidades de informação.
Como é possível perceber através das palavras de John Tukey, a análise de dados vai muito
além da área computacional. É uma ciência interdisciplinar, que envolve matemática e estatística
de modo a solucionar aquilo a que a área se propõe, ou seja: recolher e processar dados, estru-
turados ou não, e de diferentes tipos e fontes, de modo a que seja possível extrair o máximo de
conhecimento e informação existente num determinado grupo ou evento [3].
Figura 2.5: Domínios da Data Science [3]
2.3 Análise de Dados 13
Quanto à aplicabilidade da Análise de Dados, são inúmeras as possibilidades. Com o passar
dos anos, a área tornou-se presença comum não só na indústria, mas também na Investigação:
• Business Analytics - a recolha e análise de dados relativos à performance do negócio ajudam
no processo de tomada de decisões assim como na construção de modelos preditivos quanto
à performance futura.
• Segurança - fraudes ou acessos indevidos podem ser detetados através da análise de logs,
com base em padrões de atividade.
• Bioengenharia - dados biológicos ou genéticos são recolhidos e estruturados de modo a
compreender as bases de doenças ou propriedades genéticas.
Todo o processo desde a recolha dos dados até à fase final pode ser observado na figura 2.6:
Figura 2.6: Processo Data Science [4]
Inicialmente a informação é recolhida do "Mundo Real". Sejam logs, e-mails ou possivelmente
material genético, há que processar esses dados para posteriormente ser possível realizar uma
análise correta. Para tal são construídos canais de Data Munging, que através de atividades como
standardising, joining ou filtering estruturam a informação consoante o seu conteúdo. [18]
Tendo a informação organizada já é possível analisar os dados de uma forma credível e susten-
tada, podendo passar à criação de algoritmos estatísticos ou machine learning de modo a resolver
determinado problema (por exemplo de classificação ou previsão). Além disso, é essencial ter
ferramentas de visualização para um melhor entendimento do conteúdo da informação. Só assim
é possível tomar decisões, a grande finalidade de todo o processo da Data Science.
14 Revisão Bibliográfica
2.3.1 Big Data
O termo Big Data também tem recebido bastante reconhecimento, sobretudo através dos me-
dia. Para isso tem contribuído o facto da Internet ser a principal fonte de informação e conheci-
mento, nos dias que correm. Todas essas interações geram enormes quantidades de dados.
Figura 2.7: Big Data [5]
Big Data pode ser descrito tomando a perspetiva dos 3 V’s [6]:
1. Volume - quantidade de dados/informação
2. Velocidade - velocidade a que os dados são criados
3. Variedade - diferentes fontes e tipos de conteúdo
Figura 2.8: Os 3 V’s do Big Data [6]
Este tipo de perspetiva acerca do termo permite compreender os seus atributos e perceber que
o volume de dados não é tudo quando se define o Big Data. Por exemplo, hoje em dia 10 Terabytes
de dados pode ser considerado como um grande volume de dados. No entanto, no dia de amanhã
poderá já não ser considerado como tal, uma vez que está sempre sujeito à evolução tecnológica,
sobretudo no que toca a hardware [19].
2.3 Análise de Dados 15
Além do volume, a velocidade e a variedade influenciam ativamente o modo como se rea-
liza o processamento dos dados. Diferentes fontes de informação geralmente significam também
diferentes formatos de dados, o que implica outro tipo de filtragem e processamento. O mesmo
acontece com a velocidade a que a informação é disponibilizada para análise, onde muitas vezes é
crucial uma noção temporal em real-time - sobretudo em ambientes industriais.
2.3.2 Data Mining
Data Mining é outro campo da Análise de Dados e, como seria de esperar, é também uma
área multidisciplinar. Na falta de uma definição ótima que consiga compreender todas os ramos
de estudo, Data Mining é aceite como o processo que possibilita a extração de informação e
conhecimento de um elevado volume de dados, para posteriormente retirar conclusões.
Para ser possível retirar conhecimento e informação de dados com diferentes formatos, ta-
manho ou linguagens, é fundamental respeitar uma sequência de passos, normalmente entendida
como o Processo de Data Mining (DM), exemplificada através da figura 2.9.
Figura 2.9: Sequência do Processo de Data Mining [7]
16 Revisão Bibliográfica
Inicialmente é necessário realizar uma limpeza dos dados - ruído ou dados inconsistentes - e
sua integração, ou seja, combinar os dados independentemente da fonte dos mesmos. Posterior-
mente há que selecionar os dados relevantes para a análise e proceder à sua transformação e conso-
lidação para formas apropriadas. De seguida, através da aplicação de métodos de DM, extraem-se
e avaliam-se os padrões representativos da informação. Finalmente, é necessário construir formas
de visualização (gráficos, tabelas...) por forma a demonstrar os dados e conhecimentos extraídos
aos utilizadores.
O conceito de DM está associado a diferentes métodos:
• Deteção de AnomaliasA deteção de anomalias, em contexto de DM, é a identificação de eventos que suscitam
suspeição por diferirem da maioria do conjunto de dados.
Como estes eventos poderão resultar em problemas no sistema, a sua deteção é importante
para o utilizador e representa uma fonte de informação bastante valiosa.
Figura 2.10: Exemplo de anomalia num conjunto de dados[20]
A figura 2.10 ilustra uma contagem de eventos num determinado espaço temporal. Como
é possível observar, a determinado momento existiu um volume de eventos gerados fora do
normal. Todos os eventos que compõe esse espaço temporal são relevantes para o utilizador
e podem ser demonstrados através de mecanismos de visualização ou reportados na forma
de notificações/alertas.
• ClusteringClustering é a associação de diferentes dados com base em propriedades similares, for-
mando diferentes clusters consoante a propriedade que o caracteriza. Por exemplo, na aná-
lise da atividade de logging, a formação de clusters tendo em conta a fonte da informação é
essencial para o processamento da informação.
• Classificação - generalização do tipo de estrutura tendo em conta a informação recolhida
dos dados;
• Regressão - procura de função que modelize o grupo de dados com menor erro;
2.3 Análise de Dados 17
Sabendo que DM é multidisciplinar, o seu conceito surge muitas vezes associado a outras áreas
como Machine Learning ou Business Intelligence.
Machine Learning é a área que se ocupa com a exploração de algoritmos capazes de aprender
de forma automática através de dados de treino. Com esses algoritmos é possível construir um
modelo com base no comportamento com os dados de treino que consegue realizar previsões, com
base em eventos anteriores. Tendo em conta a entrada do sistema, existem diferentes formas de
Aprendizagem [21]:
• Aprendizagem com Supervisão: dados de supervisão presentes no set de treino (Ex. Clas-
sificação);
• Aprendizagem sem Supervisão: sem informação relativa aos dados (Ex. Clustering);
• Aprendizagem com Semi-Supervisão: informação de entrada incompleta (com e sem da-
dos de supervisão);
• Aprendizagem Ativa: interação dinâmica com o utilizador quanto a dados de entrada;
18 Revisão Bibliográfica
2.4 Análise e Gestão de Logs
A maioria dos sistemas SCADA são desenhados para operar 24 horas por dia. Como tal, é
crucial que os mesmos sejam credíveis e que também estejam disponíveis, uma vez que qualquer
degradação da qualidade de serviço irá afetar negativamente aplicações do sistema distribuído e,
inevitavelmente, os lucros da empresa. A deteção de anomalias participa ativamente na gestão de
incidentes em sistemas de grande-escala.
Este tipo de sistemas tem a capacidade de gerar ficheiros de log, que registam todo o tipo de
informação, seja de aplicações do SCADA, ou até do próprio sistema operativo e ligações a base
de dados. Para a deteção de anomalias, a análise da atividade de logging é muito importante, pois
permite perceber rapidamente as causas e as fontes dessas mesmas falhas.
Apesar desta área de trabalho estar em constante evolução, existe ainda muito por explorar,
sobretudo na análise automática de logs. Ainda é prática comum a análise manual deste tipo de
ficheiros, algo que é contra-producente, pelas seguintes razões:
1. Sistemas de grande-escala são demasiado complexos para uma única pessoa dominar, tor-
nando impensável que a mesma consiga identificar anomalias através de ficheiros de log.
2. Os sistemas geram milhões de linhas de eventos, o que se traduz em vários gigabytes ou até
terabytes de informação.
3. A análise manual de logs torna complicada a deteção de falsos-positivos.
4. Temporalmente muito exigente.
Como tal, a indústria tem procurado realizar uma análise automática dos ficheiros de log de
modo a reduzir significativamente o tempo e esforço despendido para tal. No subcapítulo 2.4.1
será feito um estudo de mercado de algumas soluções já existentes.
A análise de logs de forma automática envolve três passos fundamentais: recolha dos ficheiros
de log, processamento dos eventos dada a desorganização da informação e construção de meca-
nismos de análise e visualização dos mesmos.
Inicialmente, é necessário recolher todos os ficheiros de log que são relevantes para análise.
Posteriormente, já com todos os ficheiros centralizados, terá que se filtrar toda a informação re-
levante em cada evento gerado, tendo em conta o seu contexto e formato. Os eventos criados em
ficheiros de logs de base de dados (ex. Oracle) são totalmente diferentes dos eventos gerados para
os logs do próprio SO, assim como dos ficheiros que as aplicações do ScateX# geram e, como tal,
devem ser tratados de formas diferentes.
2.4 Análise e Gestão de Logs 19
Os ficheiros de log derivados do Oracle apresentam uma sintaxe baseada em XML:
<msg t ime =’2018−12−03T10 : 5 2 : 2 0 . 8 2 2 + 0 0 : 0 0 ’ o r g _ i d = ’ o r a c l e ’
comp_id = ’ rdbms ’ t y p e = ’UNKNOWN’ l e v e l = ’16 ’ h o s t _ i d = ’SCD−LOAD−2b ’
h o s t _ a d d r = ’ 1 7 2 . 1 8 . 2 1 3 . 2 ’ p i d = ’53962 ’ >
< t x t >Unable t o o b t a i n c u r r e n t p a t c h i n f o r m a t i o n due t o e r r o r :
20001 , ORA−20001: L a t e s t xml i n v e n t o r y i s n o t l o a d e d i n t o t a b l e
</ t x t > </msg>
Por outro lado, as aplicações do ScateX# reportam para um formato totalmente diferente do
anterior, como podemos ver de seguida:
Sys tem_Moni tor 41313 2 0 1 8 / 1 2 / 1 1 2 1 : 4 5 : 1 1 . 9 1 7
E n t i t y [SCD−LOAD−2B :NAVIGATOR] s t a t u s changed from
[ Wai t ing ] t o [ S t a r t i n g ]
Even tLogger 78808 2 0 1 8 / 1 2 / 1 9 1 4 : 5 9 : 0 4 . 3 1 9 (BUS) No
T x K i l l O n F a i l u r e s e t on c o n f i g f i l e , r e s e t i n g t o TRUE
NodeManager 78225 2 0 1 8 / 1 2 / 2 2 1 3 : 2 1 : 2 7 . 3 0 0 (BUS) INFO : Rece ived
G e t P r o c e s s S t a t u s r e q u e s t from S t a r t u p
Os eventos do sistema operativo podem ter o seguinte formato, baseado em rsyslog:
Dec 9 0 3 : 5 2 : 5 5 SCD−LOAD−1b wdogMULTFE : wdogMULTFE : Warn . P r o c C n t r l −Reply message s e n t t o watchdog
Ao observar os exemplos anteriores, é notória a diferença entre os ficheiros de logs. Para além
disso, o formato de cada evento pode variar consoante o tipo e a quantidade de informação enviada.
Como tal, terão de ser classificadas e tratadas de formas diferentes por forma a poderem ser usadas
por ferramentas e mecanismos de visualização.
2.4.1 Estudo de Mercado
Atualmente existem várias soluções relativas a plataformas de gestão e monitorização de logs
aplicacionais. São sobretudo ferramentas modulares, que entre si disponibilizam as funções de
recolha dos ficheiros, de tratamento dos eventos e de visualização de toda a informação relevante.
Muitas dessas soluções são open-source, apesar de normalmente apresentarem ferramentas
modulares pagas e são apresentadas com mais detalhe nas tabelas 2.3 e 2.4.
20 Revisão Bibliográfica
Na escolha de uma plataforma há que considerar diversos fatores para além das funcionalida-
des que apresentam na análise e monitorização de logs aplicacionais. O custo associado à plata-
forma é um fator muito importante, dado que a maioria das ferramentas open-source apresenta as
funcionalidades base gratuitas, mas tal integração não seria possível ao nível da Produção. Tipica-
mente, módulos de Machine Learning ou de Alertas não constam nas ferramentas base gratuitas
para utilização. Como tal, essa análise deve ser feita, tendo como principal objetivo a redução
máxima do custo associado ao produto, sem perda de funcionalidades que sejam relevantes para a
execução deste projeto.
PLATAFORMAS SOFTWARENome SO Real-time Regex Processamento Dados
Graylog Linux 3 3 Self-HostedSplunk ES Windows/Linux 3 3 Self-Hosted
IBM QRadar Windows/Linux 3 3 Hosted SaaSStack ELK Windows/Linux/MacOS Near real-time 3 Self-HostedSumoLogic Windows/Linux/MacOS Near real-time 3 Hosted SaaS
Tabela 2.3: Comparação plataformas Análise de logs
Outro aspeto relevante para o projeto em questão prende-se com a forma como os dados são
recolhidos e processados, podendo ser feito em servidores centralizados (SaaS) ou então através
do próprio servidor local do utilizador. As tarefas realizadas no próprio servidor do utilizador
implicam a utilização de hardware capaz de as executar de uma forma eficiente e rápida. Por
outro lado, a utilização de uma plataforma com recurso a servidores centralizados significa que
os serviços de gestão são disponibilizados pelo próprio fabricante, o que poderá ser ou não uma
vantagem uma vez que desse modo todos os dados passam também pelo fabricante, algo que
pode não ser desejável. Por último, um fator relevante para o projeto passa pelo reconhecimento
de expressões regulares (regex), de modo a detetar e/ou excluir certas palavras ou expressões de
texto.
PLATAFORMAS SOFTWARENome Visualizações Machine Learning Alertas Custo
Graylog 3 3 3 PagoSplunk ES 3 7 7 Livre
IBM QRadar 3 3 3 PagoStack ELK 3 7 7 LivreSumoLogic 3 3 3 Pago
Tabela 2.4: Comparação plataformas Análise de logs
A partir desta análise é possível observar rapidamente que algumas plataformas são pagas e,
como tal, não representam uma oportunidade para o projeto. Quanto à deteção de anomalias ou
definição de alertas e notificações, na tabela 2.4 estão identificados os que apresentam estas fun-
cionalidades como parte do seu pacote base. No caso das plataformas open-source, uma vez que
2.4 Análise e Gestão de Logs 21
tais opções fazem parte da subscrição paga, as mesmas foram referenciadas como não possuindo
estas funcionalidades.
22 Revisão Bibliográfica
2.5 Stack ELK
Após uma Análise de Mercado relativa às soluções já existentes, foi sugerido pela EPS a utili-
zação da Stack ELK. É uma ferramenta modular e bastante flexível, sendo uma opção válida para
inúmeros casos de uso. Como foi visto em 2.4.1, é uma plataforma que suporta várias distribui-
ções Linux assim como Windows e MacOS. Permite a utilização de expressões regulares, o que
se torna determinante para a realização do corrente projeto.
A Stack ELK é composta por um conjunto de produtos open-source que no seu todo oferecem
mecanismos de recolha, processamento e análise de dados de diferentes fontes, nomeadamente:
• Elasticsearch - armazenamento e pesquisa de dados;
• Logstash - processamento e estruturação de dados;
• Kibana - análise e monitorização com recurso a visualizações;
Possui ainda os módulos Beats, cuja função passa pela recolha de eventos de diferentes tipos:
• Packetbeat - responsável pela recolha de dados relativos aos protocolos de rede em servi-
dores;
• Filebeat - recolha de dados no formato de log de vários servidores;
• Metricbeat - permite recolher informação do servidor como utilização do processador, me-
mória e outros processos;
• Winlogbeat - recolha e processamento de eventos Windows;
Os eventos recolhidos são posteriormente transmitidos para o Logstash, responsável por pro-
cessar e estruturar toda a informação. Após o processamento de dados, os mesmos são enviados
e armazenados no Elasticsearch. A partir desse momento a informação torna-se disponível para o
utilizador, permitindo a visualização através da Kibana. A figura 2.11 ilustra a arquitetura geral
do funcionamento da Stack ELK.
Figura 2.11: Arquitetura de Recolha e Análise de Dados - Stack ELK [8]
2.5 Stack ELK 23
2.5.1 Filebeat
Para ser possível centralizar logs de diferentes servidores é necessário recorrer a um módulo
da Stack ELK. O Filebeat é o agente responsável pela recolha e envio dos dados para o Logstash,
de modo a serem processados.
É baseado em dois componentes: inputs e harvesters. Os harvesters são responsáveis por
abrir e fechar o ficheiro, assim como ler o conteúdo do mesmo linha-a-linha. Caso o ficheiro seja
alterado durante a sua leitura, o Filebeat continua o harvest, não existindo perda de dados.
Os inputs fazem a gestão dos harvesters e definem os ficheiros para leitura, através do seu
diretório [22].
Através da sua configuração é possível definir diferentes ficheiros de log de diferentes diretó-
rios, assim como excluir linhas de logs ou ficheiros específicos, com base em expressões regulares.
2.5.2 Logstash
O agente responsável pelo processamento de dados após a sua recolha é o Logstash. Esta
ferramenta facilita todo o processo de Data Mining, isto é, integração de dados recolhidos e toda
a sua transformação e normalização. A informação que permite ao Logstash realizar esse proces-
samento de dados reside em apenas um ficheiro de configuração, ou numa combinação de vários
ficheiros.
O processamento da informação no Logstash é feita de um modo sequencial, com base em três
parâmetros: inputs, filtros e outputs, como mostrado na figura 2.12 [23].
Figura 2.12: Execução do processamento no Logstash [9]
1. Input - Para processar os dados é necessário, primeiro que tudo, recebê-los. Para cada
ficheiro de configuração apenas pode ser definido um tipo de input, tal como ficheiros locais,
eventos recolhidos pelo Filebeat ou mensagens syslog.
2. Filter - O filtro é o núcleo de todo o processamento da informação recolhida. Através da
forma de plugin, existem dezenas de filtros que permitem trabalhar e transformar dados de
formas e fontes diferentes, como por exemplo o grok que permite estruturar dados de log
com recurso a padrões pré-definidos ou que o próprio utilizador pode construir. O plugin
xml estrutura e analisa eventos com a sintaxe xml.
3. Output - A última fase da execução do Logstash depende dos outputs definidos. É possível
enviar todos os dados transformados e filtrados para o Elasticsearch para posterior visuali-
zação ou ainda para escrita num ficheiro local.
24 Revisão Bibliográfica
No capítulo 4 serão apresentados de uma forma detalhada todos os plugins utilizados para
configuração do Logstash no decorrer do projeto.
2.5.3 Elasticsearch
O Elasticsearch é uma aplicação de pesquisa e armazenamento de dados. Funciona em near
real-time, o que significa que existe um espaço de tempo muito curto entre a altura em que o
documento é armazenado e a altura em que pode ser analisado e pesquisado.
O funcionamento da ferramenta baseia-se nos seguintes conceitos:
1. Cluster - é um conjunto de nós (servidores) que guardam todos os dados e fornecem as
capacidades de pesquisa e de indexing a todos os nós.
2. Nó - é um único servidor que faz parte de um cluster e guarda um conjunto de dados.
3. Index - é um conjunto de documentos. Um único cluster pode ter múltiplos indíces, como
por exemplo um para logs de servidores SCADA e outro para logs de Workstations (WKS)
[24].
4. JSON sobre HTTP - o facto do Elasticsearch transferir ficheiros por Hypertext Transfer
Protocol (sendo que estes encontram-se no formato JSON) possibilita a integração com
API’s desenvolvidas em diferentes linguagens como Java, Python, Ruby ou Perl [25].
A partir do momento em que os dados chegam ao Elasticsearch, estes têm de ser mapeados. O
mapeamento consiste na forma como os documentos são indexados e as suas variáveis guardadas.
O Elasticsearch possui uma REST API, interface aplicativa, que permite realizar operações sobre
os dados como GET, PUT ou DELETE através de pedidos HTTP sobre a forma de queries.
Quanto às variáveis, estas podem ser de diferentes tipos:
• String
• Numérico - long, integer, short, byte, float.
• Geo-localização - para localização com base em coordenadas (latitude e longitude).
• timestamp - gerado para todos os documentos, caso não seja feito na configuração;
2.5 Stack ELK 25
Após a execução do mapeamento, todos os dados estão disponíveis para pesquisa ou visuali-
zação no Kibana. A título exemplar, poderia ser executado o seguinte mapeamento:
{ "indexName": {
"mappings": {
"typeName": {
"properties": {
"source": { "type": "ip"},
"log_level": { "type": "text"},
"message": { "type": "text"},
"geolocation": { "type": "geo_point"},
"timestamp": { "type": "date"}
}
}
}
}
}
Caso fosse necessário, por exemplo, listar todos os eventos cujo nível fosse "ERROR", tal
poderia ser feito recorrendo a queries, conforme o seguinte exemplo:
GET /indexName/typeName/_search {
"query": {
"match": {
"log_level": "ERROR"
}
}
}
2.5.4 Kibana
Kibana é a plataforma baseada em browser que permite analisar, realizar pesquisas e visualizar
dados disponíveis nos indíces do Elasticsearch, tendo como objetivo tornar mais eficiente e rápida
toda a tarefa de diagnóstico de erros. Para isso dispõe de diversas funcionalidades como a criação
de dashboards - conjunto de visualizações (gráficos, mapas, tabelas, etc.) à navegação e pesquisa
de dados [26].
A construção de dashboards tem o intuito de oferecer aos utilizadores um ambiente de visuali-
zação de certos dados que permitam, por um lado, monitorizar o estado dos sistemas e, por outro,
realizar uma rápida análise de eventos com recurso a queries e filtros. Todo o tipo de queries
realizados no Elasticsearch via REST API pode também ser feito através da Kibana de uma forma
mais simples e dinâmica.
26 Revisão Bibliográfica
No desenho das dashboards deve-se ter em conta certos aspetos que influenciam a facilidade
com que os dados importantes são transmitidos ao utilizador [27]:
• Utilização do tipo de gráfico certo, consoante a informação a mostrar.
• Divisão da informação por área de análise.
• Escolha de cores e layout o mais simples possível.
Apesar do objetivo de utilização da Kibana serem as dashboards, a plataforma possui diversas
funcionalidades:
• Discover Page - Onde é possível explorar todos os dados indexados no Elasticsearch através
de queries e filtros, assim como definir a escala temporal de pesquisa e análise de eventos.
Figura 2.13: Página Discover [10]
• Visualize Page - Onde se criam visualizações dos dados, com base em agregações, filtros
e queries - desde gráficos de linhas, barras, áreas ou pie-charts; tabelas de dados, mapas
geográficos, etc.
2.5 Stack ELK 27
• Dashboard Page - Para condensar todas as visualizações criadas anteriormente numa única
página, de modo a oferecer ao utilizador toda uma interface de análise e monitorização de
dados.
Figura 2.14: Exemplo de Dashboard [11]
• Dev Tools Page - Utilizado principalmente para interação com o Elasticsearch, com um
painel de consola e outro de resposta. Aqui é possível manipular e relizar queries nos dados
guardados no Elasticsearch.
• Management Page - Página onde é possível visualizar e alterar todos os índices e variáveis
presentes na base de dados do Elasticsearch.
Todos os módulos da Stack ELK têm uma função bem específica e, no seu todo, proporcionam
um ambiente de análise e monitorização de grandes quantidades de dados, o que facilita toda a
tarefa de diagnóstico de erros. Apesar de ser uma plataforma open-source, existem módulos que
requerem a subscrição paga do X-Pack, como:
• Alertas e Notificações - permite definir alertas e notificações (e-mail, slack) com base em
condições e regras pré-definidas.
• Machine Learning - para deteção de anomalias relacionados com desvios temporais, com-
portamentos irregulares, etc.
• Monitorização - para monitorização de todo o comportamento dos clusters e nós.
28 Revisão Bibliográfica
Capítulo 3
Análise de Requisitos
Neste capítulo é analisada a aplicação de monitorização já existente na Efacec e definidos
todos os requisitos para o novo sistema de análise e visualização de logs aplicacionais. É ainda
apresentada a proposta de solução adotada para que fosse possível cumprir todos os requisitos.
3.1 hostMonitor
O hostMonitor é uma aplicação desenvolvida pela Efacec para monitorização do ScateX#.
Essa monitorização visa identificar indicadores de problemas ou potenciais problemas, através da
Monitorização de Logs Aplicacionais e da Comparação dos dados em sistemas redundantes.
Na identificação de uma falha existe a possibilidade de ser enviada uma notificação por e-mail,
SMS ou relatório para um servidor central. A monitorização dos logs aplicacionais do ScateX# é
feita recorrendo à identificação de palavras-chaves contidas nos mesmos, como por exemplo:
• exception
• java.lang.OutOfMemory
• warning
De modo a ignorar todos os falsos-positivos que existam nos eventos, também existe a possi-
bilidade de configurar palavras-chave de exclusão:
• ABOUT TO loadExceptions
• DbmsDigitalExceptions
• The previous error is not a real error.
29
30 Análise de Requisitos
Com as palavras-chave de exclusão evita-se um reconhecimento de erro ou de problema para
casos conhecidos.
No entanto o hostMonitor possui algumas limitações, a que este projeto se dispõe a anular, tal
como:
1. A monitorização aplica-se apenas aos logs das aplicações do ScateX#, excluindo os logs
do SO e da Oracle, que alojam importantes informações sobre o estado do sistema e das
ligações à base de dados.
2. Não tem como centralizar todos os ficheiros de log e toda a informação inerente.
3. Não possui mecanismos de visualização desses mesmos dados, de modo a proporcionar uma
fácil análise e identificação de padrões e relações entre eventos em diferentes servidores.
3.2 Requisitos
Definiram-se vários requisitos para o sistema de acordo com o seu nível de importância na exe-
cução deste projeto, divididos em cinco tipos - Sistema, Segurança, Aplicação, Oracle e Operaci-
onal - e serão apresentados de seguida, através das tabelas 3.1, 3.2, 3.3, 3.4 e 3.5, respetivamente.
Cada tipo de requisito apresenta funcionalidades que devem ser implementadas ou eventos que
devem ser processados. Para a definição de todos os requisitos apresentados foi crucial o conhe-
cimento prévio por parte da equipa de SCADA relativamente às lacunas que a solução existente
apresentava, assim como da própria plataforma ScateX#. Os requisitos foram ainda organizados
pela sua prioridade, de acordo com a seguinte nomenclatura:
• P1 - Prioridade Máxima
• P2 - Prioridade Intermédia
• P3 - Prioridade Baixa (Facultativo)
ID Tipo Título Descrição Prioridade
1.1Arquitetura do
Sistema
O sistema a implementardeve ser desenhado comatenção à capacidade de
armazenamento e processamento
P1
1.2
Sistema
Recolha dosdados
O sistema deverá recolherdados dos servidores que
compõem o ScateX#:SCADA, DMS, SAH,
ICCP, WKS
P1
Tabela 3.1: Requisitos do sistema a implementar
3.2 Requisitos 31
ID Tipo Título Descrição Prioridade
2.1Tentativas delogin por SSH
P1
2.2Logins aceites
por SSHP1
2.3
Segurança
Logins falhadospor SSH
Os acessos por SSH aosdiferentes servidores sãoreportados como eventosde log, pelo que devem
ser analisados e demonstradosem visualizações
P1
Tabela 3.2: Requisitos de monitorização de segurança
ID Tipo Título Descrição Prioridade
3.1Crashes deaplicações
P1
3.2Contagem deerros/avisos
P2
3.3Eventos por
servidorP1
3.4Programas em
execução por servidorP1
3.5Tabela de exploração
de eventosP2
3.6
Aplicação
Contagem de erros nosistema ao longo do
tempo
Todos os eventos reportadospelos diferentes SO
(Linux, Windows) devem seranalisados e processados,com ênfase para os errosou avisos reportados das
diferentes aplicações
P1
Tabela 3.3: Requisitos de monitorização dos eventos do Sistema Operativo
ID Tipo Título Descrição Prioridade
4.1Erros das
ligações à BDP1
4.2Contagem decertos erros
P1
4.3Shutdown e Init da
base de dadosP2
4.4Conexões por
servidorP1
4.5Conexões por
aplicaçãoP2
4.6
Oracle
Erros e falhas deconexão
A base de dados da Oraclepossui dois ficheiros de log com
interesse de monitorização:alert e listener. Devem ser
analisados todos os erros nosservidores com ligações à BD,
assim como asconexões à mesma
P1
Tabela 3.4: Requisitos de monitorização dos eventos da base de dados Oracle
32 Análise de Requisitos
ID Tipo Título Descrição Prioridade
5.1Erros do
System MonitorP1
5.2Contagem de erros
das chaves de pesquisaP1
5.3Variação dos erros e dos
alarmes com o tempoP1
5.4Alarmes reportados
pelo ScateX#P1
5.5Tabela de exploraçãodos eventos com erros
P1
5.6
Operacional
Variação das medidasrecebidas pelo SCADA
e relação com a sua média
Os logs aplicacionais do ScateXestão presentes em todosos servidores analisados.
Deve ser realizado uma análiseespecífica ao ficheiro de log do
SystemMonitor, através de chavesde pesquisa. Todos os eventos com
erros ou avisos devem serdemonstrados através devisualizações, tal como
os alarmes reportados pelo ScateX P3
Tabela 3.5: Requisitos de monitorização aplicacional relativos ao ScateX#
3.3 Proposta de Solução
A solução para uma plataforma de centralização de logs e análise e visualização de dados
sugerida pela EPS foi a Stack ELK. Através de módulos, esta solução oferece todo um mecanismo
de recolha, análise, manipulação e visualização de dados.
No entanto, a integração da mesma num sistema SCADA como o ScateX# implica o desen-
volvimento de uma arquitetura distribuída.
Como sistema distribuído, o ScateX# é caracterizado por possuir múltiplos postos de trabalho
e servidores com variadas aplicações. Uma instalação típica do ScateX# é composta por:
• 4 servidores SCADA
• 4 servidores DMS
• 2 servidores SAH
• 1 servidor ICCP
• > 20 WKS
Quer seja em servidores ou postos de trabalho, todas as aplicações e ligações a base de dados
geram informação sob a forma de ficheiros de log da sua atividade, tal como o próprio sistema
operativo. Todos esses ficheiros possuem dados com enorme valor, sobretudo na ocorrência de
falhas no sistema.
3.3 Proposta de Solução 33
A implementação dos servidores onde a Stack estará instalada deverá contemplar alguns aspe-
tos relevantes, sobretudo no que diz respeito a componentes de hardware.
3.3.1 Necessidades de Hardware
Para implementar um sistema cujo objetivo é gerir e processar grandes quantidades de dados
é necessário, inicialmente, assegurar que os requisitos de hardware são cumpridos, sob pena do
sistema falhar e consequentemente poder existir perda de dados. [28]
Aquando do desenvolvimento da arquitetura da solução, foram tidos em conta alguns fatores
que afetavam a qualidade e rapidez do serviço, relativamente aos servidores centrais de armazena-
mento e processamento de dados:
1. Memória RAM - fundamental para o processo do Elasticsearch pois todas as queries, agre-
gações e alojamento da informação requerem acessos constantes à memória heap.
2. Núcleos de Processamento - aspeto menos relevante da arquitetura do cluster pois as tarefas
não são pesadas a nível de processamento.
3. Capacidade de Disco - é o subsistema cujo acesso é mais lento em todo o sistema. Em
casos de uso como na ingestão de ficheiros de log é um componente que facilmente fica
saturado dado o enorme volume de dados.
Para perceber as necessidades de hardware é importante ter conhecimento de certas informa-
ções, como a quantidade de dados gerados diariamente a centralizar no servidor e o tempo de
retenção dos mesmos em base de dados.
Com o intuito de aferir o volume de dados que o sistema terá de lidar, foram realizados testes
de controlo sobre os ficheiros de log gerados para análise.
Através do controlo realizado e mostrado na tabela 3.6, foi possível aproximar o volume de
dados gerado diariamente. Para isso tomou-se como dados de referência o valor da média diária
de dados gerados por tipo de servidor numa instalação típica, chegando-se à variação do volume
de dados entre cada dia.
34 Análise de Requisitos
Controlo de Volume de DadosServidor Source Dia 1 Dia 2 Dia 3 Variação Diária
ScateX# 1,7 GB 2,2 GB 2,8 GB
Oracle 4,45 MB 5,3 MB 7 MBSCADA
Red Hat 36,7 MB 63,1 MB 88,5 MB
0,6 GB/dia
ScateX# 3,6 GB 4 GB 4,2 GB
Oracle 10,6 MB 11,4 MB 11,9 MBDMS
Red Hat 6,71 MB 15,4 MB 20,7 MB
0,32 GB/dia
ScateX# 0,36 GB 0,42 GB 0,5 GBWKS
Windows 60 MB 120 MB 180 MB0,13 GB/dia
ScateX# 7,2 MB 12,7 MB 25,4 MBSAH
Windows 60 MB 120 MB 180 MB70 MB/dia
ScateX# 19 MB 22 MB 26 MBICCP
Red Hat 2,3 MB 3,5 MB 4,9 MB4,8 MB/dia
Tabela 3.6: Tabela de controlo do volume de informação gerado por servidor
Todo o volume de informação, aquando num pólo típico do ScateX#, aproximaria-se da ordem
dos 10GB/dia. Tendo conhecimento do volume de dados gerado diariamente e do período de
retenção de quatro meses dos mesmos, é possível definir o número de nós necessários para o
sistema, tal como as especificações de hardware do conjunto de servidores.
Nnodes > Ndias ×Tamanho1dia
Armazenamento(3.1)
Tomando ainda o caso de armazenamento com recurso a um disco de 500GB, a equação 3.1
tomaria a seguinte forma:
Nnodes > 120× 10500
> 2,4nodes (3.2)
Pela expressão 3.2 é possível verificar que serão necessários 3 servidores para armazenar e
processar todos os pedidos de acesso aos dados.
3.3 Proposta de Solução 35
A arquitetura desenhada para integrar a Stack ELK no ScateX#, representada na figura 3.1,
possui três servidores centrais de armazenamento de dados, onde se encontra instalado o Elastic-
search. A distribuição teve em conta a forma como é realizada o armazenamento dos dados. Ou
seja, um dos servidores é responsável por armazenar os dados mais recentes (por exemplo dos
últimos dois meses) - Hot-Data Server. Num outro servidor encontram-se os dados mais antigos,
nomeado de Warm-Data Server. Ao contrário do servidor de dados mais recentes, este necessita
de requisitos de hardware menos robustos dado que todo o acesso e agregações dos dados serão
realizados em menor número de situações. Por último, sugere-se a implementação de um servidor
Master para o sistema se tornar ainda mais disponível e robusto [29].
Figura 3.1: Integração do sistema baseado na Stack ELK no ScateX#
Dada a elevada necessidade de acesso aos servidores de dados e armazenamento, sugere-se
que os mesmos cumpram os seguintes requisitos:
• 64 GB memória RAM
• 500 GB memória de disco
• 6 núcleos de processamento
36 Análise de Requisitos
A arquitetura também contempla a implementação de outro servidor, onde está instalado o
Logstash e a Kibana, aplicações responsáveis pelo processamento de grandes quantidades de in-
formação e visualização dos mesmos. Este necessita de menos potência no que diz respeito às
especificações aconselhadas:
• 32 GB memória RAM
• 500 GB disco SSD
• 6 núcleos de processamento
Em todos os servidores de onde se pretende recolher informação deverão estar instalados dois
módulos Beats: Winlogbeat para recolha e processamento automático de eventos do Windows, e
o Filebeat para recolha de eventos aplicacionais e de Linux. Todo o processo de instalação do
software nos diferentes servidores encontra-se descrito no apêndice A. O processo da recolha dos
dados até à fase onde todos ficam disponíveis e armazenados encontra-se ilustrado pelo diagrama
UML de sequência no apêndice B.
Capítulo 4
Implementação
No presente capítulo é abordado todo o projeto de implementação da Stack ELK no Sca-
teX#. Desde a configuração para a recolha dos diferentes eventos de logging em servidores SCA-
DA/DMS, WKS ou SAH através do Filebeat e Winlogbeat, até todo o código implementado para
processamento, estruturação e análise de dados de diferentes fontes e formatos.
Por último, são mostradas todas as dashboards e visualizações criadas com o intuito de ofe-
recer aos utilizadores um ambiente de monitorização e análise rápida e eficiente sobre um grande
volume de informação.
4.1 Configuração Filebeat
Para a recolha dos ficheiros de interesse ser possível, é necessário definir as entradas do sis-
tema, ou seja, a localização dos ficheiros que se pretende analisar e monitorizar. Todas as funcio-
nalidades que o Filebeat possui são configuráveis através de um ficheiro: filebeat.yml.
4.1.1 filebeat.inputs
Na secção de entradas do ficheiro de configuração do Filebeat, definem-se todos os ficheiros
que o Filebeat deve recolher para posterior análise e processamento. Para isso foram utilizadas as
seguintes funcionalidades:
• type - tipo do ficheiro a recolher: pode ser do tipo log (para ficheiros no formato de log);
tipo TCP (para recolha de eventos sobre uma rede TCP), assim como outros.
• paths - localização do ficheiro a recolher;
• multiline - gestão de eventos que produzam mais do que uma linha;
• exclude_files/exclude_lines - ficheiros ou linhas que se pretendem excluir logo à partida;
37
38 Implementação
Para o corrente projeto, todos os eventos recolhidos são do tipo Log. No caso dos servidores
Linux, a leitura dos ficheiros com informação do próprio SO é realizada da seguinte forma:
- type: log
paths:
- /var/log/secure
tags: ["auth"]
- type: log
paths:
- /var/log/messages
tags: ["syslog"]
- type: log
paths:
- /var/log/iptables.log
tags: ["iptables"]
Como é possível verificar, para a recolha dos ficheiros basta apenas definir o tipo e o caminho
para o mesmo. No entanto, para facilitar o posterior processamento da informação no Logstash,
foram definidas tags que permitem rapidamente reconhecer a fonte dos eventos recolhidos.
Uma vez que o Filebeat lê os ficheiros linha-a-linha, é necessário configurá-lo para situações
em que os eventos gerados tenham mais do que uma linha. Tal acontece nos logs do Oracle
(formato XML) ou até nos próprios logs aplicacionais do ScateX#.
- type: log
paths:
- /home/scatex/scadadms/sxcli/sxlocal/base/log/\*.log
tags: ["root_log"]
multiline.pattern: ’^[[:space:]] | \:$’
multiline.match: after
- type: log
paths:
- /home/oracle/diag/rdbms/sxdb/SXDB/alert/log.xml
tags: ["alert_xml"]
multiline.pattern: ’^<msg’
multiline.negate: true
multiline.match: after
multiline.flush_pattern: ’</msg>’
4.1 Configuração Filebeat 39
Foram utilizadas as seguintes propriedades da funcionalidade multiline, que permitem gerir de
forma correta todos os possíveis eventos compostos por múltiplas linhas:
• pattern - expressão regular a identificar
• negate - define se a expressão deve ser negada ou não;
• match - especifica como as linhas devem ser combinadas: before ou after, e depende da
configuração anterior;
• flush_pattern - expressão regular a identificar que finaliza o evento de múltiplas linhas;
No caso dos logs aplicacionais, se o evento começar por um espaço em branco ou terminar
com o caractere ’:’, é associado automaticamente ao evento anterior. Por outro lado, os eventos
gerados pela Oracle apresentam múltiplas linhas, iniciadas sempre por ’<msg’ e terminadas por
’</msg>’. Como tal, todas as linhas entre as duas expressões são consideradas como do mesmo
evento.
Como já foi referido anteriormente, existe a necessidade de excluir certos eventos para des-
piste de falsos-positivos, conhecidos em antemão, ou até certos ficheiros cujo interesse é irrele-
vante para análise. Tal pode ser feito recorrendo às funcionalidades exclude_lines e exclude_files,
que identificam essas situações com base em expressões regulares, como demonstrado no excerto
seguinte:
- type: log
paths:
- /home/scatex/scadadms/sxcli/sxlocal/base/log/\*.log
tags: ["root_log"]
multiline.pattern: ’^[[:space:]] | \:$’
multiline.match: after
exclude_files:
- /home/scatex/scadadms/sxcli/sxlocal/base/log/SM_err\.log
- /home/scatex/scadadms/sxcli/sxlocal/base/log/dump_in\.log
exclude_lines: [’ERROR_BAD_VOLTAGE_CONNECTION’]
exclude_lines: [’This error is not a real error’]
4.1.2 output.logstash
Tendo todas as entradas definidas, falta apenas selecionar a saída do Filebeat, ou seja, iden-
tificar para onde deve o Filebeat enviar todos dados recolhidos: Elasticsearch ou Logstash. No
presente projeto, toda a informação deve ser reencaminhada para o Logstash, onde é feita a mani-
pulação e estruturação dos dados.
40 Implementação
Como tal, a secção de saídas do ficheiro de configuração do Filebeat deve ser definida da
seguinte forma:
hosts: ["XXX.XXX.XXX.XX:5044"]
Desta forma, todos os eventos recolhidos pelo Filebeat são enviados para o servidor central,
identificado pelo seu IP, através do porto 5044. Toda a informação está então disponível para
tratamento pelo agente responsável - Logstash.
4.2 Configuração Logstash
Tal como referido em 2.5.2, a execução do Logstash baseia-se em três processos diferentes:
input, filter e output. Toda esta informação é declarada em ficheiros de configuração que permitem,
com recurso a plugins e filtros disponibilizados pelo Logstash, tornar dados desorganizados em
informação válida e útil, para posteriormente poder ser utilizada por mecanismos de visualização.
Ao longo deste sub capítulo serão apresentados todos os conteúdos utilizados através do fi-
cheiro de configuração para processamento dos eventos recebidos pelo Logstash.
4.2.1 Input
Na secção de entrada do Logstash deve estar definida a forma como o mesmo recebe os dados
para processamento. No caso do projeto, todos os eventos são recolhidos pelo Filebeat, pelo que
o mesmo deve ser declarado como entrada da seguinte forma:
input {
beats {
port => 5044
}
}
Assim, o agente Logstash está continuamente à espera de novos eventos através do porto 5044,
recolhidos pelo Filebeat.
4.2.2 Filter
O núcleo de todo o processamento e estruturação dos dados é realizado na secção Filter do
ficheiro de configuração.
Através do Filebeat foram definidas tags para associar os eventos à sua fonte, o que foi crucial
para a análise dos mesmos no Logstash. É através das tags que o código do ficheiro de configura-
ção do Logstash está estruturado, ou seja, consoante a fonte do ficheiro são realizados e aplicados
métodos e processamento de dados diferentes, que melhor se aplicam ao formato dos eventos e ao
conteúdo que se pretende extrair.
4.2 Configuração Logstash 41
Filtro GrokO filtro Grok foi o principal recurso utilizado para estruturar dados de modo a poderem ser
analisados e pesquisados por queries.
O seu modo de funcionamento baseia-se na combinação de padrões de texto com uma expres-
são regular que se identifique com o evento, apresentando a seguinte sintaxe:
%{SINTAXE:SEMANTICA}
SINTAXE é o padrão que irá combinar com um determinado evento. Existem padrões pré-
definidos prontos a utilizar na configuração, mas também há a possibilidade de criar padrões que
melhor sirvam para o problema com base na sintaxe de Oniguruma. [30]
Caso fosse recebido o seguinte exemplo de evento aplicacional do ScateX#:
Sys tem_Moni tor 78057 2 0 1 8 / 1 2 / 1 9 1 4 : 5 8 : 3 9 . 3 8 0 E n t i t y
[SCD−LOAD−1B : E f a _ I c c p ] s t a t u s changed from [ Unknown ] t o [ Loading ]
Recorrendo ao filtro Grok seria possível estruturar este tipo de eventos da seguinte forma:
grok { match => { "message" =>["%{WORD:sysMon_prgm} %{POSINT:sysMon_pid}
%{DATESTAMP:date} \[%{DATA:sysMon_host}:%{DATA:sysMon_from}\]
%{GREEDYDATA:sysMon_msg}"]}}
A configuração anterior resultaria na seguinte estruturação dos dados:
• sysMon_prgm - Nome do programa (System_Monitor)
• sysMon_pid - No de processo (78057)
• date - 2018/12/19 14:58:39.380
• sysMon_host - SCD-LOAD-1B
• sysMon_from - Efa_Iccp
• sysMon_msg - status changed from [Unknown] to [Loading]
Outro tipo de evento que merece ser analisado está relacionado com pacotes de dados, que
podem ser bloqueados ou não. Toda essa informação está presente no ficheiro iptables.log.
Um exemplo de formato deste tipo de eventos poderá ser o seguinte:
Jan 2 0 4 : 1 3 : 4 0 SCD−LOAD−2b k e r n e l : IPTABLES : IN= ens32
OUT= MAC= f f : f f : f f : f f : f f : f f : 2 c : 9 e : f c : d6 : 9 8 : b f : 0 8 : 0 0 SRC= 1 7 2 . 1 8 . 2 1 0 . 2 4 3
DST= 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 LEN=237 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=53213 DPT=53213 LEN=217
42 Implementação
Recorrendo ao filtro grok, seria possível recolher informação válida através dos seguintes pa-
drões:
grok { match => { "message" =>[ "%{SYSLOGTIMESTAMP:timestamp}+
%{HOSTNAME:source_host}+(?<chain>[A-Za-z0-9_-]+)
?.*IN=%{WORD:in_interface}?.*OUT=(%{WORD:out_interface})
?.*MAC=%{NETFILTERMAC}?.*SRC=%{IP:src_ip}?.*DST=%{IP:dst_ip}
?.*TTL=%{INT:ttl}?.*PROTO=%{WORD:protocol}?.*SPT=%{INT:src_port}
?.*DPT=%{INT:dst_port}?.*LEN=%{INT:final_len}" } }
Para o último caso foram criados padrões para estruturar certa informação que não era possível
recorrendo aos padrões disponibilizados pela biblioteca do Logstash:
pattern_definitions => { "NETFILTERMAC" =>
"%{COMMONMAC:dst_mac}:%{COMMONMAC:src_mac}:%{ETHYPE:ethtype}"}
pattern_definitions => { "ETHYPE" =>
"(?:(?:[A-Fa-f0-9]{2}):(?:[A-Fa-f0-9]{2}))" }
Toda esta estruturação permite retirar os seguintes campos de qualquer tipo de evento gerado
em iptables.log:
• timestamp - January 2nd 2019, 04:13:40.000
• source_host - SCD-LOAD-2b
• source_mac - 2c:9e:fc:d6:98:bf
• dst_mac - ff:ff:ff:ff:ff:ff
• src_ip - 172.18.210.243
• dst_ip - 255.255.255.255
• protocol - UDP
Filtro XMLPara ficheiros cujo formato original é XML, o Logstash apresenta um filtro que realiza toda a
estruturação de dados de forma automática. Este caso aplica-se aos ficheiros de log gerados pelo
Oracle. Para essas situações, o filtro XML é aplicado da seguinte forma:
else if "alert_xml" in [tags] {
xml {
source => "message"
target => "parsed_alert"
}
}
4.2 Configuração Logstash 43
Caso fosse recebido o seguinte evento:
<msg t ime =’2018−12−27T02 : 0 0 : 0 0 . 1 5 3 + 0 0 : 0 0 ’ o r g _ i d = ’ o r a c l e ’ comp_id = ’ rdbms ’
t y p e = ’UNKNOWN’ l e v e l = ’16 ’ h o s t _ i d = ’SCD−LOAD−2b ’
h o s t _ a d d r = ’ 1 7 2 . 1 8 . 2 1 3 . 2 ’ p i d = ’72990 ’ >
< t x t > S e t t i n g Resource Manager p l a n DEFAULT_PLAN v i a p a r a m e t e r
</ t x t > </msg>
A aplicação do filtro ao evento recebido resultaria na seguinte estruturação da informação:
• parsed_alert.time - 2018-12-27T02:00:00.153+00:00
• parsed_alert.org_id - oracle
• parsed_alert.host_id - SCD-LOAD-2b
• parsed_alert.host_addr - 172.18.213.2
• parsed_alert.txt - Setting Resource Manager plan DEFAULT_PLAN via parameter
Filtro mutateO filtro mutate permite realizar modificações e operações sobre as variáveis existentes, tal
como modificar ou remover, ou até converter os campos em diferentes tipos.
Ao longo de todo o código implementado para a estruturação dos ficheiros de log, a utilização
deste filtro foi recorrente e, como tal, importante para a execução do sistema. Um exemplo de
uso do mesmo refere-se a certos eventos que são gerados no ficheiro messages.log em servidores
SCADA/DMS. Tais eventos estão diretamente relacionados com os alarmes gerados, que possuem
informação relativamente à localização do mesmo, quando aplicado num dos pólos do sistema da
EDP.
De seguida é apresentado um exemplo de alarme reportado para messages.log:
a larms_2gw : d d b _ a l r : Warn . GenProc−No : 1 3 3 3 , Id : 1 0 4 4 2 ,
TimeScada : 2 6 / 1 1 / 1 8 1 5 : 5 6 : 0 8 , TimeSource : 1 5 4 3 2 4 7 7 3 3 . 0 , Kidx : 5 3 2 2 0 1 ,
s t a t e : 1 . 0 0 0 0 0 0 , t y p e : 5 , Hl0 : LISBOA , S t a t =0200H, AlrTyp=c2H , a t t r =10H
Para este tipo de eventos, foi inicialmente aplicado o filtro grok para estruturar todos os campos
de informação. Posteriormente foi aplicado o filtro mutate para associar cada localização (por
distrito) às suas coordenadas geográficas. Só desse modo seria possível construir um mapa com
as incidências de alarmes por localização. Essa implementação foi realizada da seguinte forma:
44 Implementação
if "LISBOA" in [al_local] {
mutate { add_field => {"latitude" => "38.7437"} }
mutate { add_field => {"longitude" => "-9.1517"} } }
A mesma implementação foi realizada para os restantes distritos de Portugal, consoante as
coordenadas geográficas, onde também existem incidências de alarmes.
Filtro dateCom a aplicação deste filtro, é pretendido que para a escala temporal sejam utilizados os
dados presentes no evento gerado e não a data a que o evento é recebido pelo Logstash. Deste
modo elimina-se o desfasamento de tempo que existe entre a data de criação do evento no ficheiro
de log e a posterior receção no Logstash.
O filtro utiliza-se da seguinte forma:
date {
match => [ "al_timestamp", "MMM dd HH:mm:ss" ]
remove_field => "al_timestamp" }
Dentro de cada filtro que a biblioteca do Logstash disponibiliza, existem configurações espe-
cíficas que podem ser utilizadas, como foi o caso do corrente projeto.
4.2.3 Output
Na secção da saída do ficheiro de configuração do Logstash encontra-se definido para onde
são encaminhados todos os dados previamente processados e estruturados. De entre várias opções
existe a possibilidade de enviar os eventos para o Elasticsearch, para um ficheiro local ou até por
e-mail. Para o projeto foi definida como saída o Elasticsearch, de modo a guardar todos os dados
nos seus índices, facilitando a pesquisa e monitorização a partir de queries.
output {
elasticsearch {
hosts => ["http://localhost:9200"]
index => "%{[@metadata][beat]}-%{+YYYY.MM.dd}"
}
}
O processo do Elasticsearch fica à espera dos eventos localmente pelo porto 9200, uma vez
que se encontram no mesmo servidor central. Diariamente é criado um índice onde são guardados
todos os eventos e campos criados pelo processamento do Logstash.
4.3 Dashboards Kibana 45
4.3 Dashboards Kibana
Após realizar todo o processamento necessário, os dados e campos criados pela execução do
Logstash estão disponíveis e guardados no Elasticsearch. Como tal estão também acessíveis pela
Kibana, a plataforma de visualização da Stack ELK.
Nesta fase do projeto procedeu-se à criação de todas as visualizações e dashboards cujo ob-
jetivo seria o de oferecer ao utilizador uma ferramenta que permite monitorizar e diagnosticar
qualquer tipo de atividade de logging do sistema. Para isso, através da interface web que a Ki-
bana disponibiliza foi possível criar visualizações facilmente, uma vez que o acesso aos diferentes
dados armazenados no Elasticsearch é direto.
4.3.1 Oracle
Todos os servidores SCADA e DMS que fazem parte do sistema possuem ligações à base de
dados da Oracle. Como tal, a atividade de logging representa uma fonte importante de informação
e conhecimento. Nesses mesmos servidores existem dois ficheiros de log onde está concentrada
toda a informação relativa às ligações de base de dados: alert e listener.
No ficheiro alert encontra-se informação relacionada com erros ou avisos nas ligações à base
de dados.
Deste modo, as visualizações desenvolvidas com base na informação presente no ficheiro alert
tiveram como foco os seguintes aspetos:
• Erros reportados do tipo ORA e TNS, que por sua vez possuem um código associado
• O servidor no qual foi reportado o erro assim como o seu endereço
• Contagem de erros com códigos específicos (Erros Deadlock, Erros Internos)
• Informação sobre o início e encerramento da base de dados
A figura 4.1 permite perceber que tipo de erros existem pelos diferentes servidores, identifica-
dos pelo seu endereço IP.
Figura 4.1: Top erros tipo "ORA"por host
46 Implementação
Outra visualização desenvolvida encontra-se na figura 4.2, onde é possível observar a deteção
de diferentes eventos com erros do tipo ORA, num gráfico de barras com base temporal.
Figura 4.2: Erros do tipo "ORA"em função do tempo
Por outro lado, o ficheiro de log listener foca-se nas ligações à base de dados. Sempre que é
feita uma ligação à BD, é reportado para o ficheiro um conjunto de eventos com informação sobre
essa mesma ligação. Todos esses eventos permitem recolher dados, destacando-se:
• Aplicação que fez a ligação
• Host de onde foi realizada a ligação
• Erros e falhas de conexão
• Protocolos utilizados nas ligações
• Tipos de serviço na conexão (update, register, etc...)
Agregar dados e variáveis de diferentes modos facilita a criação de visualizações que demons-
tram toda a informação presente no ficheiro, facilitando a tarefa do utilizador no diagnóstico de
erros e problemas.
Duas das visualizações criadas sobre a informação presente no ficheiro listener podem ser
observadas pelas figuras 4.3 ou 4.4.
A primeira permite observar todas as conexões realizadas à base de dados pelas diferentes
aplicações. Através do gráfico de barras desenvolvido é possível verificar qualquer anomalia no
número de conexões assim como detetar aplicações cuja ligação à base de dados não seria espe-
rada.
4.3 Dashboards Kibana 47
Figura 4.3: Conexões à BD por aplicação em função do tempo
A visualização da figura 4.4 permite observar as conexões realizadas à base de dados pelos di-
ferentes servidores identificados pelo seu endereço. Qualquer ligação não desejada será facilmente
identificada pela observação deste gráfico com base temporal.
Figura 4.4: Conexões à BD por host em função do tempo
48 Implementação
4.3.2 RedHat 7
Os servidores SCADA, DMS e ICCP possuem instalado o RedHat Enterprise Linux 7.3 (RH7)
de 64 bits, sendo que o próprio SO gera eventos no formato de ficheiro de log que devem ser
analisados e monitorizados.
Relativamente aos logs gerados pelo SO, foram considerados indispensáveis para análise os
seguintes ficheiros: messages.log e secure.log. Nesses ficheiros está presente informação rela-
cionada com a segurança do sistema e dados sobre a execução de serviços e processos no SO,
destacando-se as seguintes situações:
• Acessos aceites/recusados por SSH aos servidores
• Erros, avisos ou falhas na execução dos serviços no SO
• Informações do ScateX# reportadas para o ficheiro messages
Todo este tipo de informação é relevante para qualquer utilizador cuja tarefa é monitorizar
e diagnosticar erros aplicacionais. A figura 4.5 ilustra a contagem de eventos pelos diferentes
servidores (SCADA, DMS, ICCP), permitindo perceber sempre que existam picos de informação.
Esse tipo de situações está normalmente associada a algum tipo de problema no sistema.
Figura 4.5: Contagem de eventos do SO por hostname em função do tempo
Outra das visualizações implementadas permite observar os diferentes processos em execu-
ção nos diferentes servidores onde o SO RedHat se encontra instalado, como demonstra a figura
4.6. Através da sua análise é possível perceber se determinado processo estará, anormalmente, a
reportar demasiados eventos no formato de logging.
4.3 Dashboards Kibana 49
Figura 4.6: Gráfico circular dos processos por hostname
Como já foi referido, os eventos de segurança do SO são reportados para secure.log, incluindo
acessos por SSH a qualquer servidor SCADA, DMS ou ICCP.
Uma das dashboards criadas foca-se na monitorização de todos os acessos aos servidores
acima descritos, realçando os seguintes tópicos:
• Logins nos diferentes servidores
• Logins aceites, recusados ou inválidos
• Utilizadores cujo login foi falhado ou inválido, referenciado pelo seu endereço IP ou user-
name
• Formas de acesso aos servidores
Figura 4.7: Tentativas de login por SSH
50 Implementação
A figura 4.7 faz parte de um conjunto de visualizações desenvolvidas com foco para a infor-
mação de acesso aos diferentes servidores. Através deste gráfico de barras é possível verificar a
contagem de acessos por SSH, sempre com a base temporal associada ao evento. Caso existam
acessos falhados ou inválidos, os mesmos são reportados e demonstrados nas dashboards, como
prova a figura.
Outro tipo de informação aquando dos acessos aceites nos servidores prende-se com a forma
como o mesmo foi realizado. Essa informação, depois de estruturada foi demonstrada através de
visualizações, como exemplificado pela figura 4.8. O gráfico de barras procura expor a forma
como os acessos são realizados ao longo do tempo, ou seja, através de password ou chave de
acesso (publickey).
Figura 4.8: Logins com sucesso por SSH
4.3.3 Windows
Todos os postos de trabalho possuem instalado o Windows 10. Os servidores SAH, como já foi
referido, baseiam-se no Windows Server. Para este tipo de servidores é necessário monitorizar os
logs aplicacionais do ScateX# e ainda os eventos que o SO gera, sobretudo a nível de Segurança.
Para o processo de recolha e processamento dos eventos do Windows foi utilizado, como já
referido, um módulo Beats - o Winlobeat. O mesmo, caso instalado nos servidores de onde se
pretende recolher informação, permite a sua recolha e processamento automático dos eventos de
logging. O facto do Windows fornecer toda a informação de logging do sistema já estruturada foi
algo que facilitou a análise e monitorização dos mesmos.
Cada evento no formato de log do Windows possui um código identificador único, que repre-
senta determinadas situações, por exemplo [31]:
• 4724 - Tentativa de redefinição da password de uma conta.
• 4624 - Uma conta realizou login com sucesso.
• 4625 - Uma conta falhou o login.
4.3 Dashboards Kibana 51
Através da análise dos dados filtrados por cada identificador de evento foi possível implemen-
tar gráficos que facilitassem ao utilizador a sua monitorização.
A figura 4.9 permite visualizar os servidores com maior número de erros reportados no sistema
operativo. No exemplo da figura, facilmente se constata que o servidor SAH apresenta um número
de erros bem superior quando comparado com a WKS.
Figura 4.9: Servidores Windows com mais erros de aplicações
Como todos os acessos são reportados para o sistema, foi possível monitorizar os mesmos. A
figura 4.10 representa essa situação, onde se observa a contagem de acessos aos servidores num
dado espaço temporal, através de um gráfico de barras.
Figura 4.10: Acessos aos servidores Windows
52 Implementação
4.3.4 ScateX#
Em todos os servidores que compõem o ScateX#, existe uma pasta dedicada aos ficheiros de
log aplicacionais que são gerados. Como tal, todos esses ficheiros são recolhidos e estruturados.
Em relação aos logs aplicacionais do ScateX#, tornou-se indispensável todo o papel do Fi-
lebeat no sistema. A exclusão de ficheiros específicos, irrelevantes para análise, foi crucial para
não sobrecarregar o Elasticsearch com dados desnecessários. Também a exclusão de expressões
demonstrou facilitar todo o processamento de dados, nomeadamente no despiste de erros que, na
realidade, não o são.
A análise de toda a informação aplicacional do ScateX# teve como intuito a deteção de erros
ou avisos, destacando-se os seguintes aspetos:
• Deteção de erros/avisos por cada aplicação
• Deteção de problemas por palavras-chave
• Alarmes gerados pelo ScateX#
Depois dos dados se encontrarem estruturados, é possível realizar uma análise de onde se
podem retirar algumas conclusões, como por exemplo:
• Variação da contagem de erros com o tempo
• Servidores/aplicações onde mais erros são detetados
A visualização desenvolvida e apresentada na figura 4.11 demonstra a variação dos eventos
aplicacionais onde foram registados erros com o tempo. Ao analisar a figura, é possível observar
qualquer tipo de variação anormal de erros no sistema.
Figura 4.11: Variação da contagem de erros com o tempo
4.3 Dashboards Kibana 53
O ScateX# permite ainda gerar alarmes na forma de log nos servidores SCADA, cujo con-
teúdo possui informações relativamente à localização dos mesmos. Nos servidores onde foram
realizados todos os testes, os alarmes gerados tinham como localização os distritos de Portugal.
Todos esses eventos foram analisados.
A figura 4.12 ilustra a variação do número de alarmes num dado espaço temporal. Ao observar
o exemplo da figura é possível identificar uma reduzida zona temporal onde existe um pico de alar-
mes gerados pelo sistema. Esse tipo de informação é indicador de um possível mau funcionamento
no sistema.
Figura 4.12: Variação do no de alarmes com o tempo
Para o utilizador facilmente observar os servidores com maior número de ocorrências de erros,
foi desenvolvida a visualização ilustrada pela figura 4.13. Através da análise da mesma é possí-
vel concluir que o servidor SCADA "SCD-LOAD-2b"é, inegavelmente, o servidor com maior
ocorrência de erros.
Figura 4.13: Servidores com maior número de ocorrências de erros
54 Implementação
Foi também construída uma visualização geográfica, apresentada na figura 4.14. Aquando de
um alarme gerado, a localização do mesmo é identificada e associada às suas coordenadas geográ-
ficas. Posteriormente, através das coordenadas, foi possível desenvolver a visualização geográfica
apresentada, revelando todas as incidências de alarmes reportadas. No exemplo é verificável a
elevada incidência de alarmes no distrito de Lisboa, quando comparadas com os restantes.
Figura 4.14: Mapa de Alarmes ScateX#
Posteriormente à criação de todas as visualizações, as mesmas foram agregadas em dashboards
divididas pelo conteúdo e fonte da informação. As dashboards desenvolvidas permitem, através
de uma organização simples, analisar e monitorizar todos os resultados do processamento de cada
ficheiro recolhido. No entanto, a interface que a Kibana disponibiliza possui ainda algumas falhas,
que merecem ser apontadas, nomeadamente:
• A disposição das visualizações nas dashboards dependem da resolução do monitor onde
serão demonstradas, pelo que a sua agregação tornou-se uma tarefa complicada.
• Alguns pontos nos mapas geográficos são difíceis de detetar.
• A página Discover, onde é possível explorar todos os dados, não permite a criação de filtros
automáticos, pelo que quanto atulizada volta ao estado default.
4.4 Alertas e Notificações 55
4.4 Alertas e Notificações
A plataforma Stack ELK possui ainda um módulo que requer subscrição paga. Este módulo
denomina-se X-Pack e possui diversas funcionalidades como ferramentas de Machine Learning
ou de Alertas e Notificações.
Dada a existência de um período experimental da subscrição, a mesma foi utilizada como
complemento do projeto, tornando o sistema mais interativo com o utilizador.
O Watcher é uma ferramenta de Alertas, incorporada na interface disponibilizada pela Kibana.
A sua execução baseia-se na sequência de quatro eventos:
1. Agenda - Agendar a execução da query e verificação da condição. Ex: 10 em 10 min,
diariamente;
2. Query - Dados de entrada para a condição do evento;
3. Condição - Avalia os dados de entrada com a condição especificada para o alerta disparar;
4. Ação - Ação a realizar na verificação da condição. Ex: Envio e-mail, notificação Slack,
evento de log;
Com o objetivo de facilitar a monitorização de erros e problemas no ScateX# e terceiras par-
tes, foram implementados alertas com base em condições e situações consideradas de elevada
importância e que, como tal, merecem o conhecimento imediato da equipa de trabalho.
Alertas Watcher
Agenda Descrição Ação15/15 min Erros do ScateX# encontrados Slack
30/30 minNo de alarmes gerados na última meia hora
maior que o normalSlack
30/30 minTentativas de acesso por SSH inválidas
ou falhadasSlack
1/1 h Erros do Oracle encontrados SlackTabela 4.1: Alarmes Implementados no Sistema
56 Implementação
Para definir os alertas descritos na tabela 4.1 foi necessário fazer o seu registo via REST API:
PUT _xpack/watcher/watch/SX_Errors
{ "trigger": {
"schedule": { "interval": "15m" } },
"input": { "search": { "request": {
"search_type": "query_then_fetch",
"indices": [ "filebeat-*" ],
"types": [], "body": {
"query": {
"bool": { "filter": [ { "range": { "@timestamp":
{ "gte": "now-15m" } } },
{ "terms": { "tags": ["root_log_notOK",
"sys_mon_erro",
"sys_mon_disap"] }}]}}
}}}},
"condition": {
"compare": { "ctx.payload.hits.total": { "gt": 1 } } },
"actions": {
"notify-slack": {
"slack": { "message": { "to": ["#elk"],
"text": "Encountered {{ctx.payload.hits.total}}
errors in the last 15 minutes" }}}}}
Pela análise do código anterior é possível verificar o modo de execução de um Alerta. Ini-
cialmente define-se a agenda de execução (10 em 10 minutos, 1 em 1 hora, etc.). De seguida é
necessário descrever a entrada da condição, que pode ser feita recorrendo a queries ou agregações,
dependendo dos dados que se quer monitorizar.
No caso supramencionado está a ser controlado o número de erros aplicacionais reportados
pelo ScateX#, de 15 em 15 minutos. A query implementada procura por tags que descrevem os
tais erros, nos últimos 15 minutos.
Posteriormente, para o alerta disparar é fundamental que a condição se verifique. A execução
da entrada definida irá retornar o número de eventos correspondentes. Se a condição se verificar
através da comparação desse valor com um pré-definido, o alerta dispara e é acionado o mecanismo
de notificação.
4.4 Alertas e Notificações 57
No corrente projeto foi utilizado o Slack como mecanismo de notificações uma vez que era já
utilizado pela equipa de trabalho. Na figura 4.15 encontra-se ilustrado o disparo do alerta descrito
anteriormente.
Figura 4.15: Notificações por Slack
58 Implementação
Capítulo 5
Testes e Validações
Por forma a validar todo o sistema desenhado, é necessário realizar testes que confirmem a cre-
dibilidade e disponibilidade do mesmo. Como tal, procedeu-se à recolha de eventos relacionados
com a atividade de logging de servidores pertencentes a uma instalação do ScateX#.
Para o corrente projeto foi disponibilizado apenas um servidor com as seguintes especificações
a nível de armazenamento e processamento:
• 30GB Memória RAM
• 4 núcleos de processamento @ 2.00GHz
• Disco de 500GB
Tendo em conta as limitações do servidor central, não seria possível realizar os testes num am-
biente real de produção, pelo que se limitou a quantidade de servidores de onde seriam recolhidos
eventos relacionados com a atividade de logging. Desse modo, todos os testes e validações foram
baseados nos eventos gerados por:
• 2 servidores SCADA, baseados em Linux RedHat 7
• 1 servidor DMS baseado em Linux RedHat 7
• 1 servidor SAH em ambiente Windows Server 2012
• 1 servidor ICCP com Linux RedHat 7
• 1 WKS com Windows 10 instalado
Nesse sentido, o único servidor disponibilizado seria suficiente para armazenar e processar
todos os eventos reportados, funcionando como o único nó do cluster. Nos múltiplos servidores
que compõem o ScateX#, encontram-se instalados os módulos Beats, para a recolha e envio dos
dados para o servidor central. A figura 5.1 representa a arquitetura implementada para os testes.
59
60 Testes e Validações
Figura 5.1: Sistema de Testes Stack ELK/ScateX#
Para assegurar a credibilidade do sistema, no decorrer do projeto foi realizado um controlo
contínuo sobre os dados que, no final de todo o processamento, eram armazenados no Elastic-
search. Ao comparar os dados recebidos com a informação no seu estado original foi possível
descartar algumas situações críticas, nomeadamente:
• Perda de eventos de logging
A perda de qualquer evento cuja fonte se pretende monitorizar constitui uma situação grave
para o correto funcionamento do sistema. Nesse sentido, foram realizados testes que envolviam a
paragem da execução dos diferentes módulos da Stack ELK, de forma controlada e por diferentes
períodos de tempo.
1. Paragem na execução do Filebeat - Nesta situação não foram registadas qualquer perda
de informação na leitura dos ficheiros. Uma das funcionalidades do Filebeat passa por
memorizar o seu estado, pelo que no reinício, o mesmo volta ao seu estado.
2. Paragem na execução do Logstash - Um dos possíveis riscos neste caso prendia-se com a
possibilidade do processamento de dados sobre determinado evento ser terminado a meio.
Tal poderia representar a perda desse evento. No entanto, ao reiniciar a aplicação, nunca
foram registados perdas de eventos, pelo que se considera como fiável nesse aspeto.
Testes e Validações 61
3. Paragem na execução do Elasticsearch - A paragem do serviço poderia ter como con-
sequência a perda de dados estruturados, caso impedisse o armazenamento dos mesmos.
No entanto não foram registadas situações como a descrita, apesar de não existir a certeza
de que o serviço seja parado exatamente durante o armazenamento dos dados.
• Duplicação dos eventos
A existência de informação duplicada no armazenamento do Elasticsearch relativamente a deter-
minado evento teria como consequência uma má análise por parte do utilizador, em particular na
ocorrência de falhas. Deste modo, todo o processo do sistema implementado, desde a recolha até
ao processamento e armazenamento da informação, foi monitorizado e testado, não tendo sido
recolhida qualquer duplicação de eventos.
• Estruturação errada dos dados
A estruturação errada dos eventos representa um risco para todo o sistema na medida em que
toda a informação demonstrada pelas visualizações poderia induzir qualquer utilizador em erro.
Consequentemente, poderiam ser tomadas decisões com base em informação errada. A execução
do Logstash permite, em todas as funcionalidades utilizadas, definir tags que são escritas aquando
do reconhecimento de falha no seu uso. Como tal, a falta de estruturação dos dados foi uma
constante no decorrer do projeto. No entanto, a mesma contribuiu para a melhoria significativa
de todo o código de processamento de dados, pelo que no final do projeto já não eram visíveis
qualquer falhas na informação armazenada pelo Elasticsearch.
• Sobrecarga de eventos no sistema
Para testar o comportamento do sistema numa situação de sobrecarga de informação no formato
de log, foi utilizado como recurso a paragem dos diferentes módulos. A única diferença seria
o tempo de paragem dos mesmos, pois após o seu reinício, todos os eventos entretanto gerados
teriam de ser recolhidos e processados num curto intervalo de tempo.
No decorrer do projeto foram realizados testes que passava pela paragem e início das aplica-
ções da Stack ELK, onde apenas se variava o tempo de paragem dos mesmos. Para isso, foram
testadas duas situações: paragem de 20 minutos e de 1 hora de todo o sistema. Em cada um dos
testes verificou-se que o sistema implementado, aquando do reinício, registava com sucesso todos
os eventos que, entretanto, foram gerados. A única diferença observada foi em relação ao número
de eventos recolhidos que se encontravam atrasados. No primeiro caso, verificaram-se situações
em que o sistema assegurava a recolha e processamento de cerca de 500 mil eventos, gerados no
tempo de paragem do sistema. A segunda situação, mais crítica dado o maior período de tempo de
paragem, revelou a robustez e validade de todo o sistema implementado. Após paragem de uma
hora de todo o sistema, o mesmo foi capaz de continuar o seu normal funcionamento, processando
todos os eventos em atraso. Nesta situação foram registados casos em que o sistema recolhia e
analisava cerca de 10 milhões de eventos, todos em atraso devido à paragem do mesmo.
62 Testes e Validações
Concluindo, foi possível constatar que a arquitetura desenhada para os testes demonstrou ser
suficiente para validar todo o sistema. O sistema implementado baseado na Stack ELK e no mó-
dulo Beats assegura a correta e eficaz monitorização dos ficheiros de formato de log, processando
toda a informação sem falhas, pelo que toda a informação representada nas dashboards pode ser
validada. Ainda assim, na implementação de todo o sistema foram encontrados alguns problemas,
nomeadamente no que concerne à análise e processamento dos eventos aplicacionais reportados
pelo ScateX#, de onde se destaca:
• A falta de uniformização da informação no formato de log foi um obstáculo, pelo que em
todo o projeto foi realizada uma análise constante aos eventos que eram reportados pelo
ScateX#, o que tornou o sistema implementado mais robusto.
• A existência de informação errada nos eventos aplicacionais relativamente a erros que, na
realidade, não o são, foi um grande entrave ao sucesso de todo o processamento de dados e
reconhecimento de erros.
Capítulo 6
Conclusões
Os eventos de atividade de logging de qualquer sistema tecnológico representam informação
valiosa, sobretudo em momentos de falha ou na deteção de anomalias, o que contribui para a
identificação de possíveis problemas antes da sua ocorrência. No entanto, a falta de estruturação
desta informação compromete a rápida e correta análise dos dados por parte do utilizador.
O presente projeto de dissertação teve como principal objetivo a implementação de uma plata-
forma de análise e monitorização de eventos relacionados com a atividade de logging da solução
SCADA da Efacec, o ScateX#.
6.1 Satisfação dos Objectivos
O sistema desenvolvido permite recolher e processar dados dos diferentes servidores que com-
põem o ScateX#, assim como monitorizar e realizar um diagnóstico de erros com base nas dash-
boards construídas.
Esta implementação visa, assim, facilitar e tornar mais eficiente toda a tarefa de diagnóstico de
erros e problemas que afetem a disponibilidade e funcionamento do ScateX#, em cada instalação.
Para tal foi desenvolvida uma solução genérica, capaz de monitorizar uma instalação típica
do ScateX#. Porém, dado o elevado volume de dados que caracterizam cada uma das instala-
ções, foram apenas considerados uma parte dos servidores para a fase de testes e validações da
plataforma.
Após a implementação da solução apresentada, foram alcançados os seguintes resultados:
• Toda a informação foi devidamente recolhida, consoante a sua fonte.
• Todos os eventos foram corretamente analisados e estruturados de acordo com o código de
processamento de dados elaborado.
• Os diferentes mecanismos de visualização criados foram agregados em dashboards, facili-
tando a rápida análise dos dados recolhidos.
• Foram definidos alertas e notificações com base em condições pré-definidas de modo a
comunicar eventuais problemas no sistema ao utilizador.
63
64 Conclusões
No decorrer do projeto foram encontradas algumas dificuldades relativas à falta de estruturação
da informação do ScateX#, o que tornou a tarefa de processamento de dados mais complexa e
demorada. Para além disso, existem várias situações em que o sistema reporta erros quando, na
realidade, não o são. Deste modo, foi necessário proceder à análise individual de cada uma destas
situações para despiste de falsos-positivos.
Concluindo, pode-se afirmar que os resultados obtidos foram positivos, uma vez que todos
os objetivos delineados foram superados com sucesso. A implementação deste sistema permitiu
validar a solução projetada para a recolha, processamento e visualização de dados relacionados
com eventos de logging.
6.2 Trabalho Futuro
Durante o período de estágio na Efacec, foi percetível o potencial da Stack ELK na análise de
eventos de logging de diferentes servidores.
Como trabalhos futuros, sugere-se a aplicação do sistema desenvolvido em situações de pro-
dução real, onde a quantidade de informação gerada é consideravelmente superior àquela que foi
processada para validar a solução apresentada.
Toda a configuração e pré-processamento dos dados encontra-se implementada, não sendo
portanto necessário qualquer tipo de alteração a nível de software para escalar o sistema a uma
situação de produção real.
Para isso, seria necessário primeiramente realizar um controlo mais aprofundado da quanti-
dade de dados que o sistema SCADA poderá gerar, bem como uma análise de custos mais deta-
lhada, dada a necessidade de componentes de hardware.
Por outro lado, sugere-se também a continuação do trabalho a nível de processamento da infor-
mação, alargando as possibilidades de análise e monitorização a outro tipo de dados considerados
relevantes.
Este projeto de dissertação representou uma mais-valia a nível de consolidação de conheci-
mentos e de resolução de problemas através do contacto com o ambiente empresarial. Considera-
se também que o trabalho desenvolvido contribuiu para a Efacec na medida em que permitiu
aumentar a eficácia dos processos de diagnóstico de falhas no sistema SCADA, possibilitando
também a criação de valor para a mesma.
Anexo A
Guia de Utilizador - Stack ELK
Para colocar em funcionamento todo o sistema de recolha, análise e monitorização de logs
aplicacionais é necessário, inicialmente, instalar uma série de módulos pertencentes à Stack ELK.
O funcionamento do sistema implica ter o Elasticsearch instalado em três servidores. Já o
Logstash e a Kibana devem ser executados numa outra máquina. Por outro lado o Filebeat deve
estar instalado em todos os servidores que compõem o ScateX#, sendo que o Winlogbeat apenas
deve ser executado nos servidores que se pretende recolher eventos de Windows.
A.0.1 Elasticsearch
1. Download do ficheiro .rpm da fonte oficial e envio para a máquina via Filezilla.
2. No diretório do ficheiro:
>> sudo rpm --install elasticsearch-6.4.2.rpm
3. Para configurar o Elasticsearch a inicializar automaticamente:
>> sudo /bin/systemctl daemon-reload
>> sudo /bin/systemctl enable elasticsearch.service
4. Para inicializar, reiniciar ou desligar:
>> sudo systemctl start elasticsearch.service
>> sudo systemctl restart elasticsearch.service
>> sudo systemctl stop elasticsearch.service
65
66 Guia de Utilizador - Stack ELK
A.0.2 Logstash
1. Download do ficheiro .rpm da fonte oficial e envio para a máquina via Filezilla.
2. No diretório do ficheiro:
>> sudo rpm --install logstash-6.4.2.rpm
3. Para configurar o Logstash a inicializar automaticamente:
>> sudo /bin/systemctl daemon-reload
>> sudo /bin/systemctl enable logstash.service
4. Para inicializar, reiniciar ou desligar:
>> sudo systemctl start logstash.service
>> sudo systemctl restart logstash.service
>> sudo systemctl stop logstash.service
A.0.3 Kibana
1. Download do ficheiro .rpm da fonte oficial e envio para a máquina via Filezilla.
2. No diretório do ficheiro:
>> sudo rpm --install kibana-6.4.2-x86_64.rpm
3. Para configurar a Kibana a inicializar automaticamente:
>> sudo /bin/systemctl daemon-reload
>> sudo /bin/systemctl enable kibana.service
4. Para inicializar, reiniciar ou desligar:
>> sudo systemctl start kibana.service
>> sudo systemctl restart kibana.service
>> sudo systemctl stop kibana.service
Guia de Utilizador - Stack ELK 67
A.0.4 Filebeat
• Windows
1. Download do ficheiro .zip da fonte oficial.
2. Extrair para C:\Program Files sob o nome Filebeat.
3. Abrir PowerShell como administrador:
>> cd ’C:\Program Files\Filebeat’
>> .\install-service-filebeat.ps1
4. Para iniciar ou desligar o Filebeat:
>> Start-Service filebeat
>> Stop-Service filebeat
• Linux
1. Download do ficheiro .rpm da fonte oficial e envio para a máquina via Filezilla.
2. No diretório do ficheiro:
>> sudo rpm -vi filebeat-6.4.2-x86_64.rpm
3. Para inicializar ou desligar:
>> sudo service filebeat start
>> sudo service filebeat stop
A.0.5 Winlogbeat
1. Download do ficheiro .zip da fonte oficial.
2. Extrair para C:\Program Files sob o nome Winlogbeat.
3. Abrir PowerShell como administrador:
>> cd ’C:\Program Files\Winlogbeat’
>> .\install-service-winlogbeat.ps1
4. Para iniciar ou desligar o Winlogbeat:
>> Start-Service winlogbeat
>> Stop-Service winlogbeat
68 Guia de Utilizador - Stack ELK
Anexo B
Diagrama UML de sequência
Figura B.1: Diagrama UML de sequência do processo
69
70 Diagrama UML de sequência
Anexo C
Dashboards
Figura C.1: Dashboard de monitorização de erros do Oracle
71
72 Dashboards
Figura C.2: Dashboard de monitorização de conexões à base de dados Oracle
Figura C.3: Dashboard de monitorização de eventos e processos a correr no Red Hat 7
Dashboards 73
Figura C.4: Dashboard de monitorização de acessos SSH aos servidores
Figura C.5: Dashboard de monitorização dos eventos do Windows
74 Dashboards
Figura C.6: Dashboard de monitorização aplicacional do ScateX#
Figura C.7: Dashboard de monitorização dos alarmes do ScateX#
Dashboards 75
Figura C.8: Dashboard geográfica de incidência de alarmes do ScateX#
76 Dashboards
Referências
[1] Inductive Automation. What is scada. https://inductiveautomation.com/static/images/basic-scada-diagram.png, último acesso a 22/11/2018.
[2] Scatex# datasheet. https://www.efacec.pt/wp-content/uploads/2016/10/CS45P1301B1_box_rounded.pdf, último acesso a 16/12/2018.
[3] Dr. G. Anjan Babu T. Giri Babu. A survey on data science technologies & big data analytics.International Journal of Advanced Research in Computer Science and Software Engineering,Fevereiro 2016.
[4] Rachel Schutt e Cathy O’Neil. Doing Data Science. O’REILLY Media, 2014.
[5] Erica Naone. https://www.technologyreview.com/s/420968/what-twitter-learns-from-all-those-tweets/.
[6] Philip Russom. Big data analytics, 2011.
[7] Jiawei Han, Micheline Kamber, e Jian Pei. Data Mining Concepts and Techniques. MorganKaufmann, 2012.
[8] Elk stack. https://d1jnx9ba8s6j9r.cloudfront.net/blog/wp-content/uploads/2017/11/2-2.png, último acesso a 17/12/2018.
[9] A practical introduction to logstash. https://www.elastic.co/assets/bltf35f0624fe18e8dd/logstash-instance-input-filter-output-plugins.png, último acesso a17/12/2018.
[10] Kibana discover page. https://www.elastic.co/guide/en/kibana/current/images/Discover-Start-Annotated.png, último acesso a 15/01/2019.
[11] Flights dashboard example. https://www.elastic.co/guide/en/kibana/current/images/Dashboard\_example.png, último acesso a 15/01/2019.
[12] Check Point Software Technologies. Critical infrastructure and scada/ics cybersecurity thre-ats, 2016.
[13] Efacec - quem somos. https://www.efacec.pt/quem-somos/, último acesso a02/12/2018.
[14] Efacec - relatório e contas 2017. https://annualreport2017.efacec.pt/relatorio/, último acesso a 03/12/2018.
77
78 REFERÊNCIAS
[15] Hormoz Kazemzadeh Tim Taylor. Integrated scada/dms/oms: Increasing distributionoperations efficiency, Março/Abril 2009. Electric Energy T&D Magazine, disponívelem https://electricenergyonline.com/energy/magazine/389/article/Integrated-SCADA-DMS-OMS-Increasing-Distribution-Operations-Efficiency.htm.
[16] Kirti. Scada: Supervisory control and data acquisition. International Journal of Engineeringand Computer Science, Vol.3, Janeiro 2014.
[17] John Tukey. The Future of Data Analysis. Institute of Mathematical Statistics, 1962.
[18] Experian Information Solutions. What is data munging? https://www.edq.com/uk/glossary/data-munging/, último acesso a 26/11/2018.
[19] Hugh J. Watson. Big data analytics: Concepts, technologies and applications. Communica-tions of the Association for Information Systems: Vol.34, Article 65., 2014.
[20] Anomaly detection example. http://amid.fish/anomaly-detection-with-k-means-clustering, último acesso a 16/01/2019.
[21] Júlia Murínová. Application log analysis. Relatório técnico, Masarykova Univerzita FakultaInformatiky, 2015.
[22] How filebeat works. https://www.elastic.co/guide/en/beats/filebeat/current/how-filebeat-works.html, último acesso a 13/12/2018.
[23] Execução do logstash. https://www.elastic.co/guide/en/logstash/6.5/pipeline.html, último acesso a 11/01/2019.
[24] Elasticsearch getting started - basic concepts. https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-concepts.html, úl-timo acesso a 12/12/2018.
[25] S.K. Goyal M.S. Divya. Elasticsearch: An advanced and quick search technique to handlevoluminous data. Compusoft, 2013.
[26] Introdução kibana. https://www.elastic.co/guide/en/kibana/current/introduction.html, último acesso a 11/01/2019.
[27] Dashboard design principles. https://www.datapine.com/blog/dashboard-design-principles-and-best-practices/, último acesso a15/01/2019.
[28] Elasticsearch hardware requirements. https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html, último acesso a 10/01/2019.
[29] Sizing hot-warm architectures. https://www.elastic.co/blog/sizing-hot-warm-architectures-for-logging-and-metrics-in-the-elasticsearch-service-on-elastic-cloud,último acesso a 12/01/2019.
[30] Sintaxe expressões regulares oniguruma. https://github.com/stedolan/jq/wiki/Docs-for-Oniguruma-Regular-Expressions-RE.txt, último acesso a15/01/2019.
REFERÊNCIAS 79
[31] Windows events to monitor. https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor, último acesso a 15/12/2018.
Top Related