Mackerel blog #mackerelio

The Official Blog of Mackerel

Google Cloud Integration Release!

Hello. Mackerel team CRE Inoue (id:a-know) here. Last Thursday was one that should have been commemorated. The 17th marked the sixth year of Mackerel’s official release.

And to celebrate... well not really, but we’ve got a big release announcement.

The long-awaited Google Cloud Integration has been released! It’s available for use starting today!

Google Cloud Integration Release

You can configure Google Cloud Integration from the ‘Google Cloud Integration’ tab in your organization’s details page.

In order to use Google Cloud Integration, you’ll need to set up a service account. You can refer to the help page linked below for more details.

With today's release, you can now integrate and monitor the following 3 Google Cloud Platform services.

Check out the help pages linked below to see which metrics are available for each service.

We plan on expanding the list of services in the future. And in order to do this, we believe that feedback / requests from our users is essential to the development process. So please feel free to contact us via the inquiry form linked below!

The system will be temporarily shut down for scheduled maintenance in October and November

Thank you for choosing Mackerel.

As stated in the title, the system is scheduled to be temporarily shut down in order to carry out maintenance. The maintenance has been broken up into two intervals and the time schedule is laid out below. We apologize for the inconvenience, and thank you for your understanding.

October shutdown schedule

Date and time

  • October 14, 2020 (Wednesday) 2:30pm -4:30pm (JST)
    • The system will be temporarily shut down within the above time period

※This time window is the longest case scenario. The system will restart as soon as maintenance is complete.


  • Migration of Redis to Amazon ElastiCache

Areas affected during maintenance period

  • The scheduled time frame is the longest case scenario and will end as soon as the work has been completed
    • Once maintenance work has begun, the entire Mackerel system will shut down for a short period of time
  • Web access to Mackerel, data posting by the agent, API access (including the CLI tool), alert notifications, etc. will be unavailable during this time
  • As soon as the scheduled maintenance has been completed and working operation has been confirmed, the system shutdown will end and an announcement will be made
  • As for mackerel-agent metric posting, data will be buffered from mackerel-agent during the maintenance period and resent after maintenance has been completed
    • If resent properly, graphs during the maintenance period will also be displayed
    • Please note that if mackerel-agent is stopped or restarted before resending is complete, buffering data will be lost
    • Trying to start up mackerel-agent during maintenance will fail because communication with Mackerel cannot be made
    • Trying to transmit to mackerel during maintenance will fail and an error message will be output in the error log
  • External monitoring and cloud integration graphs may be incomplete during the maintenance period

November shutdown schedule

Date and time

  • November 25, 2020 (Wednesday) (JST)

※ The time will be announced one month before the scheduled date. Similar to the maintenance in October, we expect to carry out this maintenance during daytime hours.


Areas affected during maintenance period

  • The areas affected during November’s maintenance are the same as that of October.

Why we chose this time schedule

Due to the fact that users rely upon the Mackerel service for system monitoring, we came to the conclusion that the best time for a temporary shutdown is during the day when the majority of users are available to respond if necessary, rather than in the middle of the night. For this reason, we’ve scheduled the maintenance to take place during a weekday in Japan Standard Time.

On the other hand, we understand that it will be difficult to perform server operations and deploy applications during the daytime and we sincerely apologize for this inconvenience.

Consideration for our users is essential in determining an appropriate maintenance timeframe and something that we want to continue to improve. If you have any feedback, please let us know.


