Hi Aaron, Doctors, all, These topics looks very important indeed when looking to reach Telco requirements for fault management as a whole. Totally +1 for this discussion.
Doctor has not yet addressed the actual monitoring part that much and would be nice to get that in shape. That is also complicated and there has been a lack of resources to give more thought to this. For example “HW specific configuration” needed to catch HW events. Monitoring agent could totally have us fast fault information and that would be a great thing to have. Doctor requirement is currently time consumed from fault detected to alarm caught by consumer (user/tenant/project). Anyhow user point of view it is essential to have < 50ms for as many faults as possible from fault occurrence to alarm caught by consumer. This means detection have to be as fast as convenient without wasting too much resources. Surely framework on top of that also need to be optimized and having as straight path to have alarm to consumer as possible. I have been working a bit with that, but it is not that easy to optimize with current Doctor architecture. Br, Tomi From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Aaron Smith Sent: Tuesday, January 24, 2017 7:12 PM To: opnfv-tech-discuss@lists.opnfv.org Subject: [opnfv-tech-discuss] [doctor] Further discussion of NFVI / APP monitoring Hi, Would there be interest in a separate meeting to discussion what an "ideal" monitoring framework might look like. Topics might include: - Polling vs Event capture - Platform independent monitor agent - Network Interfaces - Kernel events - VM / Container monitoring - Common bus for Events / Telemetry / Config - Common Object model - Agent configuration - Performance - <<50ms This would be an informal brainstorming activity with more emphasis on concepts than existing projects (unless necessary). Thoughts? Aaron -- Aaron Smith | Senior Principal Software Engineer NFV Partner Engineering Red Hat aasm...@redhat.com<mailto:aasm...@redhat.com> Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com<http://redhat.com>
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
