[openstack-dev] [vitrage] [nova] VM Heartbeat / Healthcheck Monitoring

lương hữu tuấn tuantuluong at gmail.com
Wed May 10 14:14:28 UTC 2017


It is well-written here in OPNFV artifact:

http://artifacts.opnfv.org/availability/review/33475/development_overview/index.html

Br,

Tuan/Nokia

On Wed, May 10, 2017 at 3:49 PM, Matt Riedemann <mriedemos at gmail.com> wrote:

> 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-request at lists.openstack.org?subject:unsubscrib
>> e
>> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170510/99d4d3d2/attachment.html>


More information about the OpenStack-dev mailing list