The Next-generation API Observability Platform

How do you know if a small code change can take down your site? What's really going on with your APIs? At Akita, we're building tools to help you answer that question.

Akita watches calls to web APIs in order to help you visualize your service graph, monitor your APIs, make sense of your request/response logs, and 💥 catch breaking changes 💥.

By passively watching traffic, Akita integrates in a low-friction, low-risk way, making it possible to run in CI/CD, staging, or production without too much overhead. Akita's API modeling technology to automatically catch breaking changes.

Get Started    FAQs

Description

Capture and store a sequence of requests/responses to a service by observing
network traffic.

Examples

akita apidump --filter "port 80" --out mytracedir

Capture requests/responses going to or coming from port 80 and store them into a directory called mytracedir.

akita apidump --filter "port 80" --out akita://my-service:trace:mytrace

Capture requests/responses going to or coming from port 80 and store them into a trace on the Akita cloud called mytrace.

akita apidump --filter "port 80" -c ./my_tests.sh -u ${USER}

Run my_tests.sh as ${USER} and capture requests/responses going to or coming from port 80. Akita will automatically terminate once the script finishes.

Required Flags

--out location

The location to store the trace. Can be an AkitaURI or a local directory.

When specifying a local directory, Akita writes HAR files to the directory.

When specifying an AkitaURI, the format is akita://{SERVICE}:trace:{NAME}, where SERVICE is the name of your service and NAME is the name of the trace on Akita Cloud where the collected data is stored.

Optional Flags

--filter string

Used to match packets going to and coming from your API service.

For example, to match packets destined/originated from port 80, you would set --filter="port 80".

The syntax follows BPF syntax (man 7 pcap-filter).

This filter is applied uniformly across all network interfaces, as set by --interfaces flag.

--interfaces []string

List of network interfaces to listen on (e.g. "lo" or "eth0").

You may specify a comma separated string (e.g. --interfaces lo,eth0) or multiple separate flags (e.g. --interfaces lo --interfaces eth0).

If not set, defaults to all interfaces on the host.

--sample-rate number

A number between [0.0, 1.0] to control sampling.

--tags []string

Adds tags to the dump.

You may specify a comma separated list of "key=value" pairs (e.g. --tags a=b,c=d) or multiple separate flags (e.g. --tags a=b --tags c=d)

--command, -c string

A command that generates requests and responses for Akita to observe. Akita will execute the command (similar to bash -c) and automatically terminate when the command finishes, without needing to receive a SIGINT.

By default, the command runs as the current user. As a safety precaution, if the current user is root, you must use the -u flag to explicitly indicate that you want to run as root.

--user, -u string

Username of the user to use when running the command specified in -c

--path-exclusions []string

Removes HTTP paths matching regular expressions.

For example, to filter out requests fetching files with png or jpg extensions, you can specify --path-exclusions ".*\.png" --path-exclusions ".*\.jpg"

Diagnostic output (version 0.12.1 and later)

If the packet capture fails to see any HTTP requests or responses, the CLI will emit one of the following warning messages:

Did not capture any TCP packets matching the filter: There were TCP packets observed, but not matching the filter that you specified. This may mean that you used an incorrect port number, or other mistake in the --filter argument.

Did not capture any TCP packets during the trace: No TCP packets were observed at all. This could occur if you specify an --interface argument other than the one that has API traffic, or if the test did not generate any network traffic.

Captured MMM TCP packets total; NNN unparsed TCP segments: The capture contains TCP streams matching the filter, but they could not be recognized as HTTP. A common reason is that they were encrypted HTTPS instead, and must be captured using a proxy or browser instead. Or, it could be that the traffic is another protocol not yet supported.

To see more details about the packet capture process, and accumulated counters, run akita with the --debug flag.

Updated about a month ago


apidump


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.