Hello Sa Pham and others,

Just to throw another option in to your discussion, the monasca-agent

would also be able to monitor the cpu, memory, etc. on an amphora.

Similar to how the Ceilometer agent -> Gnocchi publishing would work, you

could then use Monasca services to track usage and set alarms. And

Monasca handles storage in a time series database (Cassandra or InfluxDB).

https://github.com/openstack/monasca-agent/blob/master/docs/Agent.md has

some details, an you can always ask questions in #openstack-monasca.

joseph

Adam Harwell wrote:

I would also note (though I'm guessing you've heard this from Michael already) that logging and metrics for internal amphora data (like Haproxy logs, agent logs, etc) is on our roadmap to officially expose via some mechanism. We discussed possible ways to do this at the last PTG, but we were just waiting on someone to have time to do a blueprint for review. If you'd like to help get support for this upstream, you're welcome (actually, highly encouraged!) to hop into our IRC channel #openstack-lbaas and we can even help you get started. Hope to see you there! --Adam Harwell (rm_work) On Mon, Nov 26, 2018, 10:19 Michael Johnson <johnsomor@gmail.com> wrote:

This is an area we have been talking about recently at the PTGs. Adding connection log offloading is on our short term road map. Someone had signed up for that, but has pivoted to work on other items. Due to that I can't say if it will make it for Stein or not. If someone is interested in picking this up, I can help point you to the documentation of our discussions at the PTGs. If not, I would expect it to land late in Stein or early in Train. As for other monitoring, CPU, etc. this is area we currently leave to the operator, but would like to do some work on. As mentioned above gnocchi appears to be a nice time-series database for metrics collection. We would need to have some design discussions on what and how to collect the data. As you mentioned, monitoring agents can be added to the amphora image at build time if the operator would like to add a local tool set. As with most parts of Octavia, we try to make things "plug-able" so that operators have a choice of tools. Both the log offloading and metrics should follow that design principle. Michael On Sun, Nov 25, 2018 at 10:49 PM Gaël THEROND <gael.therond@gmail.com> wrote:

installed on the amphora in order to get proper metrics about what’s going on with the LoadBalancer, is it fully cpu loaded? Is it using all network resources available, are the file descriptors near the initial limits? How much xxx HTTP return code the loadBalancer is facing and send those logs to an ELK or something similar.