为什么很多公司都自主开发监控系统？（Linux运维方面）
关注者
924
被浏览
77,661
25 个回答
码农
先占个坑
首先如果仅仅是用于linux运维 也就是如果你的监控系统仅需要机器指标 那么开源产品随便用 反正就那么十几个到几十个指标 你就算有十万台服务器 分钟级监控 也还是可以毫无压力搞定的，但是吧，很多时候还有监控服务器上的进程，甚至还有些业务数据或者说是进程性能数据。这样现有开源就有点费劲了。之前我们用opentsdb，然后发现数据每天3.5g，查询聚合数据的时候很慢（因为opentsdb每次从磁盘捞数据）。实在忍不了了，重写。现在每天500g，查询秒级返回。各种报警自行支持。这就是我们写的目的。只因为已有的满足不了并且开源社区的发展速度跟不上公司需求的发展速度。
最后，文无第一的原则，程序员还是有点炫技倾向的。
当然，从私人角度讲，重头解决采集，聚合，存储，同步，报警甚至是智能化，这个过程本身就是一次非常好的学习经历。
首先如果仅仅是用于linux运维 也就是如果你的监控系统仅需要机器指标 那么开源产品随便用 反正就那么十几个到几十个指标 你就算有十万台服务器 分钟级监控 也还是可以毫无压力搞定的，但是吧，很多时候还有监控服务器上的进程，甚至还有些业务数据或者说是进程性能数据。这样现有开源就有点费劲了。之前我们用opentsdb，然后发现数据每天3.5g，查询聚合数据的时候很慢（因为opentsdb每次从磁盘捞数据）。实在忍不了了，重写。现在每天500g，查询秒级返回。各种报警自行支持。这就是我们写的目的。只因为已有的满足不了并且开源社区的发展速度跟不上公司需求的发展速度。
最后，文无第一的原则，程序员还是有点炫技倾向的。
当然，从私人角度讲，重头解决采集，聚合，存储，同步，报警甚至是智能化，这个过程本身就是一次非常好的学习经历。
找不到工作的产品经理。
其实这个问题可以延伸到，为什么很多公司都自主开发订餐系统，很多公司都自主开发客户管理系统，为什么很多公司都打算自主开发运营监控系统？
除开生产力过胜，和可恶的 KPI 之外，我觉得还有一些其他重要原因吧。
很多答案里提到了当业务变得慢慢复杂起来，开源的、第三方的监控解决方案，不能满足需求，我觉得说不通。拿一张图来说话吧：
上图来自一家分享和发现各 IT 公司使用什么工具的网站：StackShare Discover and discuss the best dev tools and cloud infrastructure services
可以看到 Facebook 用了 Datadog 来做运维监控，Netflix 用了 Boundary 来做运维监控。
那么，那么多业务量巨大的公司，在监控这块依旧使用 Datadog Boundary 这样的第三方监控解决方案。
说明业务量大、逻辑复杂，根本不是要转向自己来研发这些系统的原因。
那为什么还要反复地造轮子、造轮子、造轮子呢？以我这几年的工作经历说说吧。
领导是傻 X
我现在所从事的刚好是给企业提供第三方监控解决方案的工作。在跟很多企业提供解决方案的时候，项目实施到一半，可能在监控本身需要加入：
这就是楼上很多人提到的所谓业务复杂，本身业务不复杂，只是领导们的要求很复杂。管理本身存在很多问题，不能够将一件大事情细分到每一项具体的事情上。而领导们觉得自己只需要考虑全局，中层干部们也没有理顺领导的要求并拆分领导的要求。
工具能够帮助我们将每项具体的事情变得更高效，但是解决不了实际情况中某个大的命题。
我一直坚信： 工具是让聪明人变得更高效，而不是让傻 X 变得牛 X。
当上层领导只能按照行政、业绩来划分具体实施人员的工作时，运维的监控这件事情就可以扩大到一个漫无边际的地步，并且和自己的行政划分、规章制度高度耦合。
有情怀的程序员太少
就拿系统监控工具这件事情来说吧，国外有 Host Graphite、Boundary、Datadog 等等。国内除了小米的 Open-Falcon|互联网企业级监控系统 和 OneAPM 的 Cloud Insight ， 鲜少有一些真正易用的、开源的、产品化的工具，来帮助我们解决某项具体事情。
但是大公司内部，却有很多人在帮助所在的公司做这些事情。但是没有想过自己做一款产品是什么样的，也没有思考过从头开始经营一款自己的产品是啥样的。
活在大公司里，盼望着过 KPI、期待着公司上市后期权可以兑现。
中国的开源和 SaaS 服务落后于国外，很大一部分原因是因为企业文化的差异和制度本身的问题吧。
总的来说，就是程序员们都在造轮子，而且轮子越造越大，可能只适合所在的企业。没有想过自己的轮子，可以形成通用化的产品。
没耐心
将一个产品吃透，按照这个产品的设计思路来指导自己的工作。我觉得比自己本身去研发一个产品效率要高很多啊。
打个不恰当的比方，设计师觉得 Photoshop 不好用，因为用钢笔要练习，而且 Photoshop 本身也不能给自己拓宽视野和给风格带来影响。所以决定要自己研发一个取代 Photoshop 并且更适合自己的产品。
也许还不适合自己公司在交接工作中的流程，行政部门打不开 PSD 文件，具体实施的人没有要求换成 CMYK 就印刷了。
幸好大部分设计师不具备研发的能力，只好耐着性子去学习了。
其实很多工具在经过反复的迭代和设计时，都透漏着设计者本身的一些方法论和思想在里面。 有些成熟工具不好用，或者很麻烦，其实可能是使用者本身的工作方式有问题。
最后做个广告吧。之前提到我也是做系统监控工具服务的，我们有一款系统监控工具 Cloud Insight ：安装简单、UI 美丽、未来会有再开发能力。爱用不用，不用拉到。啊哈哈，上几张图。
———————————补充 @bhuztez 的提问——————————————————
说一下 Cloud Insight 的产品规划吧。我们正在做事件处理，有参考国外的 Bigpanda，主要方向是报警风暴的处理、事件的聚合，以及动态门限类与算法有关的报警策略。
然后我们也用到了 OpenTSDB，架在了 HBase 上，负载还不错。虽然在公测，但是每天处理的数据量还是挺大的。
至于行政和规章制度需要架在产品里，我指的不是报警需要分发到不同的人、并且选择不同的渠道来分发。这些一般的第三方工具，和开源工具集成一些渠道，都可以做到。
我指的是，之前面对的企业客户。可能老板根本不需要看指标，老板需要看机房里每天机器是不是 DOWN 掉了，还需要很酷炫的 3D 建模。
而真正的实际操作人员，又需要到很具体很具体的指标，甚至每个单位都需要落实到产品里。
一个工具不可能自上而下地解决管理上的问题，我们的目标是通过一个像 JIRA 的工具来达到通用的、科学的管理，而不是把这个工具做到跟公司一些很腐化的制度绑定在一起。
就像有些公司项目管理做得很烂，JIRA 用不起来，所以去找国内一些软件公司来做一个和自己制度高度耦合的项目管理软件，并天真地以为可以解决问题。
除开生产力过胜，和可恶的 KPI 之外，我觉得还有一些其他重要原因吧。
很多答案里提到了当业务变得慢慢复杂起来，开源的、第三方的监控解决方案，不能满足需求，我觉得说不通。拿一张图来说话吧：
上图来自一家分享和发现各 IT 公司使用什么工具的网站：StackShare Discover and discuss the best dev tools and cloud infrastructure services
可以看到 Facebook 用了 Datadog 来做运维监控，Netflix 用了 Boundary 来做运维监控。
那么，那么多业务量巨大的公司，在监控这块依旧使用 Datadog Boundary 这样的第三方监控解决方案。
说明业务量大、逻辑复杂，根本不是要转向自己来研发这些系统的原因。
那为什么还要反复地造轮子、造轮子、造轮子呢？以我这几年的工作经历说说吧。
领导是傻 X
我现在所从事的刚好是给企业提供第三方监控解决方案的工作。在跟很多企业提供解决方案的时候，项目实施到一半，可能在监控本身需要加入：
- 你们能不能顺便把 IT 资产管理也给做了？
- 你们能不能帮我们做下整个园区的 3D 建模？
- 你们能不能按照我们的行政划分，把每项监控事宜都落到个人头上？
这就是楼上很多人提到的所谓业务复杂，本身业务不复杂，只是领导们的要求很复杂。管理本身存在很多问题，不能够将一件大事情细分到每一项具体的事情上。而领导们觉得自己只需要考虑全局，中层干部们也没有理顺领导的要求并拆分领导的要求。
工具能够帮助我们将每项具体的事情变得更高效，但是解决不了实际情况中某个大的命题。
我一直坚信： 工具是让聪明人变得更高效，而不是让傻 X 变得牛 X。
当上层领导只能按照行政、业绩来划分具体实施人员的工作时，运维的监控这件事情就可以扩大到一个漫无边际的地步，并且和自己的行政划分、规章制度高度耦合。
有情怀的程序员太少
就拿系统监控工具这件事情来说吧，国外有 Host Graphite、Boundary、Datadog 等等。国内除了小米的 Open-Falcon|互联网企业级监控系统 和 OneAPM 的 Cloud Insight ， 鲜少有一些真正易用的、开源的、产品化的工具，来帮助我们解决某项具体事情。
但是大公司内部，却有很多人在帮助所在的公司做这些事情。但是没有想过自己做一款产品是什么样的，也没有思考过从头开始经营一款自己的产品是啥样的。
活在大公司里，盼望着过 KPI、期待着公司上市后期权可以兑现。
中国的开源和 SaaS 服务落后于国外，很大一部分原因是因为企业文化的差异和制度本身的问题吧。
总的来说，就是程序员们都在造轮子，而且轮子越造越大，可能只适合所在的企业。没有想过自己的轮子，可以形成通用化的产品。
没耐心
将一个产品吃透，按照这个产品的设计思路来指导自己的工作。我觉得比自己本身去研发一个产品效率要高很多啊。
打个不恰当的比方，设计师觉得 Photoshop 不好用，因为用钢笔要练习，而且 Photoshop 本身也不能给自己拓宽视野和给风格带来影响。所以决定要自己研发一个取代 Photoshop 并且更适合自己的产品。
也许还不适合自己公司在交接工作中的流程，行政部门打不开 PSD 文件，具体实施的人没有要求换成 CMYK 就印刷了。
幸好大部分设计师不具备研发的能力，只好耐着性子去学习了。
其实很多工具在经过反复的迭代和设计时，都透漏着设计者本身的一些方法论和思想在里面。 有些成熟工具不好用，或者很麻烦，其实可能是使用者本身的工作方式有问题。
最后做个广告吧。之前提到我也是做系统监控工具服务的，我们有一款系统监控工具 Cloud Insight ：安装简单、UI 美丽、未来会有再开发能力。爱用不用，不用拉到。啊哈哈，上几张图。
———————————补充 @bhuztez 的提问——————————————————
说一下 Cloud Insight 的产品规划吧。我们正在做事件处理，有参考国外的 Bigpanda，主要方向是报警风暴的处理、事件的聚合，以及动态门限类与算法有关的报警策略。
然后我们也用到了 OpenTSDB，架在了 HBase 上，负载还不错。虽然在公测，但是每天处理的数据量还是挺大的。
至于行政和规章制度需要架在产品里，我指的不是报警需要分发到不同的人、并且选择不同的渠道来分发。这些一般的第三方工具，和开源工具集成一些渠道，都可以做到。
我指的是，之前面对的企业客户。可能老板根本不需要看指标，老板需要看机房里每天机器是不是 DOWN 掉了，还需要很酷炫的 3D 建模。
而真正的实际操作人员，又需要到很具体很具体的指标，甚至每个单位都需要落实到产品里。
一个工具不可能自上而下地解决管理上的问题，我们的目标是通过一个像 JIRA 的工具来达到通用的、科学的管理，而不是把这个工具做到跟公司一些很腐化的制度绑定在一起。
就像有些公司项目管理做得很烂，JIRA 用不起来，所以去找国内一些软件公司来做一个和自己制度高度耦合的项目管理软件，并天真地以为可以解决问题。