O uso da Stack ELK no Diagnóstico de Problemas …...Problemas em Sistemas SCADA em Produção Miguel António T. da Costa Leite Mestrado Integrado em Engenharia Eletrotécnica e

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.


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.


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]


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.


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].


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]


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;


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;


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.


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.


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.


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.


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.


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


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


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


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



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.


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


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.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:]] | \:$’


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.


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.


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.


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


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



>> sudo rpm --install logstash-6.4.2.rpm

3. Para configurar o Logstash a inicializar automaticamente:


>> sudo /bin/systemctl enable logstash.service


>> sudo systemctl start logstash.service

>> sudo systemctl restart logstash.service

>> sudo systemctl stop logstash.service

A.0.3 Kibana



>> sudo rpm --install kibana-6.4.2-x86_64.rpm

3. Para configurar a Kibana a inicializar automaticamente:


>> sudo /bin/systemctl enable kibana.service


>> 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



>> 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

https://inductiveautomation.com/static/images/basic-scada-diagram.png

https://inductiveautomation.com/static/images/basic-scada-diagram.png

https://www.efacec.pt/wp-content/uploads/2016/10/CS45P1301B1_box_rounded.pdf

https://www.efacec.pt/wp-content/uploads/2016/10/CS45P1301B1_box_rounded.pdf

https://www.technologyreview.com/s/420968/what-twitter-learns-from-all-those-tweets/

https://www.technologyreview.com/s/420968/what-twitter-learns-from-all-those-tweets/

https://d1jnx9ba8s6j9r.cloudfront.net/blog/wp-content/uploads/2017/11/2-2.png

https://d1jnx9ba8s6j9r.cloudfront.net/blog/wp-content/uploads/2017/11/2-2.png

https://www.elastic.co/assets/bltf35f0624fe18e8dd/logstash-instance-input-filter-output-plugins.png



https://www.elastic.co/guide/en/kibana/current/images/Discover-Start-Annotated.png

https://www.elastic.co/guide/en/kibana/current/images/Discover-Start-Annotated.png

https://www.elastic.co/guide/en/kibana/current/images/Dashboard\ _example.png

https://www.elastic.co/guide/en/kibana/current/images/Dashboard\ _example.png

https://www.efacec.pt/quem-somos/

https://annualreport2017.efacec.pt/relatorio/

https://annualreport2017.efacec.pt/relatorio/

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.

https://electricenergyonline.com/energy/magazine/389/article/Integrated-SCADA-DMS-OMS-Increasing-Distribution-Operations-Efficiency.htm



https://www.edq.com/uk/glossary/data-munging/

https://www.edq.com/uk/glossary/data-munging/

http://amid.fish/anomaly-detection-with-k-means-clustering

http://amid.fish/anomaly-detection-with-k-means-clustering

https://www.elastic.co/guide/en/beats/filebeat/current/how-filebeat-works.html

https://www.elastic.co/guide/en/beats/filebeat/current/how-filebeat-works.html

https://www.elastic.co/guide/en/logstash/6.5/pipeline.html

https://www.elastic.co/guide/en/logstash/6.5/pipeline.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-concepts.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-concepts.html

https://www.elastic.co/guide/en/kibana/current/introduction.html

https://www.elastic.co/guide/en/kibana/current/introduction.html

https://www.datapine.com/blog/dashboard-design-principles-and-best-practices/

https://www.datapine.com/blog/dashboard-design-principles-and-best-practices/

https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html

https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html

https://www.elastic.co/blog/sizing-hot-warm-architectures-for-logging-and-metrics-in-the-elasticsearch-service-on-elastic-cloud

https://www.elastic.co/blog/sizing-hot-warm-architectures-for-logging-and-metrics-in-the-elasticsearch-service-on-elastic-cloud

https://github.com/stedolan/jq/wiki/Docs-for-Oniguruma-Regular-Expressions-RE.txt

https://github.com/stedolan/jq/wiki/Docs-for-Oniguruma-Regular-Expressions-RE.txt

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.

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor



Documents

O uso da Stack ELK no Diagnóstico de Problemas …...Problemas em Sistemas SCADA em Produção Miguel António T. da Costa Leite Mestrado Integrado em Engenharia Eletrotécnica e