Supabase CLI 2.15.8 - connecting to intake.logs.datadoghq.com

[yz778]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

Fresh install of Supabase using the 2.15.8 CLI tool. The supabase_analytics container shows errors [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443: connection refused every second.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. mkdir test
2. cd test
3. supabase init
4. supabase start
5. docker logs -f supabase_analytics

Expected behavior

It should not be

Screenshots

System information

• OS: Linux
• Browser: n/a
• Supabase CLI: 2.15.8
• Logflare image: public.ecr.aws/supabase/logflare:1.11.0

Additional context

None

[Hallidayo]

Hi, I've moved this issue over from the supabase repo as its an issue with the cli.

[smndtrl]

Having the same error with the following in config.toml on 2.19.7

[analytics]
enabled = true
port = 54327
# Configure one of the supported backends: `postgres`, `bigquery`.
backend = "postgres"

and all logs in studio are 401 errors like e.g.

{
  "code": 401,
  "message": "Unauthorized",
  "requestId": "e5118dd3-925c-4778-b232-0b296df087f5"
}

[syntaxaire]

I don't think this issue is specific to the CLI. I am using supabase self-hosted with the official docker compose config and this log message constantly appears in the analytics container. Fortunately, this is not a production setup. Do people using supabase self-hosted in production know that their containers are doing this?

[MoOx]

I was having CPU related issues with my computer and ended up looking at docker and saw an weird unexpected "high" cpu usage from a unused local supabase setup

What surprised me was the supabase_analytics_learnee so I checked logs and saw this

13:30:40.086 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:40.130 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:41.211 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:41.331 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:41.435 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:41.720 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:42.075 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:43.030 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:43.316 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:43.450 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:44.471 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:44.695 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:44.735 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:47.271 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:47.937 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:50.252 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:51.211 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:51.455 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated


13:30:53.246 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443:⁠ ALPN protocol not negotiated

And this is not stopping, I can scroll hours with this logs.
Is my computer actually trying to access this URL for real or is docker blocking this ?
Anyway, this seems unexpected.

How can I prevent this issue ?

[sweatybridge]

Hi there, our logflare team has merged an upstream fix Logflare/logflare#2784

we are just waiting for a new docker image release to update cli. it will probably be included in the cli release tmr

[sbs44]

@sweatybridge – I really appreciate you getting to this one! For some reason I just assumed that this was "just a me" problem so I never looked into it and have just been putting up with the ~50 Datadog warnings per minute when working locally (isn't a problem on my linked instance).

Just wanted to let you know that I'm running supabase-beta (CLI version v2.45.5 with supabase/logflare v1.22.3) and the logs are still flooded:

18:13:52.146 [warning] Failed to connect to https://http-intake.logs.ap1.datadoghq.com:443 connection refused
18:13:56.966 [warning] Failed to connect to https://http-intake.logs.ap1.datadoghq.com:443 connection refused
18:14:00.507 [warning] Failed to connect to https://http-intake.logs.ap1.datadoghq.com:443 connection refused
18:14:02.570 [warning] Failed to connect to https://http-intake.logs.ap1.datadoghq.com:443 connection refused

Sharing this in case it's helpful:

... back when I thought it was a good idea to self-host, I was able to fix the issue with a super simple modification to the Logflare source.

The problem stems from Logflare creating Finch connection pools for Datadog endpoints even when running in Supabase mode where Datadog is not used. In v1.22.3, it looks like the datadog_connection_pools() function in lib/logflare/application.ex defaults to include all Datadog pools because :http_connection_pools defaults to ["all"].

I fixed this in my v1.18.1 fork by checking for Supabase mode directly:

defp build_finch_pools(http1_count) do
  base_pools = %{
    :default => [protocols: [:http1]],
    "https://bigquery.googleapis.com" => [...]
  }

  # Only add Datadog pools if not in Supabase mode
  if Application.get_env(:logflare, :supabase_mode) do
    base_pools
  else
    Map.merge(base_pools, datadog_pools)
  end
end

I think in the latest release (v1.22.3), an even simpler fix would be to leverage the existing :http_connection_pools configuration. The Supabase CLI could set this config to an empty list [] (or any list that excludes both "datadog" and "all") when starting the Logflare container. Unless I'm missing something, that would prevent the Datadog pools from being created without requiring any Logflare code changes.

[Icehunter]

As I'm self-hosting to fit data residency requirements, when I saw this happening as well, I got concerned that telemetry/etc data is being harvested by the app. I haven't signed up for and will not use datadog, so what is this and how do I disable calling home?

[sweatybridge]

closing as it has been resolved with latest logflare

there shouldn't be any telemetry harvested without explicit user consent