Skip to content

Commit df5545f

Browse files
tdabasinskastdabasinskas
committed
docs(honeycomb): add honeycomb data migration guide
1 parent 87bac07 commit df5545f

File tree

1 file changed

+263
-0
lines changed
  • data/docs/migration/migrate-from-honeycomb

1 file changed

+263
-0
lines changed

‎data/docs/migration/migrate-from-honeycomb/data.mdx‎

Lines changed: 263 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,263 @@
1+
---
2+
date: 2025-09-09
3+
id: migrate-data-from-honeycomb
4+
title: Migrate Data from Honeycomb to SigNoz
5+
description: Learn how to migrate traces, logs, and metrics data from Honeycomb to SigNoz with unified observability benefits.
6+
---
7+
8+
This guide explains how to migrate observability data from Honeycomb to SigNoz, leveraging the unified OpenTelemetry approach that both platforms now support. You'll learn how traces, logs, and metrics flow seamlessly through a single OTLP endpoint to SigNoz, enabling enhanced correlation and unified observability.
9+
10+
## Prerequisites
11+
12+
Before migrating your data from Honeycomb to SigNoz:
13+
14+
- **SigNoz Setup**: Active [SigNoz Cloud](https://signoz.io/teams/) account or [self-hosted SigNoz](https://signoz.io/docs/install/self-host/) instance
15+
- **Application Access**: Ability to modify OpenTelemetry configuration and restart instrumented applications
16+
- **Honeycomb Data Documentation**: Understanding of your current data types and retention requirements
17+
18+
## Understanding Unified Data Flow
19+
20+
Before migrating your data, it's important to understand how Honeycomb and SigNoz handle observability data differently. This knowledge will help you plan your migration strategy and configure proper data correlation in SigNoz.
21+
22+
### Honeycomb's Data Model
23+
24+
Honeycomb treats most observability data as events with structured fields:
25+
26+
| Data Type | Honeycomb Approach | Characteristics |
27+
|-----------|-------------------|-----------------|
28+
| **Traces** | Structured events with trace context | Events with span relationships |
29+
| **Logs** | Structured events with custom fields | Application logs as events |
30+
| **Metrics** | Derived columns, custom events, and SLOs | Calculated from events + custom metrics |
31+
| **Events** | Core data structure | Flexible schema with arbitrary fields |
32+
33+
### SigNoz's Unified Approach
34+
35+
SigNoz provides native OpenTelemetry support with configurable correlation:
36+
37+
| Data Type | SigNoz Approach | Advantages |
38+
|-----------|----------------|------------|
39+
| **Traces** | Native OpenTelemetry spans | Standard distributed tracing |
40+
| **Logs** | Structured logs with trace correlation | Trace-to-log linking when configured |
41+
| **Metrics** | OpenTelemetry metrics + Prometheus | PromQL querying with trace correlation |
42+
| **Correlation** | Configurable signal linking with trace context | Enhanced debugging when properly configured |
43+
44+
## Unified Data Flow to SigNoz
45+
46+
### Single OTLP Endpoint Benefits
47+
48+
SigNoz uses a unified OpenTelemetry collector that receives traces, logs, and metrics through a single OTLP endpoint. This seamless approach provides:
49+
50+
- **Automatic correlation**: Traces, logs, and metrics with matching trace context are automatically linked
51+
- **Unified timestamps**: All signals share consistent timing for accurate debugging
52+
- **Single configuration**: One endpoint handles all telemetry types without separate setup
53+
- **Reduced complexity**: No need to configure separate pipelines for different signal types
54+
55+
### How Signals Flow and Correlate
56+
57+
When properly configured, telemetry data flows seamlessly:
58+
1. Applications send all signals to the same SigNoz OTLP endpoint
59+
2. SigNoz automatically correlates data using trace context (trace_id, span_id)
60+
3. Users can jump from metrics to traces to logs with automatic linking
61+
4. Unified dashboards show all signals together for complete observability
62+
63+
## OpenTelemetry Configuration
64+
65+
Since both Honeycomb and SigNoz use OpenTelemetry, migrating your data involves updating your OTLP endpoint configuration to point to SigNoz instead of Honeycomb.
66+
67+
**Complete the basic setup first**: Follow the [OpenTelemetry endpoint migration guide](/docs/migration/migrate-from-opentelemetry-to-signoz/) to configure your applications to send data to SigNoz.
68+
69+
This guide covers the data aspects of migration - configuring trace correlation, formatting logs properly, understanding retention differences, and verifying that traces, logs, and metrics are all flowing correctly to SigNoz.
70+
71+
## Traces Migration
72+
73+
### Honeycomb Events to OpenTelemetry Spans
74+
75+
Honeycomb represents traces as events with span relationships, while SigNoz uses standard OpenTelemetry spans with full distributed tracing support.
76+
77+
### Trace Configuration Examples
78+
79+
**Java Applications:**
80+
```java
81+
// OpenTelemetry Java auto-instrumentation
82+
// Add to JVM arguments:
83+
-javaagent:path/to/opentelemetry-javaagent.jar
84+
-Dotel.exporter.otlp.endpoint=https://ingest.{region}.signoz.cloud:443
85+
-Dotel.exporter.otlp.headers=signoz-access-token=YOUR_KEY
86+
-Dotel.service.name=your-service-name
87+
```
88+
89+
**Node.js Applications:**
90+
```javascript
91+
// OpenTelemetry Node.js setup
92+
const { NodeSDK } = require('@opentelemetry/sdk-node');
93+
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
94+
95+
const sdk = new NodeSDK({
96+
instrumentations: [getNodeAutoInstrumentations()],
97+
serviceName: 'your-service-name',
98+
});
99+
100+
sdk.start();
101+
```
102+
103+
**Python Applications:**
104+
```python
105+
# OpenTelemetry Python auto-instrumentation
106+
# Install: pip install opentelemetry-distro opentelemetry-exporter-otlp
107+
# Run with:
108+
opentelemetry-bootstrap -a install
109+
opentelemetry-instrument \
110+
--exporter_otlp_endpoint=https://ingest.{region}.signoz.cloud:443 \
111+
--exporter_otlp_headers=signoz-access-token=YOUR_KEY \
112+
--service_name=your-service-name \
113+
python your_app.py
114+
```
115+
116+
## Logs Migration
117+
118+
### Structured Logs with Trace Correlation
119+
120+
SigNoz automatically correlates logs with traces when both contain matching trace and span IDs, providing enhanced debugging capabilities beyond Honeycomb's event-based approach.
121+
122+
### Log Configuration Examples
123+
124+
To enable automatic log-to-trace correlation in SigNoz, configure your logging libraries to include trace_id and span_id fields in log output:
125+
126+
**Application Logs with Trace Correlation:**
127+
128+
**Java (Logback):**
129+
```xml
130+
<!-- logback-spring.xml -->
131+
<configuration>
132+
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
133+
<encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
134+
<providers>
135+
<pattern>
136+
<pattern>
137+
{
138+
"timestamp": "%d{yyyy-MM-dd HH:mm:ss.SSS}",
139+
"level": "%level",
140+
"thread": "%thread",
141+
"logger": "%logger{40}",
142+
"message": "%message",
143+
"trace_id": "%X{trace_id:-}",
144+
"span_id": "%X{span_id:-}"
145+
}
146+
</pattern>
147+
</pattern>
148+
</providers>
149+
</encoder>
150+
</appender>
151+
<root level="INFO">
152+
<appender-ref ref="STDOUT"/>
153+
</root>
154+
</configuration>
155+
```
156+
157+
**Node.js (Winston):**
158+
```javascript
159+
const winston = require('winston');
160+
const { trace } = require('@opentelemetry/api');
161+
162+
const logger = winston.createLogger({
163+
format: winston.format.combine(
164+
winston.format.timestamp(),
165+
winston.format.json(),
166+
winston.format.printf((info) => {
167+
const span = trace.getActiveSpan();
168+
if (span) {
169+
const spanContext = span.spanContext();
170+
info.trace_id = spanContext.traceId;
171+
info.span_id = spanContext.spanId;
172+
}
173+
return JSON.stringify(info);
174+
})
175+
),
176+
transports: [new winston.transports.Console()]
177+
});
178+
```
179+
180+
**Python (structlog):**
181+
```python
182+
import structlog
183+
from opentelemetry import trace
184+
185+
def add_trace_info(logger, method_name, event_dict):
186+
span = trace.get_current_span()
187+
if span:
188+
span_context = span.get_span_context()
189+
event_dict["trace_id"] = format(span_context.trace_id, "032x")
190+
event_dict["span_id"] = format(span_context.span_id, "016x")
191+
return event_dict
192+
193+
structlog.configure(
194+
processors=[
195+
add_trace_info,
196+
structlog.processors.JSONRenderer()
197+
]
198+
)
199+
```
200+
201+
### Centralized Log Collection
202+
203+
For advanced centralized log collection using OpenTelemetry Collector, see the [SigNoz logs ingestion documentation](https://signoz.io/docs/userguide/logs/).
204+
205+
## Data Retention and Historical Considerations
206+
207+
### Historical Data Migration
208+
209+
**Important**: SigNoz cannot directly import historical data from Honeycomb. Plan your migration strategy accordingly:
210+
211+
| Consideration | Recommendation |
212+
|---------------|---------------|
213+
| **Historical Data** | Cannot be migrated - plan for parallel operation during transition |
214+
| **Retention Overlap** | Run both systems temporarily to maintain historical access |
215+
| **Compliance Requirements** | Ensure retention policies meet regulatory needs |
216+
| **Data Export** | Export critical historical data from Honeycomb before migration |
217+
218+
While both platforms use OpenTelemetry for data ingestion, they store data in different formats. Honeycomb uses proprietary event-based storage, while SigNoz stores telemetry data in ClickHouse using schemas optimized for analytical queries. Direct data migration between these systems is not supported.
219+
220+
### Retention Policy Comparison
221+
222+
| Platform | Retention Options | Cost Model |
223+
|----------|-------------------|------------|
224+
| **Honeycomb** | Plan-based limits (14-90 days typical) | Per-event pricing |
225+
| **SigNoz Cloud** | Configurable retention (7-90 days) | Predictable monthly pricing |
226+
| **Self-hosted SigNoz** | Unlimited (storage-dependent) | Infrastructure costs only |
227+
228+
SigNoz offers more flexible retention options, especially with self-hosted deployments where retention is limited only by your storage capacity. This can provide significant cost advantages for organizations requiring longer data retention periods. Honeycomb's per-event pricing model can become expensive with high-volume applications, while SigNoz Cloud provides predictable monthly costs regardless of event volume. For maximum cost control and unlimited retention, self-hosted SigNoz allows you to scale storage based on your infrastructure budget rather than vendor-imposed limits.
229+
230+
## Verify Unified Data Flow
231+
232+
After completing your data migration configuration, verify that all telemetry signals are flowing correctly to SigNoz and correlating properly.
233+
234+
235+
### Check Signal Flow
236+
237+
**Verify each telemetry type in SigNoz:**
238+
239+
1. **Traces**: Navigate to **Services** tab and confirm your applications appear with recent traces
240+
2. **Logs**: Check **Logs** tab for properly formatted application logs with trace_id and span_id fields
241+
3. **Metrics**: Open **Metrics** tab to verify application and infrastructure metrics are appearing
242+
4. **Correlation**: Test that traces link to related logs and metrics for unified debugging
243+
244+
### Validate Data Accuracy
245+
246+
During parallel operation, compare data consistency between platforms:
247+
248+
**Key validation checks:**
249+
- **Request volumes**: Verify similar trace and log counts between Honeycomb and SigNoz
250+
- **Latency metrics**: Compare percentile values (p95, p99) for consistency
251+
- **Error rates**: Ensure error percentages match between platforms
252+
- **Custom metrics**: Validate business metrics show similar values
253+
254+
If discrepancies appear, review your OpenTelemetry configuration and ensure all applications are sending complete telemetry data to SigNoz.
255+
256+
257+
## Next Steps
258+
259+
With your data migration complete, continue with the remaining migration components:
260+
261+
1. **[Migrate Metrics](/docs/migration/migrate-from-honeycomb/metrics/)** - Configure custom metrics, derived columns, and additional metrics sources
262+
2. **[Migrate Dashboards](/docs/migration/migrate-from-honeycomb/dashboards/)** - Recreate Honeycomb boards with enhanced SigNoz visualizations
263+
3. **[Migrate Alerts](/docs/migration/migrate-from-honeycomb/alerts/)** - Convert triggers to SigNoz alert rules with multi-signal correlation

0 commit comments

Comments
 (0)