William

Results 56 issues of William

Right now its hard to discover information about how a Heroic cluster is being used, requiring something like a separate QueryLog analytics setup. Some of this information is actually pretty...

type:enhancement
component:api

### The idea is to add support for user natural language support for arithmetic operations upon timeseries' E.g. a Grafana user with Queries `"A"` and `"B"` could create a new...

type:enhancement
component:core
note:accepted
[rfc]

# Problem Aggregating percentiles is a hard problem. They show the point at which a certain percentage of observed values occur. For example, the 99th percentile is the value which...

note:rfc

The row key schema for metrics backends (bigtable/cassandra) is pretty hard to find and understand without someone to explain it. We need to add the design to our docs, with...

type:documentation
note:accepted

The test should load a large amount of data into the cluster and then query it back out. I don't think we need to verify every metric; we can do...

component:tests

The Bigtable implementation is using Google's [HBase client](https://github.com/googleapis/java-bigtable-hbase). While this works ok, switching to the [Google Cloud library](https://github.com/googleapis/google-cloud-java) has some benefits. Its versioned in step with other GCP libraries, nad...

component:bigtable
type:chore

Some invalid queries can cause exceptions with 500 errors returned. For example, [a query](https://github.com/spotify/heroic/blob/master/heroic-core/src/main/java/com/spotify/heroic/http/query/QueryResource.java#L105) for metrics that [doesn't have a range](https://github.com/spotify/heroic/blob/master/heroic-core/src/main/java/com/spotify/heroic/CoreQueryManager.java#L476). This should be a 400 error instead of throwing...

type:bug
component:api

There are a fair amount of top-level config options that relate to http. It would be cleaner to have them in their own section. I think the complete list is:...

level:starter
component:core
type:chore

Right now module dependencies within Heroic are a little tangled. While not a huge issue, it makes it harder to walk through the code and harder to extract functionality. Ideally...

type:chore

BigTable is hardcoded to use [4 billion-sized partitions](https://github.com/spotify/heroic/issues/364#issuecomment-389532401) based on the timestamp. While this value can't really be changes for an existing cluster, it is something that should be configurable...

type:enhancement
component:bigtable
note:accepted