Migrate from Honeycomb to SigNoz

Sizing starts with two numbers you can measure before you build anything: how many spans you send per second, and how large an average span is once it is stored. SigNoz writes telemetry into ClickHouse, a column-oriented database, so storage on disk depends on the data your spans carry, not on the plan you pay Honeycomb for. Honeycomb's event counts show volume at the source, and your collector metrics show what is actually leaving your applications. Use both, because sampling and dropped attributes change the numbers.

• Span rate: Record spans per second at peak and on an average day, by service, over at least one full business cycle.
• Average span size: Estimate bytes per span from sampled exports, including attributes, events and links, since high-cardinality attributes drive size.
• Retention target: Decide how many days of traces you need online, which you may set differently from Honeycomb's 60 days.
• Growth: Add expected growth for new services and instrumentation over the period you plan to keep the environment.
• Query pattern: Note how often engineers run wide queries, because interactive query load adds compute beyond storage.

Confirm current sizing guidance for ClickHouse and the SigNoz collector with SigNoz before you commit to hardware, since figures change between releases.

A single-node pilot runs SigNoz with Docker Standalone on one host. It suits a proof of concept that receives a sample of production traffic, lets engineers compare traces against Honeycomb, and tests dashboards and alert rules. A single host has no redundancy, so a failed disk or host means lost telemetry and a rebuild, which is acceptable for a pilot and not for production. Keep the pilot's retention short and its data disposable.

• Scope the sample: Route one or two services or a fixed percentage of spans through the pilot, and document exactly what is included.
• Size storage for the pilot window: Multiply your measured span rate and average size by the pilot length, then add headroom for ClickHouse merges and temporary space.
• Set retention explicitly: Configure a short retention so the pilot does not fill the disk.
• Plan the exit: Decide now whether pilot data is kept, exported or discarded when the pilot ends.
• Back up configuration: Keep the compose files and collector configuration in version control, even though the pilot is not production.

Before relying on a pilot number, check the current Standalone install guidance in the SigNoz self-host installation docs and confirm minimum host resources with SigNoz.

Docker Swarm is a middle option when your team already runs Swarm and wants several nodes without moving to Kubernetes. SigNoz documents Swarm as a self-hosted install path, so the sizing question shifts from one host to placement: which nodes run ClickHouse, the collector and the query services, and how storage attaches to each node. ClickHouse keeps its data on local or attached volumes, so a node that holds a replica must have durable storage that survives rescheduling.

• Pin stateful services: Constrain ClickHouse to nodes with the disk capacity and I/O you measured, rather than letting Swarm place it freely.
• Size each node for merges: Leave disk and memory headroom for background merges, which consume resources during ingestion peaks.
• Separate ingestion from queries: Where possible, keep collector and query load on separate nodes so a heavy query does not slow ingestion.
• Plan volume backups: Define how each ClickHouse volume is backed up and how a lost node is restored.
• Test node failure: Rehearse losing a storage node and confirm how long recovery takes in your environment.

Confirm the supported Swarm topology and ClickHouse storage layout with SigNoz, because multi-node ClickHouse setups need specific guidance that a single-node figure does not cover.

Kubernetes with Helm is the usual production choice, because SigNoz documents Helm installs and guides for several managed and GitOps environments. Sizing here means requests and limits for each component, persistent volume classes for ClickHouse, and a backup plan that matches your recovery objectives. Storage class performance matters as much as capacity, since ClickHouse writes and merges constantly during ingestion and reads heavily during investigation.

• Set resource requests deliberately: Base ClickHouse memory and CPU on your query concurrency and ingestion rate, and avoid tight limits that throttle merges.
• Choose storage classes: Select persistent volumes with the throughput your measured span rate requires, and confirm expansion is supported.
• Plan retention and TTL: Align ClickHouse data expiry with your retention target so disk use stays predictable.
• Back up ClickHouse: Use a backup method your team can restore and test, and record the restore time you have measured.
• Keep sizing under version control: Store Helm values and sizing decisions with the release that introduced them, so upgrades can be compared.

SigNoz's install docs cover AWS, GCP, AKS, OpenShift, Argo CD and Flux CD, so review the guide for your platform and confirm current chart values with SigNoz before you set production numbers.

Teams in regulated or air-gapped environments size ClickHouse with the same inputs but add constraints on where data sits and who can reach it. Retention may be set by audit or incident review requirements, and backups may need to stay in a specific location or be encrypted with keys you hold. Every copy of telemetry, including backups and the Honeycomb dual-shipping period, is data you must account for in storage and in your records.

