tag: Dynatrace ,  SAP BTP, PostgreSQL

前言：

看到有朋友问起，在大型的Cloud环境下边，有哪些好的监控工具或服务。也是有的。愿意花钱烧钱的，可以看看Dynatrace。

Dynatrace是一款强大的云平台监控工具，它提供了一套完整的解决方案，也基本上在各大云厂商上，都可以做到高效集成。当然其服务价格也不便宜。

介绍：

上图就是SAP BTP 中的Cloud环境集成Dynatrace，可以对一个Region中所有的微服务、基础服务分类进行监控，能拿到非常详细的各项指标。

实例1:  JVM相关监控小例

而下边两张图就分别是某一个微服务中的JVM(某一个实例)遇到了OOM, 出现了短暂的Crash的监控图。在那个时刻，基本上DevOps手上也会收到相应的预警邮件。因为各项微服务都是autoscaling的，宕掉一个，立马又会启动一个，影响不算太大。

容器的内存在不到5G的时候挂了，而JVM的head，似乎那个时候还不到1.1GB。所以，微服务的应用层或者某个地方的配置（如JVM配置参数）触发了memory commit error，导致出错。而不太像是JVM的max heap  size不够出这种错。

实例2：PostgreSQL数据库实例监控

我们可以很方便的查看目标Region的所有数据库实例的运行状态。

慢查询，数据库的disk usage, memory usage, connection占用情况等基本情况也都有相应的Dashboard可以看到。

当然一些比较复杂的监控，你可以通过相关代码进行集成，可以使用通用的metrics查询得到相应的指标。这些都是Devops/DBops额外要做的事。

上边的例子只是SAP BTP在CloudFoundry云环境下的示例。而BTP还支持SAP NEO hana cloud，Kyma等其它Cloud环境。底层的IaaS，有SAP自身的，也有来自AWS的、MS的Azure、Google的GCP以及国内的Ali Cloud。多方共存。

吐槽：

方便的地方：

以DB为例 ，备份恢复之类的工作，确实不需要太多考虑了，在DB服务初始化的时候，就已经定义了相关的备份恢复以及HA的策略了，花的钱多，自然会有更好的维护。需要考虑的是如何让你的应用与提供的DB服务达到最佳匹配，以最少的钱得到最匹配的服务。

再说说不方便的地方：

同样以DB为例 ，就以PostgreSQL为例 ，好多好用的插件，基本上你用不到，想要用它列出来的某些插件，还得单独安装(相关权限受到很大的限制)，甚至有的插件就不能用。也就是说，你使用的可能是”阉割“版的PG。

针对DevOps/DBOps：

在不断监控之余，可能得要想方设法减少资源的消耗，为整个Cloud环境节省费用，同时还能满足外部客户的正常的性能需求（功能需求不表）。内存的、DISK的、网络的，各个环节。还有底层服务的各种价格对比。

再回到DBA的话题，可能他遇到的问题，比过去更复杂了，而不是简单了。因为在非cloud环境下，内存的使用就是真实的可控内存，但是在cloud上边，container的内存，你通过overcommit_memory以及overcommit_ratio就无法控制，因为这两个参数是在更上一级的host级别才生效的。从多container共享物理内存。出了问题，情况就得复杂了很多。有时可能需要多个部门合作，才能找到原因。

做架构的、做Ops的、做DBA的、做PO的、做QA的，这些角色，最后看起来没有一个是多余的。