13:00:21 #startmeeting monasca 13:00:21 Meeting started Tue Feb 4 13:00:21 2020 UTC and is due to finish in 60 minutes. The chair is witek. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:25 The meeting name has been set to 'monasca' 13:00:33 hello everyone 13:00:40 Hello 13:00:41 hi 13:00:48 Hello 13:00:51 hi 13:00:53 hi 13:01:03 hi, strong Fujitsu today :) 13:01:08 :) 13:01:16 nice 13:01:27 the agenda for today 13:01:32 https://etherpad.openstack.org/p/monasca-team-meeting-agenda 13:01:58 please add items if applicable 13:02:17 #topic ujson not maintained 13:02:59 it was raised in openstack-discuss that ujson library is causing problems when deploying Ceilometer in Kolla 13:03:23 the library hasn't been maintained for a long time already 13:04:04 and we should consider replacing it with some alternative 13:04:35 I've included related links into etherpad 13:04:43 https://github.com/esnme/ultrajson/issues/343 13:04:51 I imagine that ujson was used in order to improve performance, instead of regular json or simplejson ? 13:05:33 yes, we're using it for serialization and wanted to improve performance 13:06:57 from what I recall, deserializing of Kafka messages was one of the items identified in persister to consume most of the time 13:07:27 Dobroslaw: was that you doing the profiling? 13:07:39 yes 13:08:14 if I remember correctly then main problem with speed was kafka lib 13:08:42 right, deserialization second? 13:09:40 I think yes 13:10:06 but my memory is hazy about that 13:11:22 could you try to dig out the results? 13:12:10 so what alternatives do we have? 13:12:27 orjson? 13:12:39 we could go with json from stdlib, simplejson 13:12:50 yes, orjson 13:13:01 there is also rapidjson 13:13:03 https://artem.krylysov.com/blog/2015/09/29/benchmark-python-json-libraries/ 13:13:13 pleas cehck this benchmark 13:13:50 it looks like simplejson is faster then ujson in python3 13:14:06 what is actually relevant for us is to know, how fast our messages are getting deserialized 13:14:11 but this benchmark is quite old ( 2016/08/13) 13:14:33 it's all about this line of code I guess: 13:14:38 https://opendev.org/openstack/monasca-persister/src/branch/master/monasca_persister/repositories/utils.py#L21 13:15:39 so running a quick comparison check should be easy 13:17:16 there is also another aspect: orjson and rapidjson are not included in global requirements 13:19:46 would someone like to do a comparison check of alternatives for our use case? 13:21:03 Do you think results using Devstack can be used? 13:21:12 yes 13:21:44 I mean, messages from DevStack 13:22:05 I will try 13:22:31 but measuring only deserialization as done in persister 13:24:05 that would be cool, thanks Martin 13:24:17 I will contact in case of more details 13:24:50 thanks, any other comments on that topic? 13:25:47 #topic OpenDev + PTG 13:26:03 continuing the topic from last week 13:26:45 TC encourages devs and ops to shape the content of the event 13:26:50 http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012239.html 13:27:14 is anyone interested in traveling and contributing? 13:27:47 monitoring session could be interesting to many 13:30:37 I am interested. So, I will ask my manager. 13:30:42 +1 13:30:47 +2 13:31:53 #AOB 13:31:58 #topic AOB 13:32:25 I've attended FOSDEM this weekend 13:32:54 on Sunday there was a complete track on Monitoring and Observability 13:32:54 https://fosdem.org/2020/schedule/track/monitoring_and_observability/ 13:33:40 many Prometheus and Grafana related talks 13:34:18 I think we should better integrate with Prometheus in future 13:34:32 not necessarily as the fixed model for Monasca 13:34:45 but to enable integrating it 13:35:08 so that operators can build own alerting rules and existing community dashboards 13:35:09 SOCM 10 ? :D 13:35:21 there is no SOC 10 13:35:26 and won't be 13:35:30 just kidding 13:36:35 if we want to get any traction in the project we have to integrate with what people are using 13:37:23 and the simplest integration we could do is to use the Prometheus remote read 13:38:31 it doesn't change the general architecture and enables ops to use both Monasca and Prometheus 13:38:59 what is required is a minor change in time series message format 13:40:20 would be good with backward compatibility so that old messages are working fine 13:41:37 we could have a configuration option to control that, or implement a migration script 13:42:07 one presentation I wanted to point to was from Rob Skillington 13:42:17 about M3DB 13:43:05 it's a scalable TSDB querying much faster then Prometheus 13:43:18 looks nice 13:44:04 dougsz was mentioning this DB in the past as one of potential options for us 13:44:48 also here, they integrate seamlessly with Prometheus with remote read/write mechanism 13:45:36 one barrier for us, they only have a Go client 13:46:23 but I chatted shortly with Rob and they seem to have an undocumented support for InfluxDB line protocol 13:46:34 oh, that's interesting 13:46:53 meaning that on the persister side we could probably just replace it with InfluxDB 13:47:20 still, we'd have to implement the query API 13:47:38 I want to follow up with Rob and ask more details 13:48:17 here the link to presentation: 13:48:24 https://fosdem.org/2020/schedule/event/m3db/ 13:49:16 do we have any other topics? 13:51:01 if not, thanks for joining 13:51:12 thanks 13:51:22 thanks Martin for volunteering on benchmarking 13:51:28 np 13:51:39 see you next week, bye 13:51:47 see you 13:51:49 #endmeeting