Hello! This is Sudo (
id:do-su-0805) from the Mackerel team CRE. Here are the details of the latest update.
- Multiple improvements to the Traces function
- Enabled the use of spans containing “http.url” as a tracking target for metrics displayed in HTTP Server Performance.
- Removed the span for the request transmission time (client time) as a tracking target for metrics displayed in HTTP Server Performance.
- The display range for Latency Distribution on the Trace List screen now displays slightly beyond the specified times.
- Services designated for traces, HTTP servers, and databases are now carried over when transitioning screens.
- Trace details now display a link to Explorer filtered by the post host information and approximate time of the trace
- The display now toggles between Japanese and English based on the user’s language settings
- 3D Secure identity authentication is now performed during credit card registration
- Made it clearer that a network error had occurred when filtering on the Hosts screen
Multiple improvements to the Traces function
We made multiple improvements to the Traces function, which we are currently providing as a beta version.
Enabled the use of spans containing “http.url” as a tracking target for metrics displayed in HTTP Server Performance.
Spans containing “http.route”, “url.path”, and “http.target” were tracked in HTTP Server Performance, but now it is possible to track spans which contain “http.url” as well.
As of OpenTelemetry Semantic Conventions 1.30.0 | OpenTelemetry, “http.url” has the Deprecated attribute, but “http.url” is used when AWS X-Ray data is collected by AWS X-Ray Receiver, so we added it as a target for tracking.
If you are an AWS X-Ray user, please try using AWS X-Ray Receiver to collect tracing data, and post it to Mackerel as well!
Removed the span for the request transmission time (client time) as a tracking target for metrics displayed in HTTP Server Performance.
The spans both for the request transmission time and the request reception time were tracked as spans aggregated in HTTP Server Performance if the spans were related to http. However, as we believe that reception data was the main thing users would want to track as HTTP Server Performance, we changed it so that the span for the transmission time is not tracked. As a result, when filtering targets to display such as services, it is now possible to do focused checks on data related to the filtered targets.
The display range for Latency Distribution on the Trace List screen now displays slightly beyond the specified times.
When specifying times on the Trace List, such as specifying 16:03 to 17:03 for example, Latency Distribution would use the display range of 16:00 to 17:00, so it was not possible to check distribution in the trace from 17:00 to 17:03.
We fixed this, and revised it so that when 16:03 to 17:03 is specified, the display range for Latency Distribution is 16:00 to 17:05.
It was difficult to see the latest Latency Distribution when you navigated to the Trace List, but this fix makes it easier to see.
Services designated for traces, HTTP servers, and databases are now carried over when transitioning screens.
Until now, clicking a Traces, HTTP server, or Database when using the trace feature would reset the service designation, making it necessary to reset the service you wanted to check every time, but we have revised it so that services designated on any screen are carried over when transitioning screens.
This has simplified tracing specific services and cross-sectional checks from a performance perspective.
Trace details now display a link to Explorer filtered by the post host information and approximate time of the trace
When displaying trace details, a link will now be displayed to check labeled metrics for the host that posted the trace if it meets the criteria.
If the trace has the “service.name” attribute and the “host.id” or “host.name” attribute, you can go to Explorer with filters applied for those attributes and the display range filtered to the approximate time the trace occurred!
(Of “host.id” and “host.name”, “host.id” is prioritized. Additionally, if it has the “service.namespace” attribute, this will also be included in the filtering criteria.)
This is a useful feature when you want to use labeled metrics to check the background or evidence for information obtained by a trace. Please take advantage of it!
The display now toggles between Japanese and English based on the user’s language settings
Until now, w only provided the tracing function in Japanese, but now it can also be displayed in English based on your Mackerel user settings! Language settings can be changed under your User Interface settings.
3D Secure identity authentication is now performed during credit card registration
In order to ensure the security of credit card payments in electronic transactions, identity authentication (EMV 3-D Secure) will become mandatory on e-commerce sites around the end of March 2025.
In accordance with this mandate, identity authentication will be performed when registering credit card information for use in payments through Mackerel. Identity authentication will be required for operations such as changing the credit card number. No additional action is necessary for credit card information that is already registered, but identity authentication may be requested depending on the processes or decisions of your credit card company.
Made it clearer that a network error had occurred when filtering on the Hosts screen
While it is possible to filter the Hosts screen by criteria such as service role and cloud integration, there was no feedback when a network error occurred while it was filtered, so it was difficult to know if it was properly filtered.
With this revision, when a network error occurs, a toast to that effect is now displayed. We apologize for the inconvenience, but please reset the filter criteria when a network error is displayed.
