stats discarded as unable to get connection to spaceport

[sekhavati]

Hi folks. Hoping you can help us understand why we're not getting any metrics being reported by our supergraph.

A bit of background to our setup:

• We're running Apollo Router v1.1.0 on our own infrastructure via containers
• The router instances are deployed in a VPC with Egress access to the internet (no ingress)
• We've set env vars APOLLO_KEY and APOLLO_GRAPH_REF as per these instructions
• APOLLO_TELEMETRY_DISABLED set to 1 (ie: disabled)
• The logs show at startup time that usage is enabled, ie:
  Apollo Studio usage reporting is enabled. See https://go.apollo.dev ...

What we're seeing though is the following error message in our logs repeatedly:

stats discarded as unable to get connection to spaceport: Error occurred while creating a new object: ReporterError: source: transport error, message: transport error"},"target":"apollo_router::plugins::telemetry::apollo_exporter

Any ideas what this could be due to?

I'm guessing this might be due to us running the Apollo Router in a container environment and certain ports not being exposed for spaceport to do its thing 🤷‍♂️

[bnjjj]

I think it's something that has been fixed in 1.2.0 in this issue/PR #1893
Could you upgrade to at least the 1.2.0 version and let us know if you still have this issue ?
It's better if you can upgrade to the latest release

[garypen]

@sekhavati I just built an image using that Dockerfile on my M1 laptop and on my linux PC and it is working fine in both cases. This is the output from my M1 build/run:

% cat dock.file 
FROM ghcr.io/apollographql/router:v1.5.0
EXPOSE 4000
WORKDIR /dist
COPY router.yaml ./config/
ENTRYPOINT ["./router"]
% docker build -f dock.file .; echo $?              
[+] Building 0.1s (8/8) FINISHED                                                
 => [internal] load build definition from dock.file                        0.0s
 => => transferring dockerfile: 33B                                        0.0s
 => [internal] load .dockerignore                                          0.0s
 => => transferring context: 2B                                            0.0s
 => [internal] load metadata for ghcr.io/apollographql/router:v1.5.0       0.0s
 => [internal] load build context                                          0.0s
 => => transferring context: 30B                                           0.0s
 => [1/3] FROM ghcr.io/apollographql/router:v1.5.0                         0.0s
 => CACHED [2/3] WORKDIR /dist                                             0.0s
 => CACHED [3/3] COPY router.yaml ./config/                                0.0s
 => exporting to image                                                     0.0s
 => => exporting layers                                                    0.0s
 => => writing image sha256:e2a4334a059cc18e6c649bd403906895e07dfda0569a7  0.0s

Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
0
% docker images | more                              
REPOSITORY                                     TAG                                        IMAGE ID       CREATED         SIZE
<none>                                         <none>                                     e2a4334a059c   20 seconds ago   190MB
ghcr.io/apollographql/router                   v1.5.0                                     d4ad45b9a687   24 hours ago    190MB
<snip>
% docker run --rm e2a4334a059c 
Apollo Router v1.5.0 // (c) Apollo Graph, Inc. // Licensed as ELv2 (https://go.apollo.dev/elv2)

⚠️  The Apollo Router requires a composed supergraph schema at startup. ⚠️

👉 DO ONE:

  * Pass a local schema file with the '--supergraph' option:

      $ ./router --supergraph <file_path>

  * Fetch a registered schema from Apollo Studio by setting
    these environment variables:

      $ APOLLO_KEY="..." APOLLO_GRAPH_REF="..." ./router

      For details, see the Apollo docs:
      https://www.apollographql.com/docs/router/managed-federation/setup

🔬 TESTING THINGS OUT?

  1. Download an example supergraph schema with Apollo-hosted subgraphs:

    $ curl -L https://supergraph.demo.starstuff.dev/ > starstuff.graphql

  2. Run the Apollo Router in development mode with the supergraph schema:

    $ ./router --dev --supergraph starstuff.graphql
% 

There may be something wrong with our image, but I can't see what it is just now.

There may be something wrong with the way you are building your docker image, so I recommend that you check your dockerfile and build arguments carefully.

[sekhavati]

@garypen Bit of a long shot but did you try taking the image built on your M1 Mac and running it on your Linux machine?

[garypen]

@sekhavati I didn't, but I wouldn't expect that to work by default. There is no Rosetta like support for running ARM64 images on AMD64. You'd have to do it in software, using something like this: https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/

[sekhavati]

I'll give 1.5.0 another sometime when I get a chance to see if there was any warning output in my console that I glazed over previously.

The reason I asked what I did was because my setup is a similar to what you described atm, as in:

• Build the image on my M1 Mac
• Push this image to our private image repository
• Download and run this image on our container infrastructure (Linux)

Above approach works fine with with v1.0.0 -> v1.4.0 but then 1.5.0 hit the issue I mentioned

[sekhavati]

@garypen I just took a re-look at this for the first time since last year. For the benefit of anyone else who hits this issue, I needed to add --platform linux/amd64 when running docker build from my M1 Mac