[core] Better control over dashboard widgets

[echeung-amzn]

Dashboards are generally fairly rigid in their implementation which is good if you just want to pick up the good defaults but bad if you want to customize them for any reason.

Ideally, the API should allow for:

• Adjusting period per-widget (which the dashboard's periodOverride allows respecting)
• Controlling what widgets are added
• Controlling what metrics are used
• Controlling positioning/sizing of widgets
• Controlling addition of annotations

This may include how widgets are added for custom monitoring, which always uses a calculated width.

[voho]

I think we could consider some way to specify this layout in monitoring props. For example, something like new SomethingMonitoring(facade, {something, layout: new WidgetRowLayout(latencyWidgets, errorWidgets)}). Not sure how customizable to make it and what would be the base building blocks. Metrics? Metric groups? Widgets? Or rather features?

[voho]

We can also create a simple prepend/append widgets methods. Either fully customized, or using the CustomMonitoring types.

[voho]

I see two possible approaches:

1. Come up with some Layout object (either generic or monitoring-specific), that would get some abstract high-level widget definitions, and the goal would be too create the specific IWidget objects. This would require creating the abstractions and basic "flow" layout. Probably would break the custom layouts in some of the monitorings (e.g. DDB).

2. Make it much easier to create sub-classes or change behaviour in the monitorX() methods. For example, add a prop to override the layout manager. This would be fully backwards compatible, but it would be difficult to reuse the layouts, since they would not have identities.

These options are not mutualy exclusive.

[echeung-amzn]

From #191:

Provisioned Concurrency Spillover count is included in lambda's invocation graph even though it is unused by our BoxerTicketingService so we would like to remove it.

Also in the latency graph, we would like to add TM99 metric and remove the P90 and P50 metrics

The ask is the ability to remove/add metrics to lambda's graphs (specifically "Invocations" and "Latency" graphs)

[christophercarney]

+1, I agree that the widgets rendered could use a bit more control. This library is amazing and easy to start using because it is opinionated but as a user I should have granular control over what is rendered and how (if I want to).

Rather than release a comprehensive widget control solution does it make sense to try and break it down into smaller deliverables? I think the prevailing sentiment amongst myself and other users of the library is that when it renders widgets that are not useful (for your usecase) it adds unnecessary noise to your overall dashboard.

Could a reasonable first step be to simply allow a user to prevent a certain widget from being rendered all. Then move to exposing the widgets in a way users can customize them, then exposing formatting, etc

[djdawson3]

Hi there,

I realize that a broader discussion on this has been opened recently, but I'm curious if the author would also be open to a short-term fix to support this functionality as I'm trying to change some configurations related to the different dashboards (e.g. different suffix than "-Summary", different period configurations, etc.).

I looked through the code and it seems that the problem is that the DefaultDashboardFactory constructor is creating dashboards in the constructor and then assigning them to their respective fields which are exposed via methods defined by the IDashboardFactory interface:

• dashboard -> createdDashboard()
• summaryDashboard -> createdSummaryDashboard()
• alarmDashboard -> createdAlarmDashboard()

This means that even if I provide my own dashboard factory, I can't actually customize the dashboards very much because the call to super() is going to immediately create dashboards which I have no control over other than what is already provided by existing props.

Instead, could we defer creation of these dashboards until a there's a createDashboard(), createSummaryDashboard() , or createAlarmDashboard() call and instead store necessary information (e.g. rendering preference, start/period overrides, etc.) as class fields? This would allow clients to at least customize some of the content.

What do you think? Is this a reasonable suggestion?