• Count every copy: Include replicas, backups and any staging environment in total storage, not only the primary cluster.
• Match retention to obligations: Set retention from your audit and incident review policy, and document the basis for each period.
• Control backup location: Keep backup targets inside approved boundaries and confirm encryption and access controls.
• Size for offline updates: If you cannot pull images directly, budget time and storage for mirroring new SigNoz and ClickHouse versions.
• Document the decision: Record sizing assumptions and their owners so an auditor can trace how capacity was chosen.

DeployOpen can help plan and document this sizing, but it does not issue audit reports or certifications. Confirm your obligations with your compliance team and the relevant standards owners.

A small team with a handful of services usually has one Collector, one SigNoz instance and a short list of boards to rebuild, so the move can finish in a single cutover window. Ownership tends to sit with one or two engineers who also carry on-call duty, which makes the ongoing operating load the main thing to plan for.

• Sequencing: Dual-ship OTLP from one service first, confirm traces appear in SigNoz, then move the remaining services in one pass.
• Pilot scope: Use one user-facing service with steady traffic so you can compare trace shapes and query results against Honeycomb.
• Boards and triggers: Rebuild only the views people open during incidents, and retire the rest.
• Ownership: Name one owner for the SigNoz host, upgrades and backups before cutover, because no one else is likely to pick them up.
• Hosting: Docker Standalone is a documented self-host option that suits a single host, so confirm sizing for ClickHouse against your expected span volume.

Check who will apply upgrades and restore backups before you switch off the Honeycomb exporter.

A large estate with many teams and SLOs moves in waves, and the harder work is the SLO and alert inventory, which takes longer than repointing exporters. Each team's SLOs need a named owner, a target and an alert path, and those definitions must be reproduced in SigNoz before the matching Honeycomb triggers are disabled. Sequence the waves by service criticality so the most important services keep their alerting history until the replacement is proven.

• Inventory first: Export the SLOs, triggers and boards for each team and mark every item as recreate, merge or retire.
• Waves: Move one team or one service tier at a time, with a parallel running period agreed in advance for each wave.
• Pilot scope: Pick a team with well-instrumented services and an engaged on-call rotation so feedback on alert noise arrives quickly.
• Collector topology: Run gateway Collectors that fan out to both backends, so teams do not each maintain their own exporter configuration.
• Capacity: Size ClickHouse for the combined span volume of every wave, since the largest estate also produces the largest ingest peaks.

Confirm how each team's SLO definitions map to SigNoz alerting before any Honeycomb trigger is turned off.

Teams on the Honeycomb Enterprise plan usually have a longer history to protect and access to the Query Data API, which makes the export step more important than it is for smaller accounts. Decide early which history you need to carry forward, because events expire after 60 days on Honeycomb. The Query Data API sits on the Enterprise plan, so plan that extraction work while the contract is still active, ahead of any renewal or downgrade date.

• Export window: Use the Query Data API while the Enterprise plan is active to save results you need for post-incident review.
• Parallel history: Dual-ship OpenTelemetry data so SigNoz builds its own history before Honeycomb access ends.
• Retention decision: Set SigNoz retention to match the review periods your teams use, and record the storage cost of anything longer.
• Contract timing: Ask Honeycomb in writing which data access and features remain after the Enterprise term ends.
• Dashboards: Recreate boards in SigNoz's Query Builder, PromQL or ClickHouse SQL, and test each one against the same time window used in Honeycomb.

Confirm the Enterprise term end date and the export options in your contract before you set the cutover plan.

Regulated teams usually need single sign-on through their identity provider, documented access controls and evidence that telemetry handling follows policy. SigNoz lists SSO on every plan, including Community, but SAML is available only on the Teams and Enterprise plans, so the plan choice is a control decision as well as a cost decision. Independent auditors issue any report or certification, so your job is to produce the configuration, access and change records they will test.

• Identity: Confirm whether SAML is a requirement, because the Community Edition does not provide it and the Teams or Enterprise plan must be scoped and priced first.
• Collector security: Use authenticator extensions such as OIDC on receivers and oauth2client on exporters, and follow the Collector configuration best practices.
• Pilot scope: Start with non-production services that carry no regulated personal data, then widen the scope once access and redaction controls are reviewed.
• Evidence: Keep dated records of configuration, access reviews, backup restores and upgrade approvals.
• Data location: Keep ClickHouse and Collector hosts inside the approved boundary and document where logs and trace attributes are stored.

Ask your assessor which controls and evidence they expect before you agree the pilot scope and the plan tier.