Golang v3 Tracker Events not received in collector

Hi Folks,

I’m having issues seeing events in good or bad stream with the latest golang tracker v3.

The following is my code. I added the print statement at the end to confirm what’s supposed to be sent. in terms of data and I’m seeing the print statement with no issues.

I’m wondering if someone else has run into similar issues. I’m assuming building the executable and running it will mean the emitter sends the event without any other setup required for the golang program.

I tried GET and POST as well as http and https. true and false for encoding as well.

Additionally, I inspected the network requests leaving my machine using a proxy (Charles) and the url that was receiving these events was https://api.apple-cloudkit.com and not the collectorUri for some reason.

Any help would be appreciated.

package main

import "fmt"
import storagememory "github.com/snowplow/snowplow-golang-tracker/v3/pkg/storage/memory"
import sp "github.com/snowplow/snowplow-golang-tracker/v3/tracker"

func main() {

	subject := sp.InitSubject()

	emitter := sp.InitEmitter(

		tracker := sp.InitTracker(
			// Create a data map of the content event
			data := map[string]interface{}{
				"action": "publishedArticle",
				"contentId": "j302",

// Create a new SelfDescribingJson
sdj := sp.InitSelfDescribingJson("iglu:com.company/company_schema/jsonschema/1-0-0", data)

  Event: sdj,
	Subject: subject,

fmt.Println("eventSent", sdj);

Hi Yazan,

If you aren’t seeing the event leave the machine at all it’s possible that due to the async nature of the Go tracker that the program may terminate before the event is sent. If you are just using this for testing I believe you can stop the emitter, and manually flush which should block and send these events before terminating.


tracker.BlockingFlush(5, 10)

Thank you Mike,
yes that worked. I see events landing in collector now.

New to golang and I’m trying to understand what’s happening here in development that wouldn’t happen in production. As in, why won’t I need to trigger the two methods you shared as well in production code.

In a production environment, such as a web server, you’d have a long living application - one which wouldn’t terminate at the end of main(). So there would be plenty of time for the tracker to send the events in the background as the application won’t close.

In your example, your application runs and then immediately closes, so you need to block that closing action until the trackers got an OK back from the collector for the events in the queue.

However, whilst web servers are long running they do eventually terminate, or reboot, or similar. You’ll usually have some sort of shutdown method (where you’ll handle things like sigterm), in there you might want to call Stop() and BlockingFlush() before the server completes it shutdown to ensure you don’t lose any events.


Thank you Paul.

1 Like