Feedback: Dynatrace with Redis Enterprise

[markotrapani]

Page https://redis.io/docs/latest/integrate/dynatrace-with-redis-enterprise/

The Dynatrace Extension description outlines "Optional" Redis configuration steps to expose the BDB name instead of just the ID:

[Optional] Redis Configuration
The Database name - label "bdb_name" is not enabled by default. Without this, Dynatrace will just use the database ID in dimensions and entity definitions.

To enable it for all databases on a cluster you have to issue the following commands:

> ccs-cli hset cluster_settings metrics_exporter_expose_bdb_name enabled
> supervisorctl restart metrics_exporter
The new labels will then be added to the Prometheus metrics once this setting is changed and the metrics_exporter process is restarted.

However, we had a customer submit ZD-133554 because their Dynatrace extension was not displaying database-specific info in the dashboard.

Only once the customer followed the above "optional" steps were they able to see the DB details in DT at all.

I'm thinking we should consider adding this recommendation in our Dynatrace doc, as well.

[mich-elle-luna]

@j8-redis What do you think about this addition? If you agree, can you help with where to add this info?

[j8-redis]

This is a complicated problem. On the Dynatrace platform there are no joins, meaning that it's not possible to combine information from two different tables. Additionally, not all groups report this value ('bdb_name'). Lastly, this value will not be reported in v2 apart from the db_config metric. The approach taken by FieldEng in light of this is to create a node/database/shard table on every dashboard, with the intent being to provide a mapping from the database id ('db') to its name ('db_name'). Given as this request regards v1 and we are working with Dyntrace to have them officially approve the v2 dashboards I would suggest including this information until such time as we deprecate v1. As for where, the 'Monitor metrics' would be the appropriate place, but Maayan has expressed the idea that customers should not be using ccs-cli commands.

[j8-redis]

Quoting someone else, "ccs-cli is unsupported and dangerous.... the customer needs to be aware they shouldn't use it for anything else unless guided by support"

[markotrapani]

Quoting someone else, "ccs-cli is unsupported and dangerous.... the customer needs to be aware they shouldn't use it for anything else unless guided by support"

This is true; we in support usually include this disclaimer when supplying ccs-cli commands to the customer. I don't see why a similar note could not accompany this in the docs, as well.

[mich-elle-luna]

In general, the docs should only cover what is supported. If docs covers unsupported uses, folks will use it for the wrong purpose and can blame us for it because we documented it. When support recommends it in a ticket, then we know an expert has diagnosed the problem and there is a record of the specific use and the guidance provided.