Skip to content
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

sig-instrumentation: Add charter document #2266

Merged
merged 1 commit into from
Aug 27, 2018
Merged
Changes from all commits
Commits
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
73 changes: 73 additions & 0 deletions sig-instrumentation/charter.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
# SIG Instrumentation Charter

This charter adheres to the conventions described in the [Kubernetes Charter README] and uses
the Roles and Organization Management outlined in [sig-governance].

## Scope

Owns best practices for cluster observability through metrics and logging
across all Kubernetes components and development of components required for all
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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

Kubernetes clusters (eg. heapster, metrics-server).

### In scope

SIG-Instrumentation revolves around the process of instrumenting and exposing
observability signals.

The act of instrumenting components not owned by SIG-Instrumentation is out of
scope, however SIG-Instrumentation is there to advise any contributors with
instrumentation decisions.

As well as giving advice in regards to instrumentation, SIG-Instrumentation
coordinates metric requirements of different SIGs for other components through
finding common APIs (such as the resource/core, custom and external metrics
APIs).


#### Code, Binaries and Services

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

- Components required for any Kubernetes cluster in regards to observability. Also referred to as the [core metrics pipeline][core-metrics-pipeline], meaning metrics that are to be consumed by the scheduler, kubectl and autoscaling. ([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. These the APIs defined in order to interface external system (such as Prometheus, Stackdriver, etc.) to be exposed to Kubernetes as a common interface, in order for Kubernetes to be able to treat metric sources as a generic metrics API. ([kubernetes/metrics](https://github.com/kubernetes/metrics), [kubernetes-incubator/custom-metrics-apiserver](https://github.com/kubernetes-incubator/custom-metrics-apiserver))
- Well established but optional components or adapters for Kubernetes clusters, if endorsed by members. Each component must have two or more members as maintainers. ([kubernetes/kube-state-metrics](https://github.com/kubernetes/kube-state-metrics), not yet officially owned by SIG-Instrumentation, but an example prospect for this category: [DirectXMan12/k8s-prometheus-adapter](https://github.com/DirectXMan12/k8s-prometheus-adapter))

#### Cross-cutting and Externally Facing Processes

- 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. (see [Instrumenting Kubernetes Guide][instrumenting-kubernetes])
- Creating, adding and maintaining the Kubernetes instrumentation guidelines.
- Coordinate cross SIG-Instrumentation efforts.
- 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](sig-node) and SIG Instrumentation.

### Out of scope

- 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.
- The act of writing log files, their format, or how they are to be processed afterwards.

## Roles and Organization Management

This SIG follows adheres to the Roles and Organization Management outlined in [sig-governance]
and opts-in to updates and modifications to [sig-governance].

### Additional responsibilities of Tech Leads

- No additional responsibilities of Tech Leads

### Deviations from [sig-governance]

Tech Leads must also fulfill all of the responsibilities of the Chair role as outlined in [sig-governance].

### Subproject Creation

By SIG Technical Leads

[sig-governance]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md
[sig-node]: https://github.com/kubernetes/community/tree/master/sig-node
[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L964-L1018
[Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md
[instrumenting-kubernetes]: https://github.com/kubernetes/community/blob/master/contributors/devel/instrumentation.md
[core-metrics-pipeline]: https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/