Add Service Ping metrics for the v3 sync outcome events

What does this MR do and why?

Follow-up to !252822 (merged), now merged to master, which added 30 internal events for v3 package metadata sync outcomes across licenses and malware_advisories, 15 outcomes each. Addresses a review comment on that MR, linked below.

That MR ships events only, reaching Snowplow from GitLab.com and Self-Managed or Dedicated instances on 18.0+ with event-level collection. Other instances get only Service Ping, so v3 sync stayed unreported there.

This MR adds 32 metric definitions under ee/config/metrics/counts_all/, data_source: internal_events, giving 92 Service Ping key paths. The 28 outcome metrics are unchanged: counts.count_total_<event_name>, time_frame: [7d, 28d, all].

The 2 delta_backlog events now get two metrics each. sums.sum_total_<event_name> uses operator: sum(value) with time_frame: [7d, 28d]. The all-time frame was dropped, since a lifetime backlog sum has no meaning and can never return to zero.

counts.count_total_<event_name> uses the same time frames and counts backlog observations, one per registry per bulk run. It tells a sum of zero apart from no bulk run, and lets an average backlog per registry be derived from sum divided by count. The backlog sum description no longer claims zero means every registry is caught up. Each observation is capped at 20 per registry, so the sum is a lower bound.

All 32 set tiers: [ultimate], product_group: composition_analysis, and milestone: '19.4'. Each introduced_by_url points at this MR, !254866 (merged), since the parent merged and carries none of these files.

ee/spec/services/package_metadata/v3_sync_service_spec.rb builds a shared tracked_events list from TRACKED_DATA_TYPES and SYNC_OUTCOMES, used by the event-definition and metric checks. The metric example expects counts.count_total_<event> for outcomes and sums.sum_total_<event>_weekly for delta_backlog, and asserts sum(value) is used only for delta_backlog. A regenerated file that lost the operator now fails, instead of silently counting registries under a sums key path.

One example asserts tracking an outcome increments its count metric. Another asserts tracking delta_backlog with value: 3 adds 3 to the weekly sum and one to the weekly count, using the :pm_sync_config factory.

Not done on purpose: no per-registry filter: { label: <purl_type> } metrics, since the label stays queryable in Snowplow on GitLab.com. No database changes, migrations, feature flag, UI changes, docs, or changelog, matching the parent MR.

References

• Parent MR: !252822 (merged)
• Review comment this follows up on: !252822 (comment 3815864674)
• Parent work item: #602417
• Success metrics discussion: #627683

Screenshots or screen recordings

Not applicable. This MR has no user-facing UI changes.

How to set up and validate locally

1. Run the specs:

   bin/rspec ee/spec/services/package_metadata/v3_sync_service_spec.rb
   bin/rspec ee/spec/config/metrics/every_metric_definition_spec.rb spec/lib/gitlab/usage/metric_definition_validate_all_spec.rb

2. Optionally, read a metric value in a Rails console:

   Gitlab::Usage::MetricDefinition.definitions['counts.count_total_sync_pmdb_v3_licenses_delta_completed']

The sync service spec passed 14 examples with 0 failures. The combined metric definition specs passed 5 examples with 0 failures. RuboCop is clean on the spec, and repo YAML lint is clean on all 32 files.

Follow-ups outside this MR

Found while reviewing the already-merged sync service. This MR does not change these. Metric descriptions keep parity with the merged event descriptions.

• A raise while listing files from PDS, before ingest starts, emits no *_failed event on the individual path. The loop stops, so later registries get no outcome either. Only the bulk path wraps its fetch.
• skipped_stop_signal fires once per loop at most, since the loop breaks after the first skipped registry. It counts loop stops, while the description promises one event per skipped registry.
• A registry PDS omits from a bulk /delta response, or lists under not_supported, still ends as delta_up_to_date, since it ingests an empty stream.
• A run that both fails to persist a slice and then hits the stop signal is reported only as *_interrupted.
• The delta_failed description mentions a PDS rejection, but a rejected delta request is only reachable on the bulk path, as bulk_delta_failed.
• Gitlab::InternalEvents.with_batched_redis_writes around backlog tracking no longer batches anything, since sum metrics write through RedisSum, which has no batch mode. Correctness is unaffected.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

🤖 Generated with Claude Code