| *** Tom_ has joined #openstack-monasca | 00:18 | |
| *** tovin07_ has joined #openstack-monasca | 00:56 | |
| *** Tom_ has quit IRC | 01:06 | |
| *** Tom_ has joined #openstack-monasca | 02:27 | |
| *** Tom__ has joined #openstack-monasca | 02:29 | |
| *** Tom_ has quit IRC | 02:31 | |
| *** bobh has joined #openstack-monasca | 02:37 | |
| *** bobh has quit IRC | 02:41 | |
| *** Tom__ has quit IRC | 03:44 | |
| *** Tom has joined #openstack-monasca | 03:46 | |
| *** Tom has quit IRC | 04:06 | |
| *** Tom has joined #openstack-monasca | 05:13 | |
| *** Tom_ has joined #openstack-monasca | 05:58 | |
| *** Tom has quit IRC | 06:00 | |
| *** pcaruana has joined #openstack-monasca | 06:45 | |
| *** tobiajo has joined #openstack-monasca | 06:51 | |
| *** jgu_ has quit IRC | 06:52 | |
| *** Tom_ has quit IRC | 07:01 | |
| *** Tom_ has joined #openstack-monasca | 07:04 | |
| openstackgerrit | Witold Bedyk proposed openstack/monasca-specs master: Define repository structure https://review.openstack.org/504108 | 07:37 |
|---|---|---|
| openstackgerrit | Witold Bedyk proposed openstack/monasca-specs master: Define repository structure https://review.openstack.org/504108 | 07:40 |
| *** Tom_ has quit IRC | 08:07 | |
| *** efoley has joined #openstack-monasca | 08:15 | |
| openstackgerrit | Witold Bedyk proposed openstack/monasca-specs master: Define repository structure https://review.openstack.org/504108 | 08:28 |
| *** tobiajo has quit IRC | 09:31 | |
| *** tobiajo has joined #openstack-monasca | 09:42 | |
| *** tovin07_ has quit IRC | 10:14 | |
| *** Tom_ has joined #openstack-monasca | 11:09 | |
| *** Tom_ has quit IRC | 11:13 | |
| *** bobh has joined #openstack-monasca | 12:26 | |
| *** Dobroslaw has quit IRC | 12:29 | |
| openstackgerrit | Johannes Grassler proposed openstack/monasca-log-api master: Fix WSGI application https://review.openstack.org/504400 | 12:29 |
| *** bobh has quit IRC | 12:34 | |
| *** Tom has joined #openstack-monasca | 13:25 | |
| *** Tom has quit IRC | 13:30 | |
| *** efoley_ has joined #openstack-monasca | 13:34 | |
| *** efoley has quit IRC | 13:34 | |
| openstackgerrit | Merged openstack/monasca-common master: Updated from global requirements https://review.openstack.org/502673 | 13:53 |
| openstackgerrit | Merged openstack/monasca-statsd master: Updated from global requirements https://review.openstack.org/502676 | 13:54 |
| openstackgerrit | Merged openstack/monasca-ui master: Updated from global requirements https://review.openstack.org/502781 | 13:55 |
| openstackgerrit | Merged openstack/monasca-persister master: Updated from global requirements https://review.openstack.org/502675 | 13:55 |
| *** efoley_ has quit IRC | 14:07 | |
| *** efoley_ has joined #openstack-monasca | 14:08 | |
| *** rbrndt has joined #openstack-monasca | 14:24 | |
| openstackgerrit | Merged openstack/monasca-log-api master: Updated from global requirements https://review.openstack.org/502674 | 14:34 |
| *** jgu_ has joined #openstack-monasca | 14:36 | |
| iurygregory | Hello people, i have monasca-agent monitoring instances in my hosts, sometimes it happens that the agent doesent collect any metrics for some instances, im using the libvirt agent to monitor. Anyone know the possible problem? I saw in logs sometimes "negative value" there is any way to avoid this? | 14:42 |
| *** vishwana_ has quit IRC | 14:54 | |
| *** tobiajo has quit IRC | 14:59 | |
| rbrndt | iurygregory, if you have some logs, you might want to post a bug/story about that in storyboard. I've never seen it before. | 15:14 |
| openstackgerrit | Ryan Brandt proposed openstack/monasca-agent master: Add some new metrics and update some old ones https://review.openstack.org/497488 | 15:19 |
| *** pcaruana has quit IRC | 15:24 | |
| jgu_ | rbrndt : influxdb python and Java Mon api have different behavior in the merge metrics option . Python api delegates the limti to influxdb which returns limit # of data points for every time series (i.e., metric). So you get limit * # of matching unique metrics measurements back. in the Java api, it gets all the measurements for all found metrics then filter by offset and limti in the Java api as you mentioned. But it is just | 15:59 |
| jgu_ | picking the first limit number of measurements when looping through the time series one by one. That is not by order of time stamps among all measurements in all series. It will depletes one time series first before go to next time series. I am not sure either one is matching the expectation that you described. thoughts? | 15:59 |
| rbrndt | The java is the one I expected. Are you sure the python one works that way? The two api's should have the same approach | 16:00 |
| jgu_ | yes, I checked the influxdb doc. The python api is not doing much data process on the influxdb query result. | 16:02 |
| rbrndt | well, I guess I stand corrected then. There is a major difference between the java and python APIs | 16:04 |
| jgu_ | which on eis more correct? :-). Let me get it straight in terms of expected behavior. let's say the query found two metrics A and B, A has 200 points, and B has 200 points. with the limit = 200, we will get the 200 points of A, and zero points from B even though B's points may even have earlier time stamp? | 16:06 |
| rbrndt | That was the expected. I don't know if it's desired behavior long term, since it was mostly an effort to match the functional characteristics of two very different databases | 16:07 |
| rbrndt | The python way is much easier in influx and we don't use vertica really anymore | 16:07 |
| jgu_ | yes, the python is very straightforward, but it has its own issue. it returns the same # (limit) of measurements for each metric, so the time stamp of last point can be different among time series. So what the user is gonna do trying to find the next batch of points? I mean the new offset has to be uniform but the last result set ends at different time for different emtrics? | 16:11 |
| rbrndt | Generally, I would expect it to be used with time restrictions, rather than offset | 16:15 |
| rbrndt | but really the issue here is how to prevent the user from requesting a HUGE number of points | 16:15 |
| rbrndt | and possible blowing up their api with the overflow | 16:15 |
| rbrndt | the real trick with the python way is that we can't predict the number of points that will be returned, since we don't know up front how many series will be returns | 16:16 |
| jgu_ | agree with you on the issue with python impl. | 16:18 |
| jgu_ | does vertica sort the query results by time stamp across all metrics then limit? | 16:18 |
| rbrndt | It's by series then time, then applies the limit | 16:19 |
| rbrndt | of course, vertica is sql, so it's pretty variable | 16:19 |
| jgu_ | and vertica offset is just timestamp? I noticed the java influxdb uses a combination of timestamp and index in offset to facilitate find next batch. | 16:20 |
| rbrndt | vertica offset is series id then time | 16:21 |
| rbrndt | influx doesn't have the series ID that vertica uses | 16:21 |
| jgu_ | yeah influx java impl uses an index id in offset -- index is how far down in the result set it needs to skip (assume the index is where the last query ends) | 16:23 |
| jgu_ | now my head is going to explode :-) | 16:24 |
| jgu_ | btw, monasca api doc needs to refresh... it says the offset is just timestamp | 16:24 |
| rbrndt | it's even more of a mess than I thought | 16:24 |
| rbrndt | Yeah, but docs also say it is an opaque value, so no one should rely on it being a timestamp | 16:25 |
| jgu_ | which doc are you referring to? I was reading at the api.md in the github. | 16:26 |
| rbrndt | I'd have to look to find it again, but I thought it was in there | 16:26 |
| rbrndt | up near the top | 16:27 |
| rbrndt | wait, do you mean the api-spec.md? or something else? | 16:28 |
| jgu_ | ok, in the terminology section. I was reading the section "list measurements" it says "offset (timestamp, optional)" | 16:28 |
| rbrndt | ok, well that certainly is inconsistent | 16:29 |
| jgu_ | lol, my head is going to explode :-). anyhow, seems that the Java behavior is expected, "correct" behavior. and acceptable to expand the offset to include a series id or index id to facilitate paging through the measurement list. | 16:31 |
| rbrndt | Yeah, thats about where we stand | 16:32 |
| jgu_ | thank you Ryan for setting me straight on the expectation! | 16:35 |
| jgu_ | have we considered sorting all measurements by timestamp across the multiple metrics and page through just by tempstamp offset? It seems to make more sense in the use case you described about vm migration, and two time series are really the same time series with two different host names? | 16:37 |
| rbrndt | Displaying that result would be harder to use and read | 16:39 |
| rbrndt | assuming it isn't a part of the use-case you mentioned | 16:39 |
| jgu_ | you mean if the two metrics are really unrelated | 16:39 |
| jgu_ | ot single time series | 16:40 |
| rbrndt | well, more in the case of group_by where we want to separate out the metrics | 16:40 |
| rbrndt | In the case of merge, the user never sees which time series are involved | 16:40 |
| jgu_ | in the case of "merge" option, you expect merge into one time series? | 16:42 |
| jgu_ | I may be wrog, I don't see the influxdb code python or Java does that | 16:43 |
| rbrndt | it will appear as such to the caller | 16:43 |
| rbrndt | It does, it may do it in influx but it definitely comes back as a single series | 16:44 |
| jgu_ | okay may be in the rest api layer | 16:44 |
| jgu_ | yes the measurement resource class does the pagination there. I stand corrected ... even the python code does the pagination in the rest resource level. The difference is the java influxdb queries the db without limit but does the our own way of limit in the influx repo java class. the python impl sends the limit to influxdb query (less data to pull) then delegates everything in the result set to the mon rest resource framework | 17:01 |
| jgu_ | to do the pagination (creating unnecessarily more objects). It is more consistent than I led you to believe :-). | 17:01 |
| rbrndt | Whew, I was worried I'd been wrong for months there | 17:03 |
| jgu_ | didn't mean to do that to you on Friday :-). Is there any hook for using db pagination directly? Cassandra allows us to store a pagination string. | 17:09 |
| jgu_ | i mean a string for their pagination state | 17:09 |
| *** efoley_ has quit IRC | 17:10 | |
| rbrndt | I don't know influx well enough anymore to say. I did most of my work in the pre 1.0 stages | 17:11 |
| *** rbrndt has quit IRC | 17:24 | |
| *** rbrndt has joined #openstack-monasca | 18:18 | |
| *** ddyer has quit IRC | 18:22 | |
| *** ddyer has joined #openstack-monasca | 18:23 | |
| *** joadavis1 has quit IRC | 19:10 | |
| *** ddyer has quit IRC | 19:43 | |
| *** joadavis has joined #openstack-monasca | 20:04 | |
| *** Tom_ has joined #openstack-monasca | 20:08 | |
| *** Tom_ has quit IRC | 20:12 | |
| *** joadavis has quit IRC | 20:16 | |
| *** joadavis has joined #openstack-monasca | 20:27 | |
| openstackgerrit | Witold Bedyk proposed openstack/monasca-api master: Add Contributor Guide https://review.openstack.org/498804 | 20:53 |
| joadavis | witek: I just checked the etherpad for the mid cycle next week and I see the Ceilosca/Ceilometer item on both Wednesday and Thursday. I assume we want it only on one day. :) Do we want to keep the discussion to a specific amount of time? | 21:31 |
| *** guimaluf has joined #openstack-monasca | 21:50 | |
| *** efoley has joined #openstack-monasca | 21:53 | |
| *** rbrndt has quit IRC | 22:47 | |
| *** efoley has quit IRC | 23:02 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!