WEBVIS(1)

πŸ’– WEBVIS πŸ’–

okay so bestie, welcome to the webvis page from the General Commands Manual β€” it's giving system-monitoring main character energy and honestly? obsessed. πŸŽ€

✨ NAME ✨

webvis β€” visualize system-level Web server activity πŸŒπŸ’…


πŸ“œ SYNOPSIS πŸ“œ

webvis [-CVz] [-A align] [-a archive] [-b maxbusy] [-h host] [-i maxio]
[-m max] [-n pmnsfile] [-O time] [-p port] [-r maxreq] [-S time] [-T
time] [-t interval] [-x version] [-Z timezone] [interface ...]

🌸 DESCRIPTION 🌸

webvis shows you a whole overview of system-level Web server performance stats, and it pulls them straight from the Performance Co-Pilot (PCP) infrastructure. No cap. 🫢

The display changes based on the performance metric values it grabs from the target host β€” which has to be running pmcd(1) and the pmdaweblog(1) Performance Metrics Domain Agent β€” or from the PCP archive log that you point at with archive. The display refreshes every interval seconds (default is 2 seconds). ⏱️

Just like in every pmview(1) scene: when you move the mouse over one of the bars, the current value and metric info for that bar pops up in the text box near the top of the display. iykyk. πŸ–±οΈβœ¨

The height of the web request bars and the network activity bars is proportional to the performance metric values relative to the maximum expected activity, and that max is controlled by the -m and -r options (details below). Same deal with -b and -i, which control the scaling for the disk activity bars.

So the bars in the webvis scene represent this stuff:

πŸ”₯ Requests by Size

At the front of the scene, the "Requests by Size" row of bars shows the rate of requests for different size requests. The histograms are defined by these byte counts: 0, 3 Kbytes, 10 Kbytes, 30 Kbytes, 100 Kbytes, 300 Kbytes, 1 Mbyte, 3 Mbytes, and anything larger than 3 Mbytes. And notice β€” the size divisions are not evenly distributed, bestie, they're lowkey all over the place. The "size" here means the data portion of the response to each Web server request. These rates are aggregated across all monitored Web servers. πŸ“Š

πŸ¦‹ Requests by Type

This row of bars shows the request rate for each type of HTTP request β€” get, post, head and other β€” aggregated across all monitored Web servers. If you want the detailed version with the breakdown of requests per Web server, go check out weblogvis(1). πŸ‘‘

🌈 Network

For every network interface there are two stacked bars. One bar shows the input traffic, the other shows the output traffic. The stacks are made up of the number of errors (red), the number of drops (orange) and the number of packets (green). πŸ’š

Generally speaking: if there are any "dropped input packets", then that network interface is saturated, or there aren't enough network resources available in the kernel to adequately service the input request load. If that's what's happening, then the Alarm Conditions rows (below πŸ‘‡) may give you more detail about where the problem is coming from.

🚨 Alarm Conditions

The red row of bars shows an assortment of TCP error conditions (aggregated for all network interfaces), the orange bars show critical kernel buffer allocation problems, and the yellow bar shows severe paging conditions. If any of these bars have a non-zero height, then the system you're monitoring might need kernel parameter tuning, software reconfiguration, or more hardware resources. fr fr.

The performance metrics behind those bars are:

  • network.tcp.drops β€” rate of dropped connections
  • network.tcp.conndrops β€” rate of embryonic connections dropped
  • network.tcp.timeoutdrop β€” rate of connections dropped by rexmit timeout
  • network.tcp.rcvbadsum β€” rate of packets discarded for bad checksums
  • network.tcp.rexmttimeo β€” rate of retransmit timeouts
  • network.tcp.sndrexmitpack β€” rate of data packets retransmitted
  • swap.pagesout β€” page swap out rate (indicating insufficient memory)
  • network.mbuf.failed β€” rate of incidents where the kernel failed to find mbuf space
  • network.mbuf.waited β€” rate of incidents where the kernel waited to find mbuf space

πŸ’… CPU

This column shows CPU utilization, aggregated over all CPUs. (CPU idle time is not included in the column.)

πŸ’œ Disk

There are two cylinders showing disk metrics:

  1. The first cylinder shows the rate of read (yellow) and write (violet) operations, aggregated over all disk spindles.
  2. The second cylinder shows the average (over all disks) percentage of time for which a disk is busy or active.
Heads up bestie: that second metric is not available in PCP1.x versions. So if webvis is being used to monitor a host running PCP1.x, this cylinder will not be displayed. 😭

To adjust the scaling of these objects, refer to the -b and -i options described below.

🧚 Mem

There are two bars showing memory metrics:

  1. The first bar shows utilized memory, with different colors representing different types of utilization (kernel, user, etc).
  2. The second bar shows the amount of free memory.
And if webvis is being used to monitor a host running PCP1.x, then only the bar showing free memory will be displayed.

If you specify any optional interface arguments on the command line, then only the network interfaces matching those interface arguments will show up in the Network section. By default, all interfaces are used. The interface arguments are used as patterns for egrep(1) matching against the interface names β€” so like, ec would select all external Ethernet interfaces for a Challenge S. 🎯

webvis uses pmview(1), so the user interface follows the one described for pmview(1), which in turn displays the scene within an Inventor examiner viewer. πŸ–ΌοΈ

webvis passes most command line options to pmview(1). So the command line options -A, -a, -C, -h, -n, -O, -p, -S, -t, -T, -x, -Z and -z, plus the user interface, are all described in the pmview(1) man page. ✨

Options specific to webvis are:

  • -b maxbusy β€” Controls the maximum (normalization) value for the average percentage of the time active over all disks. The default value is 30% active.
  • -i maxio β€” Controls the maximum (normalization) value for the sum of the aggregate disk read and disk write rates. The default value is 100 I/Os per second.
  • -m max β€” Controls the maximum (normalization) value for the packet input and packet output rates. The default value is 750 packets/second.
  • -r maxreq β€” Controls the maximum Web request rate. The default is 5% of the maximum packet rate (i.e. 38 requests/second by default). The maximum Web error rate is fixed at 20% of the maximum Web request rate (i.e. 7 errors/second by default).
  • -V β€” The derived configuration file for pmview(1) is written on standard output. You can save it and use it directly with pmview if you wanna customize the display, or modify some of the normalization parameters. πŸ’Ύ

πŸŽ€ FILES πŸŽ€

  • $PCP_VAR_DIR/pmns/* β€” default PMNS specification files
  • $PCP_VAR_DIR/config/pmlogger/config.web β€” pmlogger(1) configuration file that can be used to create a PCP archive suitable for display with webvis

🌟 PCP ENVIRONMENT 🌟

Environment variables with the prefix PCP_ are used to parameterize the file and directory names used by PCP. On each installation, the file /etc/pcp.conf contains the local values for these variables. The $PCP_CONF variable may be used to specify an alternative configuration file, as described in pcp.conf(4). 🫧


πŸ‘€ SEE ALSO πŸ‘€

pmcd(1), pmchart(1), pmdaweblog(1), pmdawebping(1), pmdumplog(1), pminfo(1), pmlogger(1), pmval(1), pmview(1), weblogvis(1), webpingvis(1), pcp.conf(4) and pcp.env(4).


and that's the whole page, bestie πŸ’– this one's brought to you by Performance Co-Pilot β€” go monitor something iconic, you've got this πŸŽ€βœ¨πŸ’…

πŸ“¦ where this page comes from