docs: add detailed info how to use influx_inspect to check if I use TSM or TSI

[stevebang]

From @akavel on July 3, 2018 12:1

System info: [Include InfluxDB version, operating system name, and other relevant details]

influxdb 1.5.4

Steps to reproduce:

$ docker run --name mytest -d influxdb:1.5.4 
cb4256853c00c6f389af44fb3a27ce09fe72f8c02f7a2a39b986b0a90839549f
$ docker exec mytest influx_inspect report -help
Displays shard level report.

Usage: influx_inspect report [flags]

    -pattern <pattern>
            Include only files matching a pattern.
    -exact
            Report exact cardinality counts instead of estimates.  Note: this can use a lot of memory.
            Defaults to "false".
    -detailed
            Report detailed cardinality estimates.
            Defaults to "false".

$ docker exec mytest influx_inspect report
report: lstat : no such file or directory

Expected behavior: [What you expected to happen]

Some info about existing database contents, showing me whether I use TSM or TSI. The --help contents for influx_inspect should explain how to actually use the command to get some correct result, possibly by showing example command line.

Actual behavior: [What actually happened]

Trying to use influx_inspect report fails with unintelligible error. Similarly for influx_inspect dumptsm, I have no idea how to actually use it after reading the --help. I tried running both of them with various options, but never managed to get any meaningful info.

Additional info: [Include gist of relevant config, logs, etc.]

The influxdb 1.5 upgrade guide only repeatedly says "use influx_inspect buildtsi"; but the docs for the tool are super sparse and cryptic. Anyway, I can't find out a way how to call influx_inspect to check whether I have TSM or TSI indexes before running the upgrade (buildtsi), and to verify whether the upgrade worked successfully after the upgrade. Without being able to check this, it doesn't make much sense to me to even attempt the upgrade, as I don't know how to check if the call succeeded.

Copied from original issue: influxdata/influxdb#10031

[stevebang]

From @e-dard on July 3, 2018 12:59

@akavel we have a dedicated docs repo: https://github.com/influxdata/docs.influxdata.com; I think that this issue should be filed over there. /cc @stevebang

[timhallinflux]

I believe the index_version is now output in the startup messages for shard open -- as of 1.6. Example:

ts=2018-09-12T00:05:20.623935Z lvl=info msg="Opened shard" log_id=0AUmNjS0000
service=store trace_id=0AUmNkfl000 op_name=tsdb_open index_version=tsi1
path=/influxdb/data/readings/autogen/918 duration=45.442ms

[akavel]

@timhallinflux You mean in normal InfluxDB logs, yes? I should grep them for "Opened shard"? Do I need to change the log level first, or is the default level <=info already?

[timhallinflux]

yes. The default level is info already.

At the end of the start-up phase there are a series of info message like the following which contains the index version being used as well...

ts=2018-09-12T00:05:20.858602Z lvl=info msg="Listening on HTTP" log_id=0AUmNjS0000 service=httpd addr=[::]:8086 https=false 
ts=2018-09-12T00:05:20.858659Z lvl=info msg="Starting retention policy enforcement service" log_id=0AUmNjS0000 service=retention check_interval=30m 
ts=2018-09-12T00:05:20.858670Z lvl=info msg="Service is running" log_id=0AUmNjS0000 service=ae 
ts=2018-09-12T00:05:20.858677Z lvl=info msg="Using index" log_id=0AUmNjS0000 version=tsi1 
ts=2018-09-12T00:05:20.858770Z lvl=info msg="Listening for signals" log_id=0AUmNjS0000 

[stevebang]

@timhallinflux Do we want detailed info on using influx_inspect to determine index types or is the new /debug/vars endpoint addition the best solution? See Add shards' index types to /debug/vars #10387. It seems to me that this should have been added to SHOW DIAGNOSTICS instead based on the kind of information. What's the value of having it in /debug/vars?

[juris]

Anyways. How to use this tool? I've tried to launch it in /var/lib/influxdb and subdirectories, but no luck. I'm on Influxdb 1.7.1 (Alpine Docker image) and still getting:

report: lstat : no such file or directory

What directory? Where should I cd to? C:\Windows\System32?
No offence, but sometimes Influx docs looks like this infamous tutorial:

[davestephens]

I was getting the same as @juris, after a bit of messing about and realising that lstat wasn't a package I was missing, I worked out that you need to provide a full path to a shard group. eg:

./influx_inspect report /data/telegraf/autogen/1008/

Better documentation, error messages or help on the cmdline would definitely help.

[macd2]

today during some research we ran a queries like SELECT "a" / "b" From X ... and SELECT ("a" + "b")/2 FROM ...
the result was that influxdb crashed entirely and was not able to restart, so we had to rebuild all indexes.
How can it be that a SELECT query even if "wrong" causes influx to completely capitulate?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[wfjm]

I also ran into this. Solution is as posted by @davestephens, simply append the storagepath
The documentation is indeed abysmal.
It starts with the online help simply being wrong, it states

Usage: influx_inspect report [flags]

and misses the key point, that the storagepath should be added as an argument.

V1.8 is history. But when preparing data migration to a V2.1 test installation one runs again into this.