15:00:39 <witek> #startmeeting monasca
15:00:43 <openstack> Meeting started Wed Dec 19 15:00:39 2018 UTC and is due to finish in 60 minutes.  The chair is witek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:46 <openstack> The meeting name has been set to 'monasca'
15:01:36 <witek> hi joadavis
15:02:18 <witek> today the first time in #openstack-monasca
15:03:04 <joadavis> =-O
15:03:27 <witek> just posted a short reminder in the old channel
15:03:45 <witek> agenda for today:
15:03:49 <witek> https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:03:56 <dougsz> hey all
15:04:06 <witek> hi dougsz
15:04:20 <witek> #topic Vitrage integration
15:04:55 <witek> we had some discussion with Ifat and Joseph about the integration with Vitrage
15:05:17 <witek> and how the monitored resources (or alarms) should be identified in Vitrage
15:05:33 <witek> here the email list discussion:
15:05:35 <witek> http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000806.html
15:06:37 <joadavis> I didn't reply to his last email, but have been trying to dig up any alarm details that may be helpful.  I haven't explored the topic deeply before
15:06:53 <joadavis> I think what he proposed is on the right track
15:07:22 <joadavis> as I understand it, metrics from vms and metrics from hosts have different metric names, which may help
15:08:11 <witek> in the change from Bartosz (POC from Berlin) he uses custom dimensions: resource_type and resource_id
15:08:55 <witek> do you think we could use such schema for all metrics?
15:08:59 <joadavis> some metrics have the resource_id already, but I don't think any have type
15:09:31 <joadavis> I think you could infer the type from the metric itself
15:09:54 <witek> most of the checks have the possibility to configure own `custom` dimensions per check instance
15:10:11 <witek> but that's e.g. not the case for libvirt
15:11:14 <joadavis> Is there a resource_type in vitrage they are trying to match with?
15:11:45 <witek> let me check their docu
15:12:43 <witek> https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html
15:13:02 <witek> they define entity type, but I guess it's not what is meant
15:13:39 <witek> as resource_type I understand e.g: node, instance, disc, interface
15:14:13 <joadavis> that is the impression I got too. That it would be used to differentiate hosts from vms, etc
15:15:43 <witek> OK, and how should we treat e.g http_check?
15:15:57 <witek> that's pretty generic
15:16:27 <joadavis> true, good point.  That is probably most generic
15:16:59 <witek> I think it's difficult to create a global mapping for metric of that type
15:18:00 <witek> similarly process
15:18:33 <joadavis> http_alive_status does have service field.  For a vm it adds component and resource_id, but for a host those fields are missing
15:19:49 <joadavis> do you think we could add a resource_type to all metrics? it might be useful, just don't know how much work that would be
15:20:58 <joadavis> not sure how we would define a resource_id for a process, as it is not an OpenStack resource in all cases
15:21:32 <joadavis> Similar questions come up for aggregated metrics.  If the metric used to trigger the alarm is aggregated across all VMs, then we don't have a resource_id
15:23:00 <joadavis> That might be a use case we should discuss with them
15:23:22 <witek> I have joined the self-healing meeting today morning (EU time)
15:23:38 <witek> and we had a longer discussion with Ifat
15:23:46 <joadavis> cool
15:24:08 <witek> she wants to propose a spec and start to define use cases we should cover
15:24:50 <joadavis> That sounds like a good idea. A starting set of use cases could keep us from digging too deep
15:25:06 <witek> there is another self-heeling meeting today in 2 hours, I guess
15:25:56 <witek> I have to think over this mapping thing, still don't have a clear picture on it
15:26:26 <witek> here the logs from today's meeting:
15:26:28 <witek> http://eavesdrop.openstack.org/meetings/self_healing/2018/self_healing.2018-12-19-09.02.log.html
15:26:43 <joadavis> thanks
15:27:29 <joadavis> If nothing comes up, I may join in at 9am PST
15:27:44 <witek> thanks, I'm not sure myself yet
15:27:53 <witek> should we move on?
15:28:05 <joadavis> Speaking of SIGs, have you seen anything about the auto-scaling sig starting meetings?
15:28:13 <witek> no
15:28:20 <joadavis> I think it has been quiet for a week
15:28:37 <joadavis> I don't think it needs meetings yet, but I would like to start contributing to their use cases too
15:29:16 <joadavis> yes, next topic. :)
15:29:23 <witek> yes, we could publish our documentation there
15:29:36 <witek> #topic spaces in dimension names
15:30:05 <joadavis> yes, I saw Matthias' comments on the bug this morning
15:30:27 <joadavis> I think it may be an acceptable workaround, but will check with the team and let support comment
15:30:46 <witek> so, the reported case is about deployment using collecting libvirt metrics
15:31:13 <witek> the dimensions zone and tenant_name are set by the plugin
15:31:20 <witek> and include spaces
15:31:53 <witek> are in general dimensions values with spaces something we should support?
15:33:00 <joadavis> fair question
15:33:37 <joadavis> looking at the designs and documentation, I think there was an assumption that fields like zone and tenant_name would be unique identifiers and not long descriptions
15:33:54 <joadavis> unique, human parsable identifiers. :)
15:34:11 <witek> apparently API accepts it and it's not explicitly forbidden in the API ref
15:34:40 <joadavis> I'm not sure how in this case someone set values iwth spaces without causing trouble at the cli or api, but you are right that it appears it accepted it
15:35:10 <joadavis> in general, it does seem like we want dimensions to be flexible and there may be other fields that we would want to support spaces in
15:35:58 <joadavis> I haven't looked in to the persister code for influxdb. How hard would it be to add escaping or something to support spaces?
15:35:58 <witek> could you check if Cassandra persister supports it?
15:36:15 <joadavis> I asked the team, but I don't think James is online yet. :)
15:36:35 <witek> InfluxDB has syntax for this, should not be very difficult
15:36:37 <joadavis> I'll follow up witg them today
15:37:03 <witek> the problem is more our matrix Python/Java + InfluxDB/Cassandra
15:37:12 <witek> thanks joadavis
15:37:14 <joadavis> yes, I was surprised it was a problem for influx
15:38:08 <witek> OK, let's follow up on this after holidays
15:38:17 <joadavis> will do
15:38:35 <witek> #topic events listener
15:39:26 <witek> dougsz has added small comments
15:39:28 <joadavis> Spec looks approved, though Doug had a couple good nits. I think we can merge and I'll do a quick follow-up to fix the nits
15:39:42 <joadavis> unless you want me to fix it first. :)
15:39:43 <witek> OK, let's do this
15:39:55 <witek> it's up to you :)
15:39:56 <dougsz> Sounds good to me
15:40:24 <witek> just gave W+1
15:40:31 <joadavis> thanks
15:40:39 <witek> :)
15:40:52 <witek> great job, thanks joadavis and Ashwin
15:41:08 <dougsz> yep, thanks guys, will be a really nice feature
15:41:57 <witek> thanks dougsz for constructive remarks and discussion
15:42:25 <dougsz> I certainly didn't do any of the hard work :)
15:42:38 <joadavis> I was finally watching the RH presentation on monitoring with Prometheus from Berlin summit. It is interesting when they come to some of the same conclusions, and have a similar event listener component. :)
15:42:56 <witek> :)
15:43:57 <witek> getting back to this presentation, I think we could also consider adding support for collectd
15:44:28 <joadavis> I've been pondering what a good solution for container monitoring will be.  collectd may be a good choice
15:44:51 <dougsz> cadvisor is also a nice one for containers
15:44:52 <joadavis> I'm still slightly clueless though. :)
15:45:20 <joadavis> yes... was it ceilometer that was using cAdvisor?
15:45:51 <dougsz> hmm, pass
15:46:33 <openstackgerrit> Merged openstack/monasca-specs master: Monasca Events Publishing Spec  https://review.openstack.org/583803
15:46:40 <dougsz> witek: we would have a Monasca Agent plugin to harvest collectd metrics?
15:47:04 <dougsz> Or were you thinking about something that submits them directly to the API?
15:47:11 <witek> I rather thought about monasca plugin for collectd
15:47:27 <dougsz> Ah, I see.
15:47:42 <witek> I think it's main advantage is that it's lightweight and performant
15:48:12 <joadavis> I'm all for light weight. on of the reoccurring concerns when deploying monasca is that it is too heavy
15:48:31 <dougsz> And here we are talking about adding Events support to it :)
15:48:40 <witek> :)
15:49:10 <dougsz> At least it is modular though, so the collector can always be turned off in favour of collect or something.
15:49:29 <dougsz> The statsd part is actually very useful to us.
15:49:34 <joadavis> modular is a good thing
15:49:44 <dougsz> +1
15:51:04 <witek> if we don't have anything else for today, I would like to wish you Merry Christmas
15:51:18 <witek> and have a good start in the new year!
15:51:18 <joadavis> It may be worth defining a 'monasca light stack' for smaller deployments.
15:51:27 <joadavis> Merry Christmas!
15:51:53 <dougsz> Thanks, Merry Christmas to you all too
15:52:02 <dougsz> Hope you get some quality time off...
15:52:38 <joadavis> I'm looking forward to time with the kids
15:53:00 <joadavis> I need to line up some interactive science experiments with them. :)
15:54:04 <witek> tomorrow we have a new additional meeting in the morning
15:54:29 <witek> and then a break until Jan, 2nd
15:54:44 <witek> thank you guys and bye bye
15:55:06 <witek> #endmeeting