go-graphite / carbonapi Goto Github PK
View Code? Open in Web Editor NEWImplementation of graphite API (graphite-web) in golang
License: Other
Implementation of graphite API (graphite-web) in golang
License: Other
If I send a request like this for a valid metric:
/info?target=metric_name
I always get the response:
empty target
If I sent the request like this:
/info/?target=metric_name
It's working.
scale(foo.bar.baz, 1e-2)
Graphite munges timestamps to minutely resolution to increase the chance of a cache hit. It also stores the data returned by the stores so future queries on the same data can also be pulled from the cache.
Decide which of these we want to implement.
[This issue serves as a reminder / todo of interval's inteneded use.]
interval
was conceived as a mechanism where the quantile threshold can be computed on a (leading IIRC) subset to enable this funciton to more efficiently process large seriesList over large intervals.
@dgryski and I discussed that we could move it to the end as an optional parameter.
Need to figure out "only minutely resolution" for queries, <= vs <, etc.
Question: preserve graphite bug compatibility or not?
As mentioned in FB Gorilla paper add support for sorting/filtering metrics against a test metric using PPMCC
Because we maintain lots of cached http connections to carbonzipper, when that service is restarted we have a large number of (now invalid) sockets which cause failures during subsequent requests.
Work around is to restart carbonapi when carbonzipper is upgraded.
It would be nice to have it. Documentation here:
https://graphite.readthedocs.org/en/0.9.10/functions.html
It's getting unwieldy.
Right now we just return an empty metric list, instead a 500 or a json blob with a useful error message.
If you specify a missing metric as part of a larger formula, the query will fail in carbonapi but succeed in Graphite.
A simple example of this is:
data.metric1 # Exists
data.metric2 # Does not exists
diffSeries(data.metric1, data.metric2) # Fails on carbonapi
diffSeries(data.metric1, transformNull(data.metric2, 0)) # Also fails on carbonapi
I would expect the result to be data.metric1
since I'd assume that data.metric1 - [undefined]
would equal data.metric1
.
A valid use case in this situation is as followed:
# Metric layout
page.[page_name].requests
page.[page_name].errors
# The number of total successful pages served (number of requests - number of errors)
# If we automate this in any form we may hit a page that has never had an error recorded.
diffSeries(page.index_html.requests, page.index_html.errors)
The graphite front-end stores responses in memcache, meaning that subsequent requests for the same metric are much faster and don't hit the stores. This is important when lots of people are looking at the same graph or fetching the same metric.
An in-memory version is fine for starters, but we should move to externalize it so it can be shared across carbonapi instances.
There are people that would like to use with carbonapi the holtWinters functions present in the python version
On carbonzipper restart, we will have a number of failed requests (~1 / cached idle connection). We don't want to add the results of these queries to our request or find cache.
What license is this and carbonzipper under?
Our internalString grammar is too simple.
via @atomicstack
It turns out people have very poor graphite queries that fail to parse. Figuring out where the missing comma needs to go is tedious at the moment. Make this easier.
Or is there a way in there right now to multiply two series together? Can't seem to figure out a good way in grafana with the current api, I think multiplySeries() would do the job.
The function mostDeviant is missing/not implemented. The implementation of this function in the original graphite seems to be very slow.
The response to an OPTIONS request doesn't include the CORS headers that an preflight AJAX request expects[1] which makes the browser to refuse to perform the request.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests
When aggregating in a fixed time range with from/until, e.g., xxxxxx0 to xxxxxx84, aggregate by 5 seconds, there is sometimes an extra or a missing value, the array length is variable by 1.
Note that the breakage might actually be in carbonzipper or carbonserver.
In addition to code.google.com shutting down, plotinum has moved to being part of the gonum project.
This move also comes with a substantial number of breaking API changes.
Figure out the full set. Figure out which subset we want to support. Hope we don't have to fully break expression parsing in the meantime.
I try to implement functions on demand.
These functions have been demanded.
Work in progress on https://github.com/dgryski/carbonapi/tree/graph-support
( Wikipedia description: Kolmogorov–Smirnov Test )
This would allow us to test, for example, a metric against itself in the past to see if the distribution has changed. Or if two metrics have similar distributions.
Naming might be among the hardest to implement.
My votes are:
(I dislike the camelCasing standard here - but it maintains consistency)
"2" here because the 1-sample version, which essentially compares against a reference (usually normal) distribution, could also be implemented .. but there seem to be better tests for that.
At the moment, each metric for a given target is fetched in parallel, but the targets themselves are processed serially. For queries with a large number of targets, this can can unnecessary slow down.
Graphite handles both, but Go's default muxer doesn't.
time, ip, request, response size, ... ?
Sometimes the browser issues a HTTP request of the type OPTIONS when it's cross domain. I know a page that broke when using carbonapi because of this. It worked normally with the python version.
Many graphing libraries use autogenerated jsonp callback names. This breaking caching heavily, since every request URI is now different.
Name parsing code is too limited
Apparently, in a render url, the rawData flag, sometimes written as rawData=1 isn't supported. We should map it onto format=raw.
It is documented here:
http://graphite.readthedocs.org/en/latest/render_api.html
and it seems to be used by grafana:
This will throttle bulk-style requests, but not adversely affect smaller API calls from proceding.
Requires a bit more thinking to figure out if this is a problem and if this is the best solution.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.