A GitHub Enterprise virtual appliance consists of individual services, configured to run on a customized Linux operating system. Monitoring the system resources such as CPU and Memory (RAM), along with GitHub application and system service metrics can help GitHub Enterprise administrators to identify performance bottlenecks, or unusual activity trends.
The GitHub Enterprise Management Console includes a Monitor dashboard located at
http(s)://[hostname]/setup/monitor. This dashboard displays graphs created with data gathered by the built in
collectd service. Data used in the graphs is sampled every 10 seconds.
Each graph has an informational tooltip describing the graph, which is accessible by hovering over or clicking on the i in the upper left corner of each graph.
Graph data can also be forwarded to an external receiver, by enabling Collectd forwarding within the GitHub Enterprise Management Console. This allows building customized dashboards and alerts for your GitHub Enterprise graph data.
This article series will explore what each of the dashboard sections cover and what specific graph trends to watch out for. As each GitHub Enterprise system is unique in user patterns and integrations, we encourage administrators to reach out to the GitHub Enterprise support team to assist with interpreting your specific instance's monitor graphs if questions arise. The graph data is included within appliance Support Bundles which can be shared with our support team.
The system health graphs provide a general overview of services and system resource utilization. CPU, Memory, and Load Average graphs are useful for identifying trends or times where provisioned resource saturation has occurred.
userfor a period of time.
longtermsystem load average for values nearing or exceeding the number of CPU cores allocated to the virtual machine.
runningin the legend at the bottom of the graph, we can isolate different process states. In the above example we have selected
zombieprocesses may indicate a service problem.
sleepingstate during normal operation.
maxnumber of open files, as well as the current number of
usedfiles should never reach the
maxvalue. Reaching the
maxcan indicate problems with a GitHub Enterprise service.
fork_ratetrend greatly depends on system activity, and will reach values upwards of 1000-2000 on busy systems.
There's more to come in the "Understanding your graphs" mini-series. If you'd like to follow along, just subscribe to the "Understanding your graphs" label (link below). Please let us know if you have any questions in the comments.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.