# PMM MySql 8.0.11 Instances Not Showing Graphs **URL:** \ **Category:** PMM 1.x\ **Created:** [December 18, 2018, 9:17am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748 "2018-12-18T09:17:14Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [December 18, 2018, 9:17am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/1 "2018-12-18T09:17:14Z")
I have a mixed environment of MySql 5.x and 8.0.11 Instances. The 5.x Instances are Enterprise and the 8.0.11 are Community. I have no issues in monitoring the MySql 5.x with PMM. The 8.0.11 instances do not gather all the data and the MySql Overview graphs are not populated (see attachment) How do I investigate further and correct. # Diagnostics [baasp@lcormysqlp01 ~]$ sudo pmm-admin check-network –-no-emoji PMM Network Status Server Address | SERVERIP Client Address | CLIENTIP - System Time NTP Server ([0.pool.ntp.org](http://0.pool.ntp.org)) | unable to get ntp time: %!s() PMM Server | 2018-12-18 14:38:14 +0000 GMT PMM Client | 2018-12-18 09:43:08 -0500 EST PMM Client to PMM Server Time Drift | 294s Time is out of sync. Please make sure the server time is correct to see the metrics. - Connection: Client → Server * * * SERVER SERVICE STATUS * * * Consul API OK Prometheus API OK Query Analytics API OK Connection duration | 1.350818ms Request duration | -544.205µs Full round trip | 806.613µs - Connection: Client ← Server * * * SERVICE TYPE NAME REMOTE ENDPOINT STATUS HTTPS/TLS PASSWORD * * * linux:metrics linux\_lcormysqlp01 CLIENTIP:42000 OK YES YES mysql:metrics mysql\_lcormysqlp01 CLIENTIP:42002 DOWN YES YES When an endpoint is down it may indicate that the corresponding service is stopped (run ‘pmm-admin list’ to verify). If it’s running, check out the logs /var/log/pmm-\*.log When all endpoints are down but ‘pmm-admin list’ shows they are up and no errors in the logs, check the firewall settings whether this system allows incoming connections from server to address:port in question. Also you can check the endpoint status by the URL: [http://SERVERIP/prometheus/targets](http://SERVERIP/prometheus/targets) # ENDPOINT STATUS - metrics-hr is the issue mysql (50/72 up) Endpoint State Labels Last Scrape Error [https://CLIENTIP:42002/metrics-lr](https://CLIENTIP:42002/metrics-lr) UP instance=“mysql\_lcormysqlp01” 30.96s ago [https://CLIENTIP:42002/metrics-hr](https://CLIENTIP:42002/metrics-hr) DOWN instance=“mysql\_lcormysqlp01” 139ms ago no token found [https://CLIENTIP:42002/metrics-mr](https://CLIENTIP:42002/metrics-mr) UP instance=“mysql\_lcormysqlp01” 45ms ago ![pmm_8011_mysqloverview_all_i_see.PNG](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/2X/f/f6a7193f61bcf95ef309929a09ae3ce9701ca21a.png) ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [December 18, 2018, 9:19am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/2 "2018-12-18T09:19:17Z")
Note that I have seen runs of sudo pmm-admin check-network –-no-emoji where the remote endpoint is OK for both linux:metrics and mysql:metrics. It makes no difference for the PMM graphs. ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [December 24, 2018, 9:46am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/3 "2018-12-24T09:46:36Z")
Hi, I just setup two new MySql 5.6 servers Bot show - Connection: Client ← Server * * * SERVICE TYPE NAME REMOTE ENDPOINT STATUS HTTPS/TLS PASSWORD * * * linux:metrics linux\_NAME01 ###.###.###.###:42000 DOWN YES YES mysql:metrics mysql\_NAME01 ###.###.###.###:42002 DOWN YES YES Yet both populate the graphs in PMM correctly. The issue appears to be MySql 8.0.11 specific… Could someone advise what to look into please? ---
**Author:** ![Roma\_Novikov](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/roma_novikov/32/1161_2.png) [@Roma\_Novikov](https://forums.percona.com/u/Roma_Novikov)\ **Post date:** [December 27, 2018, 4:33am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/4 "2018-12-27T04:33:12Z")
- System Time NTP Server ([0.pool.ntp.org](http://0.pool.ntp.org)) | unable to get ntp time: %!s() PMM Server | 2018-12-18 14:38:14 +0000 GMT PMM Client | 2018-12-18 09:43:08 -0500 EST PMM Client to PMM Server Time Drift | 294s Time is out of sync. Please make sure the server time is correct to see the metrics. * * * This can be related to some problems. Pls check ntp on your Client and Server ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 8, 2019, 11:08am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/5 "2019-01-08T11:08:13Z")
Roma, Thanks for the suggestion. It was badly out of sync and is now correct. Unfortunately this did not correct the problem. The issue is specific to MySql 8 Only the MySql graphs do not populate. Specifically if you wish to focus on one “MySql Client Thread Activity” does not populate. However I see two the do. “Process States” and “Top Process States Hourly”. What is different between MySql 5.6 and 8.x that would lead to this issue? Thanks, Peter ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 8, 2019, 1:02pm UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/6 "2019-01-08T13:02:41Z")
This is current status [baasp@server ~]$ sudo pmm-admin check-network –-no-emoji PMM Network Status Server Address | XXX.XXX.XXX.XXX Client Address | XXX.XXX.XXX.XXX - System Time NTP Server ([0.pool.ntp.org](http://0.pool.ntp.org)) | unable to get ntp time: %!s() PMM Server | 2019-01-08 18:28:09 +0000 GMT PMM Client | 2019-01-08 13:28:21 -0500 EST PMM Client to PMM Server Time Drift | OK - Connection: Client → Server * * * SERVER SERVICE STATUS * * * Consul API OK Prometheus API OK Query Analytics API OK Connection duration | 2.294508ms Request duration | -1.583215ms Full round trip | 711.293µs - Connection: Client ← Server * * * SERVICE TYPE NAME REMOTE ENDPOINT STATUS HTTPS/TLS PASSWORD * * * linux:metrics mysql80\_lcormysqlp01 XXX.XXX.XXX.XXX:42000 OK YES YES mysql:metrics mysql80\_lcormysqlp01 XXX.XXX.XXX.XXX:42002 DOWN YES YES When an endpoint is down it may indicate that the corresponding service is stopped (run ‘pmm-admin list’ to verify). If it’s running, check out the logs /var/log/pmm-\*.log When all endpoints are down but ‘pmm-admin list’ shows they are up and no errors in the logs, check the firewall settings whether this system allows incoming connections from server to address:port in question. Also you can check the endpoint status by the URL: [url][http://XXX.XXX.XXX.XXX/prometheus/targets[/url]](http://XXX.XXX.XXX.XXX/prometheus/targets%5B/url%5D) I have attached the current status from prometheus as well. ![Capture.PNG](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/2X/d/d30ced27dab15ae1e6c18c87dca56d6094b31932.png) ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 14, 2019, 7:58am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/7 "2019-01-14T07:58:04Z")
Does anyone have suggestions on how to diagnose and correct the issue please? ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 14, 2019, 1:52pm UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/8 "2019-01-14T13:52:39Z")
Using [url][http://www.dataarchitect.cloud/troubleshooting-percona-monitoring-and-management-pmm-metrics/[/url]](http://www.dataarchitect.cloud/troubleshooting-percona-monitoring-and-management-pmm-metrics/%5B/url%5D) I have been able to see that it is the High Resolution MySQL data that is not being gathered. I need to get a port opened before I can see the data stream directly in a browser now. In addition the client is on 1.16.0 and the server is running 1.17.0. This too is being addressed. But I don’t believe it is a factor as the issue has persisted for months. ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 14, 2019, 2:11pm UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/9 "2019-01-14T14:11:02Z")
Client now running 1.17.0 and issue persists On start of mysqld\_exporter we see: time=“2019-01-14T15:28:22-05:00” level=info msg=“Starting mysqld\_exporter (version=, branch=, revision=)” source=“mysqld\_exporter.go:331” time=“2019-01-14T15:28:22-05:00” level=info msg=“Build context (go=go1.10.1, user=, date=)” source=“mysqld\_exporter.go:332” time=“2019-01-14T15:28:22-05:00” level=info msg=“HTTP basic authentication is enabled” source=“mysqld\_exporter.go:386” time=“2019-01-14T15:28:22-05:00” level=info msg=“HTTPS/TLS is enabled” source=“mysqld\_exporter.go:401” time=“2019-01-14T15:28:22-05:00” level=info msg=“Enabled High Resolution scrapers:” source=“mysqld\_exporter.go:415” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.info\_schema.innodb\_metrics" source=“mysqld\_exporter.go:417” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.global\_status" source=“mysqld\_exporter.go:417” time=“2019-01-14T15:28:22-05:00” level=info msg=“Enabled Medium Resolution scrapers:” source=“mysqld\_exporter.go:421” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.info\_schema.processlist" source=“mysqld\_exporter.go:423” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.slave\_status" source=“mysqld\_exporter.go:423” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.perf\_schema.eventswaits" source=“mysqld\_exporter.go:423” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.perf\_schema.file\_events" source=“mysqld\_exporter.go:423” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.info\_schema.query\_response\_time" source=“mysqld\_exporter.go:423” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.info\_schema.innodb\_cmp" source=“mysqld\_exporter.go:423” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.info\_schema.innodb\_cmpmem" source=“mysqld\_exporter.go:423” time=“2019-01-14T15:28:22-05:00” level=info msg=“Enabled Low Resolution scrapers:” source=“mysqld\_exporter.go:427” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.global\_variables" source=“mysqld\_exporter.go:429” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.binlog\_size" source=“mysqld\_exporter.go:429” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.info\_schema.userstats" source=“mysqld\_exporter.go:429” time=“2019-01-14T15:28:22-05:00” level=info msg=" --collect.custom\_query" source=“mysqld\_exporter.go:429” time=“2019-01-14T15:28:22-05:00” level=info msg=“Listening on 192.168.72.192:42002” source=“mysqld\_exporter.go:438” time=“2019-01-14T14:37:23-05:00” level=info msg=“Starting mysqld\_exporter (version=, branch=, revision=)” source=“mysqld\_exporter.go:331” time=“2019-01-14T14:37:23-05:00” level=info msg=“Build context (go=go1.10.1, user=, date=)” source=“mysqld\_exporter.go:332” time=“2019-01-14T14:37:23-05:00” level=info msg=“HTTP basic authentication is enabled” source=“mysqld\_exporter.go:386” time=“2019-01-14T14:37:23-05:00” level=info msg=“HTTPS/TLS is enabled” source=“mysqld\_exporter.go:401” time=“2019-01-14T14:37:23-05:00” level=info msg=“Enabled High Resolution scrapers:” source=“mysqld\_exporter.go:415” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.info\_schema.innodb\_metrics" source=“mysqld\_exporter.go:417” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.global\_status" source=“mysqld\_exporter.go:417” time=“2019-01-14T14:37:23-05:00” level=info msg=“Enabled Medium Resolution scrapers:” source=“mysqld\_exporter.go:421” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.slave\_status" source=“mysqld\_exporter.go:423” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.info\_schema.processlist" source=“mysqld\_exporter.go:423” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.perf\_schema.eventswaits" source=“mysqld\_exporter.go:423” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.perf\_schema.file\_events" source=“mysqld\_exporter.go:423” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.info\_schema.query\_response\_time" source=“mysqld\_exporter.go:423” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.info\_schema.innodb\_cmp" source=“mysqld\_exporter.go:423” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.info\_schema.innodb\_cmpmem" source=“mysqld\_exporter.go:423” time=“2019-01-14T14:37:23-05:00” level=info msg=“Enabled Low Resolution scrapers:” source=“mysqld\_exporter.go:427” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.global\_variables" source=“mysqld\_exporter.go:429” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.binlog\_size" source=“mysqld\_exporter.go:429” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.info\_schema.userstats" source=“mysqld\_exporter.go:429” time=“2019-01-14T14:37:23-05:00” level=info msg=" --collect.custom\_query" source=“mysqld\_exporter.go:429” time=“2019-01-14T14:37:23-05:00” level=info msg=“Listening on 192.168.72.192:42002” source=“mysqld\_exporter.go:438” ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 14, 2019, 2:12pm UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/10 "2019-01-14T14:12:14Z")
Yet Prometheus shows “no token found” for [metrics-hr](https://192.168.72.192:42002/metrics-hr) ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 14, 2019, 2:48pm UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/11 "2019-01-14T14:48:05Z")
The current results of : sudo pmm-admin check-network –-no-emoji Are all GREEN (see attached). Yet I still do not have any data for Prometheus it still shows “no token found” for [metrics-hr](https://192.168.72.192:42002/metrics-hr) And hence the detailed graphs for MySql are blank. ![pmm_check_network.PNG](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/2X/3/356fa3384be9f595c5b8b9181d0b343f98dc966e.png) ---
**Author:** ![Peter](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/peter/32/2_2.png) [@Peter](https://forums.percona.com/u/Peter)\ **Post date:** [January 14, 2019, 3:07pm UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/12 "2019-01-14T15:07:00Z")
Hi, If you go to [url][https://192.168.72.192:42002/metrics-hr[/url]](https://192.168.72.192:42002/metrics-hr%5B/url%5D) with browser are you getting page with metrics or are you seeing something else Per: [url][https://github.com/prometheus/prometheus/issues/3154[/url]](https://github.com/prometheus/prometheus/issues/3154%5B/url%5D) Such behavior is possible if there is some malformed metric name. Might be in your installation such metric is reported for some reason ? ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 15, 2019, 7:33am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/13 "2019-01-15T07:33:00Z")
Peter, Thanks for the reply. I am just waiting on our internal team to open the ports so I may see [URL][https://192.168.72.192:42002/metrics-hr[/URL]](https://192.168.72.192:42002/metrics-hr%5B/URL%5D) from my PC. May take a few days:( I will report the results once I have them. But we are advancing and that is all that matters. Peter ---
**Author:** ![Peter](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/peter/32/2_2.png) [@Peter](https://forums.percona.com/u/Peter)\ **Post date:** [January 15, 2019, 8:01am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/14 "2019-01-15T08:01:11Z")
Hi, There is an easier way 🙂 You can log in to your server and use curl to get the output: curl -k [url][https://192.168.72.192:42002/metrics-hr[/url]](https://192.168.72.192:42002/metrics-hr%5B/url%5D) ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 16, 2019, 10:42am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/15 "2019-01-16T10:42:33Z")
Attached is output of curl -k -u admin:PASSWORDSECRET [https://192.168.72.192:42002/metrics-hr](https://192.168.72.192:42002/metrics-hr) There is some data returned with dash - but would it matter ? # TYPE go\_gc\_duration\_seconds summary go\_gc\_duration\_seconds{quantile=“0”} 2.6608e-05 go\_gc\_duration\_seconds{quantile=“0.25”} 4.1159e-05 go\_gc\_duration\_seconds{quantile=“0.5”} 5.0552e-05 go\_gc\_duration\_seconds{quantile=“0.75”} 7.095e-05 . . . # HELP mysql\_info\_schema\_innodb\_metrics\_adaptive\_hash\_index\_adaptive\_hash\_searches\_btree\_total Number of searches using B-tree on an index search . . . # HELP mysql\_info\_schema\_innodb\_metrics\_buffer\_buffer\_pool\_read\_ahead\_evicted\_total Read-ahead pages evicted without being accessed (innodb\_buffer\_pool\_read\_ahead\_evicted) It would appear to be gathering the data just not processing it:( Thanks in advance for reviewing and advising on this issue. Peter [curl\_output\_metric\_hr.txt](https://forums.percona.com/uploads/short-url/nQrcmMHbxxETD5YXnTs34HZMOJR.txt) (72.8 KB) ---
**Author:** ![Roma\_Novikov](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/roma_novikov/32/1161_2.png) [@Roma\_Novikov](https://forums.percona.com/u/Roma_Novikov)\ **Post date:** [January 16, 2019, 3:54pm UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/16 "2019-01-16T15:54:06Z")
[baasp](https://percona.vanillacommunities.com/profile/x/x/41678) cam you also check [url][Percona Monitoring and Management](https://www.percona.com/doc/percona-monitoring-and-management/faq.html#how-to-troubleshoot-communication-issues-between-pmm-client-and-pmm-server%5B/url%5D) and especially [url][Percona Monitoring and Management](https://www.percona.com/doc/percona-monitoring-and-management/deploy/index.html#deploy-pmm-diagnostics-for-support%5B/url%5D) section. Maybe we’ll found some ideas in the logs ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 21, 2019, 11:25am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/17 "2019-01-21T11:25:06Z")
Have any ideas based on the output been sparked? ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 22, 2019, 7:51am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/18 "2019-01-22T07:51:42Z")
Hi has the data provided sparked an insight into correcting the issue? ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 22, 2019, 7:55am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/19 "2019-01-22T07:55:23Z")
Sorry for the spam, my bad I had not noted the thread had gon over to a second page. Attached is the logs.zip from the server. [pmm-server\_2019-01-22-13-22.zip](https://forums.percona.com/uploads/short-url/agC88rIwpQ7aTZSV0ojWmGZqPsS.zip) (110 KB) ---
**Author:** ![baasp](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@baasp](https://forums.percona.com/u/baasp)\ **Post date:** [January 22, 2019, 7:58am UTC](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748/20 "2019-01-22T07:58:01Z")
Output of check-network [me@lcormysqld01 ~]$ sudo pmm-admin check-network –-no-emoji PMM Network Status Server Address | SERVER\_IP Client Address | CLIENT\_IP - System Time NTP Server ([0.pool.ntp.org](http://0.pool.ntp.org)) | unable to get ntp time: %!s() PMM Server | 2019-01-22 13:24:48 +0000 GMT PMM Client | 2019-01-22 08:26:25 -0500 EST PMM Client to PMM Server Time Drift | 97s Time is out of sync. Please make sure the server time is correct to see the metrics. - Connection: Client → Server * * * SERVER SERVICE STATUS * * * Consul API OK Prometheus API OK Query Analytics API OK Connection duration | 1.771548ms Request duration | -615.793µs Full round trip | 1.155755ms - Connection: Client ← Server * * * SERVICE TYPE NAME REMOTE ENDPOINT STATUS HTTPS/TLS PASSWORD * * * linux:metrics mysql80\_lcormysqld01 CLIENT\_IP:42000 OK YES YES mysql:metrics mysql80\_lcormysqld01 CLIENT\_IP:42002 DOWN YES YES When an endpoint is down it may indicate that the corresponding service is stopped (run ‘pmm-admin list’ to verify). If it’s running, check out the logs /var/log/pmm-\*.log When all endpoints are down but ‘pmm-admin list’ shows they are up and no errors in the logs, check the firewall settings whether this system allows incoming connections from server to address:port in question. Also you can check the endpoint status by the URL: [http://SERVER\_IP/prometheus/targets](http://SERVER_IP/prometheus/targets) [Next page](https://forums.percona.com/t/pmm-mysql-8-0-11-instances-not-showing-graphs/6748.md?page=2)