Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility with graphite-web 1.1.x? #342

Open
reyjrar opened this issue Nov 24, 2021 · 1 comment
Open

Compatibility with graphite-web 1.1.x? #342

reyjrar opened this issue Nov 24, 2021 · 1 comment

Comments

@reyjrar
Copy link
Contributor

reyjrar commented Nov 24, 2021

I know Booking was stuck on graphite-web 0.9.x for a long time. Have you upgraded to 1.1.x?

I ask, because while using this fork's carbonapi/carbonzipper as the CLUSTER_SERVERS for graphite-web-1.1.8, I'm not able to make any queries with globs work.

Setup:

  • carbonapi listening on localhost:8082
  • carbonzipper listening on localhost:8081

In graphite-web's local_settings.py

# ------------------------------------------------------------------------
# Connect to the local carbonapi endpoint
# ------------------------------------------------------------------------
CLUSTER_SERVERS = ["127.0.0.1:8081"]
INTRACLUSTER_HTTPS         = False
REMOTE_FETCH_TIMEOUT       = 90.0
REMOTE_FIND_TIMEOUT        = 30.0
REMOTE_RETRY_DELAY         = 30
REMOTE_EXCLUDE_LOCAL       = False
REMOTE_STORE_MERGE_RESULTS = False

Regardless whether this is set to 8081 (zipper) or 8082 (carbonapi), I'm able to resolve find calls, and fully qualified render targets (i.e., foo.bar.baz), but any target with a glob in it is ignored.

Like if I call /render/?format=json&target=foo.bar.baz&target=foo.*.* I get back

[ 
  { 
    "target": "foo.bar.baz",
    "tags": { ... },
    "datapoints": [ .. ]
  }
]

But if I query find for foo.*.* I get all the results I expect.

I've tried this with graphite09compat: true|false in zipper and sendGlobsAsIs: true|false in api, and every permutation thereof.

@reyjrar
Copy link
Contributor Author

reyjrar commented Nov 30, 2021

As a work-around, I spun up the python graphite-web on the data nodes and pointed CLUSTER_SERVERS to that.. it's significantly slower than using carbonapi/carbonzipper but it works and only humans are using the graphite-web end points.. I cut-over all our automation to using carbonapi.

I can also confirm that this fork can handle 10-20 times the concurrent query load as the mainline carbonapi 0.15.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant