Where did one report request spend its time?
A bike shop opens its appointment report, but the page takes several seconds to respond. Honeycomb can show the steps it received from the website and the report service on one timeline. You can see how much of the wait the measured report preparation accounts for, and where there are still gaps to investigate.
That connected record is a trace. Each timed step is a span. Honeycomb calls the timeline a waterfall because the bars show when each step began and how long it lasted. Your services have to record the steps for them to appear. A long parent bar can include time spent waiting for a child step, so read their positions together.
What should you check before sending a trace?
Start with a test website and a test report service that read made-up records. Check where both services send and save data before running the request. Keep real records and live notifications disconnected. If you cannot confirm the connections, use two local stand-ins with no live credentials.
Keep forwarding to Honeycomb off while you inspect one synthetic trace locally. Check both the recorded spans and the tracing information in the request headers between the two test services. Keep a short list of fields such as service name, step name, timing, outcome and the random identifiers that join the steps. Review anything the tracing library adds automatically. Keep personal names, credentials, raw URLs, request bodies, prompts and returned report contents out of what you send. Leave optional extra context off for this exercise and send only the trace information needed to join the steps between the two test services.
How do you check that both services appear?
For two Node.js test services, Honeycomb documents setup with OpenTelemetry, a set of tools for recording and sending these measurements. Each service needs its own name. Use a credential for sending data to a Honeycomb test environment and keep it in protected server settings.
After the safety checks, have the test website request a report from the test service once. You can give the test service a known short delay. Find the trace for that request in Honeycomb and check that the report service appears as a step beneath the website’s call. The timeline should show the delay where you put it. If the steps appear separately or one is missing, check that both services record spans and that the trace identifier crosses the call before drawing a conclusion about timing.
What counts toward the limit when traffic grows?
Honeycomb counts each received span as an event. A note recorded as a span event or an extra link between spans also counts. One report request with four received spans and no such notes or extra links uses four events. The Free plan lists up to 20 million events per month and a separate allowance of up to 100 million metric data points per month.
Honeycomb’s pricing FAQ describes a notice when a team exceeds its monthly event allowance. For a second consecutive month over the allowance, it describes a throttling notice and ten days to adjust before throttling begins. Separately, Honeycomb Support documents a Free plan limit of 2,000 events per second for traffic into one dataset through its Events API. Requests over that rate can be dropped. A quiet dashboard can therefore miss work your app actually did.
Once you can see a complete test trace, check how many spans your busiest tasks generate. If you start retaining only a sample of traces, keep that decision in mind when reading the results. Choosing a sample before you know the outcome can miss rare slow or failed requests.
What can you keep if you change where traces go?
Save the query results you need while they’re still retained. Honeycomb Support documents a 1,000-row limit on exporting through the interface. It also documents an Enterprise query API option for up to 10,000 summarized rows when time-series results are turned off. That API can query at most seven days of data at a time.
Keep the trace setup and the definitions of any saved views or alerts you need to rebuild. Reconfigure the sender and verify new data at the new destination. Honeycomb’s US and EU instances are separate, and Support says existing data cannot move directly between them. Check the retention window on your account before relying on an older trace.