sig-instrumentation: Add charter document #2266

brancz · 2018-06-14T16:08:35Z

This PR is currently work in progress and meant for sig-instrumentation to iterate on its charter document.

@kubernetes/sig-instrumentation-misc

coffeepac · 2018-06-18T21:18:35Z

sig-instrumentation/charter.md

+
+### Out of scope
+
+Outline of things that could be confused as falling into this SIG but don't


Topics we don't cover (suggested):

event (metric, log) processing

prescribing what are error states

I think these are reasonable additions.

coffeepac · 2018-06-18T21:23:00Z

sig-instrumentation/charter.md

+  - Follow [KEP] decision making process
+
+- Test health
+  - Canonical health of code published to <link to dashboard>


should this be a link to the testgrid at: https://k8s-testgrid.appspot.com/sig-instrumentation ?

coffeepac · 2018-06-18T21:23:30Z

sig-instrumentation/charter.md

+
+- Test health
+  - Canonical health of code published to <link to dashboard>
+  - Consistently broken tests automatically send an alert to <link to google group>


https://groups.google.com/forum/#!forum/kubernetes-sig-instrumentation

philips · 2018-07-20T16:48:51Z

Thank you for your patience as we work to your SIG charter merged.

Through the process of reviewing the first 11 charters the Steering Committee (SC) found a lot of copy/paste language caused by our poorly designed initial charter template. To fix this there is a new SIG charter template which focuses on the main things we want to see in charters: scope and responsibilities.

Please consider updating to this charter template and putting focus into the scope and responsibilities. SC members will focus more on a deep review of scope more than anything else and using this template will help with that focus.

brancz · 2018-07-26T08:20:20Z

@coffeepac @philips I updated this PR with the new charter template and incorporated your comments. Let's go through this in today's sig-instrumentation meeting.

DirectXMan12

comments inline

DirectXMan12 · 2018-07-26T16:37:05Z

sig-instrumentation/charter.md

+
+By SIG Technical Leads
+
+[sig-governance]: sig-governance.md


this doesn't end up at the right place

