toru / h2olog Goto Github PK

https://docs.python.org/3/library/argparse.html

Current code is fairly simple but it would feel more appropriate if the standard library could take over.

warning: implicitly declaring library function 'sprintf' with type 'int (char *, const char *, ...)' [-Wimplicit-function-declaration]

Reported on an older kernel. IIUC, it should be a matter of including the standard header file.

Sadly the current use of bpf_probe_read() will not pass the BPF verifier on certain kernel versions. Related issue: iovisor/bcc#1260

Use MAX_STR_LEN or sizeof(header_foo) for the time being.

BCC currently has a limitation where USDT reader funcs cannot be called from a static helper function (iovisor/bcc#1255). This makes it a little tricky to reduce the over-redundancy of the code. Therefore consider implementing a macro-based helper.

The ideal flow would be:

1. read and parse quicly-probes.d
2. call the macro with the probe name, field index, field name, and field type

Another huge benefit of this approach is that supporting future probes would become easy.

IIUC, h2o has two modes, identified by the special argument "quic." If set, it logs QUIC and HTTP events. If not, it logs HTTP events only. The limitation of the approach is that it is not capable of logging QUIC events only (therefore it cannot be used for tracing other applications using quicly). The other problem is that it does not trace TLS events.

I think that things would become clearer if there were three options to designate tracing at each layer. E.g., -H for HTTP-level tracing, -Q for QUIC level, -T for TLS-level.

Couple of solid benefits:

1. Easier for developers to get started
2. Intended BCC version is always used

As of BCC v0.13.0, USDT#enable_probe() in the python binding cannot accept provider names. If it is implemented, we'd better use it to avoid name collisions.

ref. iovisor/bcc#2799

At the moment, the command is capable of only logging either of the two at once. This prevents us from doing cross-layer analysis, e.g, looking into what HTTP response is sent on a particular QUIC STREAM frame.

I think we should simply log all the events regardless of the layer (e.g., provider in terms of USDT).

When emitting events from multiple providers to JSON, the event names can be prefixed by their prefixes (e.g., receive event of quicly provider becomes quicly_receive). Doing so would align the output to that generated by https://github.com/h2o/quicly/blob/master/misc/probe2trace.pl.

At the moment, h2olog autogenerates tracing code only for QUIC-level probes.

It would be great if we could use that for HTTP- and TLS-level events too. To give an example, h3_packet_receive and h3_packet_forward are HTTP-level events that have been recently added to H2O. But neither of them are supported by h2olog.

It would be useful to know what kind of HTTP request had triggered the QUIC trace.

Please consider adding the following fields, as they are useful for diagnosing issues:

• first-octet - see https://github.com/h2o/quicly/blob/master/misc/probe2trace.pl#L154-L163
• lengths of data in certain events (e.g., receive, crypto_decrypt)

first-octet is the only source that we can use to determine what the peer has sent when that packet cannot be decrypted. Lengths helps us because we can anticipate what the payload was.

Piping to stdout works too, but it'd be nice if we can provide a command-line option.

This could help simplify the code.

Something like: -h1, -h2, -h3

While bpf_probe_read_str is the correct function to use for our use-case, sadly the function doesn't exist on older kernels (< 4.11). Therefore use the widely available bpf_probe_read instead.