GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring
1–10 of 36 posts
Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring
#2Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring
#3Now, if they somehow get to have these monitoring numbers automatically sent back to a centralized server where they can gather more insights about various installations, that would be killer, but I am not sure about the feasibility, giving the privacy implications (although plenty of open source software does it).
Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring
#4Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring
#5Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring
#6I am curious why you'd need to run monitoring on your own instances, since the assumption is that given a set of resources (say X RAM and Y CPU), you can support Z users. At least I remember they advertised such a number. Now, if they somehow get to have these monitoring numbers automatically sent back to a centralized server where they can gather more insights about various installations, that would be killer, but I…
We indeed publish a list of requirements https://docs.gitlab.com/ce/install/requirements.html
But this is not enough. Not all hardware is created equal (one core is faster than another) and not all users are created equal (one might push many more branches per day). So to help people with the performance of their GitLab server we think the integrated metrics will be a large benefit.
But another important reason to add this is to ensure that GitLab has metrics about applications that are deployed with GitLab.
> Now, if they somehow get to have these monitoring numbers automatically sent back to a centralized server where they can gather more insights about various installations, that would be killer, but I am not sure about the feasibility, giving the privacy implications (although plenty of open source software does it).
We're very conscious of the privacy implications of sending data about GitLab usage back. We're doing that not with Prometheus but with a usage ping in GitLab EE. We're working on bringing that usage ping to CE, for our reasoning see https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...
BTW People can use Prometheus monitoring in three forms: on-premise centralized, on-premises federated, and as a SaaS
On-premises centralized is what we just shipped.
Prometheus is easy to federate, where some of the metrics of a server are included in another one. In the future we might give every deployed application its own Prometheus server in a pod.
If you want to use Prometheus as a SaaS we recommend Weaveworks https://www.weave.works/solution/prometheus-monitoring/
Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring
#7I really love Gitlab but there's this one thing that's been niggling me about Gitlab.com and it's that every time the app is updated my sessions are invalidated and I need to go through 2FA login all over again.
Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring
#8Gitlab is a true inspiration to me. I hope they continue onwards with good luck and fortune!
Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring
#9I really love Gitlab but there's this one thing that's been niggling me about Gitlab.com and it's that every time the app is updated my sessions are invalidated and I need to go through 2FA login all over again.
Re: GitLab 8.16 Released with auto deploy on GKE and Prometheus monitoring
#10I am curious why you'd need to run monitoring on your own instances, since the assumption is that given a set of resources (say X RAM and Y CPU), you can support Z users. At least I remember they advertised such a number. Now, if they somehow get to have these monitoring numbers automatically sent back to a centralized server where they can gather more insights about various installations, that would be killer, but I…
> I am curious why you'd need to run monitoring on your own instances, since the assumption is that given a set of resources (say X RAM and Y CPU), you can support Z users. At least I remember they advertised such a number. We indeed publish a list of requirements https://docs.gitlab.com/ce/install/requirements.html But this is not enough. Not all hardware is created equal (one core is faster than another) and not al…