Application tracing system for Go, based on Google's Dapper.

appdash (view on Sourcegraph)

Appdash is an application tracing system for Go, based on Google's Dapper and Twitter's Zipkin.

Appdash allows you to trace the end-to-end handling of requests and operations in your application (for perf and debugging). It displays timings and application-specific metadata for each step, and it displays a tree and timeline for each request and its children.

To use appdash, you must instrument your application with calls to an appdash recorder. You can record any type of event or operation. Recorders and schemas for HTTP (client and server) and SQL are provided, and you can write your own.

Usage

To install appdash, run:

go get -u sourcegraph.com/sourcegraph/appdash/cmd/...

A standalone example using Negroni and Gorilla packages is available in the examples/cmd/webapp folder.

A demo / pure net/http application (which is slightly more verbose) is also available at cmd/appdash/example_app.go, and it can be ran easily using appdash demo on the command line.

Community

Questions or comments? Join us on #sourcegraph in the Gophers slack!

Development

Appdash uses vfsgen to package HTML templates with the appdash binary for distribution. This means that if you want to modify the template data in traceapp/tmpl you can first build using the dev build tag, which makes the template data be reloaded from disk live.

After you're finished making changes to the templates, always run go generate sourcegraph.com/sourcegraph/appdash/traceapp/tmpl so that the data_vfsdata.go file is updated for normal Appdash users that aren't interested in modifying the template data.

Components

Appdash follows the design and naming conventions of Google's Dapper. You should read that paper if you are curious about why certain architectural choices were made.

There are 4 main components/concepts in appdash:

  • Spans: A span refers to an operation and all of its children. For example, an HTTP handler handles a request by calling other components in your system, which in turn make various API and DB calls. The HTTP handler's span includes all downstream operations and their descendents; likewise, each downstream operation is its own span and has its own descendents. In this way, appdash constructs a tree of all of the operations that occur during the handling of the HTTP request.
  • Event: Your application records the various operations it performs (in the course of handling a request) as Events. Events can be arbitrary messages or metadata, or they can be structured event types defined by a Go type (such as an HTTP ServerEvent or an SQLEvent).
  • Recorder: Your application uses a Recorder to send events to a Collector (see below). Each Recorder is associated with a particular span in the tree of operations that are handling a particular request, and all events sent via a Recorder are automatically associated with that context.
  • Collector: A Collector receives Annotations (which are the encoded form of Events) sent by a Recorder. Typically, your application's Recorder talks to a local Collector (created with NewRemoteCollector. This local Collector forwards data to a remote appdash server (created with NewServer that combines traces from all of the services that compose your application. The appdash server in turn runs a Collector that listens on the network for this data, and it then stores what it receives.

Language Support

