fix(migrate-from-honeycomb): address review comments

tdabasinskas · tdabasinskas · commit cc4d8ab18610 · 2025-09-21T21:32:52.000+03:00
diff --git a/data/docs/migration/migrate-from-honeycomb-to-signoz.mdx b/data/docs/migration/migrate-from-honeycomb-to-signoz.mdx
@@ -37,23 +37,10 @@ If you're still using Honeycomb's legacy SDKs, follow this approach:
 
 2. **Then**: Follow the OpenTelemetry endpoint configuration steps in this guide
 
-## Honeycomb vs SigNoz Feature Mapping
-
-| Honeycomb Feature | SigNoz Equivalent | Migration Notes |
-|------------------|-------------------|-----------------|
-| Derived Columns | PromQL Queries | Convert aggregations to PromQL expressions |
-| Custom Metrics | OTLP Metrics + Prometheus | Use OpenTelemetry SDKs or Prometheus format |
-| SLOs | Alert Rules | Convert to PromQL-based alert conditions |
-| Triggers | Alert Manager | Configure notification channels and rules |
-| Heatmaps | Histogram Metrics | Use histogram_quantile() functions |
-| Rate Calculations | rate() function | Built-in PromQL rate calculations |
-
 ## Migration Guides
 
 Please refer to the following guides for step-by-step instructions on migrating each component from Honeycomb to SigNoz:
 
-- [Migrating Data](/docs/migration/migrate-from-honeycomb/data) - Configure traces, logs, metrics flow and data correlation
-- [Migrating Metrics](/docs/migration/migrate-from-honeycomb/metrics) - Transfer custom metrics, derived columns, and SLOs  
-- [Migrating Dashboards](/docs/migration/migrate-from-honeycomb/dashboards) - Recreate boards and queries with enhanced visualizations
-- [Migrating Alerts](/docs/migration/migrate-from-honeycomb/alerts) - Convert triggers to alert rules with notification channels
- 
+- **[Migrating Data](/docs/migration/migrate-from-honeycomb/data)** - Configure traces, logs, and metrics flow with unified data correlation and additional metrics sources
+- **[Migrating Dashboards](/docs/migration/migrate-from-honeycomb/dashboards)** - Recreate boards and queries with enhanced visualizations
+- **[Migrating Alerts](/docs/migration/migrate-from-honeycomb/alerts)** - Convert triggers to alert rules with notification channels
diff --git a/data/docs/migration/migrate-from-honeycomb/dashboards.mdx b/data/docs/migration/migrate-from-honeycomb/dashboards.mdx
@@ -5,7 +5,7 @@ title: Migrate Dashboard from Honeycomb to SigNoz
 description: Learn how to migrate Honeycomb dashboards and queries to SigNoz with comprehensive query translation patterns.
 ---
 
-Since both platforms are now OpenTelemetry-native, the migration primarily focuses on translating Honeycomb's 
+Since both platforms are now OpenTelemetry-native, the migration primarily focuses on translating Honeycomb's
 proprietary query syntax to PromQL and ClickHouse SQL, while leveraging SigNoz's enhanced visualization and querying capabilities.
 
 ## SigNoz Dashboard Templates
