NGINX Observability

NGINX is often the first point of contact for interaction with your service. With a very small amount of instrumentation, we can reliably find the source of any slowness in a massive distributed system in just a few clicks. For example: adding headers in app code with timing information for any calls out to data backends, microservices or third-party services.

By enriching NGINX logs with useful information about service behavior and parsing it into structured data, Honeycomb makes it possible to answer deep questions about systems instantly.



Get Started Now
Kubernetes logs, cluster events, resource and state metrics together in Honeycomb for deep observability

Example configuration of NGINX logging for Honeycomb

Data Collection

The honeytail agent captures and streams log files to Honeycomb as they’re written. Honeytail converts the strings into structured json objects and reads the config file to add any extra fields defined, so we don’t have to change any regular expressions (or other hacks) to detect the new information.

You can also backfill old logs into Honeycomb to look at past data.

Getting Answers

When debugging a complex system, we usually want to start at the edge and systematically work our way down. With enriched NGINX logs in Honeycomb, you can ask questions like:

  • Which endpoints are slowest?
  • Is the service evenly slow across endpoints, or only high for reads?
  • If it’s higher for reads, is it equally slower for all data sources or only MongoDB?
  • If it’s only slower for MongoDB, is it equally slow for all replica sets?
  • If it’s only slow for some replica sets, is it equally slow for all secondaries?
  • What do those have in common — is the queue length high, are they running the same version, are they the same instance type?
  • Is it equally slow handing off to all app instances, or are a few timing out at 30 seconds?
  • Are those running the same version, were some of them deployed recently, are the slow ones starved for memory?
  • Is it equally slow for all userids or app ids, or are some much slower?
  • If slower for some, are they coming from the same replica set?
  • Are they performing the same action or hitting the same endpoint?
  • Are all return codes the same, or is it only 500s?
An example of the kinds of NGINX data you can query in Honeycomb

Get started today!

Start Free Trial Schedule Demo