[jira] [Updated] (KUDU-3564) Range specific hashing table when queried with InList predicate may lead to incorrect results
[
https://issues.apache.org/jira/browse/KUDU-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-3564:
Description:
Reproduce steps that copy from the Slack channel:
{code:sql}
-- create the table and data in Impala:
CREATE TABLE age_table
(
id BIGINT,
name STRING,
age INT,
PRIMARY KEY(id,name,age)
)
PARTITION BY HASH (id) PARTITIONS 4,
HASH (name) PARTITIONS 4,
range (age)
(
PARTITION 30 <= VALUES < 60,
PARTITION 60 <= VALUES < 90
)
STORED AS KUDU
TBLPROPERTIES ('kudu.num_tablet_replicas' = '1');
ALTER TABLE age_table ADD RANGE PARTITION 90<= VALUES <120
HASH(id) PARTITIONS 3 HASH(name) PARTITIONS 3;
INSERT INTO age_table VALUES (3, 'alex', 50);
INSERT INTO age_table VALUES (12, 'bob', 100);
{code}
Now, let's run a few queries using the {{kudu table scan}} CLI tool:
{noformat}
# This query produces wrong results: the expected row for 'bob' isn't returned.
# Note that the troublesome row is in the range partition with custom
(per-range) hash schema.
$ sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["IN", "id", [12,20]]]'
Total count 0 cost 0.0224966 seconds
# This query produces correct results: the expected row for 'alex' is returned.
$ sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["IN", "id", [3,20]]]'
(int64 id=3, int32 age=50)
Total count 1 cost 0.0178102 seconds
# However, predicates on the primary key columns seem to work as expected, even
for the rows in the range with custom hash schema.
$ sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["=", "id", 12]]'
(int64 id=12, int32 age=100)
Total count 1 cost 0.0137217 seconds
{noformat}
was:
Reproduce steps that copy from the Slack channel:
{code:sql}
// create the table and data in Impala:
CREATE TABLE age_table
(
id BIGINT,
name STRING,
age INT,
PRIMARY KEY(id,name,age)
)
PARTITION BY HASH (id) PARTITIONS 4,
HASH (name) PARTITIONS 4,
range (age)
(
PARTITION 30 <= VALUES < 60,
PARTITION 60 <= VALUES < 90
)
STORED AS KUDU
TBLPROPERTIES ('kudu.num_tablet_replicas' = '1');
ALTER TABLE age_table ADD RANGE PARTITION 90<= VALUES <120
HASH(id) PARTITIONS 3 HASH(name) PARTITIONS 3;
INSERT INTO age_table VALUES (3, 'alex', 50);
INSERT INTO age_table VALUES (12, 'bob', 100);
# This query produces wrong results: the expected row for 'bob' isn't returned.
# Note that the troublesome row is in the range partition with custom
(per-range) hash schema.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["IN", "id", [12,20]]]'
Total count 0 cost 0.0224966 seconds
# This query produces correct results: the expected row for 'alex' is returned.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["IN", "id", [3,20]]]'
(int64 id=3, int32 age=50)
Total count 1 cost 0.0178102 seconds
# However, predicates on the primary key columns seem to work as expected, even
for the rows in the range with custom hash schema.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["=", "id", 12]]'
(int64 id=12, int32 age=100)
Total count 1 cost 0.0137217 seconds
{code}
> Range specific hashing table when queried with InList predicate may lead to
> incorrect results
> -
>
> Key: KUDU-3564
> URL: https://issues.apache.org/jira/browse/KUDU-3564
> Project: Kudu
> Issue Type: Bug
>Affects Versions: 1.17.0
>Reporter: YifanZhang
>Priority: Major
>
> Reproduce steps that copy from the Slack channel:
>
> {code:sql}
> -- create the table and data in Impala:
> CREATE TABLE age_table
> (
> id BIGINT,
> name STRING,
> age INT,
> PRIMARY KEY(id,name,age)
> )
> PARTITION BY HASH (id) PARTITIONS 4,
> HASH (name) PARTITIONS 4,
> range (age)
> (
> PARTITION 30 <= VALUES < 60,
> PARTITION 60 <= VALUES < 90
> )
> STORED AS KUDU
> TBLPROPERTIES ('kudu.num_tablet_replicas' = '1');
> ALTER TABLE age_table ADD RANGE PARTITION 90<= VALUES <120
> HASH(id) PARTITIONS 3 HASH(name) PARTITIONS 3;
> INSERT INTO age_table VALUES (3, 'alex', 50);
> INSERT INTO age_table VALUES (12, 'bob', 100);
> {code}
> Now, let's run a few queries using the {{kudu table scan}} CLI tool:
> {noformat}
> # This query produces wrong results: the expected row for 'bob' isn't
> returned.
> # Note that the troublesome row is in the range partition with custom
> (per-range) hash schema.
> $ sudo -u kudu kudu table scan default.age_table -columns=id,age
> -predicates='["AND", ["IN", "id", [12,20]]]'
> Total count 0 cost 0.0224966 seconds
> # This query produces correct results: the expected row for 'alex' is
> returned.
> $ sudo -u kudu kudu table scan default.age_table -columns=id,age
> -predicates='["AND", ["IN", "id",
[jira] [Updated] (KUDU-3564) Range specific hashing table when queried with InList predicate may lead to incorrect results
[
https://issues.apache.org/jira/browse/KUDU-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-3564:
Description:
Reproduce steps that copy from the Slack channel:
{code:sql}
// create the table and data in Impala:
CREATE TABLE age_table
(
id BIGINT,
name STRING,
age INT,
PRIMARY KEY(id,name,age)
)
PARTITION BY HASH (id) PARTITIONS 4,
HASH (name) PARTITIONS 4,
range (age)
(
PARTITION 30 <= VALUES < 60,
PARTITION 60 <= VALUES < 90
)
STORED AS KUDU
TBLPROPERTIES ('kudu.num_tablet_replicas' = '1');
ALTER TABLE age_table ADD RANGE PARTITION 90<= VALUES <120
HASH(id) PARTITIONS 3 HASH(name) PARTITIONS 3;
INSERT INTO age_table VALUES (3, 'alex', 50);
INSERT INTO age_table VALUES (12, 'bob', 100);
// This query produces wrong results: the expected row for 'bob' isn't returned.
// Note that the troublesome row is in the range partition with custom
(per-range) hash schema.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["IN", "id", [12,20]]]'
Total count 0 cost 0.0224966 seconds
// This query produces correct results: the expected row for 'alex' is returned.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["IN", "id", [3,20]]]'
(int64 id=3, int32 age=50)
Total count 1 cost 0.0178102 seconds
// However, predicates on the primary key columns seem to work as expected,
even for the rows in the range with custom hash schema.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["=", "id", 12]]'
(int64 id=12, int32 age=100)
Total count 1 cost 0.0137217 seconds
{code}
was:
Reproduce steps that copy from the Slack channel:
{code:sql}
// create the table and data in Impala:
CREATE TABLE age_table
(
id BIGINT,
name STRING,
age INT,
PRIMARY KEY(id,name,age)
)
PARTITION BY HASH (id) PARTITIONS 4,
HASH (name) PARTITIONS 4,
range (age)
(
PARTITION 30 <= VALUES < 60,
PARTITION 60 <= VALUES < 90
)
STORED AS KUDU
TBLPROPERTIES ('kudu.num_tablet_replicas' = '1');
ALTER TABLE age_table ADD RANGE PARTITION 90<= VALUES <120
HASH(id) PARTITIONS 3 HASH(name) PARTITIONS 3;
insert into age_table values (3, 'alex', 50);
insert into age_table values (12, 'bob', 100);
// only predicate "in" for data in custom hash cannot be found,
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["IN", "id", [3,20]]]'
(int64 id=3, int32 age=50)
Total count 1 cost 0.0178102 seconds {code}
> Range specific hashing table when queried with InList predicate may lead to
> incorrect results
> -
>
> Key: KUDU-3564
> URL: https://issues.apache.org/jira/browse/KUDU-3564
> Project: Kudu
> Issue Type: Bug
>Affects Versions: 1.17.0
>Reporter: YifanZhang
>Priority: Major
>
> Reproduce steps that copy from the Slack channel:
>
> {code:sql}
> // create the table and data in Impala:
> CREATE TABLE age_table
> (
> id BIGINT,
> name STRING,
> age INT,
> PRIMARY KEY(id,name,age)
> )
> PARTITION BY HASH (id) PARTITIONS 4,
> HASH (name) PARTITIONS 4,
> range (age)
> (
> PARTITION 30 <= VALUES < 60,
> PARTITION 60 <= VALUES < 90
> )
> STORED AS KUDU
> TBLPROPERTIES ('kudu.num_tablet_replicas' = '1');
> ALTER TABLE age_table ADD RANGE PARTITION 90<= VALUES <120
> HASH(id) PARTITIONS 3 HASH(name) PARTITIONS 3;
> INSERT INTO age_table VALUES (3, 'alex', 50);
> INSERT INTO age_table VALUES (12, 'bob', 100);
> // This query produces wrong results: the expected row for 'bob' isn't
> returned.
> // Note that the troublesome row is in the range partition with custom
> (per-range) hash schema.
> sudo -u kudu kudu table scan default.age_table -columns=id,age
> -predicates='["AND", ["IN", "id", [12,20]]]'
> Total count 0 cost 0.0224966 seconds
> // This query produces correct results: the expected row for 'alex' is
> returned.
> sudo -u kudu kudu table scan default.age_table -columns=id,age
> -predicates='["AND", ["IN", "id", [3,20]]]'
> (int64 id=3, int32 age=50)
> Total count 1 cost 0.0178102 seconds
> // However, predicates on the primary key columns seem to work as expected,
> even for the rows in the range with custom hash schema.
> sudo -u kudu kudu table scan default.age_table -columns=id,age
> -predicates='["AND", ["=", "id", 12]]'
> (int64 id=12, int32 age=100)
> Total count 1 cost 0.0137217 seconds
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KUDU-3564) Range specific hashing table when queried with InList predicate may lead to incorrect results
[
https://issues.apache.org/jira/browse/KUDU-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-3564:
Description:
Reproduce steps that copy from the Slack channel:
{code:sql}
// create the table and data in Impala:
CREATE TABLE age_table
(
id BIGINT,
name STRING,
age INT,
PRIMARY KEY(id,name,age)
)
PARTITION BY HASH (id) PARTITIONS 4,
HASH (name) PARTITIONS 4,
range (age)
(
PARTITION 30 <= VALUES < 60,
PARTITION 60 <= VALUES < 90
)
STORED AS KUDU
TBLPROPERTIES ('kudu.num_tablet_replicas' = '1');
ALTER TABLE age_table ADD RANGE PARTITION 90<= VALUES <120
HASH(id) PARTITIONS 3 HASH(name) PARTITIONS 3;
INSERT INTO age_table VALUES (3, 'alex', 50);
INSERT INTO age_table VALUES (12, 'bob', 100);
# This query produces wrong results: the expected row for 'bob' isn't returned.
# Note that the troublesome row is in the range partition with custom
(per-range) hash schema.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["IN", "id", [12,20]]]'
Total count 0 cost 0.0224966 seconds
# This query produces correct results: the expected row for 'alex' is returned.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["IN", "id", [3,20]]]'
(int64 id=3, int32 age=50)
Total count 1 cost 0.0178102 seconds
# However, predicates on the primary key columns seem to work as expected, even
for the rows in the range with custom hash schema.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["=", "id", 12]]'
(int64 id=12, int32 age=100)
Total count 1 cost 0.0137217 seconds
{code}
was:
Reproduce steps that copy from the Slack channel:
{code:sql}
// create the table and data in Impala:
CREATE TABLE age_table
(
id BIGINT,
name STRING,
age INT,
PRIMARY KEY(id,name,age)
)
PARTITION BY HASH (id) PARTITIONS 4,
HASH (name) PARTITIONS 4,
range (age)
(
PARTITION 30 <= VALUES < 60,
PARTITION 60 <= VALUES < 90
)
STORED AS KUDU
TBLPROPERTIES ('kudu.num_tablet_replicas' = '1');
ALTER TABLE age_table ADD RANGE PARTITION 90<= VALUES <120
HASH(id) PARTITIONS 3 HASH(name) PARTITIONS 3;
INSERT INTO age_table VALUES (3, 'alex', 50);
INSERT INTO age_table VALUES (12, 'bob', 100);
// This query produces wrong results: the expected row for 'bob' isn't returned.
// Note that the troublesome row is in the range partition with custom
(per-range) hash schema.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["IN", "id", [12,20]]]'
Total count 0 cost 0.0224966 seconds
// This query produces correct results: the expected row for 'alex' is returned.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["IN", "id", [3,20]]]'
(int64 id=3, int32 age=50)
Total count 1 cost 0.0178102 seconds
// However, predicates on the primary key columns seem to work as expected,
even for the rows in the range with custom hash schema.
sudo -u kudu kudu table scan default.age_table -columns=id,age
-predicates='["AND", ["=", "id", 12]]'
(int64 id=12, int32 age=100)
Total count 1 cost 0.0137217 seconds
{code}
> Range specific hashing table when queried with InList predicate may lead to
> incorrect results
> -
>
> Key: KUDU-3564
> URL: https://issues.apache.org/jira/browse/KUDU-3564
> Project: Kudu
> Issue Type: Bug
>Affects Versions: 1.17.0
>Reporter: YifanZhang
>Priority: Major
>
> Reproduce steps that copy from the Slack channel:
>
> {code:sql}
> // create the table and data in Impala:
> CREATE TABLE age_table
> (
> id BIGINT,
> name STRING,
> age INT,
> PRIMARY KEY(id,name,age)
> )
> PARTITION BY HASH (id) PARTITIONS 4,
> HASH (name) PARTITIONS 4,
> range (age)
> (
> PARTITION 30 <= VALUES < 60,
> PARTITION 60 <= VALUES < 90
> )
> STORED AS KUDU
> TBLPROPERTIES ('kudu.num_tablet_replicas' = '1');
> ALTER TABLE age_table ADD RANGE PARTITION 90<= VALUES <120
> HASH(id) PARTITIONS 3 HASH(name) PARTITIONS 3;
> INSERT INTO age_table VALUES (3, 'alex', 50);
> INSERT INTO age_table VALUES (12, 'bob', 100);
> # This query produces wrong results: the expected row for 'bob' isn't
> returned.
> # Note that the troublesome row is in the range partition with custom
> (per-range) hash schema.
> sudo -u kudu kudu table scan default.age_table -columns=id,age
> -predicates='["AND", ["IN", "id", [12,20]]]'
> Total count 0 cost 0.0224966 seconds
> # This query produces correct results: the expected row for 'alex' is
> returned.
> sudo -u kudu kudu table scan default.age_table -columns=id,age
> -predicates='["AND", ["IN", "id", [3,20]]]'
> (int64 id=3, int32 age=50)
> Total count 1 cost 0.0178102 seconds
> # However, predicates on the primary key columns seem to work as expected,
> even for the rows in the range
[jira] [Updated] (KUDU-3564) Range specific hashing table when queried with InList predicate may lead to incorrect results
[
https://issues.apache.org/jira/browse/KUDU-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-3564:
Status: In Review (was: Open)
> Range specific hashing table when queried with InList predicate may lead to
> incorrect results
> -
>
> Key: KUDU-3564
> URL: https://issues.apache.org/jira/browse/KUDU-3564
> Project: Kudu
> Issue Type: Bug
>Affects Versions: 1.17.0
>Reporter: YifanZhang
>Priority: Major
>
> Reproduce steps that copy from the Slack channel:
>
> {code:sql}
> // create the table and data in Impala:
> CREATE TABLE age_table
> (
> id BIGINT,
> name STRING,
> age INT,
> PRIMARY KEY(id,name,age)
> )
> PARTITION BY HASH (id) PARTITIONS 4,
> HASH (name) PARTITIONS 4,
> range (age)
> (
> PARTITION 30 <= VALUES < 60,
> PARTITION 60 <= VALUES < 90
> )
> STORED AS KUDU
> TBLPROPERTIES ('kudu.num_tablet_replicas' = '1');
> ALTER TABLE age_table ADD RANGE PARTITION 90<= VALUES <120
> HASH(id) PARTITIONS 3 HASH(name) PARTITIONS 3;
> insert into age_table values (3, 'alex', 50);
> insert into age_table values (12, 'bob', 100);
> // only predicate "in" for data in custom hash cannot be found,
> sudo -u kudu kudu table scan default.age_table -columns=id,age
> -predicates='["AND", ["IN", "id", [3,20]]]'
> (int64 id=3, int32 age=50)
> Total count 1 cost 0.0178102 seconds {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KUDU-3564) Range specific hashing table when queried with InList predicate may lead to incorrect results
[
https://issues.apache.org/jira/browse/KUDU-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-3564:
Code Review: https://gerrit.cloudera.org/#/c/21243/
> Range specific hashing table when queried with InList predicate may lead to
> incorrect results
> -
>
> Key: KUDU-3564
> URL: https://issues.apache.org/jira/browse/KUDU-3564
> Project: Kudu
> Issue Type: Bug
>Affects Versions: 1.17.0
>Reporter: YifanZhang
>Priority: Major
>
> Reproduce steps that copy from the Slack channel:
>
> {code:sql}
> // create the table and data in Impala:
> CREATE TABLE age_table
> (
> id BIGINT,
> name STRING,
> age INT,
> PRIMARY KEY(id,name,age)
> )
> PARTITION BY HASH (id) PARTITIONS 4,
> HASH (name) PARTITIONS 4,
> range (age)
> (
> PARTITION 30 <= VALUES < 60,
> PARTITION 60 <= VALUES < 90
> )
> STORED AS KUDU
> TBLPROPERTIES ('kudu.num_tablet_replicas' = '1');
> ALTER TABLE age_table ADD RANGE PARTITION 90<= VALUES <120
> HASH(id) PARTITIONS 3 HASH(name) PARTITIONS 3;
> insert into age_table values (3, 'alex', 50);
> insert into age_table values (12, 'bob', 100);
> // only predicate "in" for data in custom hash cannot be found,
> sudo -u kudu kudu table scan default.age_table -columns=id,age
> -predicates='["AND", ["IN", "id", [3,20]]]'
> (int64 id=3, int32 age=50)
> Total count 1 cost 0.0178102 seconds {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KUDU-3562) Inconsistency in 'available space' metrics when reserving more than 2GiB
[
https://issues.apache.org/jira/browse/KUDU-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-3562:
Fix Version/s: 1.18.0
1.17.1
Resolution: Fixed
Status: Resolved (was: In Review)
> Inconsistency in 'available space' metrics when reserving more than 2GiB
>
>
> Key: KUDU-3562
> URL: https://issues.apache.org/jira/browse/KUDU-3562
> Project: Kudu
> Issue Type: Bug
> Components: master, tserver
>Affects Versions: 1.16.0, 1.17.0
>Reporter: Alexey Serbin
>Assignee: Alexey Serbin
>Priority: Major
> Fix For: 1.18.0, 1.17.1
>
>
> When setting {{\-\-fs_data_dirs_reserved_bytes}} and
> {{\-\-fs_wal_dir_reserved_bytes}} flags to values greater than 2GiBytes, the
> {{wal_dir_space_available_bytes}} and {{data_dirs_space_available_bytes}}
> reports incorrect numbers for both Kudu masters and tablet servers. The
> metrics report much more space than actually available.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (KUDU-3561) Too Many Warning Log: "Entity is not relevant to Prometheus"
[ https://issues.apache.org/jira/browse/KUDU-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Serbin updated KUDU-3561: Fix Version/s: 1.18.0 1.17.1 Resolution: Fixed Status: Resolved (was: In Review) > Too Many Warning Log: "Entity is not relevant to Prometheus" > > > Key: KUDU-3561 > URL: https://issues.apache.org/jira/browse/KUDU-3561 > Project: Kudu > Issue Type: Bug > Components: metrics >Affects Versions: 1.17.0 >Reporter: Liu Lin >Assignee: Alexey Serbin >Priority: Major > Fix For: 1.18.0, 1.17.1 > > Attachments: image-2024-03-30-22-54-28-735.png > > > I encountered the same issue as KUDU-3549, so I recompiled Kudu using the > master branch. > Now Prometheus is able to collect metrics from Kudu correctly through the > /metrics_prometheus endpoint. > However, I noticed a large number of "Failed to write entity [xxx] as > Prometheus: Not found: Entity is not relevant to Prometheus" warning logs in > the Tserver's logs. > !image-2024-03-30-22-54-28-735.png! > Could you please confirm if this is a code issue? If not, how can I reduce > these logs? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (KUDU-3561) Too Many Warning Log: "Entity is not relevant to Prometheus"
[ https://issues.apache.org/jira/browse/KUDU-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834448#comment-17834448 ] ASF subversion and git services commented on KUDU-3561: --- Commit 832690f70ae039daf274744d617332895be8e541 in kudu's branch refs/heads/branch-1.17.x from Alexey Serbin [ https://gitbox.apache.org/repos/asf?p=kudu.git;h=832690f70 ] KUDU-3561 skip tablet entities in Prometheus format Currently, the Prometheus metrics writer outputs only server-level metrics. Prior to this patch, the Prometheus metrics writer would output a warning message for every tablet it encounters while iterating through all the existing metric entities. This patch addresses the issue: the tablet entries are now silently skipped, as they should. I also added a TODO for KUDU-3563 to output tablet-level metrics in Prometheus format as well. Change-Id: I618bbc2caab7a8d9812eeaeb67ac42b0293b0654 Reviewed-on: http://gerrit.cloudera.org:8080/21226 Reviewed-by: Mahesh Reddy Reviewed-by: Abhishek Chennaka Tested-by: Alexey Serbin (cherry picked from commit dd4e37b445da7f367746fb83d92e21b8dc3d8eb8) Reviewed-on: http://gerrit.cloudera.org:8080/21231 > Too Many Warning Log: "Entity is not relevant to Prometheus" > > > Key: KUDU-3561 > URL: https://issues.apache.org/jira/browse/KUDU-3561 > Project: Kudu > Issue Type: Bug > Components: metrics >Affects Versions: 1.17.0 >Reporter: Liu Lin >Assignee: Alexey Serbin >Priority: Major > Attachments: image-2024-03-30-22-54-28-735.png > > > I encountered the same issue as KUDU-3549, so I recompiled Kudu using the > master branch. > Now Prometheus is able to collect metrics from Kudu correctly through the > /metrics_prometheus endpoint. > However, I noticed a large number of "Failed to write entity [xxx] as > Prometheus: Not found: Entity is not relevant to Prometheus" warning logs in > the Tserver's logs. > !image-2024-03-30-22-54-28-735.png! > Could you please confirm if this is a code issue? If not, how can I reduce > these logs? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (KUDU-3563) Output tablet-level metrics in Prometheus format
[ https://issues.apache.org/jira/browse/KUDU-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834449#comment-17834449 ] ASF subversion and git services commented on KUDU-3563: --- Commit 832690f70ae039daf274744d617332895be8e541 in kudu's branch refs/heads/branch-1.17.x from Alexey Serbin [ https://gitbox.apache.org/repos/asf?p=kudu.git;h=832690f70 ] KUDU-3561 skip tablet entities in Prometheus format Currently, the Prometheus metrics writer outputs only server-level metrics. Prior to this patch, the Prometheus metrics writer would output a warning message for every tablet it encounters while iterating through all the existing metric entities. This patch addresses the issue: the tablet entries are now silently skipped, as they should. I also added a TODO for KUDU-3563 to output tablet-level metrics in Prometheus format as well. Change-Id: I618bbc2caab7a8d9812eeaeb67ac42b0293b0654 Reviewed-on: http://gerrit.cloudera.org:8080/21226 Reviewed-by: Mahesh Reddy Reviewed-by: Abhishek Chennaka Tested-by: Alexey Serbin (cherry picked from commit dd4e37b445da7f367746fb83d92e21b8dc3d8eb8) Reviewed-on: http://gerrit.cloudera.org:8080/21231 > Output tablet-level metrics in Prometheus format > > > Key: KUDU-3563 > URL: https://issues.apache.org/jira/browse/KUDU-3563 > Project: Kudu > Issue Type: Improvement > Components: master, server, tserver >Reporter: Alexey Serbin >Priority: Major > Labels: metrics, prometheus, supportability, visibility > > The request to support outputting Kudu metrics in Prometheus format is > tracked [KUDU-3375|https://issues.apache.org/jira/browse/KUDU-3375]. The > [first take on > this|https://github.com/apache/kudu/commit/00efc6826ac9a1f5d10750296c7357790a041fec] > has taken care of the server-level metrics, ignoring all the tablet-level > metrics. > In the scope of this JIRA item, it's necessary to output all the tablet-level > metrics in Prometheus format as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
