1. Docs
2. Send Data to Honeycomb
3. Kubernetes
4. No-Code Data with Honeycomb Network Agent

Send Data with the Honeycomb Network Agent (No Code)

Table of Contents

If you are working in a coding language that is currently unsupported by OpenTelemetry trace instrumentation, aren’t able to touch your code (legacy services, anyone?), or just need a fast starting point, Honeycomb can still give you insights into your applications deployed to Kubernetes.

In this guide, you will learn how to get answers about how your applications on Kubernetes are performing in production using the Honeycomb Network Agent, which is a low-effort, no-code, language-agnostic solution to get telemetry for your applications running in Kubernetes. The Network Agent does not require any modification of your application code or application deployments on Kubernetes in order to collect data.

When you finish, you’ll have visibility into application network interactions (for example, source/destination IPs and port numbers), Kubernetes information (for example, source and destination pod names), and application-level, format-specific information (for example, HTTP method and response status code)–all without making any changes to your application code or deployment manifest.

Before You Begin 

Before beginning this guide, you should have:

• Created a running Kubernetes cluster.
• Created a namespace named honeycomb.

Step 1: Add Honeycomb’s Helm Repository 

Honeycomb’s Helm GitHub repository includes a Helm chart that contains all of the necessary resources you need to deploy the Honeycomb Network Agent to your Kubernetes cluster.

1. Add the repo:

   helm repo add honeycomb https://honeycombio.github.io/helm-charts
   

2. Update your repos to ensure Helm is aware of the latest versions:

   helm repo update
   

Step 2: Install the Honeycomb Network Agent 

Install the Honeycomb Network Agent using the Network Agent Helm chart:

helm install network-agent honeycomb/network-agent --namespace honeycomb

Step 3: Verify the Network Agent Installation 

Verify that Helm properly deployed the network agent by using the kubectl command to see if the pods are running:

kubectl get pod -n honeycomb -o wide

This command should return something like:

NAME                      READY   STATUS    RESTARTS   AGE   IP               NODE                                           NOMINATED NODE   READINESS GATES
hny-network-agent-gn7rw   1/1     Running   0          23s   192.168.42.207   ip-192-168-42-207.us-east-2.compute.internal   <none>           <none>
hny-network-agent-jw766   1/1     Running   0          23s   192.168.43.44    ip-192-168-43-44.us-east-2.compute.internal    <none>           <none>

Once you’ve verified that the agents are up and running, you can use kubectl to look at the startup logs to make sure there are no errors or other issues:

kubectl logs -n honeycomb daemonsets/hny-network-agent

This command should return something like:

{"level":"info","agent_version":"0.2.0-beta","api_key":"******************ABcD","endpoint":"https://api.honeycomb.io","dataset":"hny-network-agent","stats_dataset":"hny-network-agent-stats","time":"2024-01-03T19:13:58Z","message":"Starting Honeycomb Network Agent"}
{"level":"info","time":"2024-01-03T19:13:58Z","message":"Agent is ready!"}

Explore Your Data in Honeycomb 

After a few minutes, data should start flowing to Honeycomb.

To see your data, log in to Honeycomb and query the hny-network-agent dataset in your environment. Try asking the Query Assistant questions like:

• “Show me the event count of my pods”
• “What’s my pod event latency?”

Understanding Network Agent Fields 

The Network Agent uses a combination of OpenTelemetry Semantic Conventions as of v1.20.0, along with some custom attributes, some meta attributes, and the ability to set arbitrary attributes as needed.

The name of the event is appropriate for the type of network communication observed. For example, HTTP events will be named according to the request’s HTTP method. The duration_ms of the event is the duration in milliseconds between the beginning of the observed network communication and the beginning of the observed response.

HTTP Attributes 

The HTTP attributes mostly follow OpenTelemetry Semantic Convention for HTTP spans.

Some HTTP attributes represent the same attribute but are currently duplicated for convenience of working with multiple semantic conventions.

Kubernetes Attributes 

The Kubernetes attributes mostly follow OpenTelemetry Semantic Convention for Kubernetes, with a notable exception of prefixing with source and destination.

Metadata Attributes 

Error attributes if there is a 4xx or a 5xx response status code:

Additional attributes added using OTEL_RESOURCE_ATTRIBUTES environment variable:

Example usage 

Getting Help 

Have questions? Encountering difficulties? Missing features? Join our Pollinators Community Slack to ask questions and learn more.

Did you find what you were looking for?

Yes No

---

If you have questions, join our Pollinators Community Slack!
Pro/Enterprise users can visit Honeycomb Support or email support@honeycomb.io.

Submit