Some of the API services are not properly mounted under /$service/
in the apache proxy. This patch tries to avoid recording data
for "services" like "v2.0" (in the case of neutron) by only adding
names if they're all letters. A single warning is emitted for any
services excluded by this check.
For the moment this will mean we don't collect data for those services,
but when their devstack API config is fixed, they'll start to show
up.
Change-Id: I41cc300e89a4f97a008a8ba97c91f0980f9b9c3f
This can happen if devstack fails to run, but we still run the post
tasks. Also could happen if some sort of hybrid job configuration
does not run all of devstack but we still end up running post jobs.
Just warn to stderr and assume no DB info.
Change-Id: I211a331ab668dbb0ad7882908cca4363f865d924
Two runs of the same job on the same patch can yield quite different
numbers for API calls if we just count the raw calls. Many of these
are tempest polling for resources, which on a slow worker can require
many more calls than a fast one.
Tempest seems to not change its User-Agent string, but the client
libraries do. So, if we ignore the regular "python-urllib" agent
calls, we get a much more stable count of service-to-service API
calls in the performance report.
Note that we were also logging in a different (less-rich) format for
the tls-proxy.log file, which hampers our ability to parse that
data in the same format. This switches it to "combined" which is used
by the access.log and contains more useful information, like the
user-agent, among other things.
Change-Id: I8889c2e53f85c41150e1245dcbe2a79bac702aad
The mysql performance_schema method for counting per-database queries
is very heavyweight in that it requires full logging (in a table) of
every query. We do hundreds of thousands in the course of a tempest
run, which ends up creating its own performance problem.
This changes the approach we take, which is to bundle a very tiny
sqlalchemy plugin module which counts just what we care about in
a special database.
It is more complex than just enabling the features in mysql, but it
is a massively smaller runtime overhead. It also provides us the
opportunity to easily zero the counters just before a tempest run.
Change-Id: I361bc30bb970cdaf18b966951f217862d302f0b9
In order to run on systems where not all requirements are present,
we should be tolerant of missing external dependencies, such as
psutil and pymysql. Print a warning (to stderr) and just leave out
those stats in that case.
Also make running the stats collector use ignore_errors:yes to avoid
failures in the future. I think the stats is not critical enough to
fail a job for bugs like this.
Related-Bug: #1970195
Change-Id: I132b0e1f5033c4f109a8b8cc776c0877574c4a49
In some cases the value is [not set], in this case
the conversion to integer does not work.
Closes-Bug: #1970431
Change-Id: I74df7d8bc9f5cbe0709a6471cf7639caea0b58e8
This makes us gather a bunch of consistent statistics after we run
tempest that can be use to measure the impact of a given change. These
are stable metrics such as "number of DB queries made" and "how much
memory is each service using after a tempest run."
Note that this will always run after devstack to generate the JSON
file, but there are two things that control its completeness:
- MYSQL_GATHER_PERFORMANCE must be enabled to get per-db stats
- Unless tls-proxy is enabled, we will only get API stats for keystone
Change-Id: Ie3b1504256dc1c9c6b59634e86fa98494bcb07b1