(it's a missing page for me)

Sorry, oversight in the template #2423

DirectXMan12 · 2018-07-26T16:39:25Z

sig-instrumentation/charter.md

+
+- Components required for any Kubernetes cluster in regards to observability.
+- Interfaces/API definitions required for any Kubernetes cluster in regards to observability.
+- Well established but optional components for Kubernetes clusters, if endorsed by member.


make this members (plural), and maybe add a note about having multiple people who can maintain.

DirectXMan12 · 2018-07-26T16:41:37Z

sig-instrumentation/charter.md

+
+#### Cross-cutting and Externally Facing Processes
+
+n/a


two concerns here:

being the "reviewers" for instrumentation (somewhat akin to api-reviewers)

being involved in things like node monitoring, where we collaborate with another sig on the details of monitoring parts of kubernetes

agreed, I think people should come to this SIG for advice on what metrics to export and the best practices on the dimensions

DirectXMan12 · 2018-07-26T16:43:45Z

sig-instrumentation/charter.md

+
+### Deviations from [sig-governance]
+
+- This SIG does not have Chairs.


maybe say "the SIG does not have chairs separately from the technical leads"

philips

Great start! Added some suggestions.

philips · 2018-07-26T17:37:30Z

sig-instrumentation/charter.md

+
+#### Cross-cutting and Externally Facing Processes
+
+n/a


agreed, I think people should come to this SIG for advice on what metrics to export and the best practices on the dimensions

philips · 2018-07-26T17:40:09Z

sig-instrumentation/charter.md

+### Out of scope
+
+- Processing of signals. For example ingesting metrics, logs, events into external systems.
+- Predescribing what error states are.


Prescribing? I don't know if predescribing works here. Maybe something like this:

Cataloging thresholds or other error states based on instrumentation e.g. alert configurations

philips · 2018-07-26T17:41:07Z

sig-instrumentation/charter.md

+
+## Scope
+
+Covers best practices for cluster observability through metrics, logging, and


Scope should be what a SIG owns. So, perhaps:

"Owns best practices for cluster..."

philips · 2018-07-26T17:42:20Z

sig-instrumentation/charter.md

+
+[Link to SIG section in sigs.yaml][sigs.yaml].
+
+#### Code, Binaries and Services


It would be worthwhile to link to the SIG's sub-projects https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects

philips · 2018-07-26T18:53:18Z

sig-instrumentation/charter.md

+
+Coordinating metric requirements of different SIGs for other components through finding common APIs.
+
+[Link to SIG section in sigs.yaml][sigs.yaml].


Probably better to link here since it is generated from sigs.yaml https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects

brancz · 2018-07-27T06:35:41Z

@coffeepac @DirectXMan12 @philips All comments addressed. I think we're in a good shape. Let me know if there anything else. Removing [WIP] as I'd be happy with this state.

philips · 2018-07-27T06:43:00Z

PTAL @derekwaynecarr @spiffxp as the steering committee reviewers.

philips

Looking good. Just want to be concrete on the code/binaries/services list.

philips · 2018-07-27T06:43:54Z

sig-instrumentation/charter.md

+
+- Components required for any Kubernetes cluster in regards to observability.
+- Interfaces/API definitions required for any Kubernetes cluster in regards to observability.
+- Well established but optional components for Kubernetes clusters, if endorsed by members. Each component must have two or more members as maintainers.


I don't understand this line. Can you explain further?

philips · 2018-07-27T06:44:11Z

sig-instrumentation/charter.md

+[List of subprojects](https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects)
+
+- Components required for any Kubernetes cluster in regards to observability.
+- Interfaces/API definitions required for any Kubernetes cluster in regards to observability.


Can you link to those APIs and Interfaces that this SIG owns?

philips · 2018-07-27T06:44:31Z

sig-instrumentation/charter.md

+
+[List of subprojects](https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects)
+
+- Components required for any Kubernetes cluster in regards to observability.


What are those components? Are they the subprojects or something else? Can you link to them?

brancz · 2018-07-27T07:13:42Z

@philips I linked out to projects and prospects as examples for each category. Let me know if you like this format or if you have other suggestions.

coffeepac

LGTM, thanks @brancz !

spiffxp

Thanks a bunch for using the shorter format.

I hope these don't come across as nitpicky, I'm trying to look for clarity, overlap and gaps. If these questions are better answered through a high bandwidth medium I can be available as well.

spiffxp · 2018-07-27T20:16:14Z

sig-instrumentation/charter.md

+## Scope
+
+Owns best practices for cluster observability through metrics, logging, and
+events across all Kubernetes components and development of relevant components.


all Kubernetes components

What does this mean? eg:

external dependencies: docker, cri-containerd, rioetcd

control plane binaries: kube-apiserver, kube-scheduler, kube-controller-manager

node binaries: kubelet, kube-proxy

addons: dns, ingress, fluentd, etc.

relevant components

What does this mean? I suspect you're trying to imply things like heapster and metrics-server here, but is there a less open ended way of doing so?

events

Needs more clarity, eg:

how does this relate to the events API and its use as represented by kubectl get events?

how does this related to the event compression algorithm implemented by sig-api-machinery?

do you own best practices on the creation of events?

how does this relate to the pod lifecycle event generator used by kubelet?

how does this relate to the events generated as part of audit logging?

please just strike the term "events" from the charter. it has not been historically the role of this sig and causes confusion.

to clarify more on events:

the event API itself is owned by sig-arch imho given its cross-cutting concern; it predates sigs.

the client side compression algo was done by me before formation of sig, but its part of client-go so api-machinery owns it now.

the event v2 api proposal is grouped under sig-instrumentation at this time, but in my opinion its addressing the api from a scalability perspective.

see: https://github.com/kubernetes/community/blob/f367271772f6616088473a6d99a0f084266d4047/contributors/design-proposals/instrumentation/events-redesign.md

all this to say, events and their best practices are not owned by a single sig imho. its by definition cross-cutting.

this SIG is mostly concerned with cross-cutting topics and standardizing them. this SIG owns very little by way of implementations in kubernetes and tries to focus on setting best practices.

with that in mind, would this be a good time to formally move best practices for events into this SIG? this would primarily focus on what is a good event, when should it be emitted, how should it be emitted, etc and little with the concrete implementation of those actions.

to be clear, I am not putting a stake in the ground on this, I am exploring a model that fits with what we've been doing with metrics and logging so far.

spiffxp · 2018-07-27T20:27:45Z

sig-instrumentation/charter.md

+
+#### Code, Binaries and Services
+
+[List of subprojects](https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects)


I feel like there are many addons missing from this list, eg:

cluster-monitoring

fluentd-elasticsearch

fluentd-gcp

metadata-agent

prometheus

etc.

@spiffxp i think addons a conflated with a concept of a distribution, and i am not sure this sig should be the owning body for all of those. defer to @brancz for his input, but i think its a grey area.

I think the question for me is whether these are examples of a metrics pipeline, not necessarily a reference impl, and not ownership of vendor-maintained addons. I know there are folks in this sig who are in these OWNERS files

None of the above fall into the "metrics pipeline" category per se, a subset of them could be selected to build one. fluentd-gcp and metadata-agent are or at least should be owned by sig-gcp, both depend on external third party services. Regarding the others:

cluster-monitoring: is owned by this sig, but deprecated due to heapster deprecation

fluentd-elasticsearch: we never discussed this formally, but I believe this is maintained by sig-instrumentation members, and I'm ok with that.

prometheus: this is owned and maintained by us, however as its readme says: "This add-on is an experimental configuration of k8s monitoring using Prometheus used for e2e tests."

What do you want to do with this information? Should we add the addons we own in the sigs.yaml? Generally all of these addons fit into the "Well established but optional components or adapters for Kubernetes clusters" category.

spiffxp · 2018-07-27T20:44:30Z

sig-instrumentation/charter.md

+
+### In scope
+
+Coordinating metric requirements of different SIGs for other components through finding common APIs.


just metrics? or also logs and events?

historically to my knowledge, it has just been metrics and not logs or events.

logging has been a concern owned by this SIG since at least January 2017 and there are e2e tests owned by this sig that predate that.

Correct, but it's wildly disputed what "correct" APIs for logging could and should look like, this goes from logging libraries (glog) to the actual format outputted by these. The only thing about logging that sig-instrumentation somewhat owns is the interface of log file directory structure. It neither owns the actual act of writing the files (typically done by the container runtime) nor does it dictate a format or how logs are to be processed afterwards. I believe we do own and maintain optional addons for this though.

spiffxp · 2018-07-27T20:46:31Z

sig-instrumentation/charter.md

+
+### Out of scope
+
+- Processing of signals. For example ingesting metrics, logs, events into external systems.


It may be helpful to have a counterpart to this in the "in scope" part. This seems to imply to me that if you're not about ingesting, you're about exposing/producing.

spiffxp · 2018-07-27T20:50:03Z

sig-instrumentation/charter.md

+
+[List of subprojects](https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects)
+
+- Components required for any Kubernetes cluster in regards to observability. ([kubernetes-incubator/metrics-server](https://github.com/kubernetes-incubator/metrics-server), [kubenernetes/heapster](https://github.com/kubernetes/heapster))


What roles do these fill / functionality do they provide that they are required?

i think this is clear enough, but we could say "core metrics pipeline" that used by core components (scheduler, kubectl, etc.)

spiffxp · 2018-07-27T20:51:27Z

sig-instrumentation/charter.md

+[List of subprojects](https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects)
+
+- Components required for any Kubernetes cluster in regards to observability. ([kubernetes-incubator/metrics-server](https://github.com/kubernetes-incubator/metrics-server), [kubenernetes/heapster](https://github.com/kubernetes/heapster))
+- Interfaces/API definitions required for any Kubernetes cluster in regards to observability. ([kubernetes/metrics](https://github.com/kubernetes/metrics), [kubernetes-incubator/custom-metrics-apiserver](https://github.com/kubernetes-incubator/custom-metrics-apiserver))


Same question here

this is really api extension points for supporting metric sources consumed by core k8s components (i.e. hpa consuming custom metric sources via api) where the metric source itself is not a k8s project (i.e. prometheus, etc.)

spiffxp · 2018-07-27T20:52:20Z

sig-instrumentation/charter.md

+- Guidance for instrumentation in order to ensure consistent and high quality instrumentation of core Kubernetes components. This includes:
+  - Reviewing any instrumentation related changes and additions.
+  - Guidance on what should be instrumented as well as dimensions of the same.
+  - Creating, adding and maintaining the Kubernetes instrumentation guidelines.


Do these exist today?

It does :) https://github.com/kubernetes/community/blob/master/contributors/devel/instrumentation.md

spiffxp · 2018-07-27T20:53:54Z

sig-instrumentation/charter.md

+
+- Processing of signals. For example ingesting metrics, logs, events into external systems.
+- Dictating what states must result in an alert. Suggestions or opt-in alerts may be in scope.
+


It may be helpful to specifically call out which kinds of addons you view as out of scope because they are cloud-provider specific (eg: those that rely on stackdriver likely fall to sig-gcp)

i would say alert management is outside the scope entirely?

we've been discussing have a base set of 'suggested alerts' around core kubernetes functionality. things like 99% API response time, pod startup time and then make it very clear that the actual thresholds need to be tuned by the user but provide some sane defaults. would that be too prescriptive?

Yes, what @coffeepac said is correct. We have been discussing that suggestions for alerts could be something we can own, as that it already falls into most members daily work, and this could allow to centralize suggested alert sets more and better.

spiffxp · 2018-07-31T18:17:48Z

sig-instrumentation/charter.md

+
+### Deviations from [sig-governance]
+
+The SIG does not have Chairs separately from the Technical Leads.


I would rephrase this as "Tech Leads must also fulfill all of the responsibilities of the Chair role as outlined in [sig-governance]"

You may also want to consider whether Tech Leads also doing Chair duties just happens to be the state of today, or something you wish to require of all future Tech Leads

derekwaynecarr

see comments.

derekwaynecarr · 2018-08-01T14:23:50Z

sig-instrumentation/charter.md

+## Scope
+
+Owns best practices for cluster observability through metrics, logging, and
+events across all Kubernetes components and development of relevant components.


please just strike the term "events" from the charter. it has not been historically the role of this sig and causes confusion.

derekwaynecarr · 2018-08-01T14:24:34Z

sig-instrumentation/charter.md

+
+### In scope
+
+Coordinating metric requirements of different SIGs for other components through finding common APIs.


historically to my knowledge, it has just been metrics and not logs or events.

derekwaynecarr · 2018-08-01T14:37:15Z

sig-instrumentation/charter.md

+## Scope
+
+Owns best practices for cluster observability through metrics, logging, and
+events across all Kubernetes components and development of relevant components.


to clarify more on events:

the event API itself is owned by sig-arch imho given its cross-cutting concern; it predates sigs.

the client side compression algo was done by me before formation of sig, but its part of client-go so api-machinery owns it now.

the event v2 api proposal is grouped under sig-instrumentation at this time, but in my opinion its addressing the api from a scalability perspective.

see: https://github.com/kubernetes/community/blob/f367271772f6616088473a6d99a0f084266d4047/contributors/design-proposals/instrumentation/events-redesign.md

all this to say, events and their best practices are not owned by a single sig imho. its by definition cross-cutting.

derekwaynecarr · 2018-08-01T14:38:49Z

sig-instrumentation/charter.md

+
+#### Code, Binaries and Services
+
+[List of subprojects](https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects)


@spiffxp i think addons a conflated with a concept of a distribution, and i am not sure this sig should be the owning body for all of those. defer to @brancz for his input, but i think its a grey area.

derekwaynecarr · 2018-08-01T14:40:03Z

sig-instrumentation/charter.md

+
+[List of subprojects](https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects)
+
+- Components required for any Kubernetes cluster in regards to observability. ([kubernetes-incubator/metrics-server](https://github.com/kubernetes-incubator/metrics-server), [kubenernetes/heapster](https://github.com/kubernetes/heapster))


i think this is clear enough, but we could say "core metrics pipeline" that used by core components (scheduler, kubectl, etc.)

derekwaynecarr · 2018-08-01T14:41:26Z

sig-instrumentation/charter.md

+[List of subprojects](https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects)
+
+- Components required for any Kubernetes cluster in regards to observability. ([kubernetes-incubator/metrics-server](https://github.com/kubernetes-incubator/metrics-server), [kubenernetes/heapster](https://github.com/kubernetes/heapster))
+- Interfaces/API definitions required for any Kubernetes cluster in regards to observability. ([kubernetes/metrics](https://github.com/kubernetes/metrics), [kubernetes-incubator/custom-metrics-apiserver](https://github.com/kubernetes-incubator/custom-metrics-apiserver))


this is really api extension points for supporting metric sources consumed by core k8s components (i.e. hpa consuming custom metric sources via api) where the metric source itself is not a k8s project (i.e. prometheus, etc.)

derekwaynecarr · 2018-08-01T14:42:44Z

sig-instrumentation/charter.md

+
+- Processing of signals. For example ingesting metrics, logs, events into external systems.
+- Dictating what states must result in an alert. Suggestions or opt-in alerts may be in scope.
+


i would say alert management is outside the scope entirely?

brancz · 2018-08-02T12:04:40Z

Added further updates according to the comments. Please take a look and let me know if I should add any more information from comments that I have replied with.

philips · 2018-08-15T19:12:44Z

/lgtm

philips · 2018-08-15T19:13:36Z

@spiffxp and @derekwaynecarr if you think the SIG Instrumentation charter now looks good can you please approve?

brancz · 2018-08-23T16:23:22Z

Does this look good to people now or anything else we should change?

spiffxp · 2018-08-23T18:59:35Z

looking...

spiffxp

I have two tiny nits on in-scope/out-of-scope. You've got my attention today, I'll see if we can iterate on this quickly.

spiffxp · 2018-08-23T19:04:06Z

sig-instrumentation/charter.md

+## Scope
+
+Owns best practices for cluster observability through metrics and logging
+across all Kubernetes components and development of components required for all


I'm still not sure "Kubernetes components" is a well understood, well defined term, but I will assume you are OK deferring the definition of this term to SIG Architecture and accepting whatever scope that implies if the definition is refined.

i am fine w/ that caveat as described by @spiffxp

spiffxp · 2018-08-23T19:11:56Z

sig-instrumentation/charter.md

+- Processing of signals. For example ingesting metrics, logs, events into external systems.
+- Dictating what states must result in an alert. Suggestions or opt-in alerts may be in scope.
+- Cloud provider specific addons are out of scope and should be taken care of by the respective SIG.
+


I feel like this should contain some of @brancz's response

It neither owns the actual act of writing the files (typically done by the container runtime) nor does it dictate a format or how logs are to be processed afterwards.

eg:

The act of writing log files, their format, or how they are to be processed afterwards

spiffxp · 2018-08-23T19:13:12Z

sig-instrumentation/charter.md

+coordinates metric requirements of different SIGs for other components through
+finding common APIs (such as the resource/core, custom and external metrics
+APIs).
+


This seems relevant as well

The only thing about logging that sig-instrumentation somewhat owns is the interface of log file directory structure.

spiffxp · 2018-08-23T19:15:01Z

sig-instrumentation/charter.md

+
+#### Code, Binaries and Services
+
+[List of subprojects](https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects)


Should we add the addons we own in the sigs.yaml?

Yes, I'll open a follow on PR based on your input, it needn't block this

spiffxp · 2018-08-27T18:16:24Z

sig-instrumentation/charter.md

+scope, however SIG-Instrumentation is there to advise any contributors with
+instrumentation decisions.
+
+As well as giving advise in regards to instrumentation, SIG-Instrumentation


nit: s/advise/advice

spiffxp · 2018-08-27T18:52:42Z

/approve

spiffxp · 2018-08-27T20:13:01Z

If I see no objections by end of day I'm going to re-add the LGTM per the above

philips · 2018-08-27T21:11:03Z

sounds good to me @spiffxp

derekwaynecarr · 2018-08-27T23:08:00Z

sig-instrumentation/charter.md

+finding common APIs (such as the resource/core, custom and external metrics
+APIs).
+
+SIG Instrumentation owns the interface of the log file and directory structure


we did not discuss this in the sig-node charter.

i think this should have some further refinement.

at best I think this is with sig-node, and not exclusively instrumentation. the sig-node charter says "Issues related to node, pod, container monitoring (with sig-instrumentation)" and probably should have also had a line for logging w/ sig-instrumentation. I think this is shared responsibility across the two sigs.

Makes sense. Will move that to shared responsibilities.

I deleted this line and added "The interface of log files and their directory structure written out by container runtimes to be processed by other systems further, is shared responsibility between SIG Node and SIG Instrumentation." To the cross-cutting section.

derekwaynecarr

i have the one request that we treat the log file and directory structure as a shared responsibility with sig-node, otherwise this is fine w/ me.

derekwaynecarr · 2018-08-27T23:40:48Z

/approve
/lgtm

k8s-ci-robot · 2018-08-27T23:40:54Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: derekwaynecarr, spiffxp

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:

~~sig-instrumentation/OWNERS~~ [derekwaynecarr,spiffxp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

k8s-ci-robot requested review from idvoretskyi and piosz June 14, 2018 16:08

coffeepac reviewed Jun 18, 2018

View reviewed changes

pwittrock added the committee/steering Denotes an issue or PR intended to be handled by the steering committee. label Jun 21, 2018

jdumars mentioned this pull request Jun 24, 2018

Charters Meta-issue kubernetes/steering#31

Closed

brancz force-pushed the sig-instrumentation-charter branch from 7f9ff41 to cb4f618 Compare July 26, 2018 08:19

k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jul 26, 2018

DirectXMan12 suggested changes Jul 26, 2018

View reviewed changes

philips mentioned this pull request Jul 26, 2018

commitee-steering: link SIG Charter to SIG Governance #2423

Merged

philips reviewed Jul 26, 2018

View reviewed changes

brancz force-pushed the sig-instrumentation-charter branch from cb4f618 to 78bb874 Compare July 27, 2018 06:34

brancz changed the title ~~[WIP] sig-instrumentation: Add charter document~~ sig-instrumentation: Add charter document Jul 27, 2018

k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 27, 2018

philips reviewed Jul 27, 2018

View reviewed changes

brancz force-pushed the sig-instrumentation-charter branch 2 times, most recently from c76d863 to bd7b695 Compare July 27, 2018 07:12

coffeepac approved these changes Jul 27, 2018

View reviewed changes

spiffxp suggested changes Jul 27, 2018

View reviewed changes

spiffxp reviewed Jul 31, 2018

View reviewed changes

derekwaynecarr suggested changes Aug 1, 2018

View reviewed changes

brancz force-pushed the sig-instrumentation-charter branch from bd7b695 to 6617db1 Compare August 2, 2018 12:02

k8s-ci-robot assigned philips Aug 15, 2018

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 15, 2018

spiffxp reviewed Aug 23, 2018

View reviewed changes

spiffxp reviewed Aug 27, 2018

View reviewed changes

brancz force-pushed the sig-instrumentation-charter branch from 6617db1 to a21a5e9 Compare August 27, 2018 18:50

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 27, 2018

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 27, 2018

spiffxp approved these changes Aug 27, 2018

View reviewed changes

derekwaynecarr reviewed Aug 27, 2018

View reviewed changes

derekwaynecarr suggested changes Aug 27, 2018

View reviewed changes

sig-instrumentation: Add charter document

7cf8a54

brancz force-pushed the sig-instrumentation-charter branch from a21a5e9 to 7cf8a54 Compare August 27, 2018 23:36

k8s-ci-robot assigned derekwaynecarr Aug 27, 2018

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 27, 2018

k8s-ci-robot merged commit c86d0ab into kubernetes:master Aug 27, 2018

brancz deleted the sig-instrumentation-charter branch August 27, 2018 23:46


		### Out of scope

		Outline of things that could be confused as falling into this SIG but don't


		### Deviations from [sig-governance]

		- This SIG does not have Chairs.


		## Scope

		Covers best practices for cluster observability through metrics, logging, and


		[Link to SIG section in sigs.yaml][sigs.yaml].

		#### Code, Binaries and Services


		Coordinating metric requirements of different SIGs for other components through finding common APIs.

		[Link to SIG section in sigs.yaml][sigs.yaml].


		[List of subprojects](https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects)

		- Components required for any Kubernetes cluster in regards to observability.


		### In scope

		Coordinating metric requirements of different SIGs for other components through finding common APIs.


		### Out of scope

		- Processing of signals. For example ingesting metrics, logs, events into external systems.


		- Processing of signals. For example ingesting metrics, logs, events into external systems.
		- Dictating what states must result in an alert. Suggestions or opt-in alerts may be in scope.


		### Deviations from [sig-governance]

		The SIG does not have Chairs separately from the Technical Leads.

sig-instrumentation: Add charter document #2266

sig-instrumentation: Add charter document #2266

Conversation

brancz commented Jun 14, 2018

coffeepac Jun 18, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

philips commented Jul 20, 2018

brancz commented Jul 26, 2018

DirectXMan12 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

philips left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brancz commented Jul 27, 2018

philips commented Jul 27, 2018

philips left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brancz commented Jul 27, 2018

coffeepac left a comment

Choose a reason for hiding this comment

spiffxp left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

derekwaynecarr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brancz commented Aug 2, 2018 • edited Loading

philips commented Aug 15, 2018

philips commented Aug 15, 2018

brancz commented Aug 23, 2018

spiffxp commented Aug 23, 2018

spiffxp left a comment

Choose a reason for hiding this comment

coffeepac Jun 18, 2018 •

edited

Loading

brancz commented Aug 2, 2018 •

edited

Loading