Understanding your GHES graphs part 1 - System Health, Processes, and Authentication #42146
Unanswered
djdefi
asked this question in
Enterprise
Replies: 7 comments 5 replies
-
|
I need guidance and mentorship on how I will run this beautiful opportunity. Who can help please? |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
I can't find the "button" |
Beta Was this translation helpful? Give feedback.
2 replies
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Nice |
Beta Was this translation helpful? Give feedback.
0 replies
This comment was marked as off-topic.
This comment was marked as off-topic.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
GitHub Enterprise Servers collect metrics from its services and the base Linux operating system. This data is useful for troubleshooting performance issues and for understanding how your system is being used. The metrics are collected and stored in a time series database, and are displayed in the GitHub Enterprise Management Console. The Management Console includes a Monitor dashboard located at
http(s)://[hostname]/setup/monitor. This dashboard displays graphs created with data gathered by the built incollectdservice. 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 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.
System Health
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.
CPU
userfor a period of time.Memory
Load
longtermsystem load average for values nearing or exceeding the number of CPU cores allocated to the virtual machine.Processes
runningin the legend at the bottom of the graph, we can isolate different process states. In the above example we have selectedrunningprocesses.blockedorzombieprocesses may indicate a service problem.sleepingstate during normal operation.Files
maxnumber of open files, as well as the current number ofusedopen files.usedfiles should never reach themaxvalue. Reaching themaxcan indicate problems with a GitHub Enterprise service.Forks
fork_ratetrend greatly depends on system activity, and will reach values upwards of 1000-2000 on busy systems.Processes
The processes graph section looks deeper into the major individual services which make up the GitHub Enterprise appliance. Looking at these services individually can show how usage trends impact system resources over time.
Processes
Memory
unicornandaqueductprocess groups normally consume the highest amount of memory, followed bymemcached,mysql, andelasticsearch.unicorn,babeld, andgit-daemonprocesses are most influenced by user activity.CPU (Kernel)
unicornprocess normally consumes the most CPU time.CPU (Application)
unicornconsumes the most CPU time, followed bybabeld,git,git-daemon, andaqueduct.I/O operations (Read IOPS)
git-daemon, andbabeldread Input/Output Operations Per Second ( IOPS ) values are influenced by Git fetch / pull activity.unicornread IOPS are influenced by web application or APIGETrequests.aqueductread IOPS are from background jobs, such as regular repository maintenance and repacking.I/O operations (Write IOPS)
git-daemonwrite IOPS reflect Git push activity and is most often the largest consumer of write IOPS.aqueductbackground jobs, such as search indexing, and repository repacking are also be a large consumer of write IOPSStorage traffic (Read)
Storage traffic (Written)
POSToperations are often the largest influencers of this graph.Authentication
The authentication graphs break down the rates at which users and applications are authenticating to the GitHub Enterprise appliance. We also track the protocol or service type such as Git or API for the authentications, which is useful in identifying broad user activity trends. The authentication graphs can help find interesting trends or timeframes to look at when diving deeper into authentication and API request logs.
Authentication Totals
Authentication Rate
LDAP
LDAP graphs will only display data if LDAP Authentication is enabled on the GitHub Enterprise appliance. These graphs can help to identify slow responses from your LDAP server, as well as the overall volume of LDAP password based authentications.
LDAP authentications
LDAP authentication response time
LDAP Sync Totals
user,team, and netnew_membersrecords which were synchronized via the LDAP Synchronization feature, when the feature is enabled.LDAP Sync Runtime
Continue the conversation
There's more in "Understanding your GHES graphs" part 2. Please let us know if you have any questions in the comments!
Beta Was this translation helpful? Give feedback.
All reactions