Service Metrics really disabled?

[Stefan Klotz]

Hi,

we have disabled the Service Metrics via the CWP "serviceMetrics.enabled", which is set to false.

When opening the Dashboard, nothing will be displayed anymore and it also states, that Service Metrics are currently disabled.

But I'm wondering if there is still continious access to the appropriate mysql tables, because when I'm checking the amount of rows for the "service_metrics" table, it's still changing up and down.

Is this normal and what does this mean? And is the usage of the Service Metrics really disabled, especially in regards to the high usage of the database to collect data for each and every request?

How can I double check this? Or can I empty the Service Metrics tables?

Thank you!

 

Ciao Stefan

[Zhijun He]

service_metrics included data with different resolution (5  seconds/hourly/daily), after certain  time, the higher resolution data will be merged to lower resolution data, therefore counting the rows in service_metrics table doesn't tell what you want.

you may check the last timestamp, for example,

select max(start_time) from service_metrics;

[Stefan Klotz]

Hi Zhijun,

thanks for the answer. Yes, I suspect something like this already.

I checked your mysql-query, it provides me a unix timestamp from 28.03. in the evening, where I disabled the Service Metrics. So this seems to be correct and it will not be used anymore.

So can I also delete all the rows in this table, if I don't require these information anymore? And if so, what's the best mysql-query to do this job (delete/truncate)?

Thank you!

 

Ciao Stefan

[Zhijun He]

Dear Ciao,

1.

Since the metrics data will eventually be merged, the fine metrics data will not survive too long.

5 second bins live for 65 minutes
Hourly bins live for 7 days
Daily bins live for a year

 

The size of metrics tables is limited.

 

2.

the metrics tables have relationship to other table which is not just used for metrics,

eg.

CONSTRAINT `service_metrics_details_ibfk_1` FOREIGN KEY (`mapping_values_goid`) REFERENCES `message_context_mapping_values` (`goid`)

 

Base on 1 and 2, I would suggest just leave the data there, it's not easy to delete metrics data and keep the data consistency at the mean time.

 

Regards,

Mark

[Stefan Klotz]

And any idea, why the Service_metrics tables/Indexes are still in the innodb_buffer_pool?

mysql> SELECT table_name AS Table_Name, index_name AS Index_Name, count(*) AS Page_Count, sum(data_size)/1024/1024 AS Size_in_MB
    -> FROM information_schema.innodb_buffer_page
    -> WHERE table_name LIKE '%metrics%'
    -> GROUP BY table_name, index_name;
+---------------------+------------------+------------+------------+
| Table_Name          | Index_Name       | Page_Count | Size_in_MB |
+---------------------+------------------+------------+------------+
| ssg/service_metrics | i_sm_nodeid      |         81 | 1.01202965 |
| ssg/service_metrics | i_sm_pstart      |         73 | 1.01194859 |
| ssg/service_metrics | i_sm_servicegoid |        341 | 3.54005814 |
| ssg/service_metrics | nodeid           |         89 | 1.04245949 |
| ssg/service_metrics | PRIMARY          |         90 | 1.11831093 |
+---------------------+------------------+------------+------------+
5 rows in set (0.09 sec)

Is this normal? Or can this be avoid/totally disabled?

Thank you!

 

Ciao Stefan