[Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system.
Hi, After some time debugging issues in StarlingX I think it would be helpful to have a tool (if there isn't one yet) to get a diagnostic of the health of the system. Something that an user, with a limited knowledge of the system like me, can run and get the status of the different components. I would like to start writing some code for this and I have a general idea on which components to check. As an initial approach I plan to: - Check that configuration has been applied without errors: I plan to check for puppet/ansible logs and look for errors there. - Check for services up and running: Look at the output of sm-dump. - Verify the health of k8s: Checking that no pods are in Init state. - Check connectivity with additional nodes: To check that nodes booted and has network access. - Not sure yet how to check storage status beyond "ceph -s" I know this might be a naive approach and I'll appreciate any guidance to get in the correct path. Thank you in advance. -Erich
Erich, I like this idea! Regarding the tech approach, one of options could be to use tools from the community. For example, Prometheus (https://prometheus.io) looks useful for K8S monitoring. -Yong On 15/05/2019, 8:18 AM, "Cordoba Malibran, Erich" <erich.cordoba.malibran@intel.com> wrote: Hi, After some time debugging issues in StarlingX I think it would be helpful to have a tool (if there isn't one yet) to get a diagnostic of the health of the system. Something that an user, with a limited knowledge of the system like me, can run and get the status of the different components. I would like to start writing some code for this and I have a general idea on which components to check. As an initial approach I plan to: - Check that configuration has been applied without errors: I plan to check for puppet/ansible logs and look for errors there. - Check for services up and running: Look at the output of sm-dump. - Verify the health of k8s: Checking that no pods are in Init state. - Check connectivity with additional nodes: To check that nodes booted and has network access. - Not sure yet how to check storage status beyond "ceph -s" I know this might be a naive approach and I'll appreciate any guidance to get in the correct path. Thank you in advance. -Erich _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Sounds like a really good idea :-) For ceph storage, what about if we start with: a) "ceph -s" and check no WARNs showed. b) Then "ceph osd tree" and check all osds are up (no down should be shown check below example just happened to me) controller-0:~$ ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 1.74194 root storage-tier -3 1.30646 chassis group-0 -4 0.43549 host storage-0 0 ssd 0.43549 osd.0 up 1.00000 1.00000 -5 0.87097 host storage-1 1 ssd 0.43549 osd.1 up 1.00000 1.00000 2 ssd 0.43549 osd.2 up 1.00000 1.00000 -10 0.43549 chassis group-1 -9 0.43549 host storage-2 3 ssd 0.43549 osd.3 down 1.00000 1.00000 controller-0:~$ date Tue May 14 18:25:59 CDT 2019 c) and after the tool can check services running in all the nodes "ceph-mon, ceph-mgr, ceph-msgr" That will help for ceph storage diagnostic. Regards, Fernando Hernandez Gonzalez Cloud Software Engineer Avenida del Bosque #1001 Col, El Bajío Zapopan, Jalisco MX, 45019 ____________________________________ Office: +52.33.16.45.01.34 inet 86450134 -----Original Message----- From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran@intel.com] Sent: Tuesday, May 14, 2019 7:18 PM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system. Hi, After some time debugging issues in StarlingX I think it would be helpful to have a tool (if there isn't one yet) to get a diagnostic of the health of the system. Something that an user, with a limited knowledge of the system like me, can run and get the status of the different components. I would like to start writing some code for this and I have a general idea on which components to check. As an initial approach I plan to: - Check that configuration has been applied without errors: I plan to check for puppet/ansible logs and look for errors there. - Check for services up and running: Look at the output of sm-dump. - Verify the health of k8s: Checking that no pods are in Init state. - Check connectivity with additional nodes: To check that nodes booted and has network access. - Not sure yet how to check storage status beyond "ceph -s" I know this might be a naive approach and I'll appreciate any guidance to get in the correct path. Thank you in advance. -Erich _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hi Eric, nice idea! I can help with ceph status beyond "ceph -s" once you get there :) Ovidiu PS. Check "fm alarm list" first ________________________________________ From: Cordoba Malibran, Erich [erich.cordoba.malibran@intel.com] Sent: Wednesday, May 15, 2019 3:18 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system. Hi, After some time debugging issues in StarlingX I think it would be helpful to have a tool (if there isn't one yet) to get a diagnostic of the health of the system. Something that an user, with a limited knowledge of the system like me, can run and get the status of the different components. I would like to start writing some code for this and I have a general idea on which components to check. As an initial approach I plan to: - Check that configuration has been applied without errors: I plan to check for puppet/ansible logs and look for errors there. - Check for services up and running: Look at the output of sm-dump. - Verify the health of k8s: Checking that no pods are in Init state. - Check connectivity with additional nodes: To check that nodes booted and has network access. - Not sure yet how to check storage status beyond "ceph -s" I know this might be a naive approach and I'll appreciate any guidance to get in the correct path. Thank you in advance. -Erich _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Some of these tools may help. I don't know which ones are still operational. https://opendev.org/starlingx/integ/src/branch/master/tools Al -----Original Message----- From: Poncea, Ovidiu [mailto:Ovidiu.Poncea@windriver.com] Sent: Wednesday, May 15, 2019 4:58 AM To: Cordoba Malibran, Erich; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system. Hi Eric, nice idea! I can help with ceph status beyond "ceph -s" once you get there :) Ovidiu PS. Check "fm alarm list" first ________________________________________ From: Cordoba Malibran, Erich [erich.cordoba.malibran@intel.com] Sent: Wednesday, May 15, 2019 3:18 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system. Hi, After some time debugging issues in StarlingX I think it would be helpful to have a tool (if there isn't one yet) to get a diagnostic of the health of the system. Something that an user, with a limited knowledge of the system like me, can run and get the status of the different components. I would like to start writing some code for this and I have a general idea on which components to check. As an initial approach I plan to: - Check that configuration has been applied without errors: I plan to check for puppet/ansible logs and look for errors there. - Check for services up and running: Look at the output of sm-dump. - Verify the health of k8s: Checking that no pods are in Init state. - Check connectivity with additional nodes: To check that nodes booted and has network access. - Not sure yet how to check storage status beyond "ceph -s" I know this might be a naive approach and I'll appreciate any guidance to get in the correct path. Thank you in advance. -Erich _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Is a great idea Actually, I would like this to be run as part of the sanity, In my personal opinion we can start with these statements: 1) What does health means for our system? Define what is the meaning of a healthy system first 2) What components should be up and running before starting to use a starling x 3) What open source tools exist to check the health of these systems, can we just pick a minimum set of the tests from these projects Once we have a clear picture of the full system and what test is going to be performed, many of us will be very happy to add ideas on it Regards Victor Rodriguez On Wed, May 15, 2019 at 9:16 AM Bailey, Henry Albert (Al) <Al.Bailey@windriver.com> wrote:
Some of these tools may help. I don't know which ones are still operational.
https://opendev.org/starlingx/integ/src/branch/master/tools
Al
-----Original Message----- From: Poncea, Ovidiu [mailto:Ovidiu.Poncea@windriver.com] Sent: Wednesday, May 15, 2019 4:58 AM To: Cordoba Malibran, Erich; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system.
Hi Eric, nice idea! I can help with ceph status beyond "ceph -s" once you get there :)
Ovidiu
PS. Check "fm alarm list" first
________________________________________ From: Cordoba Malibran, Erich [erich.cordoba.malibran@intel.com] Sent: Wednesday, May 15, 2019 3:18 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system.
Hi,
After some time debugging issues in StarlingX I think it would be helpful to have a tool (if there isn't one yet) to get a diagnostic of the health of the system. Something that an user, with a limited knowledge of the system like me, can run and get the status of the different components.
I would like to start writing some code for this and I have a general idea on which components to check.
As an initial approach I plan to:
- Check that configuration has been applied without errors: I plan to check for puppet/ansible logs and look for errors there. - Check for services up and running: Look at the output of sm-dump. - Verify the health of k8s: Checking that no pods are in Init state. - Check connectivity with additional nodes: To check that nodes booted and has network access. - Not sure yet how to check storage status beyond "ceph -s"
I know this might be a naive approach and I'll appreciate any guidance to get in the correct path.
Thank you in advance.
-Erich
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hi Victor, The 3 questions are indeed very important! And they indeed should be asked permanently. As a starting point it's worth looking first at StarlingX own Fault Management components. You can start from there and synthesize a set of conditions, per domain, that are a minimum requirement. Currently, if memory serves me, sanity check fm alarm-list for any error condition (so we do check this) but we don't have a custom/external set of scripts to test for this (test teams should confirm this). Of course this may not be enough (what happens if fm itself is broken, or there is a bug and we don't report an error condition?). So, as a starting point check /etc/fm/events.yaml for defined error conditions then look at the collect tool for command used... then ask each domain what is the best approach. Re using external tools. I believe this may be overkill. A set of custom tests that use our own commands (e.g. parse ceph -s, ceph osd tree, ceph df) should be enough. Ovidiu ________________________________________ From: Victor Rodriguez [vm.rod25@gmail.com] Sent: Wednesday, May 15, 2019 5:38 PM To: Bailey, Henry Albert (Al) Cc: Poncea, Ovidiu; Cordoba Malibran, Erich; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system. Is a great idea Actually, I would like this to be run as part of the sanity, In my personal opinion we can start with these statements: 1) What does health means for our system? Define what is the meaning of a healthy system first 2) What components should be up and running before starting to use a starling x 3) What open source tools exist to check the health of these systems, can we just pick a minimum set of the tests from these projects Once we have a clear picture of the full system and what test is going to be performed, many of us will be very happy to add ideas on it Regards Victor Rodriguez On Wed, May 15, 2019 at 9:16 AM Bailey, Henry Albert (Al) <Al.Bailey@windriver.com> wrote:
Some of these tools may help. I don't know which ones are still operational.
https://opendev.org/starlingx/integ/src/branch/master/tools
Al
-----Original Message----- From: Poncea, Ovidiu [mailto:Ovidiu.Poncea@windriver.com] Sent: Wednesday, May 15, 2019 4:58 AM To: Cordoba Malibran, Erich; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system.
Hi Eric, nice idea! I can help with ceph status beyond "ceph -s" once you get there :)
Ovidiu
PS. Check "fm alarm list" first
________________________________________ From: Cordoba Malibran, Erich [erich.cordoba.malibran@intel.com] Sent: Wednesday, May 15, 2019 3:18 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system.
Hi,
After some time debugging issues in StarlingX I think it would be helpful to have a tool (if there isn't one yet) to get a diagnostic of the health of the system. Something that an user, with a limited knowledge of the system like me, can run and get the status of the different components.
I would like to start writing some code for this and I have a general idea on which components to check.
As an initial approach I plan to:
- Check that configuration has been applied without errors: I plan to check for puppet/ansible logs and look for errors there. - Check for services up and running: Look at the output of sm-dump. - Verify the health of k8s: Checking that no pods are in Init state. - Check connectivity with additional nodes: To check that nodes booted and has network access. - Not sure yet how to check storage status beyond "ceph -s"
I know this might be a naive approach and I'll appreciate any guidance to get in the correct path.
Thank you in advance.
-Erich
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Also note that we already have a CLI that checks some basic system health (host status, ceph health and alarms). This CLI could be extended if there were additional health items we wanted to check. [wrsroot@controller-0 ~(keystone_admin)]$ system health-query System Health: All hosts are provisioned: [OK] All hosts are unlocked/enabled: [OK] All hosts have current configurations: [OK] All hosts are patch current: [OK] Ceph Storage Healthy: [OK] No alarms: [OK] Bart -----Original Message----- From: Poncea, Ovidiu [mailto:Ovidiu.Poncea@windriver.com] Sent: May 23, 2019 5:42 AM To: Victor Rodriguez; Bailey, Henry Albert (Al) Cc: Cordoba Malibran, Erich; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system. Hi Victor, The 3 questions are indeed very important! And they indeed should be asked permanently. As a starting point it's worth looking first at StarlingX own Fault Management components. You can start from there and synthesize a set of conditions, per domain, that are a minimum requirement. Currently, if memory serves me, sanity check fm alarm-list for any error condition (so we do check this) but we don't have a custom/external set of scripts to test for this (test teams should confirm this). Of course this may not be enough (what happens if fm itself is broken, or there is a bug and we don't report an error condition?). So, as a starting point check /etc/fm/events.yaml for defined error conditions then look at the collect tool for command used... then ask each domain what is the best approach. Re using external tools. I believe this may be overkill. A set of custom tests that use our own commands (e.g. parse ceph -s, ceph osd tree, ceph df) should be enough. Ovidiu ________________________________________ From: Victor Rodriguez [vm.rod25@gmail.com] Sent: Wednesday, May 15, 2019 5:38 PM To: Bailey, Henry Albert (Al) Cc: Poncea, Ovidiu; Cordoba Malibran, Erich; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system. Is a great idea Actually, I would like this to be run as part of the sanity, In my personal opinion we can start with these statements: 1) What does health means for our system? Define what is the meaning of a healthy system first 2) What components should be up and running before starting to use a starling x 3) What open source tools exist to check the health of these systems, can we just pick a minimum set of the tests from these projects Once we have a clear picture of the full system and what test is going to be performed, many of us will be very happy to add ideas on it Regards Victor Rodriguez On Wed, May 15, 2019 at 9:16 AM Bailey, Henry Albert (Al) <Al.Bailey@windriver.com> wrote:
Some of these tools may help. I don't know which ones are still operational.
https://opendev.org/starlingx/integ/src/branch/master/tools
Al
-----Original Message----- From: Poncea, Ovidiu [mailto:Ovidiu.Poncea@windriver.com] Sent: Wednesday, May 15, 2019 4:58 AM To: Cordoba Malibran, Erich; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system.
Hi Eric, nice idea! I can help with ceph status beyond "ceph -s" once you get there :)
Ovidiu
PS. Check "fm alarm list" first
________________________________________ From: Cordoba Malibran, Erich [erich.cordoba.malibran@intel.com] Sent: Wednesday, May 15, 2019 3:18 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Diagnostic metrics of a healthy StarlingX system.
Hi,
After some time debugging issues in StarlingX I think it would be helpful to have a tool (if there isn't one yet) to get a diagnostic of the health of the system. Something that an user, with a limited knowledge of the system like me, can run and get the status of the different components.
I would like to start writing some code for this and I have a general idea on which components to check.
As an initial approach I plan to:
- Check that configuration has been applied without errors: I plan to check for puppet/ansible logs and look for errors there. - Check for services up and running: Look at the output of sm-dump. - Verify the health of k8s: Checking that no pods are in Init state. - Check connectivity with additional nodes: To check that nodes booted and has network access. - Not sure yet how to check storage status beyond "ceph -s"
I know this might be a naive approach and I'll appreciate any guidance to get in the correct path.
Thank you in advance.
-Erich
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hi Erich, We are introducing a new application (stx-monitor) that will include the Open Source Elastic (https://www.elastic.co/) set of monitoring services that may be leveraged for this activity. The Elastic components include Elasticsearch, Filebeat, Metricbeat, Logstash and Kibana. Specific monitor of key logs and metrics can be performed via Elastic. It is also K8s cluster aware, and provides monitoring of both the infrastructure and pods/containers. In general, custom system level monitoring is integrated into collectd for in-service monitoring of the system. It is responsible for raising system alarms and events through a continuous monitoring of the hosts and services. The service manager (SM) will monitor K8s master services and report on that health independently and raise alarms and events as necessary (you don't need to look at sm-dump). I recommend leveraging these existing components for any gaps that may be identified in the system level health monitoring. -Matt On 2019-05-14, 8:18 PM, "Cordoba Malibran, Erich" <erich.cordoba.malibran@intel.com> wrote: Hi, After some time debugging issues in StarlingX I think it would be helpful to have a tool (if there isn't one yet) to get a diagnostic of the health of the system. Something that an user, with a limited knowledge of the system like me, can run and get the status of the different components. I would like to start writing some code for this and I have a general idea on which components to check. As an initial approach I plan to: - Check that configuration has been applied without errors: I plan to check for puppet/ansible logs and look for errors there. - Check for services up and running: Look at the output of sm-dump. - Verify the health of k8s: Checking that no pods are in Init state. - Check connectivity with additional nodes: To check that nodes booted and has network access. - Not sure yet how to check storage status beyond "ceph -s" I know this might be a naive approach and I'll appreciate any guidance to get in the correct path. Thank you in advance. -Erich _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Thanks Erich for taking care of a healthy StarlingX System. Matt, You are bringing a very important topic which we would like to address now, with the only objective to take advantage of your experience and the work you have completed.
We are introducing a new application (stx-monitor) that will include the Open Source Elastic (https://www.elastic.co/) set of monitoring services that may be leveraged for this activity. The Elastic components include Elasticsearch, Filebeat, Metricbeat, Logstash and Kibana. Specific monitor of key logs and metrics can be performed via Elastic. It is also K8s cluster aware, and provides monitoring of both the infrastructure and pods/containers.
From our side, we are working to enable a set of tools around metrics / performance, here you have the StarlingX Metrics board: https://storyboard.openstack.org/#!/board/145 Which contains today 2 high level stories: - Footprint Metrics: CPU, Memory, Storage v0.1 + Alerts v0.3 - Performance Metrics: Include OPNFV We are focusing today in Footprint Collection System which is basically the leverage of the following existing projects: - System Server Side - Prometheus - Grafana - Cluster Node Side - Node Exporter
In general, custom system level monitoring is integrated into collectd for in- service monitoring of the system. It is responsible for raising system alarms and events through a continuous monitoring of the hosts and services. The service manager (SM) will monitor K8s master services and report on that health independently and raise alarms and events as necessary (you don't need to look at sm-dump).
I recommend leveraging these existing components for any gaps that may be identified in the system level health monitoring.
Yes, let us ask you these question and your support, based in your experience: - Are we working in parallel with 2 different approaches for the same task? - Are they 2 different tasks that at some point could be integrated together? - Can we take a look at the development of stx-monitor to understand more about its architecture? - Can we have some time in our community meetings to get more into the details of stx-monitor and find out possible collaboration activities? Best Regards StarlingX Mexico Team
Hi Abraham, See inline. On 2019-05-16, 12:10 PM, "Arce Moreno, Abraham" <abraham.arce.moreno@intel.com> wrote: Thanks Erich for taking care of a healthy StarlingX System. Matt, You are bringing a very important topic which we would like to address now, with the only objective to take advantage of your experience and the work you have completed. > We are introducing a new application (stx-monitor) that will include the Open > Source Elastic (https://www.elastic.co/) set of monitoring services that may be > leveraged for this activity. The Elastic components include Elasticsearch, > Filebeat, Metricbeat, Logstash and Kibana. Specific monitor of key logs and > metrics can be performed via Elastic. It is also K8s cluster aware, and provides > monitoring of both the infrastructure and pods/containers. From our side, we are working to enable a set of tools around metrics / performance, here you have the StarlingX Metrics board: https://storyboard.openstack.org/#!/board/145 Which contains today 2 high level stories: - Footprint Metrics: CPU, Memory, Storage v0.1 + Alerts v0.3 - Performance Metrics: Include OPNFV We are focusing today in Footprint Collection System which is basically the leverage of the following existing projects: - System Server Side - Prometheus - Grafana - Cluster Node Side - Node Exporter MP> I did see this story and some of the early commits. I mostly viewed this as being a testing and KPI activity, so I didn't feel there was overlap. They could be complimentary, but it is worth diving into the details to determine alignment. MP> The goal of the introduction of Elastic components is to handle the on-going monitoring of the infrastructure and Kubernetes cluster for the end operator (product scope). The initial requirement was to provide a long-term storage and analysis solution for host and container logs. However, Elastic has evolved to a full stack monitoring solution that can also be leveraged for metrics, security and APM, providing a unified solution for all system data collection (including the application). Having them aggregated permits more intelligent monitoring and alerting since the entire observability landscape is available. > In general, custom system level monitoring is integrated into collectd for in- > service monitoring of the system. It is responsible for raising system alarms and > events through a continuous monitoring of the hosts and services. The service > manager (SM) will monitor K8s master services and report on that health > independently and raise alarms and events as necessary (you don't need to look > at sm-dump). > > I recommend leveraging these existing components for any gaps that may be > identified in the system level health monitoring. Yes, let us ask you these question and your support, based in your experience: - Are we working in parallel with 2 different approaches for the same task? MP> I think there may be overlap, but review of the use-cases would help to determine if this is true. - Are they 2 different tasks that at some point could be integrated together? MP> Possibly, let's review the requirements and goals. - Can we take a look at the development of stx-monitor to understand more about its architecture? MP> The initial WIP review is planned to be posted later this week or early next week. The initial code is focused on providing the Elastic services required to solve the log persistence use-case. - Can we have some time in our community meetings to get more into the details of stx-monitor and find out possible collaboration activities? MP> Absolutely. I briefly introduce it at the PTG in Denver, but we didn't get an opportunity to dive into the details. Best Regards StarlingX Mexico Team
participants (9)
-
Arce Moreno, Abraham
-
Bailey, Henry Albert (Al)
-
Cordoba Malibran, Erich
-
Hernandez Gonzalez, Fernando
-
Hu, Yong
-
Peters, Matt
-
Poncea, Ovidiu
-
Victor Rodriguez
-
Wensley, Barton