[Plugin] Datadog Integration

[javigomez]

Summary

datadoghq.com allows you to create:

• Metrics for services status, health,... and custom metrics
• Generate Dashboards out of these metrics to understand the status of your software
• Create Monitors that warns you in case a metric has an anomaly.

For example, we could track the Accessibility Score metric provided by the Google Lighthouse measurements, see its trend over time and warn us if there is a substantial drop.

It would be very nice to be able to:

• list links to Dashboards (or embed the dashboards) related to a specific github repository in the Backstage software catalog (see https://docs.datadoghq.com/videos/dashboards/).
• list links to Monitors monitoring the software contained in a specific github repository in the Backstage software catalog (see https://docs.datadoghq.com/videos/monitors/).
• list metric related to a specific github repository in the Backstage software catalog (for example my-service_latency, my_service_error-rate).

[stefanalund]

Thanks for adding this @javigomez! I know for a fact that many companies are interested in this plugin. Are you planning on working on it yourself or should I add a [help wanted] label? 🙏

[javigomez]

My feeling is that we can't do the plugin as standalone, is not until the software catalog feature is finished that we will be able to work in it @stefanalund

Please add [help wanted] label, maybe someone has an idea to start it without the catalog

[stefanalund]

@javigomez OK! It's good that we are starting to make excellent progress on the Service Catalog then :)

https://github.com/spotify/backstage/milestone/4

[stefanalund]

@javigomez when this PR lands it will be straight forward to add tools like Datadog to the Service Catalog.

Also noting that this is currently the top 👍 voted plugin in the community 😄

[jlind23]

Any update so far? :)

[regicsolutions]

@javigomez did you make any progress with this plugin?

[dtuite]

@freben @Rugvip We are going to start this tomorrow. I have assigned myself.

/cc @padraigobrien

[padraigobrien]

We created a Datadog plugin, https://www.npmjs.com/package/@roadiehq/backstage-plugin-datadog, it is possible to share dashboards and graphs , however the currently functionality for sharing involves creating a public URL, Datadog confirmed this is currently the only way to to share dashboards and graphs, they have logged a feature request on their end to expose dashboard/graphs in a more secure way via the API, they managed expectations that the earliest it will be looked at is Q2 of 2021.

[adamdmharvey]

That's fantastic 👏 , thanks to you and the Roadie team @padraigobrien ! If I might suggest next steps,

• Clarify that limitation in the plugin README as it may be different than @javigomez 's original intent but can be used to align if/when they enhance their API
• Add the plugin to the Backstage Plugin Marketplace

And with those this issue is likely closable? Any chance you might be able to help there Padraig?

[OrkoHunter]

@padraigobrien @dtuite Today someone asked about a Datadog plugin, and I looked at https://backstage.io/plugins and said Nope, there isn't one! And then, I discovered this issue and your npm package. :)

Could you please add the plugin to https://backstage.io/plugins so that it's easier to discover? And any other Roadie plugins that might be missing? ;) 🙏

[dtuite]

@OrkoHunter Thanks for reminding us Himanshu. I will take care of this today and close this issue once done.

[hydrosquall]

Hi @padraigobrien - I came across this post while looking for a hackathon idea - thanks for the great work on backstage!

a feature request on their end to expose dashboard/graphs in a more secure way via the API,

There is a mechanism for secure sharing of public dashboards via URL via the "magic link" feature: https://www.datadoghq.com/blog/dashboard-sharing/ . Shareable URLs can also be generated programmatically via API .

Do these two features account for what you were originally seeking when you developed the plugin, or would you be seeking out additional functionality?

[andrewthauer]

Disclaimer, I have only read the blog post and not actually tried this. However, from the looks of it, all this does is allow you to control what dashboard information is available when view from this magic link. It still sounds like the link itself is only secured by obscurity rather using an actual API token or something?

[regicsolutions]

We are starting to forward logs to Datadog using the Datadog log collection AWS Lambda function that can basically forward just about anything, we are in the process of forwarding AWS Code Deploy and EC2 logs now, would be great to be able to view these logs in Backstage based on tags

Would be cool to have a view similar to datadogs CI service where you are able to view more than one Dashboard 😀

[hydrosquall]

It still sounds like the link itself is only secured by obscurity rather using an actual API token or something?

@andrewthauer, thanks for taking a look. You're right that this mechanism doesn't use an API token, but it's different than just security by obscurity, since the links expire and are only sent to users from a permitlist of emails or email domains. Would this work for your use case, or are you interested in a different authorization mechanism?

[andrewthauer]

@hydrosquall - I'm not sure this would help at the moment without re-thinking how things work. The typical flow would be a team that manages a catalog-info-yaml file would add a link within that file so that other users of Backstage can view the dashboard/widget within Backstage. This URL is essentially hard coded and managing/refreshing the link would require dynamically changing the link at runtime. I'm sure it would be possible, but not trival and require a fair bit of complexity to manage the links.

Just some rough thoughts here but perhaps a less complex aporoach would be to leverage the DD API instead somehow. Perhaps a new type of persistent magic link could be created, but they require an additional authorization header to be added for them to be valid. Essentially the link alone only is a pointer but doesn't grant access. To avoid leaking the auth header to the front-end it might require proxying the requests through the Backstage backend (which could append the auth header more securely).

Alternatively, some mechanism where the Backstage backend can create a temporary token/session that can be revoked and passes that on to the frontend for temporary usage. I think the distinction here is the auth mechanism is not coupled directly to the link itself.

[hydrosquall]

@andrewthauer - thanks for the additional detail. To make sure I'm reading this correctly:

add a link within that file so that other users of Backstage can view the dashboard/widget within Backstage

1. Is it the case that not all of these Backstage users are users of Datadog?
2. Is it the case that not all of the Backstage users are on the same company email domain?

This URL is essentially hard coded and managing/refreshing the link would require dynamically changing the link at runtime

It seems to me that you may be able to get the intended behavior using 'share by domain' option. This way you can

1. use a static hardcoded URL (avoiding the need to refresh the link dynamically), while also
2. not requiring that everyone viewing the dashboard to have a Datadog account, while also
3. sharing more securely than using the full "public dashboards" option.

The DD API API proxying idea is interesting, but I'd want to better understand why adding an additional auth mechanism is necessary before recommending more time investigating it to the team. Accessing Datadog through a proxy seems like it would require additional development work on the Backstage side for this to be a viable solution and is something that would have to be done very carefully to be secure, so I'm not sure it's worth the effort compared to using one of the existing secure sharing options.