Skip to content
This repository has been archived by the owner on Dec 6, 2024. It is now read-only.

zPages proposal #110

Merged
merged 7 commits into from
Jun 9, 2020
Merged

zPages proposal #110

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
e1ae316
zPages proposal
SergeyKanzhelev Jun 2, 2020
14f054f
renamed file to the PR number
SergeyKanzhelev Jun 2, 2020
25992c8
linter issues
SergeyKanzhelev Jun 2, 2020
04c05cc
linter issues
SergeyKanzhelev Jun 2, 2020
aef42cc
Merge branch 'master' into pages
SergeyKanzhelev Jun 6, 2020
064ee83
added some principles for zPages development
SergeyKanzhelev Jun 6, 2020
de5f733
fixes after Reiley review
SergeyKanzhelev Jun 6, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 37 additions & 0 deletions text/0110-z-pages.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# zPages: general direction (#110)

Make zPages a standard OpenTelemetry component.

## Motivation

Self-introspection debug pages or zPages are in-process web pages that display collected data from the process they are attached to. They are used to provide in-process diagnostics without the need of any backend to examine traces or metrics. Various implementations of zPages are widely used in many environments. The standard extensible implementation of zPages in OpenTelemetry will benefit everybody.

## Explanation

This OTEP is a request to get a general approval for zPages development as an experimental feature [open-telemetry/opentelemetry-specification#62](https://github.com/open-telemetry/opentelemetry-specification/pull/632). See [opencensus.io/zpages](https://opencensus.io/zpages/) for the overview of zPages.
SergeyKanzhelev marked this conversation as resolved.
Show resolved Hide resolved

## Internal details

Implementation of zPages includes multiple components - data collection (sampling, filtering, configuration), storage and aggregation, and a framework to expose this data.

This is a request for a general direction approval. There are a few principles for the development:

1. zPages MUST NOT be hardcoded into OpenTelemetry SDK.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by "not be hardcoded"? Something like this?

Suggested change
1. zPages MUST NOT be hardcoded into OpenTelemetry SDK.
1. zPages MUST NOT be enabled or configured by default in the OpenTelemetry SDK.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or does this mean it must be supplied in a separate package/code unit rather than "weaved into" the SDK?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SergeyKanzhelev Please clarify.

Copy link
Contributor

@jmacd jmacd Jun 9, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with your interpretation about making zPages a separate package / code unit, at the level of a span processor (for tracing). In OpenCensus, the zPages support was baked-in to the default SDK tracer. This relates to open-telemetry/opentelemetry-specification#373 about having access to live, unfinished spans.

2. OpenTelemetry implementation of zPages MUST be split as two separate components - one for data, another for rendering. So that, for example, data providers could be also integrated into other rendering frameworks.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
2. OpenTelemetry implementation of zPages MUST be split as two separate components - one for data, another for rendering. So that, for example, data providers could be also integrated into other rendering frameworks.
2. OpenTelemetry implementation of zPages MUST be split into two separate components - one for data collection and handling, another for rendering. This way, for example, data providers could be also integrated into other rendering frameworks.

3. zPages SHOULD be built as a framework that provides a way to extend information exposed from the process. Ideally all the way to replace OpenTelemetry SDK with alternative source of information.

## Trade-offs and mitigations

We may discover that implementation of zPages as a vendor-specific or user-specific plugins may be preferable. Based on initial investigation, extensible standard implementation will benefit everybody.

## Prior art and alternatives

[opencensus.io/zpages](https://opencensus.io/zpages/)

## Open questions

N/A

## Future possibilities

N/A