> > How is this different from the watchdog action flavor extra spec / image > property which already exists? >
Yes, understand it is similar to the virtual hardware watchdog of QEMU/KVM. ( I referred to this at end of original mail, with ref: https://libvirt.org/formatdomain.html#elementsWatchdog ) However, the VM Heartbeat / Health-check Monitoring · provides a higher-level (i.e. application-level) heartbeating o i.e. if the Heartbeat requests are being answered by the Application running within the VM · provides more than just heartbeating, as the Application can use it to trigger a variety of audits, · provides a mechanism for the Application within the VM to report a Health Status / Info back to the Host / Cloud, · provides notification of the Heartbeat / Health-check status to higher-level cloud entities thru Vitrage o e.g. VM-Heartbeat-Monitor - to - Vitrage - (EventAlarm) - Aodh - ... - VNF-Manager - (StateChange) - Nova - ... - VNF Manager Greg. From: Matt Riedemann <mriede...@gmail.com> Reply-To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Date: Wednesday, May 10, 2017 at 9:49 AM To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [vitrage] [nova] VM Heartbeat / Healthcheck Monitoring On 5/9/2017 1:11 PM, Waines, Greg wrote: I am looking for guidance on where to propose some “_VM Heartbeat / Health-check Monitoring_” functionality that I would like to contribute to openstack. Briefly, “_VM Heartbeat / Health-check Monitoring_” · is optionally enabled thru a Nova flavor extra-spec, · is a service that runs on an OpenStack Compute Node, · it sends periodic Heartbeat / Health-check Challenge Requests to a VM over a virtio-serial-device setup between the Compute Node and the VM thru QEMU, · on loss of heartbeat or a failed health check status will result in fault event, against the VM, being reported to Vitrage thru its data-source API. Where should I contribute this functionality ? · put it ALL in Vitrage ... both the monitoring and the data-source reporting ? · put the monitoring in Nova, and just the data source reporting in Vitrage ? · other ? Greg. p.s. other info ... Benefits of “VM Heartbeat / Health-check Monitoring” · monitors health of OS and Applications INSIDE the VM o i.e. even just a simple Ack of the Heartbeat would validate that the OS is running, IO mechanisms (sockets, etc) are working and processes are getting scheduled · health-check status reporting can trigger and report on either high-level or detailed application-specific audits within the VM, · the simple virtio-serial-device interface thru QEMU is UP very early in VM life cycle and is virtually _always up_ o i.e. its available for reporting issues virtually all the time, o ... compared to reporting issues over Tenant Network to a remote VNFManager which relies on Ethernet and IP Networking within the VM itself and then any provider network and adjacent routers around the compute nodes ... · uses a simple “Line-Delimited JSON” Format over virtio serial device ( http://www.linux-kvm.org/page/Virtio-serial_API ) o simple to implement protocol inside VM, in pretty much any language o ( although would provide reference implementation ) · provides more thorough instance monitoring than libvirt’s emulated hardware watchdog ( https://libvirt.org/formatdomain.html#elementsWatchdog ) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev How is this different from the watchdog action flavor extra spec / image property which already exists? -- Thanks, Matt __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
