Status Page Usage Ping

What does this MR do?

Overview

This adds data about status page usage to the usage ping.

Specifically,

Number of projects publishing issues to Status page site

Number of issues published to Status Page site

Technical Implementation

Project Count

Use an existing scope to count number of projects where StatusPageSettings.enabled is true

Issue Count

Use a new scope to count to count number of public (non-confidential) issues for projects where StatusPageSettings.enabled is true.

• Query executed is:

SELECT COUNT(*) FROM "issues” 
INNER JOIN "projects" ON "projects"."id" = "issues"."project_id” 
INNER JOIN "status_page_settings" ON "status_page_settings"."project_id" = "projects"."id” 
WHERE "status_page_settings"."enabled" = TRUE 
AND "issues"."confidential" = FALSE;

• Adds a partial index

Before adding the index this is the query plan from gitlab.com:

 Aggregate  (cost=130.02..130.03 rows=1 width=8) (actual time=0.006..0.006 rows=1 loops=1)
   Buffers: shared hit=1
   ->  Nested Loop  (cost=1.14..129.95 rows=29 width=0) (actual time=0.003..0.003 rows=0 loops=1)
         Buffers: shared hit=1
         ->  Nested Loop  (cost=0.57..61.52 rows=15 width=12) (actual time=0.003..0.003 rows=0 loops=1)
               Buffers: shared hit=1
               ->  Index Scan using index_status_page_settings_on_project_id on public.status_page_settings  (cost=0.14..22.59 rows=15 width=8) (actual time=0.002..0.002 rows=0 loops=1)
                     Filter: status_page_settings.enabled
                     Rows Removed by Filter: 0
                     Buffers: shared hit=1
               ->  Index Only Scan using projects_pkey on public.projects  (cost=0.43..2.59 rows=1 width=4) (actual time=0.000..0.000 rows=0 loops=0)
                     Index Cond: (projects.id = status_page_settings.project_id)
                     Heap Fetches: 0
         ->  Index Scan using index_issues_on_project_id_and_iid on public.issues  (cost=0.56..3.25 rows=131 width=4) (actual time=0.000..0.000 rows=0 loops=0)
               Index Cond: (issues.project_id = projects.id)
               Filter: (NOT issues.confidential)
               Rows Removed by Filter: 0

After adding the index this is the query plan from gitlab.com:

Aggregate  (cost=127.72..127.73 rows=1 width=8) (actual time=0.043..0.044 rows=1 loops=1)
   Buffers: shared hit=1
   ->  Nested Loop  (cost=1.12..127.64 rows=29 width=0) (actual time=0.012..0.012 rows=0 loops=1)
         Buffers: shared hit=1
         ->  Nested Loop  (cost=0.56..59.22 rows=15 width=12) (actual time=0.012..0.012 rows=0 loops=1)
               Buffers: shared hit=1
               ->  Index Only Scan using status_page_settings_enabled_partial on public.status_page_settings  (cost=0.12..20.28 rows=15 width=8) (actual time=0.011..0.011 rows=0 loops=1)
                     Heap Fetches: 0
                     Buffers: shared hit=1
               ->  Index Only Scan using projects_pkey on public.projects  (cost=0.43..2.59 rows=1 width=4) (actual time=0.000..0.000 rows=0 loops=0)
                     Index Cond: (projects.id = status_page_settings.project_id)
                     Heap Fetches: 0
         ->  Index Scan using index_issues_on_project_id_and_iid on public.issues  (cost=0.56..3.25 rows=131 width=4) (actual time=0.000..0.000 rows=0 loops=0)
               Index Cond: (issues.project_id = projects.id)
               Filter: (NOT issues.confidential)
               Rows Removed by Filter: 0

The perf difference appears fairly minor at the moment but we are taking advantage of Index Only Scan using status_page_settings_enabled_partial on status_page_setting and the cost is slightly less.

Screenshots

Admin Area > Metrics and profiling

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team

Part of #207409 (closed)