piotrp
Repos
11
Followers
13
Following
1

Events

Build with Avro/Schema-Registry support

Currently when trying to decode Avro using Schema Registry I get:

% ERROR: This build of kcat lacks Avro/Schema-Registry support

Created at 5 hours ago
issue comment
Invalid dashboard UID in the request error on custom home dashboard

Then isn't this also a design issue of this functionality? If this dashboard must be already existing, then configuration should only point to dashboard's UID, not file path. Or in other words, default_home_dashboard_path should be deprecated and a new default_home_dashboard_uid should be introduced, because current method of setting default home dashboard makes little sense.

Created at 6 days ago
issue comment
Invalid dashboard UID in the request error on custom home dashboard

I'm using absolute path:

[dashboards]
default_home_dashboard_path = /var/lib/grafana/home.json
Created at 2 weeks ago
opened issue
Invalid dashboard UID in the request error on custom home dashboard

What happened:

I set custom home dashboard using default_home_dashboard_path, now when entering Grafana I see an error in UI: "Invalid dashboard UID in the request" obraz

What you expected to happen:

No error

How to reproduce it (as minimally and precisely as possible):

docker-compose.yml

version: '3.8'
services:
  grafana:
    image: grafana/grafana:9.1.2
    volumes:
      - ./Home.json:/tmp/Home.json
    ports:
      - "3000:3000"
    environment:
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_DASHBOARDS_DEFAULT_HOME_DASHBOARD_PATH=/tmp/Home.json

Home.json - empty dashboard from the same Grafana version, with Annotations & Alerts removed for simplicity (the same happens when I leave it)

{
  "annotations": {
    "list": []
  },
  "editable": true,
  "fiscalYearStartMonth": 0,
  "graphTooltip": 0,
  "id": 1,
  "links": [],
  "liveNow": false,
  "panels": [],
  "schemaVersion": 37,
  "style": "dark",
  "tags": [],
  "templating": {
    "list": []
  },
  "time": {
    "from": "now-6h",
    "to": "now"
  },
  "timepicker": {},
  "timezone": "",
  "title": "Custom Home",
  "uid": "JqqE7eWVk",
  "version": 2,
  "weekStart": ""
}

Environment:

  • Grafana version: 9.1.2
  • Data source type & version: -
  • OS Grafana is installed on: Docker (grafana:9.1.2)
  • User OS & Browser: Windows, Firefox 104.0.1
  • Grafana plugins: -
  • Others: -
Created at 3 weeks ago

add tests with server in different timezone

Created at 1 month ago
issue comment
Metricbeat module beat-xpack leads to incorrect cluster in Stack Monitoring

I don't have time to test this now, but only one of my three pipelines is using the elasticsearch output, the remaining two use a custom one.

Created at 1 month ago
Timestamp read from database is treated as if it was in JVM timezone

No, the legacy driver worked correctly. I stumbled upon this issue when I tried upgrading and my JDBC code using getTimestamp failed.

I created a test case at https://github.com/piotrp/clickhouse-driver-issue-1048, where you can see that the same test passes when run with legacy driver, and fails with the new one. I also added a test demonstrating that round trip with setTimestamp/getTimesatamp doesn't work correctly. This should be runnable under Java 17 by:

docker-compose up -d
mvn --fail-at-end test

Thanks for this pointer, for now I worked around this by using getObject(.., Instant.class). Fortunately I'm using hand-crafted row mappers, so it was easy to do.

Created at 1 month ago
piotrp create branch master
Created at 1 month ago
piotrp create repository
Created at 1 month ago
Timestamp read from database is treated as if it was in JVM timezone

I believe the issue is in the way getTimestamp works. Value is read correctly from database, as 2021-08-13 11:00:00 at UTC: obraz

but here:

https://github.com/ClickHouse/clickhouse-jdbc/blob/27f8951cdc380bf1799f76efc21fc377fc6d5981/clickhouse-jdbc/src/main/java/com/clickhouse/jdbc/ClickHouseResultSet.java#L626-L634

it's read into dt as LocalDateTime(2021-08-13T11:00) (tz is null here, but both possible code paths give the same result). Then it's copied into defaultCalendar which is at JVM's time zone.

Created at 1 month ago
Timestamp read from database is treated as if it was in JVM timezone

When reading a DateTime value I get a timestamp that is shifted back by my JVM timezone offset.

Server is in UTC, JVM in Europe/Warsaw (UTC+2). When I try to read a DateTime value 2021-08-13T11:00:00Z I get 2021-08-13T09:00:00Z.

Is this driver bug or am I doing something wrong?

package test;

import com.clickhouse.jdbc.ClickHouseConnection;
import com.clickhouse.jdbc.ClickHouseDataSource;
import com.clickhouse.jdbc.ClickHouseDriver;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

import java.sql.Connection;
import java.sql.SQLException;
import java.time.Instant;
import java.util.Optional;
import java.util.TimeZone;

public class TimeTests {
    private final static String URL = "jdbc:clickhouse://localhost:18123/";
    private final static String USERNAME = "default";
    private final static String PASSWORD = "";

    static {
        System.out.println(ClickHouseDriver.class.getPackage().getImplementationVersion());
        TimeZone.setDefault(TimeZone.getTimeZone("Europe/Warsaw"));
    }

    @Test
    void testReading() throws SQLException {
        var dataSource = new ClickHouseDataSource(URL);
        try (var conn = dataSource.getConnection(USERNAME, PASSWORD)) {
            prepareTestTable(conn);

            execSql("INSERT INTO dates(d) VALUES (toDateTime(toUnixTimestamp('2021-08-13 11:00:00', 'UTC'), 'UTC'))", conn);

            try (var stmt = conn.createStatement()) {
                var rs = stmt.executeQuery("SELECT formatDateTime(d, '%F %T'), d FROM dates");
                Assertions.assertTrue(rs.next());
                Assertions.assertEquals("2021-08-13 11:00:00", rs.getString(1));
                var ts = rs.getTimestamp(2);
                // Assertion below fails with:
                // Expected :2021-08-13T11:00:00Z
                // Actual   :2021-08-13T09:00:00Z
                // looks like UTC date from server was treated as if it was in JVM TZ (Europe/Warsaw = UTC+2)
                Assertions.assertEquals(Instant.parse("2021-08-13T11:00:00Z"), ts.toInstant());
            }
        }
    }

    void prepareTestTable(ClickHouseConnection conn) throws SQLException {
        Assertions.assertEquals(TimeZone.getTimeZone("UTC"), conn.getServerTimeZone());
        Assertions.assertEquals(TimeZone.getTimeZone("Europe/Warsaw"), conn.getJvmTimeZone());
        Assertions.assertEquals(Optional.empty(), conn.getEffectiveTimeZone());

        execSql("DROP TABLE IF EXISTS dates", conn);
        execSql("CREATE TABLE dates (d DateTime) ENGINE=Memory", conn);
    }

    void execSql(String sql, Connection conn) throws SQLException {
        try (var stmt = conn.createStatement()) {
            stmt.execute(sql);
        }
    }

}
Created at 1 month ago
closed issue
Inconsistent ordering in code completion popup

Describe the bug Ordering on list of available attributes is inconsistent: unfiltered list is sorted, while applying filtering breaks that.

Example: obraz

NK version: 2020-08-17-11-29-preview_0_2_fixes-78f37a7fdfab01a20c604c3ccbbdb672c2e17c02-SNAPSHOT Browser: Firefox 80

Created at 1 month ago
ngx.exit() closes the connection. so benchmark tools with socket reuse (keep alive) do not work

You can increase the number of available sockets by changing net.ipv4.ip_local_port_range, and allow for socket reuse by setting net.ipv4.tcp_tw_reuse = 1 (both are sysctl parameters). Also, keep in mind that unless you set -H "Connection: close" in wrk nginx will reuse connections due to keepalive_requests.

Created at 1 month ago
opened issue
Some top grid lines are missing when min value of y axis is set

Description

Using axis․y․min may result in missing grid lines: obraz

I would expect each tick on y axis to have its own line, but depending source values some lines may be missing.

Steps to check or reproduce

JSFiddle: https://jsfiddle.net/vc0hux95/

bb.generate({
  data: {
    columns: [
	    ["data1", 130, 340, 200, 500, 250, 350]
    ],
    type: "line"
  },
  axis: {
    y: {
      min: 0
    }
  },
  grid: {
    y: {
      show: true
    }
  },
  bindto: "#lineChart"
});
Created at 1 month ago
issue comment
Empty datum name breaks chart generation

Thanks, that's certainly a better workaround, but even then an empty string shouldn't completely break the API.

Created at 1 month ago
issue comment
Empty datum name breaks chart generation

I'm displaying values coming from server logs, e.g. counts of HTTP Referer header. Empty string is not a sane value, but it may appear, and I hit this error when testing various edge cases.

I fully agree that this is not something that should be present in data. My main issue here is that a valid string input breaks chart completely (empty string) or causes degraded user experience (space).

