========================== #opendaylight-meeting: tws ========================== Meeting started by tbachman at 17:01:36 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-meeting/2015/tws/opendaylight-meeting-tws.2015-07-13-17.01.log.html . Meeting summary --------------- * SDN SDK Presentation (tbachman, 17:01:50) * The SDN SDK group had a creation review, and the TSC had a lot of questions around the project’s scope. This TWS was meant to provide a forum to allow the SDN SDK group to better address/present the scope of their project (tbachman, 17:06:01) * The focus of the Centinal project is only for the logging functionality of ODL (tbachman, 17:06:47) * The ODL logging mechanism is very expensive — multiple logs generated from various ODL features, modules, and tools (tbachman, 17:07:17) * Engineers are expected to have ODL know-how to figure out seach queries in logs to extract intelligent data (tbachman, 17:07:36) * The isn’t a real-time tracking of logs (per user defined rules) for specific error conditions or diagnosis (tbachman, 17:07:59) * expcetation of a classid monitoring user-interface to track set rules/threshold alerts log/data (tbachman, 17:08:30) * The project uses the MD-SAL, Log source, DB/Presistence, cassandra/Hbase from ODL (tbachman, 17:10:08) * it Adds a web interface with dashboard, alerts, streams, log search and analytics, diagnostics, and health (tbachman, 17:10:37) * There will also be NB APIs (tbachman, 17:10:51) * Prem_ has submitted a similar topic for the ODL summit, and is interested in possibly collaborating with this effort (tbachman, 17:11:31) * Prem_ proposal includes a log analyzer in order to correlate logs between various modules as a first step (tbachman, 17:12:02) * dbainbri asks why a standard off-the-shelf library/tools (e.g. ELK) insn’t used instead (tbachman, 17:12:32) * Prem_ says that for their proposal is to use the log stack for available analyzers (tbachman, 17:12:51) * sumit_kapoor says they’re doing more analysis and features that aren’t provided by current analyzers — things that are ODL specific (tbachman, 17:13:20) * dbainbri asks if they’re driving all logs through the MD-SAL (tbachman, 17:13:55) * sumit_kapoor says only the rules are going into the ODL data store (tbachman, 17:14:17) * dbainbri says sounds more like an analyzer (tbachman, 17:15:34) * dbainbri asks if he has to update his log4j code to support this (tbachman, 17:17:36) * sumit_kapoor says you don’t have to update your code (tbachman, 17:17:46) * sumit_kapoor says there’s a syslog appender that sends the messages in real time to their syslog (tbachman, 17:18:45) * sumit_kapoor says they offer more analytics/diagnostics before persisting (tbachman, 17:19:27) * dbainbri says he sees two different things — log collection and real-time analytics and batch processing (e.g. SPARK), and wouldn’t want the MD-SAL in the way of eitehr of those (tbachman, 17:21:05) * sumit_kapoor says this is a framework for the performance data as well. (tbachman, 17:23:50) * dbainbri is concerned about multiple projects going after the same capability (tbachman, 17:25:21) * moizer asks if they’ve considered using Flume + Kibana for the same purpose? (tbachman, 17:29:17) * Prem_ says their presentation would be around that (tbachman, 17:32:02) * dbainbri says right now he’s less concerned about technology and more concerned about a common philosophy about stream processing (tbachman, 17:32:30) * dbainbri also includes a common direction in batch processing as well. (dbainbri, 17:32:51) * The project provides a streams service, which has a mechanism to route messages into categories in real time while they are processed like stream for audit logs; rule configuration include message, level, source, etc.; streams are generated by the graylog server as per user-defined rules; event handler module handles streams from graylog server and persist them into centinel model (tbachman, 17:35:26) * Log alerts service allows alerts generated based on specific event matching in real-time; alert condition types can be message count, field value, and field string value (tbachman, 17:36:00) * Search and Analyze service supports a search query language; a time range for search can be specified; visualization includes histogram (tbachman, 17:36:40) * Prem_ asks dbainbri if a unified log analyzer that analyzes SDN Apps + ODL + SDN switch would be beneficial? (tbachman, 17:40:09) * dbainbri asks how log analysis is different from analyzing any other data stream — argues that it isn’t, so that ODL needs a way to analyze stream data and combine data from multiple sources in that analysis (tbachman, 17:42:31) * dbainbri says this normalizes log data (as well as other data) in some way, and then people can write different analytics against the data (tbachman, 17:43:01) * dbainbri thinks log data is just yet another event (dbainbri, 17:43:10) * dbainbri also thinks ODL logs are often clogged with "system or debug" logs as opposed to messages that mean something from the "control" aspect. (dbainbri, 17:43:51) * dbainbri continues to think that this means not all logs have to end in a generated event that needs to be analyzed . (dbainbri, 17:44:23) * Prem_ agrees it does become another stream of data provided it is processed and normalized (tbachman, 17:44:30) * alagalah asks if there’s a new project proposal for Centinel? (tbachman, 17:44:47) * sumit_kapoor says this is a new project proposal — it’s one of the features of the original SDN SDK proposal (tbachman, 17:45:08) * alagalah asks if they’re using the persistence project — not introducing a new dependency on the data store (tbachman, 17:46:07) * sumit_kapoor says they’re using the persistence project (tbachman, 17:46:14) * dbainbri asks if alarms are going through the persistence layer (tbachman, 17:46:47) * sumit_kapoor says yes (tbachman, 17:47:01) * dbainbri asks if the ODL persistence project is capable of handling an alarm storm? (tbachman, 17:47:47) * sumit_kapoor says if these things happen, the alarm storm would be handled before persisting (tbachman, 17:48:08) * colindixon asks if the project decomposes into 3 pieces; log gathering; log analysis framework; analysis programs (tbachman, 17:52:12) * colindixon says it’s more work to create rules that make meaningful alarms than it is to create a rules engine — asks if they will be contributing rules themselves (tbachman, 17:54:12) * sumit_kapoor says they will specify some preconfigured rules — e.g. for the openflowplugin (tbachman, 17:54:26) * sumit_kapoor says ODL users can creat emore rules (tbachman, 17:54:42) * Prem_ asks if the rules can be derived from the state diagrams of any apps/module? (tbachman, 17:54:56) * sumit_kapoor says they will also provide some preconfigured rules for SFC (tbachman, 17:55:12) * dbainbri: need to separate technology from common best practice philosophy (dbainbri, 18:04:26) Meeting ended at 18:05:13 UTC. People present (lines said) --------------------------- * tbachman (62) * dbainbri (18) * odl_meetbot (6) * Prem_ (6) * abhijitkumbhare (3) * icbts (2) * alagalah (2) * colindixon (1) * sumit_kapoor (1) Generated by `MeetBot`_ 0.1.4