MySQL Bugs: #120529: Contribution: Log a warning when history list length exceeds threshold

Bug #120529	Contribution: Log a warning when history list length exceeds threshold
Submitted:	22 May 17:08
Reporter:	OCA Admin (OCA)	Email Updates:
Status:	Open	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:		OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
This bug tracks a contribution by Tony Chen (Github user: tonychen2001), as described in http://github.com/mysql/mysql-server/pull/661

How to repeat:
See description

Suggested fix:
See contribution code attached

Contribution submitted via Github - Log a warning when history list length exceeds threshold (*) Contribution by Tony Chen (Github tonychen2001, https://github.com/mysql/mysql-server/pull/661#issuecomment-4510300768): I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it.

Contribution: git_patch_3710850663.txt (text/plain), 36.45 KiB.

I commented on this PR, link below and comment copied (I also need to comment in the bug because unclear if the comment on the PR will reach Oracle).

https://github.com/mysql/mysql-server/pull/661#issuecomment-4529187433

> innodb_disable_hll_notification	OFF	bool	Suppresses the warning entirely

I do not think this variable is needed: there is already [log_error_suppression_list](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_log_error_supp...) for that.

> Surfacing it in the error log makes the symptom discoverable to operators and log-aggregation pipelines without active monitoring.

I am not sure aiming at making all miss-configuration (or degraded states) discoverable to operators in the error log is the right thing to do.  Also, having a log-aggregation pipeline without having active monitoring is not a very common situation (I see you are from AWS, and maybe this applies to RDS, but still, not super common).

IMHO, miss-configuration or degraded states should be discoverable via metrics (Statues, InnoDB Mectrics, or P_S).  Active monitoring might not be needed, but running a tool connecting to MySQL an giving recommendation is the right way to do this, not cluttering the logs.

To achieve above, we could keep `innodb_hll_notification_threshold` and adding a InnoDB Metrics indicating the threshold has be crossed.

> I do not think this variable is needed: there is already [log_error_suppression_list](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_log_error_supp...) for that.

Ah yes, thanks for pointing that out.

> IMHO, miss-configuration or degraded states should be discoverable via metrics (Statues, InnoDB Mectrics, or P_S).  Active monitoring might not be needed, but running a tool connecting to MySQL an giving recommendation is the right way to do this, not cluttering the logs.
> To achieve above, we could keep `innodb_hll_notification_threshold` and adding a InnoDB Metrics indicating the threshold has be crossed.

Thank you for the feedback, what you're saying makes sense to me. The main purpose of this contribution was to surface this proposition of better observability of this degraded state. Adding an indicator to the InnoDB Metrics is certainly a reasonable way to do this. 
In any case, I hope some change in this direction can be included in MySQL.