Postgres tracing stops working on long-lived connection.

[sync-by-unito[bot]]

I deployed src/stirling/source_connectors/socket_tracer/protocols/pgsql/testing/postgres.yaml and src/stirling/source_connectors/socket_tracer/protocols/pgsql/testing/demo.yaml to a namespace called stirling-testing. After 1-2minutes no traffic is traced from the postgres demo pod to postgres anymore. Deleting the demo pod and restarting it fixes the issue, so it seems like at some point the long-lived connection gets marked as not postgres traffic and is no longer traced.

Note: I think src/stirling/source_connectors/socket_tracer/protocols/pgsql/testing/postgres.yaml got moved or deleted so not sure where to get that part of the repro from.

┆Issue is synchronized with this Jira Bug by Unito

[sync-by-unito[bot]]

➤ Yaxiong Zhao commented:

Put to myself for tracking. Unfortunately I have not done anything for this.

[sync-by-unito[bot]]

➤ Natalie Serrino commented:

Adding onto this, it looks like we have a similar issue with a New Relic integration customer. They are using Kong, which creates long-lived connections to Postgres instances. Yaxiong Zhao Omid Azizi let me know if there are questions that we can ask the customer that would help us diagnose https://konghq.com/kong/ ( https://konghq.com/kong/ )

[sync-by-unito[bot]]

➤ Omid Azizi commented:

Is it a case where it originally traces and then stops? Or does it never trace?

[sync-by-unito[bot]]

➤ Natalie Serrino commented:

Unclear. I asked the customer facing person to ask the customer to try restarting the PEM to see if it starts collecting data, so hopefully we can find out