When it comes to HAVING logs, more is good.
For READING logs, less time spent is better.
A concise trace gets answers fast by
highlighting what’s working and what’s not.
So easy to use non-techs can get answers without waiting on/interrupting devs building your future.
Quicklog combines the capabilities of distributed tracing with key application events. Instantly retrieve real-time events by application-defined key values. For exammple entering a user-id could list all the recent actions by a user, or entering a widget-id could show any activity related to a specific widget.
Once you see the high-level flow of activity, you can see what DID or did NOT happen in that flow. Usually that’s enough to give you the answer. In cases where more detail is needed, just click on a trace/span-id for full details in Loggly or other logging provider. [Trace/span id’s are described in the F.A.Q.]
Time-travel: Even if your application tags a trace mid-way through processing, all the events from any source that occured before that point in time are also shown when the tag is entered into Quicklog.
The REST API is fully documented for use from any other language or environment. There are two POST requests: one for logging messages with a trace/span id and another for tagging a trace id with an application-defined key:value. The GET requests enable querying Quicklog from scripts or command line to automate recurring tasks.
Q: What are trace-id’s, span-id’s and Zipkin?
trace-id is a unique random id created when starting a request. Other services called while processing a request all share the same trace-id. A
span-id is generated for the segment of a request processed within each service. There is a parent/child (caller/callee) relationship of span-id’s. Zipkin defines a convention for how trace/span-id’s are communicated.
Q: Is Zipkin distributed tracing required to use Quicklog?
A: No. Even without Zipkin trace/span-id propagation, Quicklog is still able to correlate events across your services using its key:value tagging. You get most of the benefits with very easy implementation.
Q: Is Quicklog only for microservices?
A: No. A single-page Vue/React/Angular webapp and backend benefits greatly from tagged logging. And even in a monolithic server-side app, having key events structured with ‘sources’ (modules) is clearer to see than digging through flat lines of logs.
Q: How much code is needed to use Quicklog?
A: Sending a Quicklog event is a one-liner:
quicklog('my-action', 'my-object', 'my-target', context, tags, trace). To add
tags just use some strings like
tags = ['MyKeyA:value1', 'a-label']. Generate the trace/span id with
trace = traceOpts('user:123', '', '') and re-use it throughout a request. A
context hash/map is for any related key/values.
Q: How do I choose the right-sized plan?
A: Quicklog is for your application’s main events during processing of a user or system action. It’s like a captain’s voice log that describes what meaningful things have or have not happened. A trace of a single user input might produce up to 20 quicklog entries. So the
Project plan could support 150 DAU with 25 posts per user. Note that ‘view’ actions which do not make any changes are exempt.
Q: What happens if the entries/day limit is exceeded?
A: If the limit is exceeded, oldest entries will be removed. For multi-project plans each project will keep at least the last 50,000 × retention-days entries. Any capacity from unused projects will be applied to projects which are in use. Effectively this allows for a greater number of DAUs with reduced retention.