Necesidades Operativas para la gestión de infraestructura mediante el análisis de logs

1. LOG MANAGEMENT
SDN

2. www.linkedin.com/in/cabreramartin/es
slideshare.net/martinjcabrera
ING. MARTIN J. CABRERA
Profesional en Telecomunicaciones y Tecnología de la Información
Perito informático Forense -Poder Judicial de la Nación
MasterBusiness Administration(MBA) –Universidad CEMA.
Ingeniero en Sistemas de Información –Universidad Abierta Interamericana.
AREAS DE TRABAJO Y RESEARCH
Networkingy Sistemas de Información.
Gestión de Servicios tecnológicos.
Sistema de Gestión de Seguridad (SGSI).
Desarrollo de planes de inversión para proyectos tecnológicos.
Informática Forense.
Delitos Informáticos.
Actualmente colaboro en la publicación de artículos en portales de divulgación tecnológica del sector. Poseo experiencia en presentaciones de proyectos tecnológicas para compañías privadas y presentaciones de tendencias tecnológicas en eventos locales de la industria.
#WHOAMI

4. PROBLEMÁTICA ACTUAL
LOG MANAGEMENT ≠ EVENT MANAGEMENT
oEstatico
oMúltiples formatos de logs
oGrandes volúmenes de información = Limite de historial
oLimitaciones de almacenamiento
oAnálisis de logs= No hay una forma fácil de buscar
oSistemas propietarios = Logs propietarios
oDiferentes tipos de logsson tratados iguales:
oError logs
oTransactionlogs
oTrace logs
oWarningslogs
oDebugslogs
oEscalable –Redundante -Seguro

5. NECESIDADES DE LOGGING ACTUALES
oMultipleInput / MultipleOutput
oCentralización de logs
oTroubleshootingissues
oEventos de red
oSistemas de gestión
oPosibilidad de ejecutar acciones en base a eventos
oSecurity
oAnálisis de logspara la detección de comportamientos sospechosos
oDetección de intrusiones –Malware activity
oUnautorizedresourseusage
oMonitoring
oMonitoreo de utilización de recursos
oCapacityplanning
oEstadisticas/Metricasde utilizacionde recursos
oDevelopersLogging
oNuevos formatos: xml, json, tweet
oIntegración con sistemas de gestión operativos
oDashboard: métricas –estadísticas –panel de control
LOGGING

6. ARQUITECTURA
SYSLOGS
Servers, routers, firewalls…
ACCESSLOG
Apache webservers
LOG EVENT
Java webapplications(JVM)
BROKER
APP
APP
APP
APP
FORWARDER
INDEXER
VISUALIZE
Search& Storage
Real time reports, dashboards, plots,
alerts
grok, mutate, multiline, csv, anonymize, etc
lumberjack
SSL
LOGGING
PLUGING

7. BENCHMARKING
Logstash
http://www.logstash.net
graphite
http://graphite.wikidot.com/
Fluentd
www.fluentd.org/
Beaver
github.com/josegonzalez/beaver
Logstash-Forwarder
github.com/elasticsearch/logstash-forwarder
Woodchuck
github.com/danryan/woodchuck
SYSLOG
http://rsyslog.com
Heka
http://hekad.readthedocs.org/en/latest/
Collectd
https://collectd.org/
ElasticSearch
http://www.elasticsearch.com/
SaaS
Cloud log Management service
Loggly
https://www.loggly.com/
Papertrail
https://papertrailapp.com/
Splunk
http://es.splunk.com/
LogEntries
https://logentries.com/
HTTP-URL-monitoring
Pingdom
https://www.pingdom.com
Cloud MonitoringService
DataDog
https://www.datadoghq.com/
Circonus
http://www.circonus.com/
Librato
https://metrics.librato.com/
Dashboad
Grafana
http://grafana.org/
Kivana
http://www.elasticsearch.org/overview/kibana/
heroku
http://dashingdemo.herokuapp.com/sample
Atlasboard
http://atlasboard.bitbucket.org/
Gdashhttp://www.devco.net/archives/2011/10/08/gdash-graphite-dashboard.php
Giraffehttp://kenhub.github.io/giraffe/#dashboard=Demo&timeFrame=1d
OPEN SOURCE

8. VCENTER

9. DASHBOARD -GRAFANA

10. DASHBOARD -KIVANA

11. LOGSTASH
https://github.com/elasticsearch/logstash/doc
Herramienta para la recolección, procesamiento y envió de logs.
Permite la implementación de un sistema redundante y distribuido mediante la utilización de módulos independientes y redundantes entre si.
Collects logs
Parses logs
Stores logs
Indexes logs
Busqueday filtradode logs
Inputs: Server logs, snmp events, windows event, iptables, Routers syslogs, databases, Netflow, rsyslogsvia tcp/udp
+60 codecs
Filters: csv, geoip, grok, mutate, etc
Outputs: elasticsearch, email, exec, mongodb, rabbitmq, redis, etc
Each must have at least an input, filter, or output stanza
from syslog and normalize duration to milliseconds
http://www.logstash.net/

12. LOG PLUGINS
# withaninput plugin:
# youcan alsouse thiscodecwithanoutput.
input {
file {
codec=> collectd{
authfile=> ... # string(optional)
nan_handling=> ... # string, oneof ["change_value", "warn", "drop"] (optional), default: "change_value"
nan_tag=> ... # string(optional), default: "_collectdNaN"
nan_value=> ... # number(optional), default: 0
prune_intervals=> ... # boolean(optional), default: true
security_level=> ... # string, oneof ["None", "Sign", "Encrypt"] (optional), default: "None"
typesdb=> ... # array(optional)
}
}
}
https://github.com/elasticsearch/logstash/blob/v1.4.2/lib/logstash/codecs/collectd.rb

13. ELASTICSEARCH
ElasticSearches una herramienta opensourcede búsqueda y análisis de información en tiempo real.
Sistema redundante
Alta disponibilidad
Multi-tenancy
http://www.elasticsearch.com/

14. GROK
Es una herramienta de análisis semántico que permite el uso de expresiones regulares para el `parseo´, filtrado y posterior tratamiento de información.
raw log:
Aug 2 13:29:58 pixl-ram sshd[1631]: Accepted publickeyfor ram from 192.168.30.1 port 49864 ssh2
non parsed:
{“text“: “Aug 2 13:29:58 pixl-ram sshd[1631]: Accepted publickeyfor ram from 192.168.30.1 port 49864 ssh2”}
Ejemplode grokenlogstash
{“text“: “Aug 2 13:29:58 pixl-ram sshd[1631]: Accepted publickeyfor ram from 192.168.30.1 port 49864 ssh2”,
“time”: “Aug 2 13:29:58”, “host”: “pixl-ram”, ”process”: “sshd”, “pid”: 1631}
Busqueda: time > “Aug 1 2014”
HerramientaOnline de parseo:
http://grokdebug.herokuapp.com/
http://grokconstructor.appspot.com/

15. KIBANA
Herramienta de análisis y visualización de información procesada y guardada en elasticsearch
HTML + JavaScript
./bin/logstashweb -a ADDRESS -p PORT

16. COLLECTD
Collect, es una herramienta que permite capturar ciertas estadísticas del sistema y vuelca estos datos en una gráfica.
Una de su principal característica es que a diferencia de otros sistemas similares collectno utiliza crontabpara colectar estos datos, sino que cuenta con su propio demonio para dicho propósito.
http://collectd.org/

17. ANEXOS

18. RRD is great, and initially Graphite did use RRD for storage. Over time though, we ran into several issues inherent to RRD's design.
1.RRD can't take updates for a timestamp prior to its most recent update. So for example, if you miss an update for some reason you have no simple way of back-filling your RRD file by telling rrdtoolto apply an update to the past. Whisper does not have this limitation, and this makes importing historical data into Graphite way wayeasier.
2.At the time whisper was written, RRD did not support compacting multiple updates into a single operation. This feature is critical to Graphite's scalability.
3.RRD doesn't like irregular updates. If you update an RRD but don't follow up another update soon, your original update will be lost. This is the straw that broke the camel's back, since Graphite is used for various operational metrics, some of which do not occur regularly (randomly occuringerrors for instance) we started to notice that Graphite sometimes wouldn't display data points which we knew existed because we'd received alarms on them from other tools. The problem turned out to be that RRD was dropping the data points because they were irregular. Whisper had to be written to ensure that all data was reliably stored and accessible.
PORQUE USAR RRD COMO DB?

19. Martin Cabrera
mc@mcabrera.com