TypeError: unorderable types: str() < int()

[mkevac]

$ pcp2pdf --version
pcp2pdf version 3.11.3

$ pcp2pdf -a /var/log/pcp/pmlogger/fedora/20160701.12.35
Parsing: 20160701.12.35
Parsing archive: [########## 100.0%] - 1.54s
Creating graphs: [######## 80.9%]multiprocessing.pool.RemoteTraceback: 
"""
Traceback (most recent call last):
  File "/usr/lib64/python3.5/multiprocessing/pool.py", line 119, in worker
    result = (True, func(*args, **kwds))
  File "/usr/lib64/python3.5/multiprocessing/pool.py", line 44, in mapstar
    return list(map(*args))
  File "/usr/lib/python3.5/site-packages/pcp2pdf/stats.py", line 111, in graph_wrapper
    ret = pcpstats_obj.create_graph(fname, label, metrics, indomres)
  File "/usr/lib/python3.5/site-packages/pcp2pdf/stats.py", line 656, in create_graph
    for indom in sorted(values):
TypeError: unorderable types: str() < int()
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/bin/pcp2pdf", line 16, in <module>
    main()
  File "/usr/lib/python3.5/site-packages/pcp2pdf/__main__.py", line 182, in main
    pcpstats.output()
  File "/usr/lib/python3.5/site-packages/pcp2pdf/stats.py", line 852, in output
    metrics_rets = pool.map(graph_wrapper, l)
  File "/usr/lib64/python3.5/multiprocessing/pool.py", line 260, in map
    return self._map_async(func, iterable, mapstar, chunksize).get()
  File "/usr/lib64/python3.5/multiprocessing/pool.py", line 608, in get
    raise self._value
TypeError: unorderable types: str() < int()

[mkevac]

archive.zip

[natoscott]

@mkevac I'm not having any luck extracting the archive.zip file you added to reproduce this problem ...

$ unzip archive.zip
Archive: archive.zip
inflating: var/log/pcp/pmlogger/fedora/20160701.12.35.0
inflating: var/log/pcp/pmlogger/fedora/20160701.12.35.index
inflating: var/log/pcp/pmlogger/fedora/20160701.12.35.meta
$ cd var/log/pcp/pmlogger/fedora
$ file *
20160701.12.35.0: bzip2 compressed data, block size = 900k
20160701.12.35.index: PCP archive (V.2) temporal index host: fedora
20160701.12.35.meta: PCP archive (V.2) metadata host: fedora
$ bunzip2 < 20160701.12.35.0 > tmp.0

bunzip2: (stdin): trailing garbage after EOF ignored

... and the .0 file is not a PCP archive either ...

$ pmloglabel 20160701.12.35.0
Bad data volume 0 label: Illegal label record at start of a PCP archive log file

?

[mbaldessari]

This is probably due to the type for indom in pmcd.pmlogger.port. It seems to have two instances one is a string called primary and the other one is an instance ID.

metric:    pmcd.pmlogger.port
archive:   shortened-ctrl-1-0
host:      ctrl-1-0.bgp.ftw
start:     Wed Aug  4 02:07:58 2021
end:       Wed Aug  4 02:59:58 2021
semantics: discrete instantaneous value
units:     none
samples:   3121
interval:  1.00 sec

                primary      161918
02:07:58.430          ?        4330
02:07:59.430       4330        4330

Should I just skip this metric by default or is this a bug somewhere?

[mbaldessari]

FWIW The reason pcp2pdf barfs is because it assumes that a metric does not change type within indom instance

[kmcdonell]

From a PCP data semantics perspective, I don't understand this issue here.
Each instance in an instance domain has an external name that is a string and in internal identifier that is an integer (both are unique for a particular instance domain). For this metric ...

$ pminfo -f pmcd.pmlogger.port

pmcd.pmlogger.port
    inst [1909868 or "1909868"] value 4330
    inst [0 or "primary"] value 4330

it just so happens that the string value of the external name for the first instance is "1909868" which has a numeric interpretation, but that does not imply anything about the string values of the other instances in the instance domain.

The type of the metric is something completely different. External instance names only have one type, namely a string.

[natoscott]

This is probably due to the type for indom in pmcd.pmlogger.port.
[...]
FWIW The reason pcp2pdf barfs is because it assumes that a metric does not change type within indom instance

InDoms don't have types - only metrics have an associated type that can differ from one to the next.

An indom is always composed of tuples of internal identifiers (unsigned integers) and external identifiers (strings). In the case of pmcd.pmlogger.port the metric value is an unsigned integer, always. So, nothing changes here - sounds like this may be a logic error in pcp2pdf dealing with the fact that the string "1909868" (external instance name - always a string) looks like an integer to python?

[mbaldessari]

I see, thanks. I think (it's been 6 years, so forgive me ;) ) i just fetch all the indoms for a metric and sort them and since one is a string and the other one is a number python barfs. I'll look into this

[natoscott]

I see, thanks. I think (it's been 6 years, so forgive me ;) )

No problem.

i just fetch all the indoms for a metric

A metric can only have one indom (instance domain), but an indom may consist of many instances - you refer to the latter I believe (in particular, what we refer to as "external instance identifiers", of which there can be many).

and sort them and since one is a string and the other one is a number python barfs. I'll look into this

Awesome!