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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions