Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC
Hi MohanKumar, Thanks for the reply. Is the design part for the “OAM Operation Manager for SFC” done? What is the approach being used to monitor the SFC? If the design is already done, I would like to contribute in implementing it. Please provide your comments. Thanks and Regards, Rajeev From: Mohan Kumar [mailto:nmohankumar1...@gmail.com] Sent: Friday, July 28, 2017 1:32 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Cc: Rajeev Satyanarayana (MFG & Tech) <rajeev.satyanaray...@wipro.com> Subject: ** Newsletter/Marketing email** Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC ** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution** Hi Rajeev, The Chain Monitoring is the missing piece in networking-sfc . Vikram and myself were discussed to introduce "SFC Manager" [1] (basically OAM tool ) few cycle before. It'll continuously monitor an existing SFC chain, when any SF VM goes down or any packet drop. It'll trigger alert and capture corresponding logs . But we haven't started any implementation on this. Feel free to discuss with community, IMO this feature will be great addition to networking-sfc [1] https://bugs.launchpad.net/networking-sfc/+bug/1513368 <https://clicktime.symantec.com/a/1/oyvdp2ozE_Pe2sKTM51_kVGy1ODcQYS_L50v9C-IyKo=?d=OZb6_jQ3JlDcR2AISJ1S1yWSl9wA-da9R6WweBZh8-1xFSm7MxSA9a4SYoOw7U5fTTE8TgbqfudjFvUJGjDkrnVR8mWytf4M3eN4AD71w1P20EuGgVBYqX2e4XU1RLCLPuDzEem8Pvb7DaVjt_oEU15hkt_CfSTEUKh58nKrnbrfyy9rDd5XIZscEY5gl3pbQ5CoXChMOmfq68AE2WCT9a01j26KThkBjxPJbv7zay4R1vkxAxl07G4VZ26lvhz-CLOS6io8hJGjhaWkAJN_i67NzGOXXjipBTRt860ew1Njxrns15bG_IJ58TV9RRw-EMQ0HNftqhXlA28RRbuLvqfjJmivRjKHrMXjeKah9B7TvU1XTn7fAwJvIbcHA8zejHC_MUDNNpDMJQ7RfC6A0v5hl8qhiG2UCM-axWeSN5erVE652SbORAGMTScANtK7PL02O8Da9-W30pJr9e8haxOIGYVgHA%3D%3D=https%3A%2F%2Fbugs.launchpad.net%2Fnetworking-sfc%2F%2Bbug%2F1513368> IRC: #networking-sfc Weekly Meeting: https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting<https://clicktime.symantec.com/a/1/6dNKaHpOkefxWGyCJEXAIE-cQCSPzu0gOs-V_OdWGO4=?d=OZb6_jQ3JlDcR2AISJ1S1yWSl9wA-da9R6WweBZh8-1xFSm7MxSA9a4SYoOw7U5fTTE8TgbqfudjFvUJGjDkrnVR8mWytf4M3eN4AD71w1P20EuGgVBYqX2e4XU1RLCLPuDzEem8Pvb7DaVjt_oEU15hkt_CfSTEUKh58nKrnbrfyy9rDd5XIZscEY5gl3pbQ5CoXChMOmfq68AE2WCT9a01j26KThkBjxPJbv7zay4R1vkxAxl07G4VZ26lvhz-CLOS6io8hJGjhaWkAJN_i67NzGOXXjipBTRt860ew1Njxrns15bG_IJ58TV9RRw-EMQ0HNftqhXlA28RRbuLvqfjJmivRjKHrMXjeKah9B7TvU1XTn7fAwJvIbcHA8zejHC_MUDNNpDMJQ7RfC6A0v5hl8qhiG2UCM-axWeSN5erVE652SbORAGMTScANtK7PL02O8Da9-W30pJr9e8haxOIGYVgHA%3D%3D=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FMeetings%2FServiceFunctionChainingMeeting> Thanks., Mohankumar.N On Thu, Jul 27, 2017 at 11:30 AM, rajeev.satyanaray...@wipro.com<mailto:rajeev.satyanaray...@wipro.com> <rajeev.satyanaray...@wipro.com<mailto:rajeev.satyanaray...@wipro.com>> wrote: Hi Igor/Cathy/Gord, Sorry for the delay in replying. As part of monitoring the SFC, I think maintaining the details of “Number of flows assigned to a given SFC”, “Number of packets/bytes dropped/hit due to the policies at each Service Function entry/exit points or for the entire SFC” would be good to start with. I feel based on some of these details, an operator can know how much the virtual switch is loaded and take a call on whether to add a new SFC, or it could even help during debugging which service function has exactly caused the disruption to SFC. As a first step, I think it would be good to add meters to provide “number of packets/bytes hit due to policy at the ingress and egress of the entire SFC” and to realize that, we would need to add specific pollsters. We can use neutron_client API to fetch the ingress and egress port details and fetch the corresponding flows for those specific ports(also get flow_infos from flow_classifier and then use them to dump_flows matching those flow_infos) and fetch the no.of packets hit due to policy from them. I have just mentioned my idea on this. Can I please know your opinion on this and provide your comments? Thanks and Regards, Rajeev. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com<http://www.wipro.com> __
[openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC
Hi Igor/Cathy/Gord, Sorry for the delay in replying. As part of monitoring the SFC, I think maintaining the details of "Number of flows assigned to a given SFC", "Number of packets/bytes dropped/hit due to the policies at each Service Function entry/exit points or for the entire SFC" would be good to start with. I feel based on some of these details, an operator can know how much the virtual switch is loaded and take a call on whether to add a new SFC, or it could even help during debugging which service function has exactly caused the disruption to SFC. As a first step, I think it would be good to add meters to provide "number of packets/bytes hit due to policy at the ingress and egress of the entire SFC" and to realize that, we would need to add specific pollsters. We can use neutron_client API to fetch the ingress and egress port details and fetch the corresponding flows for those specific ports(also get flow_infos from flow_classifier and then use them to dump_flows matching those flow_infos) and fetch the no.of packets hit due to policy from them. I have just mentioned my idea on this. Can I please know your opinion on this and provide your comments? Thanks and Regards, Rajeev. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com __ 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
[openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC
Hi All, I am interested to know if there are any meters available for monitoring SFC through ceilometer, like no.of flows associated with an SFC or packets in/out for an SFC etc? If they are available, please let me know how to configure and use them. If not, are there any plans of providing support to them in coming releases? Thanking you, Regards, Rajeev. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com __ 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
[openstack-dev] [collectd-ceilometer-plugin] dpdkstat related meters are not displayed under "ceilometer meter-list"
Hi All, I am working on bringing up Newton version of Openstack on 3 Nodes(Controller, Compute and Network). I am using OVS with DPDK on my Compute Node and to get dpdk port related statistics on my Ceilometer, I have configured collectd to use DPDKSTAT plugin and also enabled the collectd-ceilometer-plugin as mentioned in their docs. I have used mongodb as the database for ceilometer service. I have observed that "ceilometer meter-list" doesn't display any of the dpdkstat related meters, but when I issue "ceilometer sample-list -m dpdkstat.if_rx_packets" I get a table populated with resource-id and other details. I am not sure why "ceilometer meter-list" is not able to list my new dpdkstat meters. Please find below my setup details: Node 1: Controller All the controller based services are running (mysqld, rabbitmq-server, mongodb, keystone, glance, dashboard, ceilometer-[notification/central/collector]) Node 2: Compute All compute based services are running (nova-compute, ovs-agent, openstack-ceilometer-compute.service) When I enable csv based write plugin in collectd, I could see all the csv files getting generated for all the dpdkstat counters and it also has data in it. One observation is, I see that that dpdkstat counters like rx_size_1024_to_max_packets etc are getting populated as resource-id for the meter dpdkstat.if_rx_packets. Is this behavior correct? Or should rx_size_1024_to_max_packets be considered as meter? After enabling both collectd-ceilometer-plugin, should I modify or update the meters.yaml or pipeline.yaml to specify dpdkstat related meters? Thanks in advance! Regards, Rajeev. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com __ 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