@@ -57,15 +57,14 @@ Please refer to the [Panel Types](https://signoz.io/docs/dashboards/panel-types/
 
 SigNoz supports essential dashboard features including:
 
-**Variables**: Create template variables for dynamic dashboards  
-**Query Builder**: [The Query Builder](https://signoz.io/docs/userguide/query-builder-v5/) is SigNoz's structured query interface that combines the power of expression-based querying with intelligent auto-completion  
-**Filters**: Apply filters across panels and data sources  
-**Sharing**: Share dashboards with team members and external users  
-**Time Controls**: Flexible time range selection and auto-refresh  
+**Variables**: Create template variables for dynamic dashboards
+**Query Builder**: [The Query Builder](https://signoz.io/docs/userguide/query-builder-v5/) is SigNoz's structured query interface that combines the power of expression-based querying with intelligent auto-completion
+**Filters**: Apply filters across panels and data sources
+**Sharing**: Share dashboards with team members and external users
+**Time Controls**: Flexible time range selection and auto-refresh
 
 For detailed dashboard management, refer to the [Manage Dashboards](https://signoz.io/docs/userguide/manage-dashboards/) documentation.
 
-
 ## Honeycomb to SigNoz Functionality Mapping
 
 ### Basic Query Translation
@@ -83,13 +82,11 @@ Honeycomb uses proprietary query syntax while SigNoz uses standard PromQL for me
 
 Each Honeycomb query needs to be rewritten for SigNoz using PromQL or ClickHouse SQL syntax, with appropriate field names and aggregation functions.
 
-
 Migrating dashboards from Honeycomb to SigNoz involves translating proprietary query syntax to standard PromQL and ClickHouse SQL. SigNoz's extensive template library, enhanced panel types, and unified observability approach provide significant advantages over Honeycomb's board-based system, enabling better visualization and correlation across metrics, logs, and traces.
 
-
 ## Next Steps
 
 With your dashboards successfully migrated from Honeycomb to SigNoz:
 
 1. **[Migrate Alerts](/docs/migration/migrate-from-honeycomb/alerts/)** - Convert Honeycomb triggers and SLOs to SigNoz alert rules for your dashboard metrics
-2. **Optimize dashboards** - Explore [advanced Query Builder features](https://signoz.io/docs/userguide/query-builder-v5/) and [dashboard management](https://signoz.io/docs/userguide/manage-dashboards/) for enhanced team collaboration
+2. **Optimize dashboards** - Explore [advanced Query Builder features](https://signoz.io/docs/userguide/query-builder-v5/) and [dashboard management](https://signoz.io/docs/userguide/manage-dashboards/) for enhanced team collaboration
diff --git a/data/docs/migration/migrate-from-honeycomb/data.mdx b/data/docs/migration/migrate-from-honeycomb/data.mdx
@@ -68,139 +68,72 @@ Since both Honeycomb and SigNoz use OpenTelemetry, migrating your data involves
 
 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.
 
-## Traces Migration
+## Configure Signal Correlation
 
-### Honeycomb Events to OpenTelemetry Spans
-
-Honeycomb represents traces as events with span relationships, while SigNoz uses standard OpenTelemetry spans with full distributed tracing support.
-
-### Trace Configuration Examples
-
-**Java Applications:**
-```java
-// OpenTelemetry Java auto-instrumentation
-// Add to JVM arguments:
--javaagent:path/to/opentelemetry-javaagent.jar
--Dotel.exporter.otlp.endpoint=https://ingest.{region}.signoz.cloud:443
--Dotel.exporter.otlp.headers=signoz-access-token=YOUR_KEY
--Dotel.service.name=your-service-name
-```
-
-**Node.js Applications:**
-```javascript
-// OpenTelemetry Node.js setup
-const { NodeSDK } = require('@opentelemetry/sdk-node');
-const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
-
-const sdk = new NodeSDK({
-  instrumentations: [getNodeAutoInstrumentations()],
-  serviceName: 'your-service-name',
-});
-
-sdk.start();
-```
+SigNoz automatically correlates logs with traces when both contain matching trace and span IDs, providing enhanced debugging capabilities beyond Honeycomb's event-based approach.
 
-**Python Applications:**
-```python
-# OpenTelemetry Python auto-instrumentation
-# Install: pip install opentelemetry-distro opentelemetry-exporter-otlp
-# Run with:
-opentelemetry-bootstrap -a install
-opentelemetry-instrument \
-  --exporter_otlp_endpoint=https://ingest.{region}.signoz.cloud:443 \
-  --exporter_otlp_headers=signoz-access-token=YOUR_KEY \
-  --service_name=your-service-name \
-  python your_app.py
+**For automatic correlation**, use OpenTelemetry SDKs which automatically inject trace context into logs. **For manual configuration** when using file-based logs or custom setups, ensure your logging libraries include trace_id and span_id fields in the log output.
+
+Once configured, you'll be able to jump from traces to logs directly in the SigNoz interface for enhanced debugging.
+
+## Configure Additional Metrics Sources
+
+After completing the basic OpenTelemetry endpoint migration, you may need to configure additional metrics collection methods to capture all your Honeycomb metrics in SigNoz.
+
+SigNoz supports multiple metrics ingestion methods:
+- **OTLP Metrics**: Direct from OpenTelemetry SDKs (primary method)
+- **Prometheus Receiver**: For existing Prometheus metrics endpoints  
+- **Custom Metrics**: Application-specific business metrics
+
+### Enable Prometheus Receiver
+
+Enable the Prometheus receiver in your SigNoz OpenTelemetry Collector configuration to scrape existing Prometheus metrics:
+
+```yaml
+# otel-collector-config.yaml
+receivers:
+  prometheus:
+    config:
+      global:
+        scrape_interval: 15s
+        evaluation_interval: 15s
+      scrape_configs:
+        - job_name: 'my-application'
+          static_configs:
+            - targets: ['localhost:8080']
+          metrics_path: '/metrics'
+          scrape_interval: 30s
+
+processors:
+  batch:
+
+exporters:
+  otlp:
+    endpoint: "ingest.{region}.signoz.cloud:443"  # For SigNoz Cloud
+    headers:
+      "signoz-ingestion-key": "${SIGNOZ_INGESTION_KEY}"
+
+service:
+  pipelines:
+    metrics:
+      receivers: [prometheus]
+      processors: [batch]
+      exporters: [otlp]
 ```
 
-## Logs Migration
-
-### Structured Logs with Trace Correlation
-
-SigNoz automatically correlates logs with traces when both contain matching trace and span IDs, providing enhanced debugging capabilities beyond Honeycomb's event-based approach.
+For detailed Prometheus receiver setup, follow the [Prometheus Receiver configuration guide](https://signoz.io/docs/userguide/send-metrics/#enable-a-prometheus-receiver).
 
-### Log Configuration Examples
-
-To enable automatic log-to-trace correlation in SigNoz, configure your logging libraries to include trace_id and span_id fields in log output:
-
-**Application Logs with Trace Correlation:**
-
-**Java (Logback):**
-```xml
-<!-- logback-spring.xml -->
-<configuration>
-    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
-        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
-            <providers>
-                <pattern>
-                    <pattern>
-                        {
-                          "timestamp": "%d{yyyy-MM-dd HH:mm:ss.SSS}",
-                          "level": "%level",
-                          "thread": "%thread",
-                          "logger": "%logger{40}",
-                          "message": "%message",
-                          "trace_id": "%X{trace_id:-}",
-                          "span_id": "%X{span_id:-}"
-                        }
-                    </pattern>
-                </pattern>
-            </providers>
-        </encoder>
-    </appender>
-    <root level="INFO">
-        <appender-ref ref="STDOUT"/>
-    </root>
-</configuration>
-```
+### Configure OTLP Metrics
 
-**Node.js (Winston):**
-```javascript
-const winston = require('winston');
-const { trace } = require('@opentelemetry/api');
-
-const logger = winston.createLogger({
-  format: winston.format.combine(
-    winston.format.timestamp(),
-    winston.format.json(),
-    winston.format.printf((info) => {
-      const span = trace.getActiveSpan();
-      if (span) {
-        const spanContext = span.spanContext();
-        info.trace_id = spanContext.traceId;
-        info.span_id = spanContext.spanId;
-      }
-      return JSON.stringify(info);
-    })
-  ),
-  transports: [new winston.transports.Console()]
-});
-```
+If your applications use OpenTelemetry SDKs, ensure metrics are enabled:
 
-**Python (structlog):**
-```python
-import structlog
-from opentelemetry import trace
-
-def add_trace_info(logger, method_name, event_dict):
-    span = trace.get_current_span()
-    if span:
-        span_context = span.get_span_context()
-        event_dict["trace_id"] = format(span_context.trace_id, "032x")
-        event_dict["span_id"] = format(span_context.span_id, "016x")
-    return event_dict
-
-structlog.configure(
-    processors=[
-        add_trace_info,
-        structlog.processors.JSONRenderer()
-    ]
-)
+**Environment Variables:**
+```bash
+export OTEL_METRICS_EXPORTER=otlp
+export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=https://ingest.{region}.signoz.cloud:443/v1/metrics
+export OTEL_EXPORTER_OTLP_HEADERS="signoz-ingestion-key=${SIGNOZ_INGESTION_KEY}"
 ```
 
-### Centralized Log Collection
-
-For advanced centralized log collection using OpenTelemetry Collector, see the [SigNoz logs ingestion documentation](https://signoz.io/docs/userguide/logs/).
 
 ## Data Retention and Historical Considerations
 
@@ -222,42 +155,17 @@ While both platforms use OpenTelemetry for data ingestion, they store data in di
 | Platform | Retention Options | Cost Model |
 |----------|-------------------|------------|
 | **Honeycomb** | Plan-based limits (14-90 days typical) | Per-event pricing |
-| **SigNoz Cloud** | Configurable retention (7-90 days) | Predictable monthly pricing |
+| **SigNoz Cloud** | **Traces/Logs**: 15, 30, 90, 180 days<br/>**Metrics**: 1, 3, 6, 13 months<br/>| Predictable monthly pricing |
 | **Self-hosted SigNoz** | Unlimited (storage-dependent) | Infrastructure costs only |
 
-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.
-
-## Verify Unified Data Flow
-
-After completing your data migration configuration, verify that all telemetry signals are flowing correctly to SigNoz and correlating properly.
-
-
-### Check Signal Flow
-
-**Verify each telemetry type in SigNoz:**
-
-1. **Traces**: Navigate to **Services** tab and confirm your applications appear with recent traces
-2. **Logs**: Check **Logs** tab for properly formatted application logs with trace_id and span_id fields  
-3. **Metrics**: Open **Metrics** tab to verify application and infrastructure metrics are appearing
-4. **Correlation**: Test that traces link to related logs and metrics for unified debugging
-
-### Validate Data Accuracy
-
-During parallel operation, compare data consistency between platforms:
-
-**Key validation checks:**
-- **Request volumes**: Verify similar trace and log counts between Honeycomb and SigNoz
-- **Latency metrics**: Compare percentile values (p95, p99) for consistency  
-- **Error rates**: Ensure error percentages match between platforms
-- **Custom metrics**: Validate business metrics show similar values
+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.
 
-If discrepancies appear, review your OpenTelemetry configuration and ensure all applications are sending complete telemetry data to SigNoz.
+**Cost Planning**: Use the [SigNoz pricing calculator](https://signoz.io/pricing/#estimate-your-monthly-bill) to estimate your monthly costs based on your expected data volume and retention needs.
 
 
 ## Next Steps
 
 With your data migration complete, continue with the remaining migration components:
 
-1. **[Migrate Metrics](/docs/migration/migrate-from-honeycomb/metrics/)** - Configure custom metrics, derived columns, and additional metrics sources
-2. **[Migrate Dashboards](/docs/migration/migrate-from-honeycomb/dashboards/)** - Recreate Honeycomb boards with enhanced SigNoz visualizations
-3. **[Migrate Alerts](/docs/migration/migrate-from-honeycomb/alerts/)** - Convert triggers to SigNoz alert rules with multi-signal correlation
+1. **[Migrate Dashboards](/docs/migration/migrate-from-honeycomb/dashboards/)** - Recreate Honeycomb boards with enhanced SigNoz visualizations
+2. **[Migrate Alerts](/docs/migration/migrate-from-honeycomb/alerts/)** - Convert triggers to SigNoz alert rules with multi-signal correlation
diff --git a/data/docs/migration/migrate-from-honeycomb/metrics.mdx b/data/docs/migration/migrate-from-honeycomb/metrics.mdx
