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.

Sign up for GitHub

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

Jump to bottom

Use md-to-godoc #3

Merged
merged 4 commits into from
Nov 8, 2016
Merged

Use md-to-godoc #3

merged 4 commits into from
Nov 8, 2016

Conversation

yurishkuro
Copy link
Member

No description provided.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 3102f30 on use-md-to-godoc into 696d52a on master.

@yurishkuro yurishkuro mentioned this pull request Nov 8, 2016
Closed
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 6136d33 on use-md-to-godoc into 696d52a on master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 2890d37 on use-md-to-godoc into 696d52a on master.

@yurishkuro yurishkuro merged commit 5767869 into master Nov 8, 2016
@yurishkuro yurishkuro deleted the use-md-to-godoc branch December 16, 2016 20:29
ideepika pushed a commit to ideepika/jaeger that referenced this pull request Oct 22, 2017
@yurishkuro @ideepika
Use md-to-godoc (jaegertracing#3)
23f2b5b
@joe-elliott joe-elliott mentioned this pull request Aug 31, 2020
Merged
@judyQD judyQD mentioned this pull request Apr 26, 2021
Closed
@destinygujun destinygujun mentioned this pull request Jun 15, 2022
Closed
bigfleet pushed a commit to bigfleet/jaeger that referenced this pull request Feb 16, 2023
@jasonsmithio
Merge pull request jaegertracing#3 from timirnich/master
e812528 
Adding redis tracing
yurishkuro added a commit that referenced this pull request Sep 27, 2023
@yurishkuro @albertteoh
Add jaeger-v2 single binary based on OTEL collector (#4766)
f7736ed 
## Which problem is this PR solving?
- Third prototype of "Jaeger-v2"
- Another alternative approach to #3500

## Description of the changes
- Adds a new binary `jaeger-v2` using OTEL Collector framework
- Minimal amount of extensions is included, to mimic what
`jaeger-collector` normally has
- It will combine all previous functions of agent/collector/query in one
binary, but controllable via config file

```
$ go run -tags=ui ./cmd/jaeger-v2 --config ./cmd/jaeger-v2/config.yaml
```

## Roadmap


https://docs.google.com/document/d/1s4_6VgAS7qAVp6iEm5KYvpiGw3h2Ja5T5HpKo29iv00/edit

## Design

* the ingestion and storing of traces will be done via standard
receivers/processors/exporters OTEL Collector components
* the jaeger-query and UI are implemented as `jaeger_query` extension
(already working in this PR)

### Storage
In order to keep the flexibility of mixing & matching storage
implementations, all backends can be configured via `jaeger_storage`
extension (we may need to add `jaeger_metrics_storage` extension in the
future). It might look like this:
```yaml
jaeger_storage:
  memory:  # defines Factory
    memstore:
      max_traces: 100000
  cassandra:
    cassandra_primary:
      servers: [...]
      namespace: jaeger
    cassandra_archive:
      servers: [...]
      namespace: jaeger_archive
```

The `jaeger_query` extension then references specific storage factories
by name:
```yaml
  jaeger_query:
    trace_storage: memstore
    dependencies: something_else
    metrics_store: prometheus_store
```

It's not clear yet if `jaeger_query` extension should simply subsume
`jaeger_storage` extension, because Query is the only one that needs
this _generic_ access to storage, while things like exporters or Kafka
ingester (receiver) always deal with a single implementation (because
OTEL Coll pipeline allows to connect them with each other, which is not
possible with extensions).

## Trade-offs
- This not using OTEL Collector builder `ocb`. That means people won't
be able to assemble a different version of the collector with other
extensions.
- We may want to support `ocb` in the future, as it makes it easier to
write custom in-process exporters for custom storage. It will require
converting all the components into their own modules.

## Next steps

* [x] Get feedback from the community on the approach
* [x] Fully implement all-in-one by wiring receivers / exporters
correctly

## Open Questions
* How can we implement all-in-one equivalent that can be run without any
config file?
* Do we want
[healthcheckextension](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/extension/healthcheckextension/README.md)
to be included by default?
* Investigate startup error `2023-09-23T19:55:46.661-0400 warn
zapgrpc/zapgrpc.go:195 [core] [Channel #2 SubChannel #3] grpc:
addrConn.createTransport failed to connect to {Addr: ":16685",
ServerName: "localhost:16685", }. Err: connection error: desc =
"transport: Error while dialing: dial tcp :16685: connect: connection
refused" {"grpc_log": true}`

---------

Signed-off-by: Yuri Shkuro <github@ysh.us>
Signed-off-by: Yuri Shkuro <yurishkuro@users.noreply.github.com>
Co-authored-by: Albert <26584478+albertteoh@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@yurishkuro @coveralls