流式统计听着挺容易的一个事情，说到底不就是数数嘛，每个告警系统里基本上都有一个简单的流式统计模块。但是当时基于storm做的时候，这几个问题还是困扰了我很长时间的。没有用过spark streaming/flink，不知道下面这些问题在spark streaming/flink里是不是都已经解决得很好了。

最近在学习各大互联网公司是如何处理数据一致性的。因为之前从事的不是这个方向的工作，所以并非什么经验之谈，只是一些学习笔记。所有资料来自互联网。

没有多少系统的告警是设计得当的。良好的告警设计是一项非常困难的工作。如何知道你收到的告警是糟糕的？多少次你收到了告警之后，立即就关掉了的？是不是成天被这些然而并没有什么卵用的东西给淹没？最常见的告警设置：cpu使用率超过90%，然后告警。这种设置在大部分场合下是没有办法提供高质量的告警的。

Gerard J. Holzmann NASA/JPL Laboratory for Reliable Software Pasadena, CA 91109

很多人在搞ELK，很多人也在搞STORM。更多人在用传统的Nagios，Zabbix等监控工具。Jason Dixon在2012就意识到这些工具的问题是每个人都想做到大而全，实际上我们更需要的是一对小二精的组件拼装成一个个性化的解决方案。推荐大家去看一下他的演讲视频：[链接]

有太多日志采集工具了。但是可以做到在繁忙的机器上低负载地采集海量日志的工具并不多。很多日志采集器是用python/perl/ruby这些语言写的。下面一个简单的测试，说明python的效率是不适合日志采集工具的。

发布变更流程管理工具：做为系统接口与其他角色的工作衔接。并提供审批环节控制发布变更的风险。流程管理工具并不负责具体的业务操作的执行，只是作为单据系统跟踪流程和确保闭环。

我们首先来看一下 JAVA 如何使用 CPU 的 SIMD 指令。这是一个ru的哥们尝试在lucene里使用SIMD指令加速lucene的postings list（也就是指定term对应的文档id列表）的解码：

这段代码演示了 python generator 的功能。可以看到 yield 同时做了两个操作，一个是往外发数据 "waht is the input"，同时做的操作是往里收数据 input。而且这个接收数据的操作是一个阻塞的操作，如果外部没有调用 next() （也就是往里传递None），或者调用send(42)（也就是往里传递42这个值），那么这个阻塞的操作就会...

Hive推出不久就被发现，虽然用的SQL但是性能离数据库还差很远。很快就有人提出是不是要给Hive加上数据库一样的索引。这明显就是分布式计算引擎向分析数据库的方向靠拢。

[链接] 之前写了一个版本，不够简练 业务运维部门有四个方面的岗位价值，按照实现的难易程度排序 效率 质量 成本 安全 效率 这是最容易实现，也是能够输出最大的价值地方。现在的竞争，更多的是 time to market 的竞争。谁能更快地把新版本推向市场，谁能最快地完成bug修复谁就更有可能赢得竞争。运维是版本交付到用户手...

Intel 为了更好的卖他们家的cpu，花了不少力气参与分布计算社区的开发，比如spark。如果真正用好这些芯片提供的特性，确实可以极大的提升分布式计算系统的性能。

大数据或者计算自身并没有任何价值。数据通过影响最终决策产生价值。最初期所谓大数据或者BI的解决方案通过提供各种漂亮的报表给经营人员，让老板做出更好的决策。

signalfx (Metrics + Streaming Analytics + Interaction = Monitoring Evolved) [链接]

大部分小企业的运维就是 ssh 加一些 fabric 脚本就可以搞定了。极端大型的企业，比如 google twitter，比如腾讯 SNG，百度等，都有一套非常完善和复杂的运维平台。我认为，这里存在一个潜在的市场机会，那就是对于那些中型企业（比如机器数量大于100，小于1000），他们的集群规模已经使得手工加脚本管理变得有些痛苦，但...

