You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by 38797715 <38...@qq.com> on 2021/01/26 10:46:56 UTC
[2.9.1]in SYS.METRICS View some data is always 0
Hi,
We found that SYS.METRICS View some data is always 0, such as
QueryCompleted,QueryExecuted,QuerySumTime,QueryCompleted,QuerySumTime
and QueryMaximumTime. This is a bug? Or what configuration is needed? Or
the related functions have not been implemented yet?
Re: [2.9.1]in SYS.METRICS View some data is always 0
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
You are running SqlFieldsQuery on client node here, but you are checking
metric on server. Metrics are per-node local.
Regards,
--
Ilya Kasnacheev
пн, 1 февр. 2021 г. в 14:16, 38797715 <38...@qq.com>:
> It's amazing, let's simplify the problem.
>
> 1.Start a node using the following configuration file
> <beans xmlns="http://www.springframework.org/schema/beans"
> <http://www.springframework.org/schema/beans>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> <http://www.w3.org/2001/XMLSchema-instance> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd">
> <bean id="ignite.cfg" class=
> "org.apache.ignite.configuration.IgniteConfiguration">
> <property name="peerClassLoadingEnabled" value="true"/>
> <property name="metricExporterSpi">
> <list>
> <bean class="org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi"/>
> </list>
> </property>
> </bean>
> </beans>
>
> 2.Use sqlline to connect the current cluster:
>
> ./sqlline.sh --verbose=true -u jdbc:ignite:thin://localhost
>
> 3.Execute the following SQL in the
> `apache-ignite-2.9.1-bin/examples/sql/world.sql`file:
> CREATE TABLE City (
> ID INT,
> Name VARCHAR,
> CountryCode CHAR(3),
> District VARCHAR,
> Population INT,
> PRIMARY KEY (ID, CountryCode)
> ) WITH "template=partitioned, backups=1, affinityKey=CountryCode,
> CACHE_NAME=City, KEY_TYPE=demo.model.CityKey, VALUE_TYPE=demo.model.City";
> INSERT INTO City(ID, Name, CountryCode, District, Population) VALUES (1,
> 'Kabul','AFG','Kabol',1780000);
>
> 4.Execute the following code:
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setClientMode(true);
> cfg.setPeerClassLoadingEnabled(true);
> cfg.setMetricExporterSpi(new SqlViewMetricExporterSpi());
> Ignite ignite = Ignition.start(cfg);
>
> IgniteCache cache = ignite.cache("City");
>
> String sql = "SELECT count(*) FROM CITY;";
> cache.query(new SqlFieldsQuery(sql)).getAll();
> 5.Execute the following SQL in the SQLLine:
> select * from sys.metrics where name like 'cache.City.Query%';
> 6.Got it!
>
> 在 2021/2/1 下午4:39, Ilya Kasnacheev 写道:
>
> Hello!
>
> No, this is not correct.
>
> Even if table is created through JDBC, nodes will collect metrics for its
> SqlFieldsQuery's:
> | cache.SQL_PUBLIC_PERSON.QueryCompleted | 2
> | |
> | cache.SQL_PUBLIC_PERSON.QueryExecuted | 2 |
> |
> | cache.SQL_PUBLIC_PERSON.QueryFailed | 0 |
> |
> | cache.SQL_PUBLIC_PERSON.QueryMaximumTime | 63
> | |
> | cache.SQL_PUBLIC_PERSON.QueryMinimalTime | 21
> | |
> | cache.SQL_PUBLIC_PERSON.QuerySumTime | 84 |
> |
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> сб, 30 янв. 2021 г. в 05:10, 38797715 <38...@qq.com>:
>
>> Hello Ilya,
>>
>> I got it.
>> If the table is created through JDBC, the metric data will be 0.
>> Only when the CREATE TABLE statement is executed through SqlFieldsQuery,
>> the data will be counted.
>>
>> I think it's a bug,Ilya, can you confirm again?
>> 在 2021/1/30 上午12:06, Ilya Kasnacheev 写道:
>>
>> Hello!
>>
>> I can see some values on the server when executing SqlFieldsQuery on the
>> same server:
>> | cache.foo.QueryCompleted | 3 |
>> |
>> | cache.foo.QueryExecuted | 3 |
>> |
>> | cache.foo.QueryFailed | 0 |
>> |
>> | cache.foo.QueryMaximumTime | 350 |
>> |
>> | cache.foo.QueryMinimalTime | 101 |
>> |
>> | cache.foo.QuerySumTime | 665 |
>> |
>>
>> I can also see them on client, but you need to a) specify
>> ClientConnectorConfiguration on client node with non-default port, b)
>> connect to that port with JDBC, and c) Enable metrics exporter SPI on the
>> client node. Then I can see the same, after running SqlFieldQuery's on
>> client:
>> | cache.foo.QueryCompleted | 3 |
>> |
>> | cache.foo.QueryExecuted | 3 |
>> |
>> | cache.foo.QueryFailed | 0 |
>> |
>> | cache.foo.QueryMaximumTime | 269 |
>> |
>> | cache.foo.QueryMinimalTime | 20 |
>> |
>> | cache.foo.QuerySumTime | 424 |
>> |
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> чт, 28 янв. 2021 г. в 14:42, 38797715 <38...@qq.com>:
>>
>>> Hello Ilya,
>>>
>>> if use sqlline execute sql, the feedback result of the following
>>> statement is correct.
>>>
>>> SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
>>>
>>> I used SqlFieldsQuery again to do the above tests, and the results were
>>> all 0. I think there may be a issue in this.
>>> 在 2021/1/28 下午6:52, Ilya Kasnacheev 写道:
>>>
>>> Hello!
>>>
>>> I think these metrics will be gathered for ScanQuery/SqlFieldsQuery
>>> executed via native Java Query API, but they will not be gathered for
>>> statements executed via JDBC.
>>>
>>> One obvious reason is that Java Query API's queries are bound to a
>>> specific cache. JDBC query is not bound to specific cache: JDBC query may
>>> operate on zero or more caches. We could map these queries back to
>>> participating caches, but I don't see that we do that.
>>>
>>> You could still use sql.queries.user. metrics:
>>> SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> ср, 27 янв. 2021 г. в 15:29, 38797715 <38...@qq.com>:
>>>
>>>> Hello Ilya,
>>>>
>>>> The test method is as follows:
>>>>
>>>> Start 2 nodes on the localhost.
>>>> Use the CREATE TABLE statement to create a table;
>>>> Use the COPY command to load some data;
>>>> Access to cluster through sqlline;
>>>> Execute select count (*) from T;
>>>> Execute select * from sys.metrics WHERE name LIKE '%cache.T%';
>>>> At this time, you will find that the relevant data are all 0, but the
>>>> value of OffHeapEntriesCount is still correct.
>>>>
>>>> If you use sqlline to access another node, the result is the same.
>>>>
>>>> The configuration file to start the cluster is as follows:
>>>> <bean id="ignite.cfg" class=
>>>> "org.apache.ignite.configuration.IgniteConfiguration">
>>>> <property name="peerClassLoadingEnabled" value="true"/>
>>>> <property name="consistentId" value=
>>>> "#{systemEnvironment['CONSISTENTID']}"/>
>>>> <property name="metricExporterSpi">
>>>> <list>
>>>> <bean class="org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi"
>>>> />
>>>> </list>
>>>> </property>
>>>> <property name="cacheConfiguration">
>>>> <list>
>>>> <bean id="partitioned-cache-template" abstract="true" class=
>>>> "org.apache.ignite.configuration.CacheConfiguration">
>>>> <property name="name" value="cache-partitioned*"/>
>>>> <property name="cacheMode" value="PARTITIONED" />
>>>> <property name="backups" value="0" />
>>>> <property name="statisticsEnabled" value="true"/>
>>>> <property name="queryParallelism" value="2"/>
>>>> <property name="partitionLossPolicy" value="READ_WRITE_SAFE"/>
>>>> </bean>
>>>> <bean id="replicated-cache-template" abstract="true" class=
>>>> "org.apache.ignite.configuration.CacheConfiguration">
>>>> <property name="name" value="cache-replicated*"/>
>>>> <property name="cacheMode" value="REPLICATED" />
>>>> <property name="statisticsEnabled" value="true"/>
>>>> <property name="partitionLossPolicy" value="READ_WRITE_SAFE"/>
>>>> </bean>
>>>> </list>
>>>> </property>
>>>> <!-- Enabling Apache Ignite Persistent Store. -->
>>>> <property name="dataStorageConfiguration">
>>>> <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
>>>> <property name="metricsEnabled" value="true"/>
>>>> <property name="defaultDataRegionConfiguration">
>>>> <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
>>>> <property name="persistenceEnabled" value="true"/>
>>>> <property name="metricsEnabled" value="true"/>
>>>> <property name="maxSize" value="#{2L * 1024 * 1024 * 1024}"/>
>>>> </bean>
>>>> </property>
>>>> </bean>
>>>> </property>
>>>> </bean>
>>>> 在 2021/1/27 下午6:24, Ilya Kasnacheev 写道:
>>>>
>>>> Hello!
>>>>
>>>> These values are per-node, as far as I know. Is it possible that you
>>>> have connected to a node which does not handle any queries (as reducer,
>>>> anyway)?
>>>>
>>>> Regards,
>>>> --
>>>> Ilya Kasnacheev
>>>>
>>>>
>>>> вт, 26 янв. 2021 г. в 13:48, 38797715 <38...@qq.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> We found that SYS.METRICS View some data is always 0, such as
>>>>> QueryCompleted,QueryExecuted,QuerySumTime,QueryCompleted,QuerySumTime
>>>>> and QueryMaximumTime. This is a bug? Or what configuration is needed?
>>>>> Or
>>>>> the related functions have not been implemented yet?
>>>>>
>>>>>
Re: [2.9.1]in SYS.METRICS View some data is always 0
Posted by 38797715 <38...@qq.com>.
It's amazing, let's simplify the problem.
1.Start a node using the following configuration file
<beansxmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<beanid="ignite.cfg"class="org.apache.ignite.configuration.IgniteConfiguration">
<propertyname="peerClassLoadingEnabled"value="true"/>
<propertyname="metricExporterSpi">
<list>
<beanclass="org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi"/>
</list>
</property>
</bean>
</beans>
2.Use sqlline to connect the current cluster:
./sqlline.sh --verbose=true -u jdbc:ignite:thin://localhost
3.Execute the following SQL in the
`apache-ignite-2.9.1-bin/examples/sql/world.sql`file:
CREATETABLECity (
ID INT,
NameVARCHAR,
CountryCode CHAR(3),
District VARCHAR,
PopulationINT,
PRIMARYKEY(ID, CountryCode)
) WITH"template=partitioned, backups=1, affinityKey=CountryCode,
CACHE_NAME=City, KEY_TYPE=demo.model.CityKey, VALUE_TYPE=demo.model.City";
INSERTINTOCity(ID, Name, CountryCode, District, Population)
VALUES(1,'Kabul','AFG','Kabol',1780000);
4.Execute the following code:
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setClientMode(true);
cfg.setPeerClassLoadingEnabled(true);
cfg.setMetricExporterSpi(new SqlViewMetricExporterSpi());
Ignite ignite = Ignition.start(cfg);
IgniteCache cache = ignite.cache("City");
String sql = "SELECT count(*) FROM CITY;";
cache.query(new SqlFieldsQuery(sql)).getAll();
5.Execute the following SQL in the SQLLine:
select * from sys.metrics where name like 'cache.City.Query%';
6.Got it!
在 2021/2/1 下午4:39, Ilya Kasnacheev 写道:
> Hello!
>
> No, this is not correct.
>
> Even if table is created through JDBC, nodes will collect metrics for
> its SqlFieldsQuery's:
> | cache.SQL_PUBLIC_PERSON.QueryCompleted | 2
> | |
> | cache.SQL_PUBLIC_PERSON.QueryExecuted | 2
> | |
> | cache.SQL_PUBLIC_PERSON.QueryFailed | 0
> | |
> | cache.SQL_PUBLIC_PERSON.QueryMaximumTime | 63
> | |
> | cache.SQL_PUBLIC_PERSON.QueryMinimalTime | 21
> | |
> | cache.SQL_PUBLIC_PERSON.QuerySumTime | 84
> | |
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> сб, 30 янв. 2021 г. в 05:10, 38797715 <38797715@qq.com
> <ma...@qq.com>>:
>
> Hello Ilya,
>
> I got it.
> If the table is created through JDBC, the metric data will be 0.
> Only when the CREATE TABLE statement is executed through
> SqlFieldsQuery, the data will be counted.
>
> I think it's a bug,Ilya, can you confirm again?
>
> 在 2021/1/30 上午12:06, Ilya Kasnacheev 写道:
>> Hello!
>>
>> I can see some values on the server when executing SqlFieldsQuery
>> on the same server:
>> | cache.foo.QueryCompleted | 3
>> | |
>> | cache.foo.QueryExecuted | 3
>> | |
>> | cache.foo.QueryFailed | 0
>> | |
>> | cache.foo.QueryMaximumTime | 350
>> | |
>> | cache.foo.QueryMinimalTime | 101
>> | |
>> | cache.foo.QuerySumTime | 665
>> | |
>>
>> I can also see them on client, but you need to a) specify
>> ClientConnectorConfiguration on client node with non-default
>> port, b) connect to that port with JDBC, and c) Enable metrics
>> exporter SPI on the client node. Then I can see the same, after
>> running SqlFieldQuery's on client:
>> | cache.foo.QueryCompleted | 3
>> | |
>> | cache.foo.QueryExecuted | 3
>> | |
>> | cache.foo.QueryFailed | 0
>> | |
>> | cache.foo.QueryMaximumTime | 269
>> | |
>> | cache.foo.QueryMinimalTime | 20
>> | |
>> | cache.foo.QuerySumTime | 424
>> | |
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> чт, 28 янв. 2021 г. в 14:42, 38797715 <38797715@qq.com
>> <ma...@qq.com>>:
>>
>> Hello Ilya,
>>
>> if use sqlline execute sql,the feedback result of the
>> following statement is correct.
>>
>> SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
>>
>> I used SqlFieldsQuery again to do the above tests, and the
>> results were all 0. I think there may be a issue in this.
>>
>> 在 2021/1/28 下午6:52, Ilya Kasnacheev 写道:
>>> Hello!
>>>
>>> I think these metrics will be gathered for
>>> ScanQuery/SqlFieldsQuery executed via native Java Query API,
>>> but they will not be gathered for statements executed via JDBC.
>>>
>>> One obvious reason is that Java Query API's queries are
>>> bound to a specific cache. JDBC query is not bound to
>>> specific cache: JDBC query may operate on zero or more
>>> caches. We could map these queries back to participating
>>> caches, but I don't see that we do that.
>>>
>>> You could still use sql.queries.user. metrics:
>>> SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> ср, 27 янв. 2021 г. в 15:29, 38797715 <38797715@qq.com
>>> <ma...@qq.com>>:
>>>
>>> Hello Ilya,
>>>
>>> The test method is as follows:
>>>
>>> Start 2 nodes on the localhost.
>>> Use the CREATE TABLE statement to create a table;
>>> Use the COPY command to load some data;
>>> Access to cluster through sqlline;
>>> Execute select count (*) from T;
>>> Execute select * from sys.metrics WHERE name LIKE
>>> '%cache.T%';
>>> At this time, you will find that the relevant data are
>>> all 0, but the value of OffHeapEntriesCount is still
>>> correct.
>>>
>>> If you use sqlline to access another node, the result is
>>> the same.
>>>
>>> The configuration file to start the cluster is as follows:
>>>
>>> <beanid="ignite.cfg"class="org.apache.ignite.configuration.IgniteConfiguration">
>>> <propertyname="peerClassLoadingEnabled"value="true"/>
>>> <propertyname="consistentId"value="#{systemEnvironment['CONSISTENTID']}"/>
>>> <propertyname="metricExporterSpi">
>>> <list>
>>> <beanclass="org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi"/>
>>> </list>
>>> </property>
>>> <propertyname="cacheConfiguration">
>>> <list>
>>> <beanid="partitioned-cache-template"abstract="true"class="org.apache.ignite.configuration.CacheConfiguration">
>>> <propertyname="name"value="cache-partitioned*"/>
>>> <propertyname="cacheMode"value="PARTITIONED"/>
>>> <propertyname="backups"value="0"/>
>>> <propertyname="statisticsEnabled"value="true"/>
>>> <propertyname="queryParallelism"value="2"/>
>>> <propertyname="partitionLossPolicy"value="READ_WRITE_SAFE"/>
>>> </bean>
>>> <beanid="replicated-cache-template"abstract="true"class="org.apache.ignite.configuration.CacheConfiguration">
>>> <propertyname="name"value="cache-replicated*"/>
>>> <propertyname="cacheMode"value="REPLICATED"/>
>>> <propertyname="statisticsEnabled"value="true"/>
>>> <propertyname="partitionLossPolicy"value="READ_WRITE_SAFE"/>
>>> </bean>
>>> </list>
>>> </property>
>>> <!-- Enabling Apache Ignite Persistent Store. -->
>>> <propertyname="dataStorageConfiguration">
>>> <beanclass="org.apache.ignite.configuration.DataStorageConfiguration">
>>> <propertyname="metricsEnabled"value="true"/>
>>> <propertyname="defaultDataRegionConfiguration">
>>> <beanclass="org.apache.ignite.configuration.DataRegionConfiguration">
>>> <propertyname="persistenceEnabled"value="true"/>
>>> <propertyname="metricsEnabled"value="true"/>
>>> <propertyname="maxSize"value="#{2L * 1024 * 1024 * 1024}"/>
>>> </bean>
>>> </property>
>>> </bean>
>>> </property>
>>> </bean>
>>> 在 2021/1/27 下午6:24, Ilya Kasnacheev 写道:
>>>> Hello!
>>>>
>>>> These values are per-node, as far as I know. Is it
>>>> possible that you have connected to a node which does
>>>> not handle any queries (as reducer, anyway)?
>>>>
>>>> Regards,
>>>> --
>>>> Ilya Kasnacheev
>>>>
>>>>
>>>> вт, 26 янв. 2021 г. в 13:48, 38797715 <38797715@qq.com
>>>> <ma...@qq.com>>:
>>>>
>>>> Hi,
>>>>
>>>> We found that SYS.METRICS View some data is always
>>>> 0, such as
>>>> QueryCompleted,QueryExecuted,QuerySumTime,QueryCompleted,QuerySumTime
>>>>
>>>> and QueryMaximumTime. This is a bug? Or what
>>>> configuration is needed? Or
>>>> the related functions have not been implemented yet?
>>>>
Re: [2.9.1]in SYS.METRICS View some data is always 0
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
No, this is not correct.
Even if table is created through JDBC, nodes will collect metrics for its
SqlFieldsQuery's:
| cache.SQL_PUBLIC_PERSON.QueryCompleted | 2 |
|
| cache.SQL_PUBLIC_PERSON.QueryExecuted | 2 |
|
| cache.SQL_PUBLIC_PERSON.QueryFailed | 0 |
|
| cache.SQL_PUBLIC_PERSON.QueryMaximumTime | 63
| |
| cache.SQL_PUBLIC_PERSON.QueryMinimalTime | 21
| |
| cache.SQL_PUBLIC_PERSON.QuerySumTime | 84 |
|
Regards,
--
Ilya Kasnacheev
сб, 30 янв. 2021 г. в 05:10, 38797715 <38...@qq.com>:
> Hello Ilya,
>
> I got it.
> If the table is created through JDBC, the metric data will be 0.
> Only when the CREATE TABLE statement is executed through SqlFieldsQuery,
> the data will be counted.
>
> I think it's a bug,Ilya, can you confirm again?
> 在 2021/1/30 上午12:06, Ilya Kasnacheev 写道:
>
> Hello!
>
> I can see some values on the server when executing SqlFieldsQuery on the
> same server:
> | cache.foo.QueryCompleted | 3 |
> |
> | cache.foo.QueryExecuted | 3 |
> |
> | cache.foo.QueryFailed | 0 |
> |
> | cache.foo.QueryMaximumTime | 350 |
> |
> | cache.foo.QueryMinimalTime | 101 |
> |
> | cache.foo.QuerySumTime | 665 |
> |
>
> I can also see them on client, but you need to a) specify
> ClientConnectorConfiguration on client node with non-default port, b)
> connect to that port with JDBC, and c) Enable metrics exporter SPI on the
> client node. Then I can see the same, after running SqlFieldQuery's on
> client:
> | cache.foo.QueryCompleted | 3 |
> |
> | cache.foo.QueryExecuted | 3 |
> |
> | cache.foo.QueryFailed | 0 |
> |
> | cache.foo.QueryMaximumTime | 269 |
> |
> | cache.foo.QueryMinimalTime | 20 |
> |
> | cache.foo.QuerySumTime | 424 |
> |
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 28 янв. 2021 г. в 14:42, 38797715 <38...@qq.com>:
>
>> Hello Ilya,
>>
>> if use sqlline execute sql, the feedback result of the following
>> statement is correct.
>>
>> SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
>>
>> I used SqlFieldsQuery again to do the above tests, and the results were
>> all 0. I think there may be a issue in this.
>> 在 2021/1/28 下午6:52, Ilya Kasnacheev 写道:
>>
>> Hello!
>>
>> I think these metrics will be gathered for ScanQuery/SqlFieldsQuery
>> executed via native Java Query API, but they will not be gathered for
>> statements executed via JDBC.
>>
>> One obvious reason is that Java Query API's queries are bound to a
>> specific cache. JDBC query is not bound to specific cache: JDBC query may
>> operate on zero or more caches. We could map these queries back to
>> participating caches, but I don't see that we do that.
>>
>> You could still use sql.queries.user. metrics:
>> SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> ср, 27 янв. 2021 г. в 15:29, 38797715 <38...@qq.com>:
>>
>>> Hello Ilya,
>>>
>>> The test method is as follows:
>>>
>>> Start 2 nodes on the localhost.
>>> Use the CREATE TABLE statement to create a table;
>>> Use the COPY command to load some data;
>>> Access to cluster through sqlline;
>>> Execute select count (*) from T;
>>> Execute select * from sys.metrics WHERE name LIKE '%cache.T%';
>>> At this time, you will find that the relevant data are all 0, but the
>>> value of OffHeapEntriesCount is still correct.
>>>
>>> If you use sqlline to access another node, the result is the same.
>>>
>>> The configuration file to start the cluster is as follows:
>>> <bean id="ignite.cfg" class=
>>> "org.apache.ignite.configuration.IgniteConfiguration">
>>> <property name="peerClassLoadingEnabled" value="true"/>
>>> <property name="consistentId" value=
>>> "#{systemEnvironment['CONSISTENTID']}"/>
>>> <property name="metricExporterSpi">
>>> <list>
>>> <bean class="org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi"
>>> />
>>> </list>
>>> </property>
>>> <property name="cacheConfiguration">
>>> <list>
>>> <bean id="partitioned-cache-template" abstract="true" class=
>>> "org.apache.ignite.configuration.CacheConfiguration">
>>> <property name="name" value="cache-partitioned*"/>
>>> <property name="cacheMode" value="PARTITIONED" />
>>> <property name="backups" value="0" />
>>> <property name="statisticsEnabled" value="true"/>
>>> <property name="queryParallelism" value="2"/>
>>> <property name="partitionLossPolicy" value="READ_WRITE_SAFE"/>
>>> </bean>
>>> <bean id="replicated-cache-template" abstract="true" class=
>>> "org.apache.ignite.configuration.CacheConfiguration">
>>> <property name="name" value="cache-replicated*"/>
>>> <property name="cacheMode" value="REPLICATED" />
>>> <property name="statisticsEnabled" value="true"/>
>>> <property name="partitionLossPolicy" value="READ_WRITE_SAFE"/>
>>> </bean>
>>> </list>
>>> </property>
>>> <!-- Enabling Apache Ignite Persistent Store. -->
>>> <property name="dataStorageConfiguration">
>>> <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
>>> <property name="metricsEnabled" value="true"/>
>>> <property name="defaultDataRegionConfiguration">
>>> <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
>>> <property name="persistenceEnabled" value="true"/>
>>> <property name="metricsEnabled" value="true"/>
>>> <property name="maxSize" value="#{2L * 1024 * 1024 * 1024}"/>
>>> </bean>
>>> </property>
>>> </bean>
>>> </property>
>>> </bean>
>>> 在 2021/1/27 下午6:24, Ilya Kasnacheev 写道:
>>>
>>> Hello!
>>>
>>> These values are per-node, as far as I know. Is it possible that you
>>> have connected to a node which does not handle any queries (as reducer,
>>> anyway)?
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> вт, 26 янв. 2021 г. в 13:48, 38797715 <38...@qq.com>:
>>>
>>>> Hi,
>>>>
>>>> We found that SYS.METRICS View some data is always 0, such as
>>>> QueryCompleted,QueryExecuted,QuerySumTime,QueryCompleted,QuerySumTime
>>>> and QueryMaximumTime. This is a bug? Or what configuration is needed?
>>>> Or
>>>> the related functions have not been implemented yet?
>>>>
>>>>
Re: [2.9.1]in SYS.METRICS View some data is always 0
Posted by 38797715 <38...@qq.com>.
Hello Ilya,
I got it.
If the table is created through JDBC, the metric data will be 0.
Only when the CREATE TABLE statement is executed through SqlFieldsQuery,
the data will be counted.
I think it's a bug,Ilya, can you confirm again?
在 2021/1/30 上午12:06, Ilya Kasnacheev 写道:
> Hello!
>
> I can see some values on the server when executing SqlFieldsQuery on
> the same server:
> | cache.foo.QueryCompleted | 3 |
> |
> | cache.foo.QueryExecuted | 3 |
> |
> | cache.foo.QueryFailed | 0 |
> |
> | cache.foo.QueryMaximumTime | 350 |
> |
> | cache.foo.QueryMinimalTime | 101 |
> |
> | cache.foo.QuerySumTime | 665 |
> |
>
> I can also see them on client, but you need to a) specify
> ClientConnectorConfiguration on client node with non-default port, b)
> connect to that port with JDBC, and c) Enable metrics exporter SPI on
> the client node. Then I can see the same, after running
> SqlFieldQuery's on client:
> | cache.foo.QueryCompleted | 3 |
> |
> | cache.foo.QueryExecuted | 3 |
> |
> | cache.foo.QueryFailed | 0 |
> |
> | cache.foo.QueryMaximumTime | 269 |
> |
> | cache.foo.QueryMinimalTime | 20 |
> |
> | cache.foo.QuerySumTime | 424 |
> |
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 28 янв. 2021 г. в 14:42, 38797715 <38797715@qq.com
> <ma...@qq.com>>:
>
> Hello Ilya,
>
> if use sqlline execute sql,the feedback result of the following
> statement is correct.
>
> SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
>
> I used SqlFieldsQuery again to do the above tests, and the results
> were all 0. I think there may be a issue in this.
>
> 在 2021/1/28 下午6:52, Ilya Kasnacheev 写道:
>> Hello!
>>
>> I think these metrics will be gathered for
>> ScanQuery/SqlFieldsQuery executed via native Java Query API, but
>> they will not be gathered for statements executed via JDBC.
>>
>> One obvious reason is that Java Query API's queries are bound to
>> a specific cache. JDBC query is not bound to specific cache: JDBC
>> query may operate on zero or more caches. We could map these
>> queries back to participating caches, but I don't see that we do
>> that.
>>
>> You could still use sql.queries.user. metrics:
>> SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> ср, 27 янв. 2021 г. в 15:29, 38797715 <38797715@qq.com
>> <ma...@qq.com>>:
>>
>> Hello Ilya,
>>
>> The test method is as follows:
>>
>> Start 2 nodes on the localhost.
>> Use the CREATE TABLE statement to create a table;
>> Use the COPY command to load some data;
>> Access to cluster through sqlline;
>> Execute select count (*) from T;
>> Execute select * from sys.metrics WHERE name LIKE '%cache.T%';
>> At this time, you will find that the relevant data are all 0,
>> but the value of OffHeapEntriesCount is still correct.
>>
>> If you use sqlline to access another node, the result is the
>> same.
>>
>> The configuration file to start the cluster is as follows:
>>
>> <beanid="ignite.cfg"class="org.apache.ignite.configuration.IgniteConfiguration">
>> <propertyname="peerClassLoadingEnabled"value="true"/>
>> <propertyname="consistentId"value="#{systemEnvironment['CONSISTENTID']}"/>
>> <propertyname="metricExporterSpi">
>> <list>
>> <beanclass="org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi"/>
>> </list>
>> </property>
>> <propertyname="cacheConfiguration">
>> <list>
>> <beanid="partitioned-cache-template"abstract="true"class="org.apache.ignite.configuration.CacheConfiguration">
>> <propertyname="name"value="cache-partitioned*"/>
>> <propertyname="cacheMode"value="PARTITIONED"/>
>> <propertyname="backups"value="0"/>
>> <propertyname="statisticsEnabled"value="true"/>
>> <propertyname="queryParallelism"value="2"/>
>> <propertyname="partitionLossPolicy"value="READ_WRITE_SAFE"/>
>> </bean>
>> <beanid="replicated-cache-template"abstract="true"class="org.apache.ignite.configuration.CacheConfiguration">
>> <propertyname="name"value="cache-replicated*"/>
>> <propertyname="cacheMode"value="REPLICATED"/>
>> <propertyname="statisticsEnabled"value="true"/>
>> <propertyname="partitionLossPolicy"value="READ_WRITE_SAFE"/>
>> </bean>
>> </list>
>> </property>
>> <!-- Enabling Apache Ignite Persistent Store. -->
>> <propertyname="dataStorageConfiguration">
>> <beanclass="org.apache.ignite.configuration.DataStorageConfiguration">
>> <propertyname="metricsEnabled"value="true"/>
>> <propertyname="defaultDataRegionConfiguration">
>> <beanclass="org.apache.ignite.configuration.DataRegionConfiguration">
>> <propertyname="persistenceEnabled"value="true"/>
>> <propertyname="metricsEnabled"value="true"/>
>> <propertyname="maxSize"value="#{2L * 1024 * 1024 * 1024}"/>
>> </bean>
>> </property>
>> </bean>
>> </property>
>> </bean>
>> 在 2021/1/27 下午6:24, Ilya Kasnacheev 写道:
>>> Hello!
>>>
>>> These values are per-node, as far as I know. Is it possible
>>> that you have connected to a node which does not handle any
>>> queries (as reducer, anyway)?
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> вт, 26 янв. 2021 г. в 13:48, 38797715 <38797715@qq.com
>>> <ma...@qq.com>>:
>>>
>>> Hi,
>>>
>>> We found that SYS.METRICS View some data is always 0,
>>> such as
>>> QueryCompleted,QueryExecuted,QuerySumTime,QueryCompleted,QuerySumTime
>>>
>>> and QueryMaximumTime. This is a bug? Or what
>>> configuration is needed? Or
>>> the related functions have not been implemented yet?
>>>
Re: [2.9.1]in SYS.METRICS View some data is always 0
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
I can see some values on the server when executing SqlFieldsQuery on the
same server:
| cache.foo.QueryCompleted | 3 |
|
| cache.foo.QueryExecuted | 3 |
|
| cache.foo.QueryFailed | 0 |
|
| cache.foo.QueryMaximumTime | 350 |
|
| cache.foo.QueryMinimalTime | 101 |
|
| cache.foo.QuerySumTime | 665 |
|
I can also see them on client, but you need to a) specify
ClientConnectorConfiguration on client node with non-default port, b)
connect to that port with JDBC, and c) Enable metrics exporter SPI on the
client node. Then I can see the same, after running SqlFieldQuery's on
client:
| cache.foo.QueryCompleted | 3 |
|
| cache.foo.QueryExecuted | 3 |
|
| cache.foo.QueryFailed | 0 |
|
| cache.foo.QueryMaximumTime | 269 |
|
| cache.foo.QueryMinimalTime | 20 |
|
| cache.foo.QuerySumTime | 424 |
|
Regards,
--
Ilya Kasnacheev
чт, 28 янв. 2021 г. в 14:42, 38797715 <38...@qq.com>:
> Hello Ilya,
>
> if use sqlline execute sql, the feedback result of the following
> statement is correct.
>
> SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
>
> I used SqlFieldsQuery again to do the above tests, and the results were
> all 0. I think there may be a issue in this.
> 在 2021/1/28 下午6:52, Ilya Kasnacheev 写道:
>
> Hello!
>
> I think these metrics will be gathered for ScanQuery/SqlFieldsQuery
> executed via native Java Query API, but they will not be gathered for
> statements executed via JDBC.
>
> One obvious reason is that Java Query API's queries are bound to a
> specific cache. JDBC query is not bound to specific cache: JDBC query may
> operate on zero or more caches. We could map these queries back to
> participating caches, but I don't see that we do that.
>
> You could still use sql.queries.user. metrics:
> SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 27 янв. 2021 г. в 15:29, 38797715 <38...@qq.com>:
>
>> Hello Ilya,
>>
>> The test method is as follows:
>>
>> Start 2 nodes on the localhost.
>> Use the CREATE TABLE statement to create a table;
>> Use the COPY command to load some data;
>> Access to cluster through sqlline;
>> Execute select count (*) from T;
>> Execute select * from sys.metrics WHERE name LIKE '%cache.T%';
>> At this time, you will find that the relevant data are all 0, but the
>> value of OffHeapEntriesCount is still correct.
>>
>> If you use sqlline to access another node, the result is the same.
>>
>> The configuration file to start the cluster is as follows:
>> <bean id="ignite.cfg" class=
>> "org.apache.ignite.configuration.IgniteConfiguration">
>> <property name="peerClassLoadingEnabled" value="true"/>
>> <property name="consistentId" value=
>> "#{systemEnvironment['CONSISTENTID']}"/>
>> <property name="metricExporterSpi">
>> <list>
>> <bean class="org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi"/>
>> </list>
>> </property>
>> <property name="cacheConfiguration">
>> <list>
>> <bean id="partitioned-cache-template" abstract="true" class=
>> "org.apache.ignite.configuration.CacheConfiguration">
>> <property name="name" value="cache-partitioned*"/>
>> <property name="cacheMode" value="PARTITIONED" />
>> <property name="backups" value="0" />
>> <property name="statisticsEnabled" value="true"/>
>> <property name="queryParallelism" value="2"/>
>> <property name="partitionLossPolicy" value="READ_WRITE_SAFE"/>
>> </bean>
>> <bean id="replicated-cache-template" abstract="true" class=
>> "org.apache.ignite.configuration.CacheConfiguration">
>> <property name="name" value="cache-replicated*"/>
>> <property name="cacheMode" value="REPLICATED" />
>> <property name="statisticsEnabled" value="true"/>
>> <property name="partitionLossPolicy" value="READ_WRITE_SAFE"/>
>> </bean>
>> </list>
>> </property>
>> <!-- Enabling Apache Ignite Persistent Store. -->
>> <property name="dataStorageConfiguration">
>> <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
>> <property name="metricsEnabled" value="true"/>
>> <property name="defaultDataRegionConfiguration">
>> <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
>> <property name="persistenceEnabled" value="true"/>
>> <property name="metricsEnabled" value="true"/>
>> <property name="maxSize" value="#{2L * 1024 * 1024 * 1024}"/>
>> </bean>
>> </property>
>> </bean>
>> </property>
>> </bean>
>> 在 2021/1/27 下午6:24, Ilya Kasnacheev 写道:
>>
>> Hello!
>>
>> These values are per-node, as far as I know. Is it possible that you have
>> connected to a node which does not handle any queries (as reducer, anyway)?
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> вт, 26 янв. 2021 г. в 13:48, 38797715 <38...@qq.com>:
>>
>>> Hi,
>>>
>>> We found that SYS.METRICS View some data is always 0, such as
>>> QueryCompleted,QueryExecuted,QuerySumTime,QueryCompleted,QuerySumTime
>>> and QueryMaximumTime. This is a bug? Or what configuration is needed? Or
>>> the related functions have not been implemented yet?
>>>
>>>
Re: [2.9.1]in SYS.METRICS View some data is always 0
Posted by 38797715 <38...@qq.com>.
Hello Ilya,
if use sqlline execute sql,the feedback result of the following
statement is correct.
SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
I used SqlFieldsQuery again to do the above tests, and the results were
all 0. I think there may be a issue in this.
在 2021/1/28 下午6:52, Ilya Kasnacheev 写道:
> Hello!
>
> I think these metrics will be gathered for ScanQuery/SqlFieldsQuery
> executed via native Java Query API, but they will not be gathered for
> statements executed via JDBC.
>
> One obvious reason is that Java Query API's queries are bound to a
> specific cache. JDBC query is not bound to specific cache: JDBC query
> may operate on zero or more caches. We could map these queries back to
> participating caches, but I don't see that we do that.
>
> You could still use sql.queries.user. metrics:
> SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 27 янв. 2021 г. в 15:29, 38797715 <38797715@qq.com
> <ma...@qq.com>>:
>
> Hello Ilya,
>
> The test method is as follows:
>
> Start 2 nodes on the localhost.
> Use the CREATE TABLE statement to create a table;
> Use the COPY command to load some data;
> Access to cluster through sqlline;
> Execute select count (*) from T;
> Execute select * from sys.metrics WHERE name LIKE '%cache.T%';
> At this time, you will find that the relevant data are all 0, but
> the value of OffHeapEntriesCount is still correct.
>
> If you use sqlline to access another node, the result is the same.
>
> The configuration file to start the cluster is as follows:
>
> <beanid="ignite.cfg"class="org.apache.ignite.configuration.IgniteConfiguration">
> <propertyname="peerClassLoadingEnabled"value="true"/>
> <propertyname="consistentId"value="#{systemEnvironment['CONSISTENTID']}"/>
> <propertyname="metricExporterSpi">
> <list>
> <beanclass="org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi"/>
> </list>
> </property>
> <propertyname="cacheConfiguration">
> <list>
> <beanid="partitioned-cache-template"abstract="true"class="org.apache.ignite.configuration.CacheConfiguration">
> <propertyname="name"value="cache-partitioned*"/>
> <propertyname="cacheMode"value="PARTITIONED"/>
> <propertyname="backups"value="0"/>
> <propertyname="statisticsEnabled"value="true"/>
> <propertyname="queryParallelism"value="2"/>
> <propertyname="partitionLossPolicy"value="READ_WRITE_SAFE"/>
> </bean>
> <beanid="replicated-cache-template"abstract="true"class="org.apache.ignite.configuration.CacheConfiguration">
> <propertyname="name"value="cache-replicated*"/>
> <propertyname="cacheMode"value="REPLICATED"/>
> <propertyname="statisticsEnabled"value="true"/>
> <propertyname="partitionLossPolicy"value="READ_WRITE_SAFE"/>
> </bean>
> </list>
> </property>
> <!-- Enabling Apache Ignite Persistent Store. -->
> <propertyname="dataStorageConfiguration">
> <beanclass="org.apache.ignite.configuration.DataStorageConfiguration">
> <propertyname="metricsEnabled"value="true"/>
> <propertyname="defaultDataRegionConfiguration">
> <beanclass="org.apache.ignite.configuration.DataRegionConfiguration">
> <propertyname="persistenceEnabled"value="true"/>
> <propertyname="metricsEnabled"value="true"/>
> <propertyname="maxSize"value="#{2L * 1024 * 1024 * 1024}"/>
> </bean>
> </property>
> </bean>
> </property>
> </bean>
> 在 2021/1/27 下午6:24, Ilya Kasnacheev 写道:
>> Hello!
>>
>> These values are per-node, as far as I know. Is it possible that
>> you have connected to a node which does not handle any queries
>> (as reducer, anyway)?
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> вт, 26 янв. 2021 г. в 13:48, 38797715 <38797715@qq.com
>> <ma...@qq.com>>:
>>
>> Hi,
>>
>> We found that SYS.METRICS View some data is always 0, such as
>> QueryCompleted,QueryExecuted,QuerySumTime,QueryCompleted,QuerySumTime
>>
>> and QueryMaximumTime. This is a bug? Or what configuration is
>> needed? Or
>> the related functions have not been implemented yet?
>>
Re: [2.9.1]in SYS.METRICS View some data is always 0
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
I think these metrics will be gathered for ScanQuery/SqlFieldsQuery
executed via native Java Query API, but they will not be gathered for
statements executed via JDBC.
One obvious reason is that Java Query API's queries are bound to a specific
cache. JDBC query is not bound to specific cache: JDBC query may operate on
zero or more caches. We could map these queries back to participating
caches, but I don't see that we do that.
You could still use sql.queries.user. metrics:
SELECT * FROM sys.metrics WHERE name LIKE 'sql%' ORDER BY name;
Regards,
--
Ilya Kasnacheev
ср, 27 янв. 2021 г. в 15:29, 38797715 <38...@qq.com>:
> Hello Ilya,
>
> The test method is as follows:
>
> Start 2 nodes on the localhost.
> Use the CREATE TABLE statement to create a table;
> Use the COPY command to load some data;
> Access to cluster through sqlline;
> Execute select count (*) from T;
> Execute select * from sys.metrics WHERE name LIKE '%cache.T%';
> At this time, you will find that the relevant data are all 0, but the
> value of OffHeapEntriesCount is still correct.
>
> If you use sqlline to access another node, the result is the same.
>
> The configuration file to start the cluster is as follows:
> <bean id="ignite.cfg" class=
> "org.apache.ignite.configuration.IgniteConfiguration">
> <property name="peerClassLoadingEnabled" value="true"/>
> <property name="consistentId" value="#{systemEnvironment['CONSISTENTID']}"
> />
> <property name="metricExporterSpi">
> <list>
> <bean class="org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi"/>
> </list>
> </property>
> <property name="cacheConfiguration">
> <list>
> <bean id="partitioned-cache-template" abstract="true" class=
> "org.apache.ignite.configuration.CacheConfiguration">
> <property name="name" value="cache-partitioned*"/>
> <property name="cacheMode" value="PARTITIONED" />
> <property name="backups" value="0" />
> <property name="statisticsEnabled" value="true"/>
> <property name="queryParallelism" value="2"/>
> <property name="partitionLossPolicy" value="READ_WRITE_SAFE"/>
> </bean>
> <bean id="replicated-cache-template" abstract="true" class=
> "org.apache.ignite.configuration.CacheConfiguration">
> <property name="name" value="cache-replicated*"/>
> <property name="cacheMode" value="REPLICATED" />
> <property name="statisticsEnabled" value="true"/>
> <property name="partitionLossPolicy" value="READ_WRITE_SAFE"/>
> </bean>
> </list>
> </property>
> <!-- Enabling Apache Ignite Persistent Store. -->
> <property name="dataStorageConfiguration">
> <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
> <property name="metricsEnabled" value="true"/>
> <property name="defaultDataRegionConfiguration">
> <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
> <property name="persistenceEnabled" value="true"/>
> <property name="metricsEnabled" value="true"/>
> <property name="maxSize" value="#{2L * 1024 * 1024 * 1024}"/>
> </bean>
> </property>
> </bean>
> </property>
> </bean>
> 在 2021/1/27 下午6:24, Ilya Kasnacheev 写道:
>
> Hello!
>
> These values are per-node, as far as I know. Is it possible that you have
> connected to a node which does not handle any queries (as reducer, anyway)?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 26 янв. 2021 г. в 13:48, 38797715 <38...@qq.com>:
>
>> Hi,
>>
>> We found that SYS.METRICS View some data is always 0, such as
>> QueryCompleted,QueryExecuted,QuerySumTime,QueryCompleted,QuerySumTime
>> and QueryMaximumTime. This is a bug? Or what configuration is needed? Or
>> the related functions have not been implemented yet?
>>
>>
Re: [2.9.1]in SYS.METRICS View some data is always 0
Posted by 38797715 <38...@qq.com>.
Hello,
I know SQL_ QUERIES and SQL_ QUERY_ HISTORY.
I opened *org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi* in
the configuration file
A new METRICS view will be added.
在 2021/1/28 上午7:02, akorensh 写道:
> Hi, there is not a view called metrics, only node_metrics, see below
>
> Here are the docs for those views:
> https://ignite.apache.org/docs/latest/monitoring-metrics/system-views
>
>
> Looks like you might be referring to an SQL view, in which case there is a
> realtime one which will only show values when the query is executing and a
> historical one which shows data for queries that have already ran.
>
> https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#sql_queries
> https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#sql_queries_history
>
> <http://apache-ignite-users.70518.x6.nabble.com/file/t2533/views.jpg>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: [2.9.1]in SYS.METRICS View some data is always 0
Posted by akorensh <al...@gmail.com>.
Hi, there is not a view called metrics, only node_metrics, see below
Here are the docs for those views:
https://ignite.apache.org/docs/latest/monitoring-metrics/system-views
Looks like you might be referring to an SQL view, in which case there is a
realtime one which will only show values when the query is executing and a
historical one which shows data for queries that have already ran.
https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#sql_queries
https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#sql_queries_history
<http://apache-ignite-users.70518.x6.nabble.com/file/t2533/views.jpg>
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: [2.9.1]in SYS.METRICS View some data is always 0
Posted by 38797715 <38...@qq.com>.
Hello Ilya,
The test method is as follows:
Start 2 nodes on the localhost.
Use the CREATE TABLE statement to create a table;
Use the COPY command to load some data;
Access to cluster through sqlline;
Execute select count (*) from T;
Execute select * from sys.metrics WHERE name LIKE '%cache.T%';
At this time, you will find that the relevant data are all 0, but the
value of OffHeapEntriesCount is still correct.
If you use sqlline to access another node, the result is the same.
The configuration file to start the cluster is as follows:
<beanid="ignite.cfg"class="org.apache.ignite.configuration.IgniteConfiguration">
<propertyname="peerClassLoadingEnabled"value="true"/>
<propertyname="consistentId"value="#{systemEnvironment['CONSISTENTID']}"/>
<propertyname="metricExporterSpi">
<list>
<beanclass="org.apache.ignite.spi.metric.sql.SqlViewMetricExporterSpi"/>
</list>
</property>
<propertyname="cacheConfiguration">
<list>
<beanid="partitioned-cache-template"abstract="true"class="org.apache.ignite.configuration.CacheConfiguration">
<propertyname="name"value="cache-partitioned*"/>
<propertyname="cacheMode"value="PARTITIONED"/>
<propertyname="backups"value="0"/>
<propertyname="statisticsEnabled"value="true"/>
<propertyname="queryParallelism"value="2"/>
<propertyname="partitionLossPolicy"value="READ_WRITE_SAFE"/>
</bean>
<beanid="replicated-cache-template"abstract="true"class="org.apache.ignite.configuration.CacheConfiguration">
<propertyname="name"value="cache-replicated*"/>
<propertyname="cacheMode"value="REPLICATED"/>
<propertyname="statisticsEnabled"value="true"/>
<propertyname="partitionLossPolicy"value="READ_WRITE_SAFE"/>
</bean>
</list>
</property>
<!-- Enabling Apache Ignite Persistent Store. -->
<propertyname="dataStorageConfiguration">
<beanclass="org.apache.ignite.configuration.DataStorageConfiguration">
<propertyname="metricsEnabled"value="true"/>
<propertyname="defaultDataRegionConfiguration">
<beanclass="org.apache.ignite.configuration.DataRegionConfiguration">
<propertyname="persistenceEnabled"value="true"/>
<propertyname="metricsEnabled"value="true"/>
<propertyname="maxSize"value="#{2L * 1024 * 1024 * 1024}"/>
</bean>
</property>
</bean>
</property>
</bean>
在 2021/1/27 下午6:24, Ilya Kasnacheev 写道:
> Hello!
>
> These values are per-node, as far as I know. Is it possible that you
> have connected to a node which does not handle any queries (as
> reducer, anyway)?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 26 янв. 2021 г. в 13:48, 38797715 <38797715@qq.com
> <ma...@qq.com>>:
>
> Hi,
>
> We found that SYS.METRICS View some data is always 0, such as
> QueryCompleted,QueryExecuted,QuerySumTime,QueryCompleted,QuerySumTime
> and QueryMaximumTime. This is a bug? Or what configuration is
> needed? Or
> the related functions have not been implemented yet?
>
Re: [2.9.1]in SYS.METRICS View some data is always 0
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
These values are per-node, as far as I know. Is it possible that you have
connected to a node which does not handle any queries (as reducer, anyway)?
Regards,
--
Ilya Kasnacheev
вт, 26 янв. 2021 г. в 13:48, 38797715 <38...@qq.com>:
> Hi,
>
> We found that SYS.METRICS View some data is always 0, such as
> QueryCompleted,QueryExecuted,QuerySumTime,QueryCompleted,QuerySumTime
> and QueryMaximumTime. This is a bug? Or what configuration is needed? Or
> the related functions have not been implemented yet?
>
>