后端 / 运维请进,这个工具非常推荐!

2018-12-20 18:23:40 +08:00
 Kilen

假如有过服务器宕机的恐惧的话,肯定很喜欢这个工具。

每当服务异常的时候,我们第一件事就是查找哪个服务挂了,如果你只有一个服务器,也许也还好,不过只有一个服务器的话估计宕机了也不会有什么恐惧感(这个时候用户量一般还不算大)

可是如果你有很多个服务器,N 多服务,要查清哪个服务出问题了,也不是那么简单。除非你的运维系统已经做的很完备,可是尽管这样,在产品飞速迭代的过程中,每周有新的服务更新上来很正常,这个时候要保证监控到位也是一种挑战。

我刚发现这个国外开发者做的 app:Net Status。

这个 app 可以让你一键 check 所有服务的运行状态,一瞬间你就知道哪个服务出问题了:

你也可以单独查看每个服务各个端口的运行状态:

如果对这些功能不感冒的话,至少,你可以用这个 app 装逼:当跟朋友在餐厅吃饭时,朋友抱怨这个 WIFI 好像有点问题的时候,你拿出手机,ping 一下 baidu,然后很淡定的说,“是的,上不了网”

如果对这个 app 好奇,这里有更详细的介绍(有一个视频):Net Status - Server Monitor

最后,心动的话赶紧去下,现在限免中,原价 28 !

4599 次点击
所在节点    程序员
28 条回复
richzhu
2018-12-21 08:56:27 +08:00
有 K8S,需要更详细的监控,直接 Prometheus + Grafana 一把梭
cominghome
2018-12-21 09:19:40 +08:00
@Kilen
大部分情况下,不光监控服务器,还会监控服务端口,这个是最基本的。进阶一点的,还会做一些接口用专门的数据包来监控服务运行状态。
所以上面几个老哥说的是正确的,这玩意真的连玩具都算不上,如果等到用户投诉才用这个工具去查早 TM 被开除了。
大部分公司面临的监控难不在于单个服务,而在整个业务层,举个例子淘宝下单接口慢,但是没有任何故障上报,甚至机器负载都不高,你怎么定位?
8355
2018-12-21 09:50:54 +08:00
难道不做监控和邮件报警....
xpresslink
2018-12-21 10:35:37 +08:00
@Kilen #18
你之所以有这种感觉是因为你没有运维经验,估计你的 LINUX 之类也玩得不够 6,不然你也不能见到这么个小玩意就激动成这样。

实际上现在互联网服务运维已经有了比较完善的成熟方案,比如 k8s 之类,一些大厂用了自己开发的解决方案。
简单地说,现在基本上都是容器化部署了,一个应用至少都会两个以上的实例,负载重的可能会有几十上百个相同实例运行,其中一个完全挂掉了也没有什么影响。而且最重要的是容器如果挂掉了,监控中心就会立刻自动置换一个新容器把应用实例拉起来了,根本不需要运维人员插手。另外监控设施是非常完善的,监控插件直接包括在 docker 基础镜像中了,不存在漏掉监控这个场景,要监控哪些项目也是由集群中的专门配置中心推送的随意定制。CPU/内存 /IO/进程 /端口之类这些都叫基础监控是很小儿科的。实际上比较重要的是业务监控,比如从用户点提交到返回结果全业务链时延都是有监控的。

总之吧,眼界限制了你的想象力。
boxvivi007
2018-12-21 11:22:35 +08:00
底层由监控触发故障自动恢复,抓取关键异常数值,前端大屏展示,显示关键全网设备关键信息和业务逻辑关系,楼主的软件说实话不太实用了
Kilen
2018-12-21 12:16:46 +08:00
@cominghome 用这个的目的不是为了监控,而是为了调试... 是当发现网站不正常的时候,而从监控里又没有发现这么有价值信息的时候,可以用这个来调试。

@xpresslink 我想说的是一个 devops 过程,而不是结果。如果是一个很稳定的网站,比如网站很久才会有比较大的变动,你的监控肯定可以做的很完备。可是如果我的网站一直是用 C 的,突然上来一个 Nodejs 服务,而且还每天都会有新的业务逻辑更新,那么要保证监控跟的上是一个挑战吧。

嗯,k8s 确实很好用,其实上了 k8s,说明这个团队的运维工作也已经俨然有序了,可是一切都会有一个过程,而在运维后台完备之前,需要有个迭代的过程。

我经历过一个高速发展的公司,从每天蹦过渡到非常稳定,而这个工具,对于当时的我,很有用。每个工具都有使用场景吧。

@xpresslink 谢谢分享
Kilen
2018-12-21 12:51:35 +08:00
有些朋友提到这个 app 就是一个玩具,对,咸鱼白菜各有所爱,也许这个工具对自己日常工作没帮助。
可是我想说,这个 “玩具” 是某一个开发者,在自己日常工作中遇到的问题,并且给这个世界提供的一个解决方案,也许这个 “玩具” 凝结了这个开发者很多心力。
吐槽两句没什么问题,可是我希望大家内心深处对每一个提供解决方案的开发者保持着尊敬。这也是当我看到一个很有趣的 app 时,为啥会这么兴奋的原因。
cominghome
2018-12-21 14:33:30 +08:00
@Kilen
----------
用这个的目的不是为了监控,而是为了调试... 是当发现网站不正常的时候,而从监控里又没有发现这么有价值信息的时候,可以用这个来调试。
一个批量 telnet 工具能调试啥。
----------
如果我的网站一直是用 C 的,突然上来一个 Nodejs 服务,而且还每天都会有新的业务逻辑更新,那么要保证监控跟的上是一个挑战吧
太简单了。大部分监控工具并不挑语言。
----------
吐槽两句没什么问题,可是我希望大家内心深处对每一个提供解决方案的开发者保持着尊敬。这也是当我看到一个很有趣的 app 时,为啥会这么兴奋的原因。
没有不尊敬开发者。怎么和你形容呢,话说难听点,站在我的角度看这个帖子,就是一个人突然发现把南瓜滚起来这样搬运轻松点,兴奋地广而告之,可是转头一看邻居都已经都农业机械化了所以对这么个主意并不感冒,为了不丢面子仍然坚持使用滚南瓜这样的方式运输自己家的南瓜。
----------
最后,我尊重开源,尊重每一个开发者,这个工具可能确实符合某些场景的使用需求,但是过时了就是过时了,自己眼界低就是眼界低,认错要诚恳挨打要站稳。也不是大家一味地批评你,你这个标题,我还真以为你找到个东西比 zabbix 简便好用比普罗米修斯靠谱,结果...

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/519488

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX