Governance/Repo cleanup (#225)
* First pass governance Signed-off-by: Joe Elliott <number101010@gmail.com> * Readme overhaul Signed-off-by: Joe Elliott <number101010@gmail.com> * added logo Signed-off-by: Joe Elliott <number101010@gmail.com> * added governance Signed-off-by: Joe Elliott <number101010@gmail.com> * Updated otel proto comment Signed-off-by: Joe Elliott <number101010@gmail.com> * removed shenaniganery Signed-off-by: Joe Elliott <number101010@gmail.com>
This commit is contained in:
Joe Elliott
@@ -1,3 +1,2 @@
|
||||
## master / unreleased
|
||||
|
||||
Frigg
|
||||
+74
-1
@@ -1,3 +1,76 @@
|
||||
# Contributor Covenant Code of Conduct
|
||||
|
||||
Frigg
|
||||
## Our Pledge
|
||||
|
||||
In the interest of fostering an open and welcoming environment, we as
|
||||
contributors and maintainers pledge to making participation in our project and
|
||||
our community a harassment-free experience for everyone, regardless of age, body
|
||||
size, disability, ethnicity, sex characteristics, gender identity and expression,
|
||||
level of experience, education, socio-economic status, nationality, personal
|
||||
appearance, race, religion, or sexual identity and orientation.
|
||||
|
||||
## Our Standards
|
||||
|
||||
Examples of behavior that contributes to creating a positive environment
|
||||
include:
|
||||
|
||||
* Using welcoming and inclusive language
|
||||
* Being respectful of differing viewpoints and experiences
|
||||
* Gracefully accepting constructive criticism
|
||||
* Focusing on what is best for the community
|
||||
* Showing empathy towards other community members
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery and unwelcome sexual attention or
|
||||
advances
|
||||
* Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
* Public or private harassment
|
||||
* Publishing others' private information, such as a physical or electronic
|
||||
address, without explicit permission
|
||||
* Other conduct which could reasonably be considered inappropriate in a
|
||||
professional setting
|
||||
|
||||
## Our Responsibilities
|
||||
|
||||
Project maintainers are responsible for clarifying the standards of acceptable
|
||||
behavior and are expected to take appropriate and fair corrective action in
|
||||
response to any instances of unacceptable behavior.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or
|
||||
reject comments, commits, code, wiki edits, issues, and other contributions
|
||||
that are not aligned to this Code of Conduct, or to ban temporarily or
|
||||
permanently any contributor for other behaviors that they deem inappropriate,
|
||||
threatening, offensive, or harmful.
|
||||
|
||||
## Scope
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community. Examples of
|
||||
representing a project or community include using an official project e-mail
|
||||
address, posting via an official social media account, or acting as an appointed
|
||||
representative at an online or offline event. Representation of a project may be
|
||||
further defined and clarified by project maintainers.
|
||||
|
||||
## Enforcement
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||||
reported by contacting the project team at conduct@grafana.com. All
|
||||
complaints will be reviewed and investigated and will result in a response that
|
||||
is deemed necessary and appropriate to the circumstances. The project team is
|
||||
obligated to maintain confidentiality with regard to the reporter of an incident.
|
||||
Further details of specific enforcement policies may be posted separately.
|
||||
|
||||
Project maintainers who do not follow or enforce the Code of Conduct in good
|
||||
faith may face temporary or permanent repercussions as determined by other
|
||||
members of the project's leadership.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
|
||||
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
|
||||
For answers to common questions about this code of conduct, see
|
||||
https://www.contributor-covenant.org/faq
|
||||
+78
-2
@@ -1,3 +1,79 @@
|
||||
# Contribute
|
||||
# Contributing
|
||||
|
||||
Frigg
|
||||
Tempo uses GitHub to manage reviews of pull requests:
|
||||
|
||||
- If you have a trivial fix or improvement, go ahead and create a pull request.
|
||||
- If you plan to do something more involved, discuss your ideas on the relevant GitHub issue.
|
||||
|
||||
## Dependency management is weird. Please read!
|
||||
|
||||
We use [Go modules](https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more) to manage dependencies on external packages.
|
||||
This requires a working Go environment with version 1.15 or greater and git installed.
|
||||
|
||||
To add or update a new dependency, use the `go get` command:
|
||||
|
||||
```bash
|
||||
# Pick the latest tagged release.
|
||||
go get example.com/some/module/pkg
|
||||
|
||||
# Pick a specific version.
|
||||
go get example.com/some/module/pkg@vX.Y.Z
|
||||
```
|
||||
|
||||
When updating dependencies it is important not to run the standard go modules commands due to the way that
|
||||
OpenTelemetry protos have been vendored. For now, after making dependency changes run
|
||||
|
||||
```bash
|
||||
make vendor-dependencies
|
||||
```
|
||||
|
||||
We are hoping to improve this in the future.
|
||||
|
||||
### Project Structure
|
||||
|
||||
```
|
||||
cmd/
|
||||
tempo/ - main tempo binary
|
||||
tempo-cli/ - cli tool for directly inspecting blocks in the backend
|
||||
tempo-vulture/ - bird-themed consistency checker. optional.
|
||||
tempo-query/ - jaeger-query GRPC plugin
|
||||
docs/
|
||||
example/ - great place to get started running Tempo
|
||||
docker-compose/
|
||||
tk/
|
||||
integration/ - e2e tests
|
||||
modules/ - top level Tempo components
|
||||
compactor/
|
||||
distributor/
|
||||
ingester/
|
||||
overrides/
|
||||
querier/
|
||||
storage/
|
||||
opentelemetry-proto/ - git submodule. necessary for proto vendoring
|
||||
operations/ - Tempo deployment and monitoring resources
|
||||
jsonnet/
|
||||
tempo-mixin/
|
||||
pkg/
|
||||
tempodb/ - object storage key/value database
|
||||
vendor/
|
||||
```
|
||||
|
||||
## Coding Standards
|
||||
|
||||
### go imports
|
||||
imports should follow `std libs`, `externals libs` and `local packages` format
|
||||
|
||||
Example
|
||||
```
|
||||
import (
|
||||
"context"
|
||||
"fmt"
|
||||
|
||||
"github.com/gogo/protobuf/proto"
|
||||
"github.com/opentracing/opentracing-go"
|
||||
|
||||
"github.com/grafana/tempo/modules/overrides"
|
||||
"github.com/grafana/tempo/pkg/validation"
|
||||
)
|
||||
|
||||
```
|
||||
+154
@@ -0,0 +1,154 @@
|
||||
---
|
||||
title: Governance
|
||||
---
|
||||
# Governance
|
||||
|
||||
This document describes the rules and governance of the project. It is meant to be followed by all the developers of the project and the Tempo community. Common terminology used in this governance document are listed below:
|
||||
|
||||
- **Team members**: Any members of the private [team mailing list][team].
|
||||
|
||||
- **Maintainers**: Maintainers lead an individual project or parts thereof ([`MAINTAINERS.md`][maintainers]).
|
||||
|
||||
- **Projects**: A single repository in the Grafana GitHub organization and listed below is referred to as a project:
|
||||
- Tempo
|
||||
|
||||
- **The Tempo project**: The sum of all activities performed under this governance, concerning one or more repositories or the community.
|
||||
|
||||
## Values
|
||||
|
||||
The Tempo developers and community are expected to follow the values defined in the [Code of Conduct][coc]. Furthermore, the Tempo community strives for kindness, giving feedback effectively, and building a welcoming environment. The Tempo developers generally decide by consensus and only resort to conflict resolution by a majority vote if consensus cannot be reached.
|
||||
|
||||
## Projects
|
||||
|
||||
Each project must have a [`MAINTAINERS.md`][maintainers] file with at least one maintainer. Where a project has a release process, access and documentation should be such that more than one person can perform a release. Releases should be announced on the [announcemount][announce] and [users][users] mailing lists. Any new projects should be first proposed on the [team mailing list][team] following the voting procedures listed below.
|
||||
|
||||
## Decision making
|
||||
|
||||
### Team members
|
||||
|
||||
Team member status may be given to those who have made ongoing contributions to the Tempo project for at least 3 months. This is usually in the form of code improvements and/or notable work on documentation, but organizing events or user support could also be taken into account.
|
||||
|
||||
New members may be proposed by any existing member by email to the [team mailing list][team]. It is highly desirable to reach consensus about acceptance of a new member. However, the proposal is ultimately voted on by a formal [supermajority vote](#supermajority-vote).
|
||||
|
||||
If the new member proposal is accepted, the proposed team member should be contacted privately via email to confirm or deny their acceptance of team membership. This email will also be CC'd to the [team mailing list][team] for record-keeping purposes.
|
||||
|
||||
If they choose to accept, the [onboarding](#onboarding) procedure is followed.
|
||||
|
||||
Team members may retire at any time by emailing [the team][team].
|
||||
|
||||
Team members can be removed by [supermajority vote](#supermajority-vote) on [the team mailing list][team].
|
||||
For this vote, the member in question is not eligible to vote and does not count towards the quorum.
|
||||
Any removal vote can cover only one single person.
|
||||
|
||||
Upon death of a member, they leave the team automatically.
|
||||
|
||||
In case a member leaves, the [offboarding](#offboarding) procedure is applied.
|
||||
|
||||
The current team members are:
|
||||
|
||||
- Annanay Agarwal - [annanay25](https://github.com/annanay25) ([Grafana Labs](https://grafana.com/))
|
||||
- Joe Elliott - [joe-elliott](https://github.com/joe-elliott) ([Grafana Labs](https://grafana.com/))
|
||||
|
||||
### Maintainers
|
||||
|
||||
Maintainers lead one or more project(s) or parts thereof and serve as a point of conflict resolution amongst the contributors to this project. Ideally, maintainers are also team members, but exceptions are possible for suitable maintainers that, for whatever reason, are not yet team members.
|
||||
|
||||
Changes in maintainership have to be announced on the [developers mailing list][devs]. They are decided by [rough consensus](#consensus) and formalized by changing the [`MAINTAINERS.md`][maintainers] file of the respective repository.
|
||||
|
||||
Maintainers are granted commit rights to all projects covered by this governance.
|
||||
|
||||
A maintainer or committer may resign by notifying the [team mailing list][team]. A maintainer with no project activity for a year is considered to have resigned. Maintainers that wish to resign are encouraged to propose another team member to take over the project.
|
||||
|
||||
A project may have multiple maintainers, as long as the responsibilities are clearly agreed upon between them. This includes coordinating who handles which issues and pull requests.
|
||||
|
||||
### Technical decisions
|
||||
|
||||
Technical decisions that only affect a single project are made informally by the maintainer of this project, and [rough consensus](#consensus) is assumed. Technical decisions that span multiple parts of the project should be discussed and made on the [developer mailing list][devs].
|
||||
|
||||
Decisions are usually made by [rough consensus](#consensus). If no consensus can be reached, the matter may be resolved by [majority vote](#majority-vote).
|
||||
|
||||
### Governance changes
|
||||
|
||||
Changes to this document are made by Grafana Labs.
|
||||
|
||||
### Other matters
|
||||
|
||||
Any matter that needs a decision may be called to a vote by any member if they deem it necessary. For private or personnel matters, discussion and voting takes place on the [team mailing list][team], otherwise on the [developer mailing list][devs].
|
||||
|
||||
## Voting
|
||||
|
||||
The Tempo project usually runs by informal consensus, however sometimes a formal decision must be made.
|
||||
|
||||
Depending on the subject matter, as laid out [above](#decision-making), different methods of voting are used.
|
||||
|
||||
For all votes, voting must be open for at least one week. The end date should be clearly stated in the call to vote. A vote may be called and closed early if enough votes have come in one way so that further votes cannot change the final decision.
|
||||
|
||||
In all cases, all and only [team members](#team-members) are eligible to vote, with the sole exception of the forced removal of a team member, in which said member is not eligible to vote.
|
||||
|
||||
Discussion and votes on personnel matters (including but not limited to team membership and maintainership) are held in private on the [team mailing list][team]. All other discussion and votes are held in public on the [developer mailing list][devs].
|
||||
|
||||
For public discussions, anyone interested is encouraged to participate. Formal power to object or vote is limited to [team members](#team-members).
|
||||
|
||||
### Consensus
|
||||
|
||||
The default decision making mechanism for the Tempo project is [rough][rough] consensus. This means that any decision on technical issues is considered supported by the [team][team] as long as nobody objects or the objection has been considered but not necessarily accommodated.
|
||||
|
||||
Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will. Decisions may, but do not need to be called out and put up for decision on the [developers mailing list][devs] at any time and by anyone.
|
||||
|
||||
Consensus decisions can never override or go against the spirit of an earlier explicit vote.
|
||||
|
||||
If any [team member](#team-members) raises objections, the team members work together towards a solution that all involved can accept. This solution is again subject to rough consensus.
|
||||
|
||||
In case no consensus can be found, but a decision one way or the other must be made, any [team member](#team-members) may call a formal [majority vote](#majority-vote).
|
||||
|
||||
### Majority vote
|
||||
|
||||
Majority votes must be called explicitly in a separate thread on the appropriate mailing list. The subject must be prefixed with `[VOTE]`. In the body, the call to vote must state the proposal being voted on. It should reference any discussion leading up to this point.
|
||||
|
||||
Votes may take the form of a single proposal, with the option to vote yes or no, or the form of multiple alternatives.
|
||||
|
||||
A vote on a single proposal is considered successful if more vote in favor than against.
|
||||
|
||||
If there are multiple alternatives, members may vote for one or more alternatives, or vote “no” to object to all alternatives. It is not possible to cast an “abstain” vote. A vote on multiple alternatives is considered decided in favor of one alternative if it has received the most votes in favor, and a vote from more than half of those voting. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.
|
||||
|
||||
### Supermajority vote
|
||||
|
||||
Supermajority votes must be called explicitly in a separate thread on the appropriate mailing list. The subject must be prefixed with `[VOTE]`. In the body, the call to vote must state the proposal being voted on. It should reference any discussion leading up to this point.
|
||||
|
||||
Votes may take the form of a single proposal, with the option to vote yes or no, or the form of multiple alternatives.
|
||||
|
||||
A vote on a single proposal is considered successful if at least two thirds of those eligible to vote vote in favor.
|
||||
|
||||
If there are multiple alternatives, members may vote for one or more alternatives, or vote “no” to object to all alternatives. A vote on multiple alternatives is considered decided in favor of one alternative if it has received the most votes in favor, and a vote from at least two thirds of those eligible to vote. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.
|
||||
|
||||
## On- / Offboarding
|
||||
|
||||
### Onboarding
|
||||
|
||||
The new member is
|
||||
|
||||
- added to the list of [team members](#team-members). Ideally by sending a PR of their own, at least approving said PR.
|
||||
- announced on the [developers mailing list][devs] by an existing team member. Ideally, the new member replies in this thread, acknowledging team membership.
|
||||
- added to the projects with commit rights.
|
||||
- added to the [team mailing list][team].
|
||||
|
||||
|
||||
### Offboarding
|
||||
|
||||
The ex-member is
|
||||
|
||||
- removed from the list of [team members](#team-members). Ideally by sending a PR of their own, at least approving said PR. In case of forced removal, no approval is needed.
|
||||
- removed from the projects. Optionally, they can retain maintainership of one or more repositories if the [team](#team-members) agrees.
|
||||
- removed from the team mailing list and demoted to a normal member of the other mailing lists.
|
||||
- not allowed to call themselves an active team member any more, nor allowed to imply this to be the case.
|
||||
- added to a list of previous members if they so choose.
|
||||
|
||||
If needed, we reserve the right to publicly announce removal.
|
||||
|
||||
[announce]: https://groups.google.com/forum/#!forum/tempo-announce
|
||||
[coc]: https://github.com/grafana/tempo/blob/master/CODE_OF_CONDUCT.md
|
||||
[devs]: https://groups.google.com/forum/#!forum/tempo-developers
|
||||
[maintainers]: https://github.com/grafana/tempo/blob/master/MAINTAINERS.md
|
||||
[rough]: https://tools.ietf.org/html/rfc7282
|
||||
[team]: https://groups.google.com/forum/#!forum/tempo-team
|
||||
[users]: https://groups.google.com/forum/#!forum/tempo-users
|
||||
@@ -0,0 +1,2 @@
|
||||
@joe-elliott
|
||||
@annanay25
|
||||
@@ -1,64 +1,38 @@
|
||||
# Tempo
|
||||
<p align="center"><img src="docs/sources/logo_and_name.png" alt="Loki Logo"></p>
|
||||
|
||||
Tempo is a Jaeger/Zipkin/OpenCensus compatible backend. It is not OpenTelemetry compatible only b/c that doesn't exist yet. Tempo ingests batches in any of the mentioned formats, buffers them and then writes them to GCS.
|
||||
Grafana Tempo is a high volume, minimal dependency distributed tracing backend. It is supports key/value lookup only and is designed to work in concert with logs and metrics (exemplars) for discovery.
|
||||
|
||||
Tempo is Jaeger, Zipkin, OpenCensus and OpenTelemetry compatible. It ingests batches in any of the mentioned formats, buffers them and then writes them to GCS, S3 or local disk. As such it is robust, cheap and easy to operate!
|
||||
|
||||
## Getting Started
|
||||
|
||||
See the [example folder](example) for various ways to get started running tempo locally.
|
||||
- [Documentation](https://grafana.com/docs/tempo/latest/)
|
||||
- [Deployment Examples](./example)
|
||||
- Deployment and log discovery Examples
|
||||
- [What is Distributed Tracing?](https://opentracing.io/docs/overview/what-is-tracing/)
|
||||
|
||||
## Architecture
|
||||
## Getting Help
|
||||
|
||||
Tempo is built around the Cortex architecture. It vendors Cortex primarily for the ring/lifecycler code.
|
||||
If you have any questions or feedback regarding Tempo:
|
||||
|
||||
### distributor
|
||||
|
||||
Distributors vendor the OpenTelemetry Collector to reuse their [receiver code](https://github.com/grafana/tempo/tree/master/pkg/distributor/receiver) and then use consistent ring hashing to split up a batch and push it to ingesters based on trace id.
|
||||
|
||||
### ingester
|
||||
|
||||
Ingesters batch traces until a configurable timeout is hit and then push them into a headblock. Blocks are cut periodically and shipped to the backend (gcs).
|
||||
|
||||
### querier
|
||||
|
||||
Queriers request trace ids both from ingesters and the backend and return the set of batches matching the requested trace id.
|
||||
|
||||
### compactor
|
||||
|
||||
Compactors iterate over all blocks looking for candidates for compaction. They are scaleable and use a consistent ring to decide ownership of a given set of blocks.
|
||||
- Ask a question on the Tempo Slack channel. To invite yourself to the Grafana Slack, visit [https://slack.grafana.com/](https://slack.grafana.com/) and join the #tempo channel.
|
||||
- [File an issue](https://github.com/grafana/tempo/issues/new) for bugs, issues and feature suggestions.
|
||||
- UI issues should be filed with [Grafana](https://github.com/grafana/grafana/issues/new).
|
||||
|
||||
## Other Components
|
||||
|
||||
### tempo-query
|
||||
tempo-query is jaeger-query with a [hashicorp go-plugin](https://github.com/jaegertracing/jaeger/tree/master/plugin/storage/grpc) to support querying tempo.
|
||||
tempo-query is jaeger-query with a [hashicorp go-plugin](https://github.com/jaegertracing/jaeger/tree/master/plugin/storage/grpc) to support querying Tempo.
|
||||
|
||||
### tempo-vulture
|
||||
tempo-vulture is tempo's bird based consistency checking tool. It queries Loki, extracts trace ids and then queries tempo. It metrics 404s and traces with missing spans.
|
||||
tempo-vulture is tempo's bird themed consistency checking tool. It queries Loki, extracts trace ids and then queries tempo. It metrics 404s and traces with missing spans.
|
||||
|
||||
### tempo-cli
|
||||
tempo-cli is place to put any utility functionality related to tempo. Currently it only supports dumping header information for all blocks from gcs.
|
||||
```
|
||||
go run ./cmd/tempo-cli -gcs-bucket ops-tools-tracing-ops -tenant-id single-tenant
|
||||
go run ./cmd/tempo-cli -backend=gcs -bucket ops-tools-tracing-ops -tenant-id single-tenant
|
||||
```
|
||||
|
||||
## TempoDB
|
||||
|
||||
[TempoDB](https://github.com/grafana/tempo/tree/master/tempodb) is contained in the tempo repository but is meant to be a stand alone key value database built on top of cloud object storage (gcs/s3).
|
||||
|
||||
## Todo
|
||||
|
||||
If you are getting into the project it would be worth reviewing the list of issues to get a feel for existing work on Tempo. Below are some of the most important issues/features to resolve before considering Tempo Beta.
|
||||
|
||||
- Determine and fix the reason for partial traces
|
||||
- https://github.com/grafana/tempo/issues/119
|
||||
- Provide a "meta" configuration layer that tightens up config and protects Tempo from upstream changes in Cortex config. This also includes the decision about whether or not Tempo should support ring storage mechanisms besides gossip.
|
||||
- https://github.com/grafana/tempo/issues/7
|
||||
- Organize data storage around a page and implement a page aligned cache.
|
||||
- https://github.com/grafana/tempo/issues/32
|
||||
- https://github.com/grafana/tempo/issues/30
|
||||
- Clean up bad blocks with the compactor. This is importtant b/c otherwise bad blocks live forever.
|
||||
- https://github.com/grafana/tempo/issues/112
|
||||
- Update otelcol dependency and move to otel proto. This should come with significant performance gains.
|
||||
- https://github.com/grafana/tempo/issues/8
|
||||
- Add a code of conduct, contributing guidelines and changelog.
|
||||
|
||||
And then, in order to offer hosted Tempo we would need to work out integration with Grafana.com APIs, authorization, and other things I'm not thinking of.
|
||||
[TempoDB](https://github.com/grafana/tempo/tree/master/tempodb) is included in the this repository but is meant to be a stand alone key value database built on top of cloud object storage (gcs/s3). It is a natively multitenant, supports a WAL and is the storage engine for Tempo.
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
@@ -178,7 +178,6 @@ func (q *Querier) FindTraceByID(ctx context.Context, req *tempopb.TraceByIDReque
|
||||
}
|
||||
|
||||
// forGivenIngesters runs f, in parallel, for given ingesters
|
||||
// TODO taken from Loki taken from Cortex, see if we can refactor out an usable interface.
|
||||
func (q *Querier) forGivenIngesters(ctx context.Context, replicationSet ring.ReplicationSet, f func(tempopb.QuerierClient) (interface{}, error)) ([]responseFromIngesters, error) {
|
||||
results, err := replicationSet.Do(ctx, q.cfg.ExtraQueryDelay, func(ingester *ring.IngesterDesc) (interface{}, error) {
|
||||
client, err := q.pool.GetClientFor(ingester.Addr)
|
||||
|
||||
Reference in New Issue
Block a user