Comments (8)
Thanks @pkittenis for the insights, I can confirm the fix solved the issue for me
from influxgraph.
What configuration is being used? Can you show graphite-api.yaml
.
There is a test for exactly this for template based configurations.
from influxgraph.
@pkittenis: Here's our graphite-api.yaml
:
finders:
- influxgraph.InfluxDBFinder
influxdb:
host: dockerhost
memcache:
host: localhost
I forgot to mention that this happens in 1.3.0 as well as 1.1.2.
For now, we've got a work-around in place on our client to just do 4 separate queries and combine the results ourselves.
Thanks!
from influxgraph.
Thanks, that narrows it down to non-template based queries. Not sure when I'll have time to look into that, glad there is a work around. Wild card query should work too as the metrics share a common path.
Could also consider moving to template based configuration as it generally performs better in influx.
from influxgraph.
This seems to happen with template based queries too. I have my template set up as:
- "mira_ce.*.timer.land.all.all.* app.host.mtype.measurement.svc.operator.stat"
But for both queries:
target=mira_ce.host1.timer.land.all.all.count &target=mira_ce.host2.timer.land.all.all.count &target=mira_ce.host1.timer.land.all.all.upper_90 &target=mira_ce.host2.timer.land.all.all.upper_90 &from=-5min&until=now&format=json&maxDataPoints=1920
and
target=host*.timer.land.all.all.count &target=host*.timer.land.all.all.upper_90 &from=-5min&until=now&format=json&maxDataPoints=1920
The data returned is in the following order:
mira_ce.host1.timer.land.all.all.count with correct values
mira_ce.host2.timer.land.all.all.count with values for mira_ce.host1.timer.land.all.all.upper_90
mira_ce.host1.timer.land.all.all.upper_90 with values for mira_ce.host2.timer.land.all.all.count
mira_ce.host2.timer.land.all.all.upper_90 with the correct values.
I also noted that when setting up my template as:
- "mira_ce.host1.timer.land.all.all.* app.host.mtype.measurement.svc.operator.stat"
- "mira_ce.host2.timer.land.all.all.* app.host.mtype.measurement.svc.operator.stat"
It works fine.
Just a side note: there are 9 different values for the stat tag and 6 different values for the host tag
from influxgraph.
Firstly and in general, prefer one target instead of multiple if there is one query that satisfies all target paths. That is the case for all the above queries, including OP (0769ecf3.*.cpu.total.*
)
Single target queries are faster. Multiple targets means multiple metrics/find
queries to gather nodes and response time will go up as number of paths increases.
target=mira_ce.hsc185.timer.land.all.all.count &target=mira_ce.hsc186.timer.land.all.all.count &target=mira_ce.hsc185.timer.land.all.all.upper_90 &target=mira_ce.hsc186.timer.land.all.all.upper_90
Can be written as target=mira_ce.*.timer.land.all.all.{count,upper_90}
or target=mira_ce.{hsc185,hsc186}.timer.land.all.all.{count,upper_90}
target=hsc18*.timer.land.all.all.count &target=hsc18*.timer.land.all.all.upper_90
can also be written as target=hsc18*.timer.land.all.all.{count,upper_90}
The above queries have correct data.
Using field in template will also have correct data, eg:
- "mira_ce.hsc185.timer.land.all.all.* app.host.mtype.measurement.svc.operator.field"
where stat
is made into a field instead of a tag. Without a named field, all field names are called value
which makes it more likely there will be conflicts like this, along with making aggregation configuration apply to all metrics regardless of path (see readme).
The issue here is order of targets was used as-is by influxgraph while influx data order is sorted. For the template case, there is a fix in place in 1.3.4 and a test to replicate the above. Thanks for raising 👍
For the OP and non-templated data I haven't been able to replicate and as far as I can see when not using templates order does not matter as data is retrieved by name.
However, as (a) a fix has been released for the template case where the issue was replicated, (b) there are at least two workarounds for OP and (c) multiple query targets where a single target with wildcards would be best doesn't make a lot of sense, I'm inclined to close it.
Can re-open if @booch can show how to replicate.
from influxgraph.
I'm no longer on the project that had the issue.
Hey @cgeers, can you try upgrading influxgraph to 1.3.4 and reverting the work-around for this, and see if it's fixed?
from influxgraph.
@booch thanks for the shoutout. This indeed had the desired effect.
from influxgraph.
Related Issues (20)
- Umm. am I an idiot?! HOT 7
- Fields for measurement appear in all metric paths that contain measurement
- 504 Gateway Timeout with Influx Cloud Integration HOT 4
- 504 Gateway Time-out w/ docker container HOT 7
- multiple target query fails with IndexError HOT 8
- Auto-conversion of tag values containing dots HOT 1
- Per metric path configurable fill parameters
- Build _manylinux_ binary wheels of releases HOT 1
- Double consolidation/aggregation of data points by graphite-api
- Use modified graphite-api package HOT 2
- Make block webapp on startup while building index behaviour configurable
- Support for multiple databases as prefix HOT 3
- Building and refreshing of index happens in every worker process putting high load on Influx HOT 1
- Improve InfluxDB response parsing performance
- Allow configurable prefix for retention policies
- TypeError: object of type 'NoneType' has no len() HOT 5
- Docker: make memcache max value configurable HOT 6
- Segfaults on building the index HOT 4
- Updates of Docker Image HOT 4
- Python 3.7 wheel build failing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from influxgraph.