-
Notifications
You must be signed in to change notification settings - Fork 648
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Views API Prototype #596
Changes from 8 commits
7419bda
aa7562a
4a7f6dd
e43a984
4d4351f
e667bc8
5d9ae6f
554dafb
f8997ca
8331f1b
d93f159
53cc0f7
e966f7e
adce43e
864b644
fea636f
af6d003
176aa55
12402f7
8e3a903
9e7332f
3eb7dcd
ac3734c
82a154c
55ad347
fbeaf34
778223e
4875769
f793247
d7fbcef
45e96f3
0b22ef7
2a55926
b74fb2d
a510eb0
54594c8
8baa90e
765e8ef
bba29d5
d609602
4b49cb7
de145ce
93c3808
2962561
58212ba
f0e74b7
a8ab8de
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,9 +19,11 @@ | |
import time | ||
|
||
from opentelemetry import metrics | ||
from opentelemetry.sdk.metrics import Counter, Measure, MeterProvider | ||
from opentelemetry.sdk.metrics import Counter, MeterProvider | ||
from opentelemetry.sdk.metrics.export.aggregate import CountAggregation | ||
from opentelemetry.sdk.metrics.export import ConsoleMetricsExporter | ||
from opentelemetry.sdk.metrics.export.controller import PushController | ||
from opentelemetry.sdk.metrics.view import View | ||
|
||
# Use the meter type provided by the SDK package | ||
metrics.set_meter_provider(MeterProvider()) | ||
|
@@ -35,16 +37,6 @@ | |
unit="1", | ||
value_type=int, | ||
metric_type=Counter, | ||
label_keys=("environment",), | ||
) | ||
|
||
requests_size = meter.create_metric( | ||
name="requests_size", | ||
description="size of requests", | ||
unit="1", | ||
value_type=int, | ||
metric_type=Measure, | ||
label_keys=("environment",), | ||
) | ||
|
||
clicks_counter = meter.create_metric( | ||
|
@@ -53,11 +45,18 @@ | |
unit="1", | ||
value_type=int, | ||
metric_type=Counter, | ||
label_keys=("environment",), | ||
) | ||
|
||
labels = {"environment": "staging"} | ||
|
||
# Views are used to define an aggregation type to use for a specific metric | ||
counter_view = View(requests_counter, CountAggregation()) | ||
clicks_view = View(clicks_counter, CountAggregation()) | ||
|
||
# Register the views to the view manager to use the views | ||
meter.register_view(counter_view) | ||
meter.register_view(clicks_view) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. qn on Should we require that all views must be registered beforehand? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Good question. Yes I believe we should enforce this as a requirement. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Dynamic view management would certainly be more challenging. Let's leave it out for now. |
||
|
||
print("Updating using direct calling convention...") | ||
# You can record metrics directly using the metric instrument. You pass in | ||
# labels that you would like to record for. | ||
|
@@ -80,3 +79,5 @@ | |
# specified labels for each. | ||
meter.record_batch(labels, ((requests_counter, 50), (clicks_counter, 70))) | ||
time.sleep(5) | ||
|
||
input("...\n") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the creating a view requires a reference to the metric instrument itself. This means we can create a view only after creating the instrument itself.
Can we instead create Views with the name/description of the instrument? This can also allow us to load Views setting from json/yml etc.
{
"metername" : "MeterForHttpLib"
, "instrumentname", "RequestCounts"
, keys : ["httpurl","httpstatus"]
"aggregation":
{
Type:, "Histogram",
Options:
{
histogramboundaries....
}
}
}
When a meter/instrument matching the above is actually created in the program, it'll get its View config automatically from the config.
Thougts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think that the application owner may not have access to
requests_counter
object, if it was an instrument created inside another library. Only that library will have access to it.The application owner will have to use "metername + instrumentname" or similar to specify an instrument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's what I did for .net prototype.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be a possible improvement in the future. For the prototype, I believe it is okay to have just the basic functionality and iterate after.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cijothomas I like what you posted here. We should be imagining that views will be configured from a
.yaml
file, which many but not all users will want.