Feature request: Topology map

[nmeisenzahl]

Hi, this feature request came to my mind after yesterday's community call.

I think it would be helpful to include a graphical topology map that somehow visualizes the communication as well as dependencies between Dapr-enabled microservices. Maybe also some basic telemetry data.

I think this could be really helpful in bigger applications/environments and helps to gain insights and dependencies.

Greets Nico

[artursouza]

I wonder if the same can be accomplished via a tracing dashboard UI, like Prometheus + Graphana. The topology can only be accomplished with tracing data, which (IMO) is a feature that belongs to something like Graphana.

Thoughts on this?

/cc @youngbupark @mukundansundar @tcnghia @yaron2

[robberphex]

Kiali has topology map, Could we suggest Kiali support Dapr?

[yaron2]

Kiali has topology map, Could we suggest Kiali support Dapr?

Where does Kiali get its data from?

[yaron2]

Ok did some reading on this, looks like it's mostly tightly coupled with Istio.

However - Kiali can read tracing data from Jaeger, and Jaeger can be set to work with Dapr via it's open telemetry collector: https://kiali.io/documentation/latest/architecture/#_jaeger

[robberphex]

Well, Kiali gets its data from metrics, specifically, from Prometheus.

The Prometheus query from Kiali is like sum(rate(istio_requests_total{reporter="source",source_workload_namespace="default"} [60s])) by (source_cluster,source_workload_namespace,source_workload,source_canonical_service,source_canonical_revision,destination_cluster,destination_service_namespace,destination_service,destination_service_name,destination_workload_namespace,destination_workload,destination_canonical_service,destination_canonical_revision,request_protocol,response_code,grpc_response_status,response_flags) > 0.

But the metric from Dapr is not enough, for example, sc-a call sc-b via http:

Name	Value
Time	2021-08-31 00:55:25
__name__	dapr_http_server_request_count
app_id	sc-a
endpoint	dapr-metrics
instance	192.168.38.223:9090
job	sc-a-dapr
method	GET
namespace	default
path	/v1.0/invoke/sc-b/method/b-get-zone
pod	sc-a-66f9465fcd-6tk5c
pod_name	sc-a-66f9465fcd-6tk5c
service	sc-a-dapr
Value	20

There is no filed can extract destination(sc-b) efficiently. So I think we have to add destination into metrics.

Maybe we should redesign the metric like istio_requests_total, to count all interaction, including Service invocation, State management(like Redis), Publish & subscribe messaging, Bindings, Actors, Secrets management, and future Configuration management.

Before we modify metrics, we need to let Kiali list Dapr workloads(app, service, etc.).

---

The Actions should be:

1. issue for Kiali support Dapr. https://github.com/kiali/kiali/issues/4310
2. issue for add destination into metrics or re-design metrics.

[robberphex]

Kiali uses cluster, serviceNs, service, workloadNs, workload, app, version to define a node in graph. I think we should add {source,dest}_{cluster,serviceNs,service,workloadNs,workload,app,version}(or equivalent label) to metricdapr_http_server_request_count.

After that, Kiali can query Dapr graph from Prometheus.