Percona Monitoring and Management 2.33.0¶
Release date: | Dec 13, 2022 |
---|---|
Installation: | Installing Percona Monitoring and Management |
Percona Monitoring and Management (PMM) is an open source database monitoring, management, and observability solution for MySQL, PostgreSQL, and MongoDB.
Important
PMM upgrade fails for versions prior to 2.33.0. Although there is a workaround, we highly recommend using the latest version of PMM. This ensures that you have access to the latest PMM features and that your environment runs on the latest version of the underlying components with all the bug fixes in place.
Release Highlights¶
Offline metric collection¶
Starting with PMM 2.33.0, we have introduced a new solution to prevent data collection interruption in PMM, via offline metric collection. A network outage between the PMM server and the client prevented metrics from being collected. As a result, the historical data was lost, which can be useful when analyzing trends, diagnosing problems, or investigating issues from a previous period.
In order to address the problem mentioned above, for the PMM server and PMM client running version 2.33.0, in case of a brief outage or network issue, metrics are stored on the monitored instance until the PMM server is up and running. At this point, the metrics will be pushed to the server. It only applies to PMM Clients that run in push mode, which is the default mode. The same holds when a brief network outage occurs on the client side.
Caution
The client node can currently store only 1 GB of offline data. So, for example, if your instance is down for three days, all the data will not be retrieved.
With the implementation of the above feature, we have taken the first step toward PMM HA. Furthermore, we are happy to provide a roadmap for PMM HA implementation, a much-anticipated solution by our users. In the event of a failover, your PMM setup will experience near-zero downtime, and monitoring will continue with the offline metric collection.
To ensure a smooth rollout, PMM HA will be introduced in phases, in line with your requirements and feedback.
Important
PMM HA will be rolled out in three stages. Stage one of PMM HA is the implementation to prevent data collection interruption with VictoriaMetrics integration for short outages included as part of PMM 2.33.0. HA stages two and three will be rolled out next year.
The following features/use cases will be covered as part of the various stages of PMM HA:
Stages of PMM HA | Solutions Provided |
---|---|
Stage one (included in PMM 2.33.0) | As an initial step towards preventing data collection interruption, we have developed the following: Prevent data collection interruption with VM integration for short outages |
Stage two (will be rolled out in 2023) | As part of PMM HA stage two, we plan to implement the following: HA data sources As part of stage two we will let the users use external data sources, thereby decreasing dependency on the file system. |
Stage three (will be rolled out in 2023) | As part of PMM HA stage three, we plan to implement the following: Clusterized HA Clustered PMM will be the focus of stage three. Detailed information will be included in the upcoming release notes. |
Guided tour of Percona Alerting¶
Following the recent improvements to PMM Alerting, we have added a short tutorial to help you explore our streamlined alerting system based on Grafana. The in-app tutorial automatically pops up when you first open the Alerting page to help you uncover the fundamentals of Percona Alerting.
Restore MongoDB backups easier¶
Building on the significant improvements for MongoDB Backup Management introduced in the previous release. We are now simplifying the process for restoring physical MongoDB backups. Starting with this release, you can restore physical backups straight from the UI, and PMM will handle the process end-to-end. Prior to this, you would require to perform additional manual steps to restart your MongoDB database service so that your applications could make use of the restored data.
Components Upgrade¶
- VictoriaMetrics has been upgraded from 1.77.1 to 1.82.1.
- As part of PMM 2.33.0, Grafana has been updated to 9.2.5, which fixes some critical vulnerabilities. For more information, see Grafana 9.2.5
New Features¶
-
PMM-10889 - Starting with PMM2.33.0, while using the pmm-admin CLI command, you do not have to know the entire command. Just type the initial command and press Tab. The rest of the command will be autocompleted.
Depending on the shell you are using, add the following to your shells .rc file for autocomplete to work:
source <(pmm-admin completion -c <your shell>) E.g. source <(pmm-admin completion -c bash)
-
PMM-10955: [Backup Management]: After restoring a backup, you can now check the time when the restore was finalized. For PITR backups, you can also check the time to which the restore was performed. This information is available on the tab Backup > Restores page, in the new Finished at column, and in the PITR timestamp field under the Actions menu.
Improvements¶
-
PMM-7000: [HA]: Staring with PMM 2.33.0, if the PMM Server goes down, metrics will be buffered on the monitored instance until PMM Server goes back online, which is when metrics will get pushed to the PMM Server.
-
PMM-10901: [Documentation]: To enable the users to use High Availability easily, we have added exclusive documentation for HA.
-
PMM-8516: [Backup Management]: When creating a backup, the Vendor field was not automatically populated in the Back-up on demand dialog. This issue is now fixed.
-
PMM-10627: [DBaaS]: You can now create a single node cluster for PSMDB.
-
PMM-10855: Avoid massive gRPC messages formatting for disabled log level
-
PMM-10903: [DBaaS]: To simplify DBaas, you no longer have to manually enter the Public Address on the PMM Settings > Advanced Settings page. With DBaaS enabled, PMM will automatically detect and populate the Public Address.
-
PMM-11085: [Backup Management]: We’ve removed the Create backup option under All backups page > Actions menu because this option can only create on-demand backups. You can continue to create both on-demand and scheduled backups using the Create backup button on this page.
-
PMM-10881: [CVE]: As part of PMM 2.33.0, Grafana was updated to 9.2.5, which fixes some critical vulnerabilities. For more information, see Grafana 9.2.5.
-
PMM-10385: Starting with PMM 2.33.0, for MySQL, the Explain tab is supported without the Examples tab. If a query in the Explain tab contains sensitive data, placeholders will replace them.
-
PMM-8655: Latest state of agents is now available on the PMM server after the connection is re-established between the client and server.
-
PMM-10969: VictoriaMetrics operator has been upgraded from 0.24 to 0.29.0.
-
PMM-10554: Postgres collector now provides runtime duration for scrapes at the collector level. As a result, we can identify collectors who take too long. By utilizing this data, corrective action can be taken.
-
PMM-10629: [Components Upgrade]: VictoriaMetrics has been upgraded from 1.77.1 to 1.82.1.
Bugs Fixed¶
-
PMM-10858: In specific environments, including AWS, some EPEL repository mirrors did not respond within the time limit defined by
pmm-update
, currently set to 30 seconds. This was causingsupervisord
to killpmm-update-checker
, the component responsible for verifying if a newer version of the PMM Server is available for upgrade. This issue has been resolved now. -
PMM-10683: [DBaaS]: While registering a K8s cluster on the Manage Components Versions modal, the versions were not getting unchecked. The issue has now been resolved.
-
PMM-11082: When adding RDS MySQL instances to PMM, some queries pertaining to table stats were executed, despite table stats being disabled.
-
PMM-10637: Fixed an issue where the queries for some panels on the PostgreSQL Instance Summary dashboards were broken.
-
PMM-11029: Whenever the
max-query-length
parameter was set to 3, 2, or 1, the PMM agent would be terminated. The issue has now been resolved. -
PMM-10732: Checking the select all checkbox on the Services, Agents, and Nodes modal in the PMM Inventory window deleted all entries on all the pages. The issue has been resolved now.
-
PMM-10062: While monitoring a large number of nodes, some dashboards had incredibly long load times, resulting in an unresponsive UI. The issue has been fixed now.
-
PMM-10983: Some panels on the dashboards were showing only short names. The issue has been resolved now.
-
PMM-11041: There was typo on the Home dashboard: COMMAND CENTER graphs. This has been fixed now.
-
PMM-10996: [Backup Management]: Fixed an issue where the initial description text for a storage location could not be updated.
-
PMM-10718: [Backup Management]: When taking backups, PMM now shows a clearer error if the pmm-agent is incompatible with the specified backup operation.
-
PMM-10558: Top 5 Collections by Documents Changed panel on the MongoDB Collection Details dashboard did not display data correctly based on the selected filters. It has now been resolved.
-
PMM-10493: [Portal Integration]: In some specific scenarios, disconnecting from Platform Portal as an Administrator would sometimes show a token error. This issue is now fixed.
-
PMM-10845: [Advisors] Fixed specific error that occurred when working with Advisors that do not specify a frequency for executing the advisor check.
-
PMM-10029: There was a potential issue with the network request exceeding the maximum message size. The issue has been resolved now.
Known issues¶
-
PMM-11126: PMM server cannot be upgraded to version 2.32.0
A bug in PMM Server ansible scripts caused PMM to upgrade Nginx’s dependencies without updating Nginx itself. Due to this, PMM throws an error while upgrading and cannot upgrade to a newer version.
Important
This issue has been resolved for PMM version 2.33.0. However, the issue persists on all the versions prior to 2.33.0.
Solution
While PMM is being upgraded, log in to the PMM server and run the following command:
sed -i 's/- nginx/- nginx*/' /usr/share/pmm-update/ansible/playbook/tasks/update.yml
-
PMM-10858: PMM server does not show latest versions available with the instances created with AWS
For PMM versions prior to 2.33.0, in specific environments, including AWS, some EPEL repository mirrors did not respond within the time limit defined by pmm-update (currently set to 30 seconds). It was causing supervisord to kill pmm-update-checker, which determines if a newer PMM Server is available for upgrade.
Solution
Log in to the PMM Server and run the following command as a root user:
$ yum-config-manager --setopt=epel.timeout=1 --save
Get expert help¶
If you need assistance, visit the community forum for comprehensive and free database knowledge, or contact our Percona Database Experts for professional support and services.