Logflare / logflare / 40377cf531e1e716373dbf6edf799d32f28819de

81%

Build Type

push

github

Committed by web-flow

Commit Message

fix: split ingest_logs telemetry counters per outcome (#3536)

* fix: split ingest_logs telemetry counters per outcome

The three ingest_logs counters in lib/telemetry.ex (`drop`,
`rejected`, `buffer_full`) all attached to the same Telemetry event
because `Telemetry.Metrics.counter/2` derives the event name by
dropping the last segment. Every emission therefore incremented all
three counters, so the per-outcome metrics showed identical values
— and `buffer_full` had no emission site at all yet was fully
populated.

- Give each outcome counter its own `event_name:` and emit
  reason-specific event names from `do_telemetry/2`.
- Re-instrument `buffer_full` in the `BufferLimiter` plug alongside
  the existing 429 path, since the previous emission site was removed
  when `Logflare.Logs.Logs` was deleted.
- Split the unsuffixed `drop` counter into per-reason counters
  (`drop_lql`, `drop_stale`, `drop_future`). LQL drops,
  stale-timestamp drops, and future-timestamp drops are distinct
  operational signals that `split_valid_events/2` was already
  differentiating in its warning log but lumping into a single
  counter.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* test: assert ingest_logs telemetry counters fire per outcome

Adds explicit `measurement: :count` on each ingest_logs counter so the
metric definition matches the `%{count: 1}` emission regardless of
reporter, and locks the event contract in with tests for `drop_lql`,
`drop_stale`, `drop_future`, `rejected`, and `buffer_full`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* style: format buffer_limiter_test assert_receive

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor: move buffer_full counter to request-level namespace

The buffer_full counter lived under the ingest_logs.* event-outcome
namespace alongside the per-event drop/rejected counters, but it is
emitted once per HTTP request from the BufferLimiter plug... (continued)

Coverage Stats

15 of 15 new or added lines in 2 files covered. (100.0%)

10 existing lines in 4 files now uncovered.

12687 of 15771 relevant lines covered (80.45%)

3677.86 hits per line