Other: Datadog Log Service - Add Destination Details
AnsweredWe've enabled the account level Datadog log service which is terrific. While reviewing the information in Datadog I do not see the destination_id and destinantion_name. Can those elements get added to the information sent to Datadog? We have many destinations so having that level of information would make reviewing details in Datadog much more helpful.
Thanks!
-
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
-
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.
-
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).
-
Dashboard & Filtering Limitations
- We cannot create environment-specific dashboards or filters.
- For example, isolating only
prodfailures is not possible without destination context.
-
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.
Please sign in to leave a comment.
Comments
3 comments