Skip to main content

Community

Other: Datadog Log Service - Add Destination Details

Answered

Please sign in to leave a comment.

Comments

3 comments

  • Official comment

    Hi Lucas,

    Thanks for the feedback! Glad to hear account-level logs are working for you. It makes sense that having destination details would be helpful in this scenario. Are there specific events that you need this for? If you can share a little bit more about how you plan to use this information in Datadog, it will help us evaluate solutions.

    Thanks!

    Amy

    Hi Amy,

    As part of our ongoing discussion under ticket #387924, the Fivetran Support team (Tapas/Kiran) has directed us to share our detailed use case on this feature request thread so that the Product team can better evaluate and prioritize it.

    Context

    We have onboarded all environment connections (dev, tst, prod) into a single Datadog account using account-level external logging for centralized monitoring. To distinguish between environments, we follow a naming convention where the destination name is prefixed with the environment (e.g., dev_broker_default_snowflake).

    Key Requirement

    In order to segregate and monitor environments effectively within Datadog, we rely on destination-level information. However, since the current logs do not include destination metadata, we are unable to leverage this naming convention.

    Challenges We Are Facing

    1. Environment Segregation

      • All logs from different environments are mixed together in Datadog.
      • Without destination details, we cannot distinguish whether an issue belongs to prod, staging, or dev.
    2. Alerting Accuracy

      • Alerts triggered for failures do not indicate the environment.
      • This makes it difficult to prioritize incidents (e.g., prod issues vs non-prod).
    3. Dashboard & Filtering Limitations

      • We cannot create environment-specific dashboards or filters.
      • For example, isolating only prod failures is not possible without destination context.
    4. Operational Overhead

      • Engineers must manually correlate connection details with external metadata sources to identify the environment.
      • This increases triage time and reduces efficiency.

    How Destination Fields Would Help

    If destination-level fields (e.g., destination_name, destination_type) are included in the logs:

    • We can derive environment directly from destination naming convention
    • Build environment-specific dashboards (prod vs non-prod)
    • Configure environment-aware alerting and escalation
    • Improve incident triage speed and operational clarity

    Summary

    Including destination-level metadata in Datadog logs is critical for us to:

    • Enable environment-level segregation
    • Improve observability and alerting
    • Reduce manual effort and dependency on external joins

    Request for ETA

    Given that this is critical for our monitoring and alerting workflows, could you please let us know:

    • Whether this feature is currently being worked on
    • If yes, any tentative ETA or roadmap timeline for availability

    We understand timelines may be subject to change, but even a rough indication would greatly help us plan interim solutions.

    Please let us know if any additional details are needed from our end.

    Thank you for your support.

    Regards,
    Rishika

    Thanks Rishika for the details around your use case, they are very helpful. We are working with our engineering team to understand what might be possible here but I'm not able to provide a timeline at the moment.