Webinar Q&A: Analyze This! Jenkins Cluster Operations and Analytics

Thank you to everyone who joined us on our webinar, the recording is now available.

And the slides are here.


Below are the questions we received during the webinar Q&A:

Q: Is the access control able to serve as a middle point between users and a backing AD/LDAP setup? Defining custom groups that just matter to Jenkins, for instance. Or it just centralizes the config?
A: Yes, CloudBees Role Based Access Control allows you to use a group provided by AD/LDAP or to define your groups in Jenkins.

Q: For these ES analytics, what DB strategy do you use actually? I mean NOSQL or conventionally RDBMS?
A: We use Elasticsearch, which is a document-oriented database and search engine.

Q: How well does the Operation Center servers scale, can it run on multiple instances with a load balancer?
A: Jenkins Operations Center can be clusterized with a load balancer. The load on JOC is limited because it is mostly an orchestrator. JOC can orchestrate dozens of Masters and hundereds of slaves

Q: How do you sync jobs, configs, etc. among Jenkins masters?
A: Jobs and configurations are not synced between masters per se. If you are referring to the HA feature in Jenkins Enterprise, this is done via a shared filesystem between the hot and cold master.

Q: Can the update center help to deploy any resources to the instance’s file system that are not part of the Jenkins configuration or plugins? Or is the update limited to the bounds of Jenkins?
A: Custom Update Centers not only serve plugin and Jenkins-core files but also serve tool installers. Popular Tool Installers are installers of Git, JDK, JVM, Maven … In that sense, Update Centers also deal with deployment of resources of slaves

Q: Do the analytics support a sort of change-back or throttling model to prevent greedy jobs from hogging too much of the resource pool?
A: Analytics is only a reporting engine. It does not affect the slave scheduling behavior.

Q: Are the metrics you generate limited by the amount of history you retain in your Jenkins instance?
A: Builds are reported in real-time, but you can re-index historical builds using a cluster operation. Builds are retained for 3 years by default in the analytics database, even if they are deleted on the remote Jenkins instance.

Q: Is there an API that will allow us to serve up the Jenkins performance charts on an internal website to our clients?
A: We provide the elasticsearch api which you can access using a Jenkins API key.

Q: Are there alerts in form of notifications on analytics sent to admins?
A: You can configure email alerts to be sent when internal metrics reach a threshold.

Q: We periodically see heap or permgen issues in our builds, but the JVM is the one called up by the Maven process to compile the code, not the master instance itself. Would the analytics view allow us to see the JVM memory for the JVM running the compiles?
A: No, Analytics does not include the JVM memory at this time.

Q: If you only have 2 VMs/servers, would it be best just to have 2 masters, or would it be best to create slaves on the existing hardware as the masters to segregate?
A: It’s usually best to run builds on slaves before you begin adding more masters.

Q: Can you export the analytics/metrics to an external graphite/grafana server?
A: The performance metrics can be reported to graphite using DropWizard metrics graphite plugin.

Q: Would this be able to interact with something like the Jenkins Mesos plugin similar to the system eBay has set up? I’d like to use Docker containers for my slaves.
A: http://www.slideshare.net/cloudbees/analyze-this-jenkins-cluster-operations-and-analytics


Blog Categories: 

Add new comment