Hello. I'm 
id:RyuGoo, Sub-Director of the Mackerel team and head of product management.
Mackerel already supports OpenTelemetry-format metrics and traces. To further strengthen observability, we are developing a new feature that adds logs to this lineup, with a target release window of summer to autumn 2026.
In this post, I'd like to share the thinking behind the "Mackerel's log feature" currently in development.
- Who is this log feature for?
- The experiences and features we plan to offer first
- The road ahead
- Sign up for Mackerel to receive the latest updates by email
Who is this log feature for?
"Logs" is a broad term covering many things. Some need to be retained long-term and intact for auditing or security; others are simply text records of events occurring in systems or applications.
We have long received many requests for log support in Mackerel. Given the diversity of these requests, it took us time to decide which needs to address first.
So we returned to first principles — the idea of observability: making it possible to infer why a problem occurred from a system's output. Our desire to deliver that capability through Mackerel became the guiding axis for this log feature's direction.
Logs for the team
When you want to identify a problem in a system, the typical setting is incident response. We started by interviewing infrastructure and software engineers, both internal and external, about how logs are used in incident response, and what challenges their teams face.
Three things emerged from our research:
- When a problem occurs, many people first look at the logs to get a sense of "what's happening."
- However, simply grasping where the logs are and what kinds of logs exist is itself difficult, and knowledge tends to be unevenly distributed among team members.
- As a result, log-driven incident response becomes siloed within the team, dependent on specific individuals.
This reminded us of one of Mackerel's signature ideas: "monitoring you cultivate" (育てる監視). If we could offer a log feature that's easy for teams to use and understand, delivered in a way that feels distinctly Mackerel, we believed we could help solve these incident-response challenges.
Usable by the team, reproducible by the team
What we learned through the interviews is that "just looking at the logs first" has become one of the first actions engineers take during incident response, regardless of whether they work on applications or infrastructure. At the same time, it became clear that the crucial information — "where to look" and "what to look at" — is often poorly organized, or concentrated in a few specific members, and many teams struggle to use logs effectively across the organization.
The concentration of log expertise in a few members is a particularly significant challenge. The knowledge that experienced engineers have unconsciously built up — "where to look, and how to look at it" — tends to remain as tacit knowledge, never written down.
As a result, even when the same problem recurs, the gap between those who can respond and those who can't never closes. And for the experienced engineers being relied upon, being expected to handle every incident becomes a burden. A state where knowledge is concentrated in individuals is hardly a sustainable operational model for a team.
This is why, with Mackerel, we want to deliver logs as "an experience the team can use together." The concept we've set for this is: "expert operations, reproducible by the team."
Specifically, we'll provide a mechanism that lets teams share and reproduce the search and filtering operations that experienced engineers use to pull the information they need from logs. Beyond simply sharing search conditions, we want to make it possible to also record the context — "in what situations is this search used?" — so members who are still learning the system have clues to deepen their understanding.
What Mackerel's log feature aims for is not merely a tool that's easy for less-experienced users. It's about building an organizational state where logs can be used effectively — through a mechanism that lets the whole team reproduce and accumulate the insight of experienced engineers.
The experiences and features we plan to offer first
In incident response, engineers often move between multiple tools and log files between detecting an alert and identifying the cause. With the Mackerel's log feature, we aim to make this "detection-to-investigation" flow proceed as smoothly as possible within Mackerel. The two experiences we'll offer in the first release are designed from this starting point, with team usability in mind.
To strengthen system observability, we previously added support for metrics and traces in alignment with OpenTelemetry, the industry standard for observability. We'll handle logs in the same way, following the format defined by OpenTelemetry.
Viewing logs at the service level
Rather than viewing things like cron execution logs, database logs, and application logs separately as individual components, we want to make it possible to view logs across components at the "service level." By grouping the chain of systems that together fulfill a single role — cron, databases, applications, and so on — as a service, you can grasp the situation in service-level units, without having to think about where each individual log resides.
This connects naturally to the experience Mackerel APM offers. Mackerel APM is also designed to handle trace information at the service level, and being able to view logs at the same granularity lets you move between them with a consistent perspective.
To take incident response as an example: when an alert fires for a specific service, being able to immediately reference the logs tied to that service translates directly into faster situational awareness. You no longer need to hunt around for which host and which path holds the relevant logs, and you can face the question of "what's happening in this service?" head-on.
Filtering with reference to saved past filter conditions
Even once you can view logs at the service level, knowing what kinds of logs a given service emits — and where to look during incident response to efficiently grasp the problem — is knowledge built through experience. As a result, a gap emerges between experienced members and others, and the burden of incident response tends to concentrate on the experienced ones.
What Mackerel's log feature offers in response to this challenge is a mechanism for "reproducing expert operations." The experience itself is simple: save a search condition together with a note, and any member of the organization can pull up the same search condition simply by selecting it from a list.
This means experienced engineers can leave behind the search conditions they frequently use during incident response, along with context on the background and when to apply them. And even when those experienced engineers aren't around, team members can immediately start exploring logs based on the saved conditions. Accumulating insight on log usage — which tends to be siloed in individuals — as a shared team asset: that's what Mackerel's log feature aims for.
The road ahead
Beyond the two experiences introduced here — "viewing logs at the service level" and "filtering with reference to saved past filter conditions" — we're already looking ahead to further log-driven experiences. For example, being able to generate alerts from logs, immediately reference logs from the moment an alert fires, or narrow down the root cause by cross-referencing Mackerel APM traces would make the incident response flow far more coherent. Detect anomalies with metrics, follow the flow of processing with traces, and confirm the details with logs. A state in which anyone on the team can complete this entire investigation within Mackerel — that's the vision of observability we're aiming for.
As a longer-term outlook, we're also exploring AI-powered log experiences. Examples include narrowing down information relevant to a problem from large volumes of logs, or surfacing hypotheses about possible causes of errors — experiences where AI helps you step into log investigation.
By having AI point to clues for what to do next after the initial "just look at the logs" step, even non-experts can more easily find a starting point for investigation. Combined with the mechanism for saving and reproducing search conditions, this should enable teams to move quickly from investigating a problem to resolving it.
In terms of offering log functionality, Mackerel is a latecomer. But rather than chasing feature parity for its own sake, we want to stay true to what makes Mackerel Mackerel and carefully craft an experience that people will actually use.
We're hard at work, targeting a release between summer and autumn this year. We'll share progress as soon as we're able, so please stay tuned.
Sign up for Mackerel to receive the latest updates by email
Mackerel delivers a variety of service-related information by email. We'll be sending out updates on the log feature as well, so if you don't yet have a Mackerel account, we hope you'll take this opportunity to sign up.
You can also easily catch the latest updates on Mackerel's official X account (@mackerelio). Please feel free to follow along there too.
