Component views are dashboards representing a window into a specific library or runtime. Component views support institutionalizing and sharing knowledge by allowing subject matter experts and on call learnings to be fed back into dashboards which every service and team can leverage. Component Views can be modeled as generic metric dashboard parameterized by a specific service. Component Views enable creating a feedback loop where one teams learnings and operational workflows can benefit every team using that shared component. Component Views are an essential pattern for distributed and multi-team systems, and can be shipped as pre-made ready to use dashboards.

Purpose

The goal of Component Views is to provide teams access to clean views curated by experience and subject matter experts. Consider a team that ran into long GC pauses in their Node.js version, so they began surfacing GC metrics to their metrics system. During an incident they have learned that GC data is a critical dimension in understanding intermittent latency issues. Another team that hasn’t encountered this issue may not have understood the GC and not incorporated these foundational metrics. If the other team were to encounter an issue with the GC they wouldn’t even have data available to them! They would be completely blind as the GC may be an unknown unknown to them. Component Views solve this by providing generic dashboards for critical components.

Feedback Loops

Having centralized dashboards support a feedback loop which continually benefits all users of the dashboard:

Component Views commonly ship alongside libraries, and are a great way for a libraries creators to encode important operational metrics for the consumers of the library.

In Practice

Each shared component/library should ship with a Component View dashboard which is parameterized by service. One thing to note is that these dashboards do not remove the need for service specific dashboards. or having component specific metrics along side a service metrics. During incidents they allow subject matter experts clean views into specific components. Some examples of components which benefit from a Component View:

Runtime (Node.js Runtime Stats, Go Runtime Stats)

Circuit Breaker Library

API Client Library View

Component View’s are commonly parameterized by service, allowing any team to see how the component is operating for their specific service. In the case of client libraries it allows the server team to see how each client is performing.

Component Views follow a pattern popularized by Netflix. Their resiliency libraries (hystrix and resilience4j) expose generic dashboards parametrizable by consuming service. The following is an example of their circuit breaker. It provides key state information, enabling any team to easily see the state of their services circuit breakers:

A similar Component View that providing essential node.js runtime statistics could be imagined:

Approach

Metric structure is important to consider when creating Component Views. The component should occupy its own namespace and not be attached to the service it’s being used in. Imagine a service where each of the services metrics are namespaced by that services name:

service1.node.runtime.heap_total

Under dogstatsd and prometheus this naming scheme doesn’t support parameterization, tightly coupling the node metrics to service1 .

An approach that supports a Component View would be a metric namespaced by the component and tagged/labeled with the service:

node.runtime.heap_total service:service1

This would allow a generic Component View dashboard to be created and have a dropdown to select the service.

Conclusion

Component Views are a critical tool in smooth service operation and democratizing information. They provide a way to share deep vertical knowledge horizontally across teams.