Situation reports will be made on the Mackerel status page (

We will also make periodical updates on our official Twitter account (

Related inquiries

Please send all inquiries regarding this matter to using the forms provided below.

Again, thank you for your understanding and cooperation.

Newly obtainable metrics added for AWS / ElastiCache Integration and more

Hello. Mackerel team CRE Inoue ( id:a-know) here with another update announcement.

Newly obtainable metrics added for AWS / ElastiCache Integration

These specification changes were announced on this blog a couple of weeks ago, and as scheduled, were released today the 7th. Check out the blog post linked below for details regarding the content.

Graph image URL added to the Webhook notification payload

Alerts that are detected/opened with Mackerel can be linked to various chat services and incident management tools by configuring notification channels. Webhook is one of the notification channels supported by Mackerel.

This mechanism lets you make a POST request for an arbitrary URL using JSON formatted information of the detected alert as the payload.

With this update, the graph image URL imageUrl is now included in the payload. If you’ve customized your notifications with our Webhook notification channel, we hope this helps you make your content even richer! certificate update

Hello. Mackerel team CRE Inoue (id:a-know) here.

This is an announcement regarding the update of the certificate. This certificate is primarily specified as the agent's communication point. We plan to carry out this update in late September.

As for the issue that occurred when last updating the certificate, please refer to the announcement made in the following article.

You can also check out the FAQ page linked below.

We have confirmed that this event may occur when the CA certificate of the host on which Mackerel agent is installed is outdated (when using CentOS 6 etc.). If this is the case, please update the ca-certificates package or update Windows as described in the FAQ page above.

The occurrence of a CA certificate becoming outdated and failing to establish SSL/TLS communication can occur in any case where SSL/TLS communication is performed from a host, and is not limited to Mackerel. Because of this, we recommend that you update your host’s CA certificate regularly.

As previously mentioned, this update is scheduled to be performed in late September. Please review the above information and take care of any necessary operations before the third week of September.

mackerel-container-agent issue regarding unusual connectivity alerts has been addressed and more

Hello. Mackerel team CRE Inoue (id:a-know) here with another update announcement.

mackerel-container-agent issue regarding unusual connectivity alerts has been addressed

An issue was discovered in mackerel-container-agent regarding connectivity alerts occurring at unusually unexpected times. This issue has been addressed in v0.4.0. If you think that this issue may apply to you, please consider using v0.4.0 of mackerel-container-agent.

The status of alerts that occur for host connectivity monitors can now be selected from an API

As was mentioned in a previous blog post, the alert status given to alerts when they occur for host connectivity monitors can be selected in the Web console. This can now be done from an API as well.

Check out the API documentation below.

Official support of mackerel-agent for Debian 8 has ended

In line with the end of Debian 8’s OS support, Mackerel has also officially ended support for the operation of mackerel-agent in Debian 8 environments.

Although official support has ended, mackerel-agent and server monitoring will still continue to run in Debian 8 environments, however, we cannot guarantee its operation with future updates. If this applies to you, please consider updating your OS soon.

【Spec Change Notice】New metric targets for AWS / ElastiCache Integration

Mackerel team CRE Inoue (id:a-know) here. Today we are announcing some new specification changes.

As stated in the title, newly obtainable metric targets are being added for AWS / ElastiCache Integration.

These changes may affect your usage fee regarding micro host conversion, particularly when using Redis. Continue reading below for more information.

Specification changes

Host Level metrics

The following metrics will be added.

  • elasticache.network_packets.out

For more information, please refer to the AWS documentation.

Redis metrics

The following metrics will be added.

  • Commands
    • elasticache.redis.commands.eval_based
    • elasticache.redis.commands.geo_spatial_based
    • elasticache.redis.commands.hyper_log_log_based
    • elasticache.redis.commands.pub_sub_based
    • elasticache.redis.commands.stream_based
  • Commands Latency
    • elasticache.redis.commands_latency.get_type
    • elasticache.redis.commands_latency.set_type
    • elasticache.redis.commands_latency.key_based
    • elasticache.redis.commands_latency.string_based
    • elasticache.redis.commands_latency.hash_based
    • elasticache.redis.commands_latency.list_based
    • elasticache.redis.commands_latency.set_based
    • elasticache.redis.commands_latency.sorted_set_based
    • elasticache.redis.commands_latency.eval_based
    • elasticache.redis.commands_latency.geo_spatial_based
    • elasticache.redis.commands_latency.hyper_log_log_based
    • elasticache.redis.commands_latency.pub_sub_based
    • elasticache.redis.commands_latency.stream_based
  • Other
    • elasticache.redis.active_defrag
    • elasticache.redis.cache_hit_rate
    • elasticache.redis.memory_percentage
    • elasticache.redis.average_ttl
    • elasticache.redis.fragmentation_ratio
    • elasticache.redis.replication_bytes
    • elasticache.redis.replication_lag
    • elasticache.redis.save_in_progress

For more information, please refer to the AWS documentation.


As a result of these specification changes, the maximum number of obtainable metrics will increase as outlined below.

  • ElastiCache / Memcached
    • The current number of 39 metrics will increase to 41 metrics.
  • ElastiCache / Redis
    • The current number of 22 metrics will increase to 50 metrics.

Please note, particularly with Redis, that exceeding the metric limit will cause the number to be converted into 2 micro hosts. (For more information regarding host conversion, refer to Handling of host conversion when plan limits are exceeded – Mackerel Support)

You can freely choose which metrics to obtain with AWS integration in the settings. These metrics will be obtained by default, so be sure to manage this as needed.

Scheduled release date

The release which includes these specification changes is scheduled for Monday, September 7th, 2020 (JST) .

These changes were implemented at the request of Mackerel users. We look forward to your feedback (feel free to contact our support team via the Mackerel Web Console).

Alert status can now be selected when an alert occurs with host connectivity monitors and more

Hello. Mackerel team CRE Inoue (id:a-know) here with another update announcement.

Alert status can now be selected when an alert occurs with host connectivity monitors

Among the various monitors that can be configured with Mackerel, ‘Host connectivity monitoring’ can detect when metric transmission from the agent (mackerel-agent) gets interrupted and issues an alert. However up until now, the status of this alert was fixed to critical. With this update, it is now possible to choose the status of an alert when it occurs.

Some users may not even be aware of host connectivity monitoring due to the fact that it’s already configured from the get-go. We recommend reviewing the page linked below.

New obtainable metrics added for AWS/RDS Integration

With this update, now up to 52 metrics are available for RDS Aurora, up to 51 for Aurora Serverless, and up to 24 metrics are available for other services. Be sure to check out the differences detailed in the link below. Also, please note that some metrics are supported for certain database engines while others may not.

OSS Updates


A bug in mackerel-plugin-linux that prevented some OS versions (Debian 10 / RHEL 8 / Ubuntu 20.04) from retrieving disk stats was fixed.


In check-log, {} is now supported for --file option specification (glob format). It is now possible to specify commands like the one below.

command = ["check-log", "--file", "/var/log/{secure,cron}", "-p", "timeout"]

Let us know what you think!