Pinging code owners:

• receiver/mysql: @djaglowski

See Adding Labels via Comments if you do not have permissions to add labels yourself.

OTLP doesn't support uint64, unfortunately.

mysql.buffer_pool.pages is marked as non-monotonic sum. But such a huge number makes it sound like it's actually a plain monotonic sum. In that case, we can probably just drop the first bit of uint64, because we care more about the difference between the scrapes rather than the magnitude of each value...

Removing needs triage based on a path forward being proposed by a project maintainer.

mysql.buffer_pool.pages is marked as non-monotonic sum. But such a huge number makes it sound like it's actually a plain monotonic sum. In that case, we can probably just drop the first bit of uint64, because we care more about the difference between the scrapes rather than the magnitude of each value...
@dmitryax
going through the logs, it does not look like it’s a monotonically increasing counter. I used awk to preserve the order.

perl -nle'print $& while m{failed to parse int64 for MysqlBufferPoolPages, value was\s+\K\d+}g' ~/Downloads/extract-2024-10-02T01_12_38.009Z.csv | awk '!a[$0]++'                         ok
18446744073709551264
18446744073709551265
18446744073709551266
18446744073709551271
18446744073709551267
18446744073709551276
18446744073709551272
18446744073709551270
18446744073709551284
18446744073709551306
18446744073709551269
18446744073709551275
18446744073709551285
18446744073709551287
18446744073709551321

Example of full log statement showing the timestamp and value not always incrementing:

1- 18446744073709551264 at 2024-10-02T01:12:07.891Z

"2024-10-02T01:12:07.891Z","""splunk-otel-collector-k8s-cluster-receiver-6864bbf5-pc6px""","""splunk-otel-collector""","2024-10-02T01:12:06.163Z        error   scraperhelper/scrapercontroller.go:197  Error         scraping metrics  {""kind"": ""receiver"", ""name"": ""mysql/primary"", ""data_type"": ""metrics"", ""error"": ""failed to parse int64 for MysqlBufferPoolPages, value was 18446744073709551264: strconv.ParseInt:    parsing \""18446744073709551264\"": value out of range"", ""scraper"": ""mysql""}"

2- 18446744073709551271 at 2024-10-02T00:21:24.036Z

"2024-10-02T00:21:24.036Z","""splunk-otel-collector-k8s-cluster-receiver-6864bbf5-pc6px""","""splunk-otel-collector""","2024-10-02T00:12:06.162Z        error   scraperhelper/scrapercontroller.go:197  Error         scraping metrics  {""kind"": ""receiver"", ""name"": ""mysql/primary"", ""data_type"": ""metrics"", ""error"": ""failed to parse int64 for MysqlBufferPoolPages, value was 18446744073709551271: strconv.ParseInt:    parsing \""18446744073709551271\"": value out of range"", ""scraper"": ""mysql""}

3- 18446744073709551269 at 2024-10-01T22:15:54.667Z

"2024-10-01T22:15:54.667Z","""splunk-otel-collector-k8s-cluster-receiver-6864bbf5-pc6px""","""splunk-otel-collector""","2024-10-01T22:06:06.155Z        error   scraperhelper/scrapercontroller.go:197  Error         scraping metrics  {""kind"": ""receiver"", ""name"": ""mysql/primary"", ""data_type"": ""metrics"", ""error"": ""failed to parse int64 for MysqlBufferPoolPages, value was 18446744073709551269: strconv.ParseInt:    parsing \""18446744073709551269\"": value out of range"", ""scraper"": ""mysql""}"

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• receiver/mysql: @djaglowski

See Adding Labels via Comments if you do not have permissions to add labels yourself.

any updates on this?
version 0.110.3 with the same issue

I'm not sure this is it, but here is a modest attempt. Since time is reported in picoseconds, the scraper currently divides all values by 1000 at recording time. I moved up the division to SQL and we will get nanos instead, and they will likely not overflow.
This fix doesn't solve the whole problem ; it has the benefit of being a no-op functionality wise.

Let's see if it passes review: #36879

Closed by #36879

Hang on, I don't know how to attend to MysqlBufferPoolPages yet.

I have done more digging and found this interesting tidbit:
https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html#statvar_Innodb_buffer_pool_pages_misc

When using compressed tables, Innodb_buffer_pool_pages_misc may report an out-of-bounds value (Bug #59550).

Here is the bug:
https://bugs.mysql.com/bug.php?id=59550

The bug mentions this type of value:

Seeing same on 5.5.24 on Debian Squeeze, with compression enabled on one huge table.

| Innodb_buffer_pool_pages_data         | 116915               |
| Innodb_buffer_pool_pages_dirty        | 206                  |
| Innodb_buffer_pool_pages_misc         | 18446744073709532994 |
| Innodb_buffer_pool_pages_total        | 98304                |

I recommend we deal with this issue for this particular metric by not recording it and not reporting an error, instead choosing to report a warning with a reference to the bug report. Please let me know if this path is advisable.

EDIT: I have opened this PR for your review which implements the fix outlined in this comment.
#36914