岗位价值有： 权限缩小 提供操作安全的保险服务 提供操作的可扩展性 提供业务和资源能见度 屏蔽资源的部署细节 静态资源调平 动态资源调平 故障处理和善后 权限缩小 通过配置文件修改一个后台参数需要登录权限，文件修改权限，甚至进程起停权限。这些运营环境的权限需要尽可能的收归到很少的人的手里以控制风险。业务运...

数据检索有两种主要形态。第一种是纯数据库型的。典型的结构是一个关系型数据，比如 mysql。用户通过 SQL 表达出所需要的数据，mysql 把 SQL 翻译成物理的数据检索动作返回结果。第二种形态是现在越来越流行的大数据玩家的玩法。典型的结构是有一个分区的数据存储，最初这种存储就是原始的 HDFS，后来开逐步有人在 HDFS ...

docker很火很红，简直到了没有道理的地步了。docker为什么这么红？因为它是一种可以用来掀桌子的技术。在部署自动化这条产业上的工人和机床制造商们，看家护院的 cmdb，分布式脚本执行等所谓核心技术即便不会变成明日黄花，也会沦为二流技术。仅仅把 docker 当成一个轻量级 vmware 来使用，是没法看穿其实质的。要理解 d...

Doc Values Doc Values 会压缩存储重复的内容。 给定这样一个简单的 mapping {代码...} 插入100万行随机的重复值 {代码...} 磁盘占用是 {代码...} 把每个word搞长一些，同样是插入100万行 {代码...} 磁盘占用不声反降 {代码...} 这说明了lucene在底层用列式存储这些字符串的时候是做了压缩的。这个要是在某个商业列式数...

告警系统的误警和漏警如何计算？在线上运行的告警设置必然是会受到骚扰频次的限制。门限设得过高就可能会漏警。但是如果每天执行一次告警质量的检查算法，然后给出一堆疑似的漏警和误警，然后结合人工辅助可以更快地发现漏警和误警的情况。

d1 ~ dn 是维度，比如 ip, idc, country 之类的值 v1 ~ vn 是值列，比如 cpu_usage, free_memeory_bytes 之类的值

同样我们以最简单的表结构开始。在elasticsearch中，先要创建index，然后index下有mapping。所谓的mapping就是表结构的概念。建表的配置如下：

d1 ~ dn 是维度，比如 ip, idc, country 之类的值 v1 ~ vn 是值列，比如 cpu_usage, free_memeory_bytes 之类的值

曾经天真的认为只要把 Storm 安装好之后，简单学习一下 Storm 的编程概念就可以把实时统计的工作完成了。毕竟实时统计无非就是加减乘除，并不牵涉到什么高深的机器学习算法。然后在实践中发现 Storm 根本没有提供实时统计所必需的很多基础设施和编程抽象，更不要说进行更复杂的通用实时计算了（比如关联两个事件流进行登...

[链接][链接][链接][链接][链接][链接] [链接][链接]

这个世界上开源和收费的监控系统实在是太多了，而不是太少了。无论是传统的nagios，ganglia，还是所谓的云监控系统。它们的工作方式其实都差不多，安装一个agent，上报数据，然后花花绿绿的图表就显示在web界面上了。无论这些系统如何包装，前端写得多么漂亮，一看截图十有八九图例是“cpu1”，“cpu2”。cpu使用率，内存，...

Plato and the Problem with Timeseries Outliers vs Probability Density Function Shifts

背景 任何一个产生环境的IT系统如果要长久下去，必须对其进行监控告警。常见的实现分为三个部分 采集目标系统的指标，并上报到中央服务器 对指标按时间窗口进行统计，并存储成为曲线 对曲线进行异常检测，在必要的时候告警通知运维人员 在过去，对于第1、2两点我们已经积累非常多的文章和工具来谈论如何来实施一个“监控...

grizzly框架的作者曾经提到NIO框架不应该使用selection key的attach功能（链接）。理由是如果attach到了selection key上，而这个selection key对应的操作迟迟不能就绪（被select出来）。那么这些selection key所attach的附件都是被强引用的，从而无法被gc。如果有大量这样的selection key累积，程序就好像发生了内存泄漏...