1. Docs
2. Send Data to Honeycomb
3. Android
4. Symbolication

Symbolicate Android Stack Traces with the OpenTelemetry Collector

Table of Contents

Use the proguard processor in your OpenTelemetry Collector to symbolicate Android stack traces.

The proguard processor replaces obfuscated names and addresses in your Android stack traces with symbols from provided Proguard files.

Before You Start 

The proguard processor is compatible with Honeycomb OpenTelemetry Android SDK version 0.0.20 and later.

To use the proguard processor, you need:

• OpenTelemetry Collector built with CGO enabled.

• An environment or container image with glibc support.

  We recommend gcr.io/distroless/cc, a secure and lightweight container image with CGO and glibc support.

If you’re not using the Honeycomb OpenTelemetry Android SDK, make sure your exception data is in the format the processor expects.

Install 

By default, the Honeycomb OpenTelemetry Collector distribution includes the proguard processor, so you can skip to the next section if you’re using it. If you use another collector distribution or build your own, it must be built with CGO enabled.

You can install the proguard processor by adding it to your OpenTelemetry Collector build configuration file.

processors:
  - gomod: github.com/honeycombio/opentelemetry-collector-symbolicator/proguardprocessor v0.0.7

You can find the latest proguard processor version on the releases page in the GitHub repo.

Proguard Files 

The proguard processor requires access to the Proguard file generated by your build process. This file can be stored in your local file system, Amazon S3, or Google Cloud Storage.

To support symbolication, your Proguard file must be versioned with the generated build UUID in the file name. For example: 6A8CB813-45F6-3652-AD33-778FD1EAB196.txt.

You can use the Honeycomb ProGuard UUID Plugin to generate UUIDs in your build process.

Configure a File Store 

Add the proguard_symbolicator as a processor in your OpenTelemetry Collector configuration:

processors:
  proguard_symbolicator:

You can then configure where your Proguard files are stored.

Local File Store 

By default, the proguard processor loads Proguard files from a local directory. You can set the file path in your collector configuration:

processors:
  proguard_symbolicator:
    # proguard_store is sets which store to use, in this case local disk
    proguard_store: file_store
    local_store:
        # (optional) path sets the base path of the files, defaults to `.`
        path: /tmp/proguards

Make sure your collector can access the path directory you set, and that file paths in stack traces match the structure of your configured file store.

Amazon S3 Store 

Optionally, you can load Proguard files from an Amazon S3 bucket. Add to your OpenTelemetry Collector configuration:

processors:
  proguard_symbolicator:
    # proguard_store sets which store to use, in this case S3
    proguard_store: s3_store
    s3_store:
        # name of the bucket the files are stored in
        bucket: proguards-bucket
        # (optional) the bucket's region
        region: us-east-1
        # (optional) prefix is used to nest the files in a sub key of the bucket
        prefix: proguards

Make sure your collector has permission to access the S3 bucket. Also, ensure the file paths in stack traces match the structure used in your file store.

Private AWS S3 bucket authentication 

To use a private Amazon S3 bucket as your file store, set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.

Google Cloud Storage Store 

Optionally, you can load Proguard files from a Google Cloud Storage (GCS) bucket. Add to your OpenTelemetry Collector configuration:

processors:
  proguard_symbolicator:
    # proguard_store sets which store to use, in this case GCS
    proguard_store: gcs_store
    gcs_store:
        # the name of the bucket the files are stored in
        bucket: proguards-bucket
        # (optional) prefix is used to nest the files in a sub key of the bucket
        prefix: proguards

Make sure your collector has permission to access the GCS bucket. Also, ensure the file paths in stack traces match the structure used in your file store.

Private GCS bucket authentication 

To use a private Google Cloud Storage bucket as your file store, set the GOOGLE_APPLICATION_CREDENTIALS environment variable.

Advanced Configuration 

In addition to basic setup, you can customize how the symbolicator processor handles stack traces by configuring attribute mappings and additional processing options.

Mapping Attributes 

Use these configuration options to specify which attributes the processor should read from and write to when handling stack traces:

Additional Processing Options 

Use these configuration options to control how stack traces are processed and managed:

Language-Based Routing 

The Proguard processor supports language-based routing to ensure it only processes signals from Android/Java/Kotlin applications. This prevents the processor from running on signals from other platforms (like iOS or JavaScript), improving performance and avoiding unnecessary processing.

Example configuration:

processors:
  proguard_symbolicator:
    allowed_languages: ["java", "android"]

allowed_languages configuration behavior:

• Empty allowed_languages (default): Processes all signals, regardless of language attribute.
• With allowed_languages configured: Only processes signals where the language attribute matches one of the allowed values (case-insensitive).
• Missing language attribute: Skips processing when allowed_languages is configured.

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