Created at 1 month ago
opened issue
Empty datum name breaks chart generation

Description

Bug 1: using empty string as datum name breaks chart generation ("Uncaught TypeError: box is undefined"). Bug 2: using space character (0x20) as datum name makes legend item almost unclickable: obraz

Using empty name makes little sense, but when using external data it may appear. Currently I'm guarding against it by replacing empty string with non-breaking space (\u00a0).

Steps to check or reproduce

JSFiddle: https://jsfiddle.net/tdnp2hfv/

Running:

bb.generate({
  data: {
    columns: [
	["data1", 30, 200, 100, 400, 150, 250],
	["", 50, 20, 10, 40, 15, 25]
    ],
    type: "line"
  },
  bindto: "#lineChart"
});

Results in:

Uncaught TypeError: box is undefined updatePositions https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:7522 updateLegendElement https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:7688 each https://d3js.org/d3.v7.min.js:2 updateLegendElement https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:7687 updateLegend https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:7128 initLegend https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:7098 initWithData https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:11270 initToRender https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:11095 runFn https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:4071 convertData https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:4362 initToRender https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:11092 init https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:11054 Chart https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:13125 generate https://naver.github.io/billboard.js/release/3.5.1/dist/billboard.js:26013 https://fiddle.jshell.net/_display/?editor_console=true:114

Created at 1 month ago
Created at 2 months ago
opened issue
Cannot see in UI that alert is suppressed

When alert instance is suppressed by a matching Silence rule it can be seen only in Silences tab, under that rule. This makes it impossible to find out whether ongoing alert is already silenced or not (e.g. by the person on call).

Alert is suppressed: obraz

It's not marked as suppressed in Alert rules tab: obraz

It's not marked as suppressed on View rule page: obraz

Grafana 9.0.4

Created at 2 months ago
opened issue
Alerting: _Create silence_ preview wrongly evaluates some conditions

I found to issues with Create silence form:

  1. When I go to Create silence screen and click on Add matcher the preview of matching alert instances disappears, making it difficult to change them because I need to remember exactly what I wanted to input (UX issue).

  2. When Label contains label name that doesn't exist within current alert instances, Condition is set to "!=", and _Value is set, all alerts disappear from preview even though this condition is valid - silence is saved successfully and alert is silenced (bug)

My alert: obraz

Valid condition, preview is hiden even though matchers should match my alarm instance: obraz

After saving silence is properly applied: obraz

Created at 2 months ago
issue comment
unable to get alert-notifications or dashboards from API

I'm not sure what information you want to extract, but if you are using Unified Alerting then alert definitions can be retrieved via (currently undocumented) /api/ruler/grafana/api/v1/rules endpoint. This API is described at https://raw.githubusercontent.com/grafana/grafana/main/pkg/services/ngalert/api/tooling/spec.json

Created at 2 months ago
issue comment
Alerting: `/api/prometheus/grafana/api/v1/alerts` uses invalid state names

Small update, for completeness sake:

  • health - error is reported by "error" instead of "err" (plus there's additional "nodata" health state)
  • there's also "NoData" alert state

For my use it would be ideal to have additional Grafana-specific information present in additional attributes (or private annotations?):

  • explicit nodata indicator (because compliance means that this will disappear from places where it's currently present, and would need to be inferred from present labels)
  • multiple values coming from firing alert with classic condition, here even having __value_string__ annotation, like in /alertmanager, would work as this can be parsed to extract metric names and values
  • some way to tell whether alert is silenced
Created at 2 months ago
issue comment
Go back button in Alerting / View rule doesn't work

But this IS the new alerting feature. The same issue is present with "Alert" tab in the new time series panel - clicking on "View" -> "Go back" gets me to "Alerting" page instead of "Alert" tab of graph/time series I was viewing.

Created at 2 months ago
issue comment
Cannot set "for 0" for existing alert

I cannot see an error that isn't there in current stable version (tested in 9.0.3).

The error you are writing about is shown for non-zero values: obraz

But not for "0": obraz

And then, what about alerts migrated from classic alerting - do they work at all? Are they silently broken? They do have "0", and I can easily create alerts with "0", which you claim to be invalid.

Does this mean that the official advice from four months ago at https://community.grafana.com/t/grafana-8-alerting-evaluation-immediate-firing-once-every-24h/62179:

To get an alert to fire immediately if the condition is true, you want to set the for time to 0. Otherwise, the condition needs to remain true for one minute before the alert will fire.

is invalid?

Created at 2 months ago