Hello! This is Sudo (id:do-su-0805) from the Mackerel CRE team. Here are the details on our latest update.
- We’re making improvements to our APM feature
- Fixed a bug where the resend option did not work in query monitor
- Changed design so that connectivity monitor will be performed on unresponsive hosts after downtime ends
- Added statusChangedAt for timing of alert status changes to webhook notifications
- Alert group notification emails now include information about the originating alerts
- A graph will now be displayed if at least one metric is posted within the display period
- Expanded range of title information for URLs generated via "Share graph"
- Fixed an issue where "ECS" would appear twice when filtering by cloud integration
- check-ntservice plugin now allows for overwriting alert status with the --status-as option
- You can now retrieve alert logs using mkr
- We published an example of an application error investigation starting with traces
- Mackerel will be exhibiting at AWS Summit Japan 2025, held June 25th and June 26th, 2025
We’re making improvements to our APM feature
We’re making ongoing improvements to Mackerel’s APM feature, which was officially released on May 1st.
You can now check trace information directly from the Traces tab on the APM screen
Previously, clicking the Traces tab would take you to a dedicated page, but with this improvement, you can now check trace information without having to transition to another page, just like with the Summary tab.
The filter in the Traces tab enables advanced filtering by attribute and resource, in addition to trace ID!
It is now possible to filter by version on each APM screen
It is now possible to filter by version on the Summary, Traces, HTTP Server, and Database screens of the APM feature.
In addition to filtering by environment (deployment.environment.name) as before, you can now filter by the version set for service.version.
You can now check usage fees under span-based billing
Span-based billing for the APM feature has begun, starting with usage in May 2025 (June 2025 billing cycle). As a result, you can now check your usage under span-based billing in the billing information section of the Plan tab.
*Customers who pay by invoice should check the invoice that we will send.
Fixed a bug where the resend option did not work in query monitor
There was a bug in Query monitor where notifications would not be resent according to the "Notification interval" that was set. We have fixed this bug and confirmed that alert notifications are now resent according to the setting. We apologize for any inconvenience this may have caused to users.
Changed design so that connectivity monitor will be performed on unresponsive hosts after downtime ends
Previously, connectivity monitor alerts that were suppressed during downtime would not be sent after the downtime ended. Because of that, people commented that they could not detect anomalies when the server did not start normally after a planned shutdown.
In order to resolve this issue, we changed the downtime feature. A connectivity monitor alert will now be sent if the connection with a host is lost during downtime, and the connection is also not restored after the downtime ends.
For example, in a case where an 8-hour downtime is set up to shut down the server from 10:00 p.m. to 6:00 a.m. the next morning, if there is no communication from the server as of 6:00 a.m., a connectivity alert will be sent at 6:00 a.m. To prevent unintended alerts, please make adjustments such as extending the end time of the downtime to a time when communications from mackerel-agent will be reliably restored (e.g., 6:05 a.m.).
Added statusChangedAt for timing of alert status changes to webhook notifications
We added a statusChangedAt field to the alert information sent by webhooks and AWS EventBridge notification channels to indicate the timing of status changes.
This will enable you to calculate how long the current status has continued, for example, when there are repeated WARNING and CRITICAL status alerts (flapping).
For more information, please refer to the following documentation.
Alert group notification emails now include information about the originating alerts
Previously, alert group email notifications did not include information about which alerts caused the alert groups to open. This improvement enables you to check the details of the alerts included in an alert group in the email notification, just like with Slack notifications.
A graph will now be displayed if at least one metric is posted within the display period
Until now, when you wanted to check posted metrics on the graph, if there were not more than a certain number of metrics posted within the display period (30 minutes, 1 day, etc.), you would see "No data exists for the selected period," and you could not view the metrics. This has now been fixed so that if at least one metric has been posted within the display period, the graph will be drawn, enabling you to view the metrics!
This change is discussed in the entry below, so please check the link for more information.
Expanded range of title information for URLs generated via "Share graph"
You can use the "Share graph" function at the upper right of a graph to generate a graph link tailored to the paste destination. The range of information in the titles provided for the generated graph links has been expanded.
When you copy graph links for "Title and URL," "Markdown," "Cosence," and "HTML," the titles will be as follows.
- Host metrics
- Host name: Graph definition name
- Service metrics
- Service name: Graph definition name
- Role graphs
- Service name: Role name: Graph definition name
Fixed an issue where "ECS" would appear twice when filtering by cloud integration
With cloud integration-based filtering on the host list screen, two "ECS" items would appear, which caused confusion. This issue has been resolved, and the labels have been modified for greater clarity as follows.
- The items have been separated into "ECS Cluster" and "ECS Task on EC2."
- "Fargate" has been renamed "ECS Task on Fargate"
check-ntservice plugin now allows for overwriting alert status with the --status-as option
The check-ntservice plugin generates a CRITICAL alert if it detects a shutdown of the applicable service or an information retrieval failure. Using the newly added --status-as option will enable you to overwrite this alert status as desired.
For example, if you specify --status-as CRITICAL=WARNING, an alert that would normally be CRITICAL will be sent as WARNING.
This feature is available for the check-ntservice included with the Windows version of mackerel-agent v0.85.0 and later.
You can now retrieve alert logs using mkr
The API was recently released for the alert log retrieval feature, and now this feature can also be used with the CLI tool mkr.
You can retrieve specified alert logs by running mkr alerts logs <alert ID>.
This functionality is available for mkr v0.61.0 and later.
We published an example of an application error investigation starting with traces
We published an article by a Mackerel engineer on using traces instead of logs when investigating errors in web apps. The article explains specific steps and how to read trace information using Mackerel, so please take a look.
Mackerel will be exhibiting at AWS Summit Japan 2025, held June 25th and June 26th, 2025
Mackerel will have a booth at AWS Summit Japan 2025, which will be held at Makuhari Messe on Wednesday, June 25th and Thursday, June 26th, 2025.
At our booth, we will be focusing on our officially released APM (Application Performance Monitoring) feature while showcasing Mackerel, which facilitates more practical observability through visualization of both infrastructure and applications.
At the venue, you will be able to actually see our APM feature in action, and we will be answering your questions about the product at our booth. We hope you'll take advantage of this opportunity to see Mackerel's new features firsthand.
