-
Notifications
You must be signed in to change notification settings - Fork 331
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
drop stackdriver metrics and tracing exporters #2183
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2183 +/- ##
==========================================
+ Coverage 66.05% 66.11% +0.06%
==========================================
Files 224 221 -3
Lines 9426 9259 -167
==========================================
- Hits 6226 6122 -104
+ Misses 2920 2862 -58
+ Partials 280 275 -5
Continue to review full report at Codecov.
|
/hold - going to wait till next week in case there's some commentary on the issue /assign @evankanderson @skonto |
/hold cancel |
customSubDomain = "test.domain" | ||
testProj = "test-project" | ||
anotherProj = "another-project" | ||
metricsDomain = "knative.dev/project" |
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.
What was the value of having different domains?
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 was a stack driver thing but we're actually prefixing this to the open census metric names so I think this should keep this around until we resolve: #2174
I think there's some value in repurposing this as a label in order to help disambiguate between components across different Knative projects (ie. serving vs eventing).
ie. in the future we drop the metric prefix and thus require labels to help segment metrics.
So for a golang memory metric - we'd have a component label ie. controller
and reuse the domain label serving
I'm ok to drop this domain if an alternative exists - ie. if the components namespace is automatically picked up as part of the metric
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 think the namespace is likely to be picked up as part of the metric; I'm not sure if we have to / want to worry about cases like queue-proxies and sources running in a user's namespace.
I'm inclined to think that namespace + some sort of component/Resource name should be sufficient here, but I might be mistaken.
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.
(With the notion that the Resource would indicate whether it was a serving or eventing construct if it was running in a user namespace, and that multi-tenant components would be running in a namespace where the name would give a clue.)
The obvious counter-example here is mink
, where all the controllers are bundled into a single Pod, but I'm not sure that's a compelling enough case.
re: loggingCfg := stackdriverConfig() This just produces a logging format that stackdriver can parse easily - I'm ok with leaving this since it helps debugging with our CI/prow runs. Do you have suggestions on other alternatives here? |
I can do a followup PR to cleanup anything that remains and discuss them in detail one by one. For that particular logging config func I would just rename it, if it does not do any harm. |
/hold I'll fix the downstream serving issues |
Downstream issue should be resolved here: |
Moving Eventing Source StatReporter out of knative.dev/pkg - knative/eventing#5587 |
these have been moved to their respective repos see: knative#608
We're going to move the StatsReporter downstream eventually related: knative/eventing#5587 knative/eventing#5586
526efe3
to
2aa3e08
Compare
I'm going to temporarily move the eventing sources metric keys to |
last PR to fix serving downstream: knative/serving#11679 |
/hold cancel - this is good now |
/hold cancel |
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.
/lgtm
/approve
I'm amused that we're deleting about 10k lines of aws-sdk-go
with this change. (Also, wow the generated proto files stackdriver pulled in were big...)
// RequestMetricsBackend specifies the request metrics destination, e.g. Prometheus, | ||
// Stackdriver. "None" disables all backends. | ||
// RequestMetricsBackend specifies the request metrics destination, e.g. Prometheus. | ||
// "None" disables all backends. |
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.
Should this have OpenCensus?
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'll add it back
customSubDomain = "test.domain" | ||
testProj = "test-project" | ||
anotherProj = "another-project" | ||
metricsDomain = "knative.dev/project" |
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 think the namespace is likely to be picked up as part of the metric; I'm not sure if we have to / want to worry about cases like queue-proxies and sources running in a user's namespace.
I'm inclined to think that namespace + some sort of component/Resource name should be sufficient here, but I might be mistaken.
customSubDomain = "test.domain" | ||
testProj = "test-project" | ||
anotherProj = "another-project" | ||
metricsDomain = "knative.dev/project" |
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.
(With the notion that the Resource would indicate whether it was a serving or eventing construct if it was running in a user namespace, and that multi-tenant components would be running in a namespace where the name would give a clue.)
The obvious counter-example here is mink
, where all the controllers are bundled into a single Pod, but I'm not sure that's a compelling enough case.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dprotaso, evankanderson The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Fixes: #2173