Appdash has clients available for Go, Python (see python/ subdir) and Ruby (see https://github.com/bsm/appdash-rb).

OpenTracing Support

Appdash supports the OpenTracing API. Please see the opentracing subdir for the Go implementation, or see the GoDoc for API documentation.

Acknowledgments

appdash was influenced by, and uses code from, Coda Hale's lunk.

Owner
Sourcegraph
Code search and navigation for teams (self-hosted, OSS)
Sourcegraph
Comments
  • Adds the Appdash implementation of the OpenTracing API

    Adds the Appdash implementation of the OpenTracing API

    This is the Appdash implementation of the OpenTracing api for Go. This is a really big diff, so I'd recommend ignoring the tests and the example app that's included for the time being. cc @slimsag

  • Replace data_generate.go with a proposed use of vfsgen binary.

    Replace data_generate.go with a proposed use of vfsgen binary.

    This change makes use of a new vfsgendev command-line tool in order to embed the static assets instead of the old data_generate.go file.

    • The tool is opinionated and designed specifically for use cases like ours here.
    • New behavior is identical to the old behavior.

    For more information, see shurcooL/vfsgen#16

  • Adds InfluxDB store.

    Adds InfluxDB store.

    Details

    Issue: https://github.com/sourcegraph/appdash/issues/98

    • [x] Adds new store engine named: InfluxDBStore, which implements Store & Queryer interfaces as:
      • [x] Collect(...) implementation:
        • Saves spans in a measurement named spans in the InfluxDB database named appdash.
        • Span.ID.Trace, Span.ID.Span & Span.ID.Parent are saved as tags - [InfluxDB indexes tags]
        • Span.Annotations are save as fields - [InfluxDB does not index fields]
        • Uses default 'ms' (milliseconds) as Point.Precision.
      • [x] Trace(...) implementation:
        • Queries for all the spans for the given trace, then is wired and returned.
        • [x] Builds tree trace: wires the trace to be returned to include it's children to the correct nesting.
      • [x] Traces(...) implementation.
        • Executes two queries: first gets all root's span for the given traces, second query gets all children spans for each trace, then traces are wired and returned; only N(default: 10) traces are returned.
        • [x] For each trace, builds a tree trace: wires it to include it's children to the correct nesting.
    • [x] Adds tests for InfluxDBStore.
    • [x] Adds NewInfluxDBStore:
      • Head function which runs the configuration needed for a new instance of InfluxDBStore - such as: run an InfluxDBServer, creates an InfluxDBClient, creates an admin user & appdash database with a retention policy if those do not already exist.
    • [x] Adds authentication to InfluxDBServer.
    • [x] Adds support to set default retention policy, which tells appdash database for how long time, data should be preserved before deleting it. (it's optional).
    • [x] Adds new InfluxDBStore webapp example:
      • Based on examples/cmd/webapp/main.go - run it with:
      • go run examples/cmd/webapp-influxdb/main.go

    Notes to consider:

    • InfluxDB sends anonymous data to m.influxdb.com, see:

      • https://docs.influxdata.com/influxdb/v0.10/administration/config/#reporting-disabled-false
      • https://github.com/influxdata/influxdb/blob/master/etc/config.sample.toml#L3
    • InfluxDB version being use is v0.10:

      Clustering, replication, and high-availability are in a beta state. The query engine is not optimized for the new TSM engine. A significant refactor of the query engine is in progress targeted for release in version 0.10.1. source

    Key Concepts

    Measurement

    The measurement acts as a container for tags, fields, and the time column, and the measurement name is the description of the data that are stored in the associated fields. Measurement names are strings, and, for any SQL users out there, a measurement is conceptually similar to a table.

    Tags

    Tags are optional. You don’t need to have tags in your data structure, but it’s generally a good idea to make use of them because, unlike fields, tags are indexed. This means that queries on tags are faster and that tags are ideal for storing commonly-queried metadata.

    Fields

    Fields are a required piece of InfluxDB’s data structure - you cannot have data in InfluxDB without fields. It’s also important to note that fields are not indexed. Queries that use field values as filters must scan all values that match the other conditions in the query. As a result, those queries are not performant relative to queries on tags (more on tags below). In general, fields should not contain commonly-queried metadata.

    Retention Policy

    The part of InfluxDB’s data structure that describes for how long InfluxDB keeps data (duration) and how many copies of those data are stored in the cluster (replication factor). RPs are unique per database and along with the measurement and tag set define a series. When you create a database, InfluxDB automatically creates a retention policy called default with an infinite duration and a replication factor set to the number of nodes in the cluster. See Database Management for retention policy management.

    Continuous Queries

    A CQ is an InfluxQL query that the system runs automatically and periodically within a database. InfluxDB stores the results of the CQ in a specified measurement. CQs require a function in the SELECT clause and must include a GROUP BY time() clause.

  • Add appdash/nettrace package

    Add appdash/nettrace package

    First draft at tracer for adding events for an underlying net.Conn Still needs tests and documentation, but I'd like to know if you'd be interested in it if I tidy it up.

    I'm using this as part of a benchmarking client for an API, which I realise is a bit of an odd use of appdash (it's all client side), but the code was easy to write and it seemed like it could be generally useful.

    Feedback is welcome.

  • Use vfsgen to statically embed template data.

    Use vfsgen to statically embed template data.

    • Remove deprecated Makefile build process.
    • Replace use of go-bindata with vfsgen for embedding template data. As a side effect, this removes the need to gofmt the generated output.
    • Move go generate directives into ./traceapp/tmpl package, since that's the only package they affect.

    Rationale

    Reasons for switching to vfsgen include:

    • Consistency across all Sourcegraph code bases.
      • Other projects need vfsgen for its additional functionality, and it's good to use the same tool for this task.
    • Ability to easily enable gzipped compression efficiently in the future.
    • No need for a follow-up go fmt ./... after regeneration.
    • Usage of http.FileSystem directly matches the needs of this project (bonus of being done in one package instead of across two separately maintained packages).
  • Improve ChunkedCollector performance slightly

    Improve ChunkedCollector performance slightly

    Summary

    This change improves performance of ChunkedCollector slightly, but also highlights an important issue (which I strongly believe will improve in Go 1.5, hopefully I will have time to test with 1.5 soon to verify). For now see the workaround mentioned in Solution section 2.

    (also see relevant tests and data at Appdash PR #80)

    Presumptions

    I believe that ChunkedCollector when placing items into it's underlying map (which holds onto them for < 500ms in our prod. apps, and just 10ms in our tests) is indirectly causing 20-41k tiny heap objects to be allocated (but the Go code is NOT leaking them) and that the Go runtime is poorly equipped in Go 1.4 to either:

    1. Reuse these small objects behind the map so that many allocations do not need to occur.
    2. Release the memory allocated by these small objects back to the OS (seen as top RES above).

    History

    I have also observed results similiar to this before in another project of mine (which unlike the case here, actually allocated several hundred thousand small objects per second), leaving me with ~12ms GC times on average. I believe these issues to be one in the same and likely fixed or improved significantly with the Go 1.5 GC improvements.

    Analysis:

    • Tests 3 and 4 show that garbage collection does bring the number of heap-objects back down to a reasonable amount, but still worse than it should be (none of those objects are in use!).
    • Test 1 shows that invoking both GC and FreeOSMemory brings the number of heap-objects back to the lowest numbers (i.e. what they should be).
    • Only test 1 (which invokes FreeOSMemory) appears to release any memory back to the host OS (Note: it is likely that Go invokes this function periodically and our test just doesn't run long enough to hit this, but I am not certain).

    Solution:

    In order to fix this issue i have looked at two things as a solution:

    1. Attempt to lower the amount of heap objects that Appdash ChunkedCollector must allocate.
      • This is not possible, because (after PR #80 is merged) it is literally just a very simple map and is being cleared to nil upon each ChunkedCollector.Flush.
      • Using anything other than a map (e.g. a slice) is probably not viable because of the number of spans that will end up in the map, we would effectively be trading memory usage for CPU usage. Not good.
      • However, I was able to identify and remove (in PR #80) a single slice that was uneeded, this cuts the total allocations nearly in half.
    2. Setup a background goroutine that occasionally invokes runtime.GC twice (needed to trigger a full GC) followed by one FreeOSMemory call.
      • Go by default triggers a GC only after the heap has grown 100%, which is normally fine, but in this case it appears to be unable to recollect these small objects and reuse them, so the heap grows nearly unbounded in size.
      • It is likely this issue would appear in apps today as a unbounded heap growth up to entire memory consumption, followed by either a (very) long GC or an OOM runtime panic.
      • A good value for which people may call these three functions in sequence might be every 5-30 minutes, just enough so that these small allocations are returned to the host OS (and can be reqaquired by Go subsequently) before the heap grows too large, but not such a quick value that it would hinder performance.

    Example:

    func init() {
        // Workaround until Go 1.5 is released, as described at:
        //
        //  https://github.com/sourcegraph/appdash/pull/80
        //
        go func() {
            for{
                time.Sleep(5 * time.Minute)
                runtime.GC()
                runtime.GC()
                debug.FreeOSMemory()
            }
        }()
    }
    
  • Go 1.5 issues with package internal

    Go 1.5 issues with package internal

    In Go 1.5, the internal/ package rule is enforced. When trying to build appdash, the build errors with a message:

    package sourcegraph.com/sourcegraph/appdash/cmd/appdash
        imports github.com/cznic/mathutil
        imports github.com/elazarl/go-bindata-assetfs
        imports github.com/gogo/protobuf/io
        imports github.com/gogo/protobuf/proto
        imports github.com/gorilla/context
        imports github.com/gorilla/mux
        imports github.com/jessevdk/go-flags
        imports sourcegraph.com/sourcegraph/appdash
        imports sourcegraph.com/sourcegraph/appdash/internal/wire
        imports sourcegraph.com/sourcegraph/appdash/internal/wire
        imports sourcegraph.com/sourcegraph/appdash/internal/wire: use of internal package not allowed
    

    I think this means you'd have to move the cmd/appdash somewhere to be a root of internal. Perhaps the easiest thing is to move ./internal to ./cmd/appdash/internal although it's not very elegant.

  • Replace gorilla/context with stdlib context

    Replace gorilla/context with stdlib context

    This PR changes the httptrace API by requiring *http.Request to be returned from SetContextSpan. To avoid breaking ani API,this change can be avoided by overwriting the fields of the request structure directly, dereferencing the shallow clone returned by WithContext.

  • Do not load template data from disk by default.

    Do not load template data from disk by default.

    This change replaces the previously-used Makefile with go:generate directives (for which go generate was designed). It also alters the default such that building an Appdash app will always produce a binary that includes the template data.

    This is easier for normal users, as majority of the time they are not interested in modifying the template data. Below is a translation of the make commands to their new equivalents:

    $ go generate
    

    Will produce two files containing the template data. By default, the data will be built into the binary for easy deployment etc by users.

    $ go install -tags=debug ./...
    

    Building the code with the debug build tag will enable usage of the second Go file generated, which loads the template data from disk (useful for development of the template files).

    Fixes #59

    /cc @beyang as he wrote the original Makefile and go-bindata code here.

  • webapp example panic: interface conversion: interface {} is nil, not appdash.SpanID

    webapp example panic: interface conversion: interface {} is nil, not appdash.SpanID

    Thanks for appdash, it looks pretty neat!

    I followed the instructions to install appdash and run the example webapp:

    $ go get -u sourcegraph.com/sourcegraph/appdash/...
    $ webapp
    

    Opened http://localhost:8699 in the browser, and got:

    PANIC: interface conversion: interface {} is nil, not appdash.SpanID
    goroutine 8 [running]:
    github.com/codegangsta/negroni.(*Recovery).ServeHTTP.func1(0x17c3080, 0xc420168018, 0xc42013ef00)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/recovery.go:41 +0x13a
    panic(0x13f00e0, 0xc420166740)
    	/usr/local/go/src/runtime/panic.go:489 +0x2cf
    main.Home(0x164e880, 0xc42015e6a0, 0xc42017c300)
    	/Users/soam/gopath/src/sourcegraph.com/sourcegraph/appdash/examples/cmd/webapp/main.go:106 +0x494
    net/http.HandlerFunc.ServeHTTP(0x1494458, 0x164e880, 0xc42015e6a0, 0xc42017c300)
    	/usr/local/go/src/net/http/server.go:1942 +0x44
    github.com/gorilla/mux.(*Router).ServeHTTP(0xc4200152c0, 0x164e880, 0xc42015e6a0, 0xc42017c300)
    	/Users/soam/gopath/src/github.com/gorilla/mux/mux.go:114 +0x10c
    github.com/codegangsta/negroni.Wrap.func1(0x164e880, 0xc42015e6a0, 0xc42000bf00, 0xc42015e6c0)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:46 +0x4d
    github.com/codegangsta/negroni.HandlerFunc.ServeHTTP(0xc42014c6a0, 0x164e880, 0xc42015e6a0, 0xc42000bf00, 0xc42015e6c0)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:29 +0x4e
    github.com/codegangsta/negroni.middleware.ServeHTTP(0x164ac00, 0xc42014c6a0, 0xc42014c740, 0x164e880, 0xc42015e6a0, 0xc42000bf00)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:38 +0xb4
    github.com/codegangsta/negroni.(middleware).ServeHTTP-fm(0x164e880, 0xc42015e6a0, 0xc42000bf00)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:38 +0x60
    sourcegraph.com/sourcegraph/appdash/httptrace.Middleware.func1(0x17c3080, 0xc420168018, 0xc42000bf00, 0xc42015e640)
    	/Users/soam/gopath/src/sourcegraph.com/sourcegraph/appdash/httptrace/server.go:84 +0x29f
    github.com/codegangsta/negroni.HandlerFunc.ServeHTTP(0xc42014c420, 0x17c3080, 0xc420168018, 0xc42000bf00, 0xc42015e640)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:29 +0x4e
    github.com/codegangsta/negroni.middleware.ServeHTTP(0x164ac00, 0xc42014c420, 0xc42014c720, 0x17c3080, 0xc420168018, 0xc42000bf00)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:38 +0xb4
    github.com/codegangsta/negroni.(middleware).ServeHTTP-fm(0x17c3080, 0xc420168018, 0xc42000bf00)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:38 +0x60
    github.com/codegangsta/negroni.(*Static).ServeHTTP(0xc42013f4a0, 0x17c3080, 0xc420168018, 0xc42000bf00, 0xc42015e620)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/static.go:53 +0x71c
    github.com/codegangsta/negroni.middleware.ServeHTTP(0x16492c0, 0xc42013f4a0, 0xc42014c700, 0x17c3080, 0xc420168018, 0xc42000bf00)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:38 +0xb4
    github.com/codegangsta/negroni.(middleware).ServeHTTP-fm(0x17c3080, 0xc420168018, 0xc42000bf00)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:38 +0x60
    github.com/codegangsta/negroni.(*Logger).ServeHTTP(0xc42013ef30, 0x17c3080, 0xc420168018, 0xc42000bf00, 0xc42015e600)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/logger.go:65 +0x89
    github.com/codegangsta/negroni.middleware.ServeHTTP(0x1649200, 0xc42013ef30, 0xc42014c6e0, 0x17c3080, 0xc420168018, 0xc42000bf00)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:38 +0xb4
    github.com/codegangsta/negroni.(middleware).ServeHTTP-fm(0x17c3080, 0xc420168018, 0xc42000bf00)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:38 +0x60
    github.com/codegangsta/negroni.(*Recovery).ServeHTTP(0xc42013ef00, 0x17c3080, 0xc420168018, 0xc42000bf00, 0xc42015e5e0)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/recovery.go:64 +0x82
    github.com/codegangsta/negroni.middleware.ServeHTTP(0x1649280, 0xc42013ef00, 0xc42014c6c0, 0x17c3080, 0xc420168018, 0xc42000bf00)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:38 +0xb4
    github.com/codegangsta/negroni.(*Negroni).ServeHTTP(0xc42013f500, 0x164e7c0, 0xc4201b80e0, 0xc42000bf00)
    	/Users/soam/gopath/src/github.com/codegangsta/negroni/negroni.go:86 +0x10d
    net/http.serverHandler.ServeHTTP(0xc420099130, 0x164e7c0, 0xc4201b80e0, 0xc42000bf00)
    	/usr/local/go/src/net/http/server.go:2568 +0x92
    net/http.(*conn).serve(0xc4201503c0, 0x164f040, 0xc420142f40)
    	/usr/local/go/src/net/http/server.go:1825 +0x612
    created by net/http.(*Server).Serve
    	/usr/local/go/src/net/http/server.go:2668 +0x2ce
    
  • Improves TestChunkedCollector.

    Improves TestChunkedCollector.

    Details

    Issue: #101

    • Improves TestChunkedCollector - it does intermittently fails becase reflect.DeepEqual cares about element position when comparing, so expected & actual variables being compare sometimes might have the same elements but in different order.
    • [x] Adds type byTraceID which we do use to sort []*wire.CollectPacket within TestChunkedCollector.
  • 503 Service Temporarily Unavailable about sourcegraph.com

    503 Service Temporarily Unavailable about sourcegraph.com

    https://sourcegraph.com/sourcegraph/appdash is 503 Service Temporarily Unavailable now.

    go: sourcegraph.com/sourcegraph/[email protected]: unrecognized import path "sourcegraph.com/sourcegraph/appdash" (parse https://sourcegraph.com/sourcegraph/appdash?go-get=1: no go-import meta tags ())

  • Use t.Cleanup instead of defer in Golang code tests

    Use t.Cleanup instead of defer in Golang code tests

    Using a proper defined cleanup function like

    t.Cleanup(func () {
      // do sth
    })
    

    is more explicit than just

    defer func () {
      // do sth
    }
    

    so let's use that approach.

  • Dependency Dashboard

    Dependency Dashboard

    This issue contains a list of Renovate updates and their statuses.

    Open

    These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

    • [ ] Update dependency bootstrap-table to v1.17.1
    • [ ] Update dependency d3 to v3.5.17
    • [ ] Update dependency d3 to v5
    • [ ] Check this option to rebase all the above open PRs at once

    • [ ] Check this box to trigger a request for Renovate to run again on this repository
  • Configure Renovate

    Configure Renovate

    WhiteSource Renovate

    Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.

    🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.


    Detected Package Files

    • traceapp/tmpl/data/layout.html (html)

    Configuration Summary

    Based on the default config's presets, Renovate will:

    • Start dependency updates only once this onboarding PR is merged
    • Enable Renovate Dependency Dashboard creation
    • If semantic commits detected, use semantic commit type fix for dependencies and chore for all others
    • Ignore node_modules, bower_components, vendor and various test/tests directories
    • Autodetect whether to pin dependencies or maintain ranges
    • Rate limit PR creation to a maximum of two per hour
    • Limit to maximum 20 open PRs at any time
    • Group known monorepo packages together
    • Use curated list of recommended non-monorepo package groupings
    • Fix some problems with very old Maven commons versions
    • Ignore spring cloud 1.x releases
    • Ignore http4s digest-based 1.x milestones
    • Use node versioning for @types/node
    • Limit concurrent requests to reduce load on Repology servers until we can fix this properly, see issue 10133
    • Run Renovate on following schedule: on the 1st through 7th day of the month

    🔡 Would you like to change the way Renovate is upgrading your dependencies? Simply edit the renovate.json in this branch with your custom config and the list of Pull Requests in the "What to Expect" section below will be updated the next time Renovate runs.


    What to Expect

    With your current configuration, Renovate will create 3 Pull Requests:

    chore(deps): update dependency bootstrap-table to v1.18.3
    • Schedule: ["on the 1st through 7th day of the month"]
    • Branch name: renovate/bootstrap-table-1.x
    • Merge into: master
    • Upgrade bootstrap-table to sha512-Wm00XTqNHcGqQgiDlZVpK4QIhO2MmMJfzNJfh8wwbBC9BR0FtdJwPqDhEYy8jCfKEhWWZe/LDB6FwY7YE9QhMg==
    • Upgrade bootstrap-table to sha512-5RNDl2gYvm6wpoVAU4J2+cMGZQeE2o4/AksK/bi355p/C31aRibC93EYxXczXq3ja2PJj60uifzcocu2Ca2FBg==
    chore(deps): update dependency d3 to v3.5.17
    • Schedule: ["on the 1st through 7th day of the month"]
    • Branch name: renovate/d3-3.x
    • Merge into: master
    • Upgrade d3 to sha512-ilnmzGTqmx3gXTbd1eLUf6LTgAFEULf1d1Pf18LR3o+IQjt1j+rtlOHX1upJUSdWlganBwNe0E7U4U5iWH+uYw==
    chore(deps): update dependency d3 to v7
    • Schedule: ["on the 1st through 7th day of the month"]
    • Branch name: renovate/d3-7.x
    • Merge into: master
    • Upgrade d3 to sha512-gIER+r9k70gtEKHRZuyOVIKis4Vy0RFGSGhW48dIqyXAnuqr3Enxwc71gq5ludmgOCYvg7pgSFu6Er3NytazKQ==

    ❓ Got questions? Check out Renovate's Docs, particularly the Getting Started section. If you need any further assistance then you can also request help here.


    This PR has been generated by WhiteSource Renovate. View repository job log here.

  • Setting up appdash in Go, not seeing traces

    Setting up appdash in Go, not seeing traces

    Hi all. Couldn't ask on slack as the link on the README is dead. When I used the in-app example code, I got traces to a local running appdash instance. I'm now trying to connect to a already running appdash instance and not getting traces. I think I'm setting up the tracer wrong. Any help?

    // my app.go
    tracer := appdashtracer.NewTracer(appdash.NewRemoteCollector("appdash.service.consul:8700"))
    

    edit Saw an example using chunked collector. Tried that, it did not work either. Still not seeing traces (appDashAddr is the same as above, appdash.service.consul:8700).

    // my app.go
    collector := appdash.NewRemoteCollector(appDashAddr)
    chunkedCollector := appdash.NewChunkedCollector(collector)
    tracer := appdashtracer.NewTracer(chunkedCollector)
    

    2nd edit updated to the following. Still no traces. No logs either.

    logger := log.New(os.Stdout, "appdash", log.Lshortfile|log.Ltime)
    collector := appdash.NewRemoteCollector(appDashAddr)
    chunkedCollector := appdash.NewChunkedCollector(collector)
    tracer := appdashtracer.NewTracerWithOptions(chunkedCollector, appdashtracer.Options{
    	Verbose: true,
    	Logger:  logger,
    })
    

    *** end edits ***

    I can hit appdash.service.consul:8700 and it comes up. But no traces to be found.

    The separately running appdash instance looks like:

    // separate server running appdash
    func main() {
    	var minEvictAge time.Duration
    	var port int
    
    	flag.DurationVar(&minEvictAge, "min-evict-age", 5*time.Minute, "set the amount of time the tracer will hold onto traces")
    	flag.IntVar(&port, "port", 8700, "the port on which the for app dash tracer will run")
    	flag.Parse()
    
    	memStore := appdash.NewMemoryStore()
    	store := &appdash.RecentStore{
    		MinEvictAge: minEvictAge,
    		DeleteStore: memStore,
    	}
    
    	appDashURLString := fmt.Sprintf("http://localhost:%d", port)
    	appDashURL, err := url.Parse(appDashURLString)
    	if err != nil {
    		log.Fatal(err)
    	}
    	tapp, err := traceapp.New(nil, appDashURL)
    	if err != nil {
    		log.Fatal(err)
    	}
    	tapp.Store = store
    	tapp.Queryer = memStore
    
    	log.Printf("starting on :%d", port)
    	log.Fatal(http.ListenAndServe(fmt.Sprintf(":%d", port), tapp))
    }
    
This example showcases an event-sourced CQRS system based on github.com/romshark/eventlog

Eventlog Example This example is showcasing an eventually consistent, fault-tolerant, event sourced system following the CQRS (Command-Query-Responsib

Mar 13, 2022
a microservice framework for rapid development of micro services in Go with rich eco-system
a microservice framework for rapid development of micro services in Go with rich eco-system

中文版README Go-Chassis is a microservice framework for rapid development of microservices in Go. it focus on helping developer to deliver cloud native a

Sep 22, 2022
Easegress (formerly known as EaseGateway)is an all-rounder traffic orchestration system
Easegress (formerly known as EaseGateway)is an all-rounder traffic orchestration system

Easegress (formerly known as EaseGateway)is an all-rounder traffic orchestration system

Sep 20, 2022
Demo Fully Isolated System Architecture

Fully Isolated System Architecture (Microservices) Arsitektur Request | | | Api Gateway --- Auth Provider |\________________________

Jul 9, 2022
ftgogo - event-driven architecture demonstration application

ftgogo (food-to-gogo) is a Golang implementation of the FTGO application described in the book "Microservice Patterns" by Chris Richardson. A library edat was developed to provide for Golang many of the solutions that Eventuate, the framework used by FTGO, provides for Java.

Sep 13, 2022
Sample full stack micro services application built using the go-Micro framework.
Sample full stack micro services application built using the go-Micro framework.

goTemp goTemp is a full stack Golang microservices sample application built using go-micro. The application is built as a series of services that prov

Jul 28, 2022
Cloud-native and easy-to-use application management platform | 云原生且易用的应用管理平台
Cloud-native and easy-to-use application management platform | 云原生且易用的应用管理平台

Website • Documentation What is NEW! August 24, 2020 ,Rainbond 5.2 Stable version is officially released View Release Rainbond Introduction Cloud nati

Sep 20, 2022
goTempM is a full stack Golang microservices sample application built on top of the Micro platform.
goTempM is a full stack Golang microservices sample application built on top of the Micro platform.

goTempM is a full stack Golang microservices sample application built on top of the Micro platform.

Sep 13, 2022
Sample cloud-native application with 10 microservices showcasing Kubernetes, Istio, gRPC and OpenCensus.
Sample cloud-native application with 10 microservices showcasing Kubernetes, Istio, gRPC and OpenCensus.

Online Boutique is a cloud-native microservices demo application. Online Boutique consists of a 10-tier microservices application. The application is

Sep 24, 2022
micro-draft-manager is a microservice that helps you to manage unstructured data in your application with sorting and full-text search

micro-draft-manager is a microservice that helps you to manage unstructured data in your application with sorting and full-text search. For example, y

Nov 24, 2021
Study Project for the application of micro services and requisition controls

Starting Endpoint GO with Retry Request Install GoLang for Linux Tutorial: LINK

Jul 4, 2022
Online Boutique: a cloud-native microservices demo application

This is an application forked from the GCP Microservice demo. Online Boutique is

Jan 5, 2022
Poc-krakend: Allows you to create, modify and delete enpoints in "configuration.json" without restart the application.

poc-krakend Description This POC is for test dynamic (Hot reload) routes in krakend. Allows you to create, modify and delete enpoints in "configuratio

Jan 26, 2022
Targetrwe api test - This project provides the backend service for the targetrwe test application

Targetrwe-api This project provides the backend service for the targetrwe test a

Feb 15, 2022
NewSQL distributed storage database based on micro service framework
NewSQL distributed storage database based on micro service framework

QLite 是基于微服务的 NewSQL 型数据库系统,与传统的一体化数据库不同,该系统将本该内置的多种数据结构(STL)拆分成多个服务模块,每个模块都是独立的一个节点,每个节点都与其主网关进行连接,从而形成分布式存储结构。

Jun 19, 2022
Design-based APIs and microservices in Go
Design-based APIs and microservices in Go

Goa is a framework for building micro-services and APIs in Go using a unique design-first approach. Overview Goa takes a different approach to buildin

Sep 19, 2022
Generates Golang client and server based on OpenAPI2 (swagger) definitions
Generates Golang client and server based on OpenAPI2 (swagger) definitions

ExperienceOne Golang APIKit ExperienceOne Golang APIKit Overview Requirements Installation Usage Generate standard project structure Define the API wi

Aug 9, 2022
Concourse is a container-based continuous thing-doer written in Go and Elm.
Concourse is a container-based continuous thing-doer written in Go and Elm.

Concourse: the continuous thing-doer. Concourse is an automation system written in Go. It is most commonly used for CI/CD, and is built to scale to an

Sep 18, 2022
🦄🌈 YoyoGo is a simple, light and fast , dependency injection based micro-service framework written in Go.
🦄🌈 YoyoGo is a simple, light and fast , dependency injection based micro-service framework written in Go.

???? YoyoGo is a simple, light and fast , dependency injection based micro-service framework written in Go. Support Nacos ,Consoul ,Etcd ,Eureka ,kubernetes.

Sep 18, 2022