Skip to content

statistics table #183

@steve-chavez

Description

@steve-chavez

Problem

Currently it's not possible to know which requests are causing most egress. The net._http_response table is temporary and gets cleaned often, so no meaningful statistics can be gathered from them.

Solution

Add some form of statistics table that has aggregated metrics, like request/response body size. Possibly per URL (or better by hostname, so series don't blow up)

Notes

  • Logging Optionally log based on status code responses #49 would not be a solution for this problem, as that only focuses on errors and not successful responses. I believe we need aggregate metrics for this.
  • pg_stat_statements doesn't refresh its statistics once drop extension pg_stat_statements is done, you need to call pg_stat_statements_reset(). Which is a hint they keep their statistics in memory somehow.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions