zelldon / zdb Goto Github PK

View Code? Open in Web Editor NEW

20.0 3.0 9.0 1.76 MB

Zeebe debug and inspection tool

Java 91.24% Shell 0.27% Kotlin 8.49%

cli debug debugging incident inspection zeebe

zdb's People

Contributors

Stargazers

Watchers

Forkers

jwulf strawhat5 npepinpe remcowesterhoud nitram509 vladimir43543 oleschoenburg lzgabel tmetzke

zdb's Issues

zdb 2.0.0 failed to read raft log from version 8.2.*

This was during a customer support. I don't remember the exact Zeebe version.I suspect it was due to the journal version change. It reported error on reading journal descriptor.

Work around was to download an older release of zdb. So not a big issue, but would be nice if we can always use latest zdb release.

Reduze jar size

Currently it is around 60MB i think we can reduce this

Create json output

For interoperability we should print the output as json or other format which can easily be parsed

Output instance entity current state

zdb instance entity gives back information about a specific element instance, incl. the key and the current record value. However, it doesn't provide the state (i.e. intent), while this is often very useful to determine what is happening or has happened.

Best-effort decoding of keys in all column families

Extending 27636a1, it would be nice if zdb would provide a number of default decoders for all column families.

Since key format may change from time to time, and decoding may be expensive, we should offer an opt-out to display the hex value instead.

Additionally, we could allow arbitrary decoding, for example by providing the key structure via a CLI parameter. Something like zbd list -cf MESSAGE_SUBSCRIPTION_BY_NAME_AND_CORRELATION_KEY -kf ssl where -kf stands for key-format and ssl specifies that keys are in the format DbString + DbString + DbLong.

Document new format flag

see #121

Update dependencies to support new Zeebe ErrorType

Zeebe has introduced the CALLED_DECISION_ERROR error type. These errors will now cause zdb to break. Updating the dependencies should solve the issue.

remco@Remcos-MacBook-Pro snapshots % zdb status -p=/Users/remco/Documents/Work/data/raft-partition/partitions/2/runtime
java.lang.RuntimeException: Unexpected error occurred during zeebe db transaction operation.
	at io.zell.zdb.db.readonly.transaction.DefaultTransactionContext.runInTransaction(DefaultTransactionContext.java:33)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.ensureInOpenTransaction(TransactionalColumnFamily.java:52)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.lambda$whileEqualPrefix$8(TransactionalColumnFamily.java:250)
	at io.zell.zdb.db.readonly.transaction.ColumnFamilyContext.withPrefixKey(ColumnFamilyContext.java:111)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.whileEqualPrefix(TransactionalColumnFamily.java:247)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.whileEqualPrefix(TransactionalColumnFamily.java:209)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.forEach(TransactionalColumnFamily.java:156)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.forEach(TransactionalColumnFamily.java:95)
	at io.zell.zdb.state.incident.IncidentState.listIncidents(IncidentState.kt:43)
	at io.zell.zdb.state.general.GeneralState.incidentDetails(GeneralState.kt:84)
	at io.zell.zdb.state.general.GeneralState.generalDetails(GeneralState.kt:29)
	at io.zell.zdb.StatusCommand.call(StatusCommand.java:31)
	at io.zell.zdb.StatusCommand.call(StatusCommand.java:16)
	at picocli.CommandLine.executeUserObject(CommandLine.java:1953)
	at picocli.CommandLine.access$1300(CommandLine.java:145)
	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2358)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2352)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2314)
	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
	at picocli.CommandLine$RunLast.execute(CommandLine.java:2316)
	at picocli.CommandLine.execute(CommandLine.java:2078)
	at io.zell.zdb.ZeebeDebugger.main(ZeebeDebugger.java:51)
Caused by: java.lang.RuntimeException: Could not deserialize object [Incident]. Deserialization stuck at offset 49 of length 334
	at io.camunda.zeebe.msgpack.UnpackedObject.wrap(UnpackedObject.java:38)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.visit(TransactionalColumnFamily.java:289)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.lambda$whileEqualPrefix$7(TransactionalColumnFamily.java:270)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.lambda$ensureInOpenTransaction$0(TransactionalColumnFamily.java:53)
	at io.zell.zdb.db.readonly.transaction.DefaultTransactionContext.runInTransaction(DefaultTransactionContext.java:27)
	... 21 more
Caused by: java.lang.RuntimeException: Could not read property 'incidentRecord'
	at io.camunda.zeebe.msgpack.value.ObjectValue.read(ObjectValue.java:112)
	at io.camunda.zeebe.msgpack.UnpackedObject.wrap(UnpackedObject.java:32)
	... 25 more
Caused by: java.lang.RuntimeException: Could not read property 'errorType'
	at io.camunda.zeebe.msgpack.value.ObjectValue.read(ObjectValue.java:112)
	at io.camunda.zeebe.msgpack.property.BaseProperty.read(BaseProperty.java:75)
	at io.camunda.zeebe.msgpack.value.ObjectValue.read(ObjectValue.java:110)
	... 26 more
Caused by: java.lang.RuntimeException: Illegal enum value: CALLED_DECISION_ERROR.
	at io.camunda.zeebe.msgpack.value.EnumValue.read(EnumValue.java:74)
	at io.camunda.zeebe.msgpack.property.BaseProperty.read(BaseProperty.java:75)
	at io.camunda.zeebe.msgpack.value.ObjectValue.read(ObjectValue.java:110)
	... 28 more

Support Log inspection on 1.0

i created a new version of Zdb, which is written in kotlin. I wrote it in a way that we can easily write integration tests and added tests for the currently supported features. In order to align with the features we had with the old version, we need to support log inspection.

https://github.com/Zelldon/zdb#log-inspection

Export data via hazelcast

It would be cool to support an additional command which exports all data via hazelcast. This would allow us to comsume it via simple monitor so we can see the internal state better.

Create Zdb 1.0 cli

i created a new version of Zdb, which is written in kotlin. I wrote it in a way that we can easily write integration tests and added tests for the currently supported features. Currently it doesn't support the same features as the old version. Plus it can't be used as a cli, which we should support.

Ephemeral container debug is not working for 8.3.x

Since Zeebe 8.3.x use non-privileged user to run zeebe process inside container - ephemeral container method became broken.

Trying with simplest busybox image:

kubectl debug -it camunda-zeebe-0 --image=busybox:1.28 --target=zeebe
Targeting container "zeebe". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
Defaulting debug container name to debugger-2x7n2.
Warning: container debugger-2x7n2: container has runAsNonRoot and image will run as root (pod: "camunda-zeebe-0_default(70ff89d8-78fa-4b49-98c0-7ef4c2f59f78)", container: debugger-2x7n2)

kubectl describe pod camunda-zeebe-0:

Ephemeral Containers:
 debugger-2x7n2:
    Container ID:    
    Image:           busybox:1.28
    Image ID:        
    Port:            <none>
    Host Port:       <none>
    State:           Waiting
      Reason:        CreateContainerConfigError
    Ready:           False
    Restart Count:   0
    Environment:     <none>
    Mounts:          <none>

Definitely it's not a problem of zdb tool ) But the users should know not to use this method for 8.3 and later versions.

Maybe it will be fixed inside k8s:
kubernetes/kubernetes#110126
kubernetes/kubectl#1108

Fix zdb for zeebe 1.x versions

There were some breaking changes between 0.26 and the upcoming 1.0.0. zdb should be able to work with 1.0.0

Annoying log on zdb output

Instead of just logging the entity zdb seems to log feel engine creation and a jvm warning - we should remove that from the output

[zell zdb/ cluster: zeebe-cluster ns:default]$ ./zdb instance entity -p /tmp/data-7629518769401758684/raft-partition/partitions/1/runtime/ 2251799813685251
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Engine created. [value-mapper: CompositeValueMapper(List(io.camunda.zeebe.el.impl.feel.MessagePackValueMapper@37f21974)), function-provider: io.camunda.zeebe.el.impl.feel.FeelFunctionProvider@11acdc30, clock: io.camunda.zeebe.el.impl.ZeebeFeelEngineClock@770d4269, configuration: Configuration(false)]
{"key":2251799813685251,"bpmnProcessId":"process","processDefinitionKey":2251799813685249,"version":1,"processInstanceKey":2251799813685251,"parentElementInstanceKey":-1,"flowScopeKey":-1,"parentProcessInstanceKey":-1,"elementType":"PROCESS","elementId":"process","jobKey":0,"children":[]}

Support investigating job state

It would be useful if zdb is able to help investigate the current state of specific jobs.

For example:

find all jobs for a specific job type (of all job states: activatable, activated, failed, etc)
print detailed info for a specific job, including current state, deadline, and retries

This could help troubleshoot issues related to job activation.

why do you use Zeebe

Hi, I am reading your project and I love this project
I have a question, why do you choose Zeebe in your project instead of others like Camunda, are there any special features that others dont have it. Can you share me it. I am wondering when I should choose Zeebe instead of your project instead of others like Camunda

Support list of instances per workflow

Previously we supported to list all process instances for a specific workflow, which is currently no longer possible. We should bring this back.

OOM when printing the log

If the log is to big, we run easily into a OOM since we read all entries first into memory before printing.

We should either only hold the string or do a continuous printing (e.g. with a callback), without holding all records the whole time.

Delete temp dir after test run

With our new integration tests we create a temporary dir, which we share with the testcontainer, such that we can read the content of the state.

The problem is that we currently are not able to delete the data after the test or test class

// This is currently not working - it will cause java.nio.file.AccessDeniedException: /tmp/data--7809705097131595652/raft-partition/partitions/1/runtime/OPTIONS-000007
// Might be related to the test container usage
//  @AfterAll
//  public static void cleanup() throws Exception {
//    FileUtil.deleteFolderIfExists(tempDir.toPath());
//  }

It seems that the testcontainer is not stopped when this method is called 🤔

I would like to have a solution which is junit 5 compatible.

Would be nice if we could take a look at this. \cc @korthout

Automate tests

With the new kotlin zdb we have integration tests with testcontainers, which I run locally. It would be a good next step if we automate them via github actions, like on each push or merge.

Be aware that we might pull the docker image before running the tests, like we do in the c# client action https://github.com/camunda-community-hub/zeebe-client-csharp/blob/master/.github/workflows/aspnetcore.yml#L7

@korthout maybe something you want to start with

Do not deserialize records

Really great Idea because I realized we don't even need to use the event registry! Since it is msgpack we can directly convert it to json ! Thanks @korthout I will change it when I have time

Example: MsgPackConverter.convertToJson(UnsafeBuffer(loggedEvent.valueBuffer, loggedEvent.valueOffset, loggedEvent.valueLength))

Originally posted by @Zelldon in #169 (comment)

Introduce kfmt for the kotlin backend

See

Better serializing keys of column families

Right now, cf keys are not serialized in the list subcommand which makes it hard to inspect the state.

Incorporate state details into new Zdb Version (1.0)

See https://github.com/Zelldon/zdb#inspect-zeebe-partition-status

Improve test coverage

We often run into issues that ZDB doesn't work either with the latest version (most of the time alphas) or maybe not with a version X.

What I want to have is a parameterized test which allows to run against all supported versions (including Snapshot) which would allows us to react faster on issues and hopefully make zdb more resilent in consequence.

README issue

and another one :)

missing ' before zdb

sed -i 's/target\/// zdb

Position of flags should not be break a command

Description

The position in which the flags are passed in the command makes a difference between a successful command, or a failing command. E.g.:

zdb state list -p=<path> results in an error saying no path is provided.
zdb state -p=<path> list works without a problem.

Expectation

The position of the flags in a command is irrelevant to execution. Both of the above commands should work.

ZDB breaks upon unknown ErrorType

When ZDB encounters an ErrorType it does not know it will break and throw a RuntimeException. We could handle this in a cleaner way by setting the enum to value to UNKNOWN when it encounters a value that is not yet supported in ZDB.

remco@Remcos-MacBook-Pro snapshots % zdb status -p=/Users/remco/Documents/Work/data/raft-partition/partitions/2/runtime
java.lang.RuntimeException: Unexpected error occurred during zeebe db transaction operation.
	at io.zell.zdb.db.readonly.transaction.DefaultTransactionContext.runInTransaction(DefaultTransactionContext.java:33)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.ensureInOpenTransaction(TransactionalColumnFamily.java:52)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.lambda$whileEqualPrefix$8(TransactionalColumnFamily.java:250)
	at io.zell.zdb.db.readonly.transaction.ColumnFamilyContext.withPrefixKey(ColumnFamilyContext.java:111)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.whileEqualPrefix(TransactionalColumnFamily.java:247)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.whileEqualPrefix(TransactionalColumnFamily.java:209)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.forEach(TransactionalColumnFamily.java:156)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.forEach(TransactionalColumnFamily.java:95)
	at io.zell.zdb.state.incident.IncidentState.listIncidents(IncidentState.kt:43)
	at io.zell.zdb.state.general.GeneralState.incidentDetails(GeneralState.kt:84)
	at io.zell.zdb.state.general.GeneralState.generalDetails(GeneralState.kt:29)
	at io.zell.zdb.StatusCommand.call(StatusCommand.java:31)
	at io.zell.zdb.StatusCommand.call(StatusCommand.java:16)
	at picocli.CommandLine.executeUserObject(CommandLine.java:1953)
	at picocli.CommandLine.access$1300(CommandLine.java:145)
	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2358)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2352)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2314)
	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
	at picocli.CommandLine$RunLast.execute(CommandLine.java:2316)
	at picocli.CommandLine.execute(CommandLine.java:2078)
	at io.zell.zdb.ZeebeDebugger.main(ZeebeDebugger.java:51)
Caused by: java.lang.RuntimeException: Could not deserialize object [Incident]. Deserialization stuck at offset 49 of length 334
	at io.camunda.zeebe.msgpack.UnpackedObject.wrap(UnpackedObject.java:38)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.visit(TransactionalColumnFamily.java:289)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.lambda$whileEqualPrefix$7(TransactionalColumnFamily.java:270)
	at io.zell.zdb.db.readonly.transaction.TransactionalColumnFamily.lambda$ensureInOpenTransaction$0(TransactionalColumnFamily.java:53)
	at io.zell.zdb.db.readonly.transaction.DefaultTransactionContext.runInTransaction(DefaultTransactionContext.java:27)
	... 21 more
Caused by: java.lang.RuntimeException: Could not read property 'incidentRecord'
	at io.camunda.zeebe.msgpack.value.ObjectValue.read(ObjectValue.java:112)
	at io.camunda.zeebe.msgpack.UnpackedObject.wrap(UnpackedObject.java:32)
	... 25 more
Caused by: java.lang.RuntimeException: Could not read property 'errorType'
	at io.camunda.zeebe.msgpack.value.ObjectValue.read(ObjectValue.java:112)
	at io.camunda.zeebe.msgpack.property.BaseProperty.read(BaseProperty.java:75)
	at io.camunda.zeebe.msgpack.value.ObjectValue.read(ObjectValue.java:110)
	... 26 more
Caused by: java.lang.RuntimeException: Illegal enum value: CALLED_DECISION_ERROR.
	at io.camunda.zeebe.msgpack.value.EnumValue.read(EnumValue.java:74)
	at io.camunda.zeebe.msgpack.property.BaseProperty.read(BaseProperty.java:75)
	at io.camunda.zeebe.msgpack.value.ObjectValue.read(ObjectValue.java:110)
	... 28 more

Support inspection of instances

zdb is already able to provide info about workflows. We should consider to expand this to instance data.

There are some cases where investigation into the running instances is necessary. For example, if no exporters were enabled, the log may already be compacted and there is no other way to retrieve this data. However, this data is available to zdb through RocksDB.

Rejection information is missing during log print

We miss information about the Rejection type and rejection reason.

  {
    "index": 15,
    "term": 1,
    "highestPosition": 62,
    "lowestPosition": 62,
    "entries": [
      {
        "key": -1,
        "position": 62,
        "sourceRecordPosition": 61,
        "intent": "CREATE",
        "recordType": "COMMAND_REJECTION",
        "valueType": "PROCESS_INSTANCE_CREATION",
        "timestamp": 1699126447774,
        "recordVersion": 20736,
        "brokerVersion": "2049.256.4608",
        "value": {
          "bpmnProcessId": "nonExisting",
          "processDefinitionKey": 0,
          "processInstanceKey": -1,
          "version": -1,
          "variables": "gA==",
          "fetchVariables": [],
          "startInstructions": []
        }
      }
    ]
  },

Incorporate incident details into new Zdb Version (1.0)

Support for empty log segments

As far as I understand modern Zeebe log code we could have a situation where there exists a current segment with data and there could be the next empty log segment initialized with zeros (if you choose to preallocate segments). But zdb currently cannot open a partition log with such segments:

aivinog1@MacBook-Pro Downloads % zdb log status -p raft-partition/partitions/1

java.lang.IllegalStateException: Expected version byte to be one [1 3] but got 0 instead.
	at io.zell.zdb.journal.file.SegmentDescriptor.getEncodingLengthForVersion(SegmentDescriptor.java:235)
	at io.zell.zdb.journal.file.SegmentsManager.readDescriptor(SegmentsManager.java:165)
	at io.zell.zdb.journal.file.SegmentsManager.loadExistingSegment(SegmentsManager.java:224)
	at io.zell.zdb.journal.file.SegmentsManager.loadSegments(SegmentsManager.java:144)
	at io.zell.zdb.journal.file.SegmentsManager.open(SegmentsManager.java:112)
	at io.zell.zdb.journal.file.SegmentedReadOnlyJournal.<init>(SegmentedReadOnlyJournal.java:42)
	at io.zell.zdb.journal.file.SegmentedJournalBuilder.build(SegmentedJournalBuilder.java:107)
	at io.zell.zdb.log.LogFactory$Companion.newReader(LogFactory.kt:44)
	at io.zell.zdb.log.LogStatus.<init>(LogStatus.kt:24)
	at io.zell.zdb.LogCommand.status(LogCommand.java:47)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at picocli.CommandLine.executeUserObject(CommandLine.java:2066)
	at picocli.CommandLine.access$1500(CommandLine.java:148)
	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
	at picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
	at picocli.CommandLine.execute(CommandLine.java:2170)
	at io.zell.zdb.ZeebeDebugger.main(ZeebeDebugger.java:60)
aivinog1@MacBook-Pro Downloads % cd raft-partition/partitions/1
aivinog1@MacBook-Pro 1 % hexdump -C -n 100 raft-partition-partition-1-124.log 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060  00 00 00 00                                       |....|
00000064
aivinog1@MacBook-Pro-Alfa 1 % hexdump -C -n 100 raft-partition-partition-1-123.log
00000000  02 08 00 04 00 07 00 01  00 e2 98 6b 2f 00 00 00  |...........k/...|
00000010  00 14 00 03 00 07 00 01  00 7b 00 00 00 00 00 00  |.........{......|
00000020  00 24 dd 87 00 00 00 00  00 00 00 00 08 01 0c 00  |.$..............|
00000030  01 00 07 00 01 00 0b fd  1c 2e 00 00 00 00 59 44  |..............YD|
00000040  00 00 10 00 02 00 07 00  01 00 24 dd 87 00 00 00  |..........$.....|
00000050  00 00 eb c1 ac 01 00 00  00 00 3d 44 00 00 09 00  |..........=D....|
00000060  01 00 08 00                                       |....|
00000064
aivinog1@MacBook-Pro 1 % ls -alt
total 524312
-rw-r--r--@  1 aivinog1  staff  134217728 11 окт 21:39 raft-partition-partition-1-123.log
-rw-r--r--@  1 aivinog1  staff        256 11 окт 21:39 raft-partition-partition-1.meta
drwxr-xr-x@  2 aivinog1  staff         64 11 окт 21:30 pending
drwxr-xr-x@ 12 aivinog1  staff        384 11 окт 21:30 runtime
drwxr-xr-x@  4 aivinog1  staff        128 11 окт 21:30 snapshots
drwxr-xr-x@ 10 aivinog1  staff        320 11 окт 18:00 .
-rw-r--r--@  1 aivinog1  staff  134217728 11 окт 17:57 raft-partition-partition-1-124.log
drwxr-xr-x@  5 aivinog1  staff        160 11 окт 14:04 ..
-rw-r--r--@  1 aivinog1  staff          1 11 окт 14:04 .raft-partition-partition-1.lock
-rw-r--r--@  1 aivinog1  staff         78 11 окт 14:04 raft-partition-partition-1.conf
aivinog1@MacBook-Pro 1 %

If you think that Zeebe can not have an empty segment in the runtime - also please let me know 🙂

Print log as dot file

with this output we can visualize it via https://graphviz.org/about/

Support list of incidents

Currently it is only possible to get the incident details, but not the list of incidents (which was previous possible). We should get this back.

BrokerVersion is not correctly read

Because of camunda/zeebe#14957 we can't correctly read with the current protocol version the BrokerVersion of the records from 8.1 and 8.2

This also affects the RejectionTYpe see #320

{
  "position": 13,
  "sourceRecordPosition": 6,
  "key": 2251799813685252,
  "recordType": "EVENT",
  "valueType": "PROCESS_INSTANCE",
  "intent": "ELEMENT_ACTIVATED",
  "rejectionType": "INVALID_ARGUMENT", # BROKEN
  "requestId": -1,
  "requestStreamId": -2147483648,
  "protocolVersion": 3,
  "brokerVersion": "2303.512.4096", # BROKEN
  "recordVersion": 1,
  "authData": "",
  "recordValue": {
    "bpmnElementType": "PROCESS",
    "elementId": "process",
    "bpmnProcessId": "process",
    "version": 1,
    "processDefinitionKey": 2251799813685249,
    "processInstanceKey": 2251799813685252,
    "flowScopeKey": -1,
    "bpmnEventType": "UNSPECIFIED",
    "parentProcessInstanceKey": -1,
    "parentElementInstanceKey": -1
  }
}

Support a filter for printed log records

When printing the log I can only print the entire log. This is problematic because sometimes I'm only interested in particular records.

Of course there are some workarounds:

pipe into result less use its powerful search capabilities
pipe into result head and tail to filter results

However, both solutions still suffer from:

it's expensive and takes a long time
an exception can occur because zdb is unable to print (e.g. unable to read) a particular record

I'd like to be able to indicate a from and until position as command options to control which records are printed.
I'd also like to be able to indicate a number of records as a command option to control how many records are printed.

README issue

in usage there is a 2nd version listed which is not there:

curl -O -L https://github.com/Zelldon/zdb/releases/download/<version>/zdb-<version>.jar

zdb status variables output should show units for values

zdb status shows min size, max size and avg size but does not display a unit for these values. I assume it is bytes, but it's unclear. Please add units to these values.

Example:

Variables: 2769
	min size: 1 B
	max size: 4.7 KB
	avg size: 46.16793 B

Unexpected special floating-point value NaN

Running zdb log status --path="./raft-partition/partitions/1/" I encountered the following exception:

WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
kotlinx.serialization.json.internal.JsonEncodingException: Unexpected special floating-point value NaN. By default, non-finite floating point values are prohibited because they do not conform JSON specification. It is possible to deserialize them using 'JsonBuilder.allowSpecialFloatingPointValues = true'
Current output: {"avgEntrySize":NaN
	at kotlinx.serialization.json.internal.JsonExceptionsKt.InvalidFloatingPointEncoded(JsonExceptions.kt:34)
	at kotlinx.serialization.json.internal.StreamingJsonEncoder.encodeDouble(StreamingJsonEncoder.kt:195)
	at kotlinx.serialization.encoding.AbstractEncoder.encodeDoubleElement(AbstractEncoder.kt:63)
	at io.zell.zdb.log.LogStatusDetails$$serializer.serialize(LogStatusDetails.kt:7)
	at io.zell.zdb.log.LogStatusDetails$$serializer.serialize(LogStatusDetails.kt:7)
	at kotlinx.serialization.json.internal.StreamingJsonEncoder.encodeSerializableValue(StreamingJsonEncoder.kt:211)
	at kotlinx.serialization.json.Json.encodeToString(Json.kt:80)
	at io.zell.zdb.log.LogStatusDetails.toString(LogStatusDetails.kt:24)
	at java.base/java.lang.String.valueOf(String.java:3388)
	at java.base/java.io.PrintStream.println(PrintStream.java:1047)
	at io.zell.zdb.LogCommand.status(LogCommand.java:40)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at picocli.CommandLine.executeUserObject(CommandLine.java:1952)
	at picocli.CommandLine.access$1100(CommandLine.java:145)
	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2332)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2326)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2291)
	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2159)
	at picocli.CommandLine.execute(CommandLine.java:2058)
	at io.zell.zdb.ZeebeDebugger.main(ZeebeDebugger.java:51)

I don't know much about the given log (I have a feeling that this might be a fully compacted log). I'll keep the log around in case we want to tackle this problem.