Deployment Guide | Honeycomb

We use cookies or similar technologies to personalize your online experience & tailor marketing to you. Many of our product features require cookies to function properly.

Read our privacy policy I accept cookies from this site

Deployment Guide

Secure Tenancy is planned to be End-of-Life at the end of 2022 in favor of built-in security enhancements. Existing customers using Secure Tenancy will continue to be supported on Honeycomb Classic until this time.

The following sections detail the recommended deployment options for Secure Tenancy infrastructure with the Kubernetes platform.

Use the technical infrastructure choice that makes sense for your scenario. If you seek information on public cloud-based platforms, see our recommended infrastructure guidelines.


This guide assumes that you have the following infrastructure setup:

  • A Kubernetes cluster
  • A DNS resolvable hostname
  • kubectl and helm CLI tools are available

In addition to this infrastructure, this guide assumes pre-existing knowledge of building containers using Docker.

Kubernetes (Helm) 

Honeycomb maintains several helm charts, one of which allows deployment of the Secure Tenancy proxy. These charts are publicly documented in Honeycomb’s helm-charts repository on GitHub.

Creating a Docker Image 

With Kubernetes, you will need to provide a container with the Secure Tenancy application installed.

Honeycomb does not currently provide any public Docker images. To generate one, follow these steps:

  1. Navigate to the Secure Tenancy tab on the Honeycomb Team Settings page.
  2. Download the Secure Proxy .tbz file, which will contain the elements required to build the Docker image.
  3. Extract the tarball as in the example Dockerfile below.
FROM debian:stretch-slim

RUN mkdir -p /srv/hny && \
    apt-get update && \
    apt-get install -y ca-certificates openssl bzip2
WORKDIR /srv/hny

COPY bin/honeycomb_secure_proxy-$VERSION.tbz secure-tenancy.tbz
RUN tar --strip-components 1 -xjf secure-tenancy.tbz && \
    rm secure-tenancy.tbz

Configuring Helm 

The following values should be configured for your Secure Tenancy setup in the values.yaml file:

  • API key
  • Dataset name (must be created within a Secure Tenancy enabled team)
  • Database connection information

For additional assistance on setting up the values.yaml file, please refer to our helm-charts/secure-tenancy documentation.

To point Secure Tenancy to your MySQL database, see the instructions from the helm-charts repository.

Running Helm 

The helm chart will create all the resources you need with the exception of a database of your chosen type.

  • Deployment (compute portion for the proxies)
  • ConfigMap
  • HorizontalPodAutoscaler
  • Ingress
  • Secrets
  • Service

To initialize the repo and create the resources, run the following commands:

helm repo add honeycomb
helm install secure-tenancy honeycomb/secure-tenancy --values ib-values.yaml --debug -n honeycomb-st
kubectl --namespace honeycomb-st port-forward $POD_NAME 8080

Validating Secure Tenancy 

To validate that the helm chart has been deployed properly, you can perform:

helm list -n honeycomb-st

This will output the deployment status for the helm chart deployment.

NAME                    NAMESPACE       REVISION    UPDATED                                 STATUS          CHART                            APP VERSION
secure-tenancy          honeycomb-st    1           2021-07-15 10:24:25.492387 -0700 PDT    deployed        secure-tenancy-0.1.3             1.7.0

To view your Secure Tenancy proxy locally (bypassing the hostname configured via k8s ingress), you can run the command:

kubectl --namespace honeycomb-st port-forward $POD_NAME 8080

Additionally, you should be able to see events appear in your Secure Tenancy dataset created above.

Removing Secure Tenancy 

To remove the helm charts and their assets, run the command:

helm uninstall secure-tenancy -n honeycomb-st --debug

Tuning the Secure Proxy 

It is a good idea to send proxy telemetry to a non-secured dataset. You can use this information to help tune the performance of the proxy. There are two fields in particular that are most helpful for performance tuning:

  • transform_req_chan_len is a measure of how many individual encryption requests are waiting for service.
  • global.parallelism is the value set for max_parallelism in the configuration.

The number of available CPUs should be tuned so that the ratio of these values is occasionally between 0 and 1 under heavy load. If the ratio is usually 1, then the proxy is overloaded and response latency will increase. If the ratio is usually 0, then the proxy is comfortably handling all the traffic and it might be possible to reduce the number of CPUs. For safety, please try to ensure that the proxy always has as least two CPU cores to work with.

It may be convenient to define a derived column called proxy_load_ratio with this formula: DIV($transform_req_chan_len, $global.parallelism).

In a well-tuned proxy, a Honeycomb query for MAX(proxy_load_ratio) will show some spikes under heavy load, but will not show an extended flat line at 1.0.

Did you find what you were looking for?