Geo: Gather unique monthly secondary site users for git operations
Problem to solve
Track unique monthly secondary user git operations (clone/push/pull). We currently track unique monthly secondary users using usage ping data. These stats capture visits to projects, issues and users pages on the secondary site and do not capture git operations. Therefore, we believe we might be getting a partial view of the number of unique monthly secondary users but omitting the git operations from the usage ping stats.
Better understanding how our customers leverage the secondary sites will guide future enhancements to Geo. It will also allow us to understand if users are benefiting from new capabilities we have delivered such as Unified URLs and proxying.
Intended users
User experience goal
GitLab product managers should be able to view stats on unique monthly secondary git operations via the analytics platform by querying the correct metric path for this metric.
Proposal
Create a new usage ping stat called unique monthly secondary git users
which tracks unique secondary users performing git operations on secondary Geo sites via SSH or HTTP(S). The metric will be per customer GitLab installation an aggregate total of unique secondary git users per month.
Why create a second state rather than extending the existing stat? Tracking these activities separately we will be able to get insight into how customers are leveraging Geo secondaries. I.e. do they use the completely functionality of the secondary site such as Web UI and for git operations or do they accelerate git operations via the secondary site but continue to navigate to the primary site Web UI.
Create another metric that tracks the number of requests made by CI runners against the secondary. We will be making it possible to [accelerate runners using secondary sites(&9779 (closed)) soon. This metric will help us understand the prevalence of this use case amongst our customer base.
Further details
We are seeing low numbers for unique monthly secondary users in usage ping data. This data is collected by detecting when a user request to access projects,issues or user pages at a secondary site is proxied to the primary. In an ideal world remote users should have a transparent experience when accessing the secondary site. We enabled proxying by default for customers using separate secondary URLs. Due to historical reasons we believe the majority of customers will have deployed Geo in this way and not using Unified URLs. We expected a gradual increase in unique monthly secondary users as more customers adopt GitLab release 15.1+. We have not seen this materialise. There are reasons to believe customers may have directed users towards the primary for Web UI operations for historical reasons - the main reason being the secondary site Web UI was read only and had limited functionality until the availability of the proxying feature.
Permissions and Security
Availability & Testing
We want to make sure the solution is scalable with hundreds of users logging into secondary sites every day. Test accurate counting of unique secondary users for git operations performance at the secondary site via:
- ssh
- http
- https
Available Tier
- Premium/
- Ultimate
What does success look like, and how can we measure that?
We see usage ping statistics coming back for unique monthly secondary git users.
Product managers are able to pull these usage metric via Tableau or Sisense to chart the historical growth of this metric over time and compare this metric against the unique monthly secondary users
metric.
What is the type of buyer?
Self-managed
Is this a cross-stage feature?
No
What is the competitive advantage or differentiation for this feature?
This will give us better insight into how our customers Geo to accelerate remote users. This data help us make more informed decisions on enhancements related to accelerating remote users.
Links / references
Discussion issue : gitlab-org/geo-team/discussions#5053
We have a git fetch metric which has been built into the following chart(internal). The data here appears to be somewhat inconsistent and we should review this metric.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.