02月06, 2017

【翻译】日志和计量和图表

原文 https://blog.raintank.io/logs-and-metrics-and-graphs-oh-my/

Grafana已经被大量用户使用并且有种类繁多的数据来源,在这些收集数据的方式方法中,日志收集方式为代表的是Elasticsearch,ELK stack(Elasticsearch, Logstash and Kibana)的一部分,计量方式为代表的是Prometheus.

监控对于我们意味着什么?监控意味着知晓系统内部发生了什么,通信情况如何,性能怎么样,有多少报错。但这不是终极目标,只是一种方法。我们的目标是能够探测,排查和解决当前出现的问题,监控是整个流程的一个组成部分。
让我们看看日志和计量如何帮助我们实现目标。

日志

日志有多种格式。在Unix系统中你会发现大量的日志,有文本日志/var/log/syslog,有二进制日志在wtmp和很多程序中,他们通常组织在/var/log下面。
对于监控来说,我们今天讨论的日志主要是应用日志。确切的说是请求日志。每个请求都会在文件中写一行日志,来记录它访问的路径,花费的时间,返回状态码,来源IP等。

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

日志能够被传送到ELK stack中心,分析和提供聚合信息并且图形化展示。

计量

计量方式也是多种多样的,我们来看其中一个方式叫“计数器”,每次发生了你“感兴趣”的事件,就会在进程中递增这个变量。可能是完成的请求,当前的错误,或者某个路径的访问时间。

你可以实现不同的数据类型,使用非整数对于延迟数据比较好。最好你的度量变量库将测量时间从程序中抽象出来,分离处理单元到前端系统中,就像Grafana一样。

# HELP api_http_request_total HTTP requests to the API
api_http_request_total{method="post",code="200"} 5027
api_http_request_total{method="post",code="400"} 1023

计量数据被周期性传送到监控系统中,用于分析并产生图表。比如Prometheus能够积攒每10s的值,并且计算出每个值的增长量,用于图形展现。

Graphing


以上两个方法对能够让你通过高级的图形知道,你的应用目前有多少请求,访问速度,有多少错误。也都可以对数据进行交叉分析。想要知道/my/endpoing最近3小时有多少错误?没问题。

利弊

都能生成一样的图形并不意味着这两种方式是一样的,两种方式都各有利弊。
日志包含每个单独的事件,所以你的用户基数和未来增长情况决定了你要处理的日志数量。这意味着更高的IO和网络需求,10台服务器,每1000个请求记录1KB日志每秒,将要耗费100MBit的带宽!这就限制了你的日志平台处理能力。有利的一面是,你能深入到具体事件中去,例如看到确切拉高平均延迟的慢请求。
计数器在事件中是聚合状态,所以深入到具体请求中找“最差请求”是不可能的。这种只传输聚合数量不会对你的系统造成额外负担。而每请求1KB日志可能等价于100个计量数据,1000请求每秒花费的网络带宽,可以传输1000000个计量单位每10秒。
以上计算只是一个例子,实际运行不建议传输这么大量的日志或者计量数据:) alt

综合工具箱

日志和计量需要结合使用。如果你要集成监控在你的应用中,你需要加入大量运行信息贯穿在你的代码库中。计量提供给你聚合的视角,日志提供给你较小的计量值,但是提供了每一个请求和事件的详细信息。 计量在处理问题时是第一手段,结合精心设计的仪表板,可以让你快速定位系统中各种古怪问题。再结合分析工具挖掘你的日志,深度检查你的源代码,去解决问题。
不要限制自己只使用一种方法来收集数据进行监测,让日志和度量两全其美。

本文链接:https://www.opsdev.cn/post/logs-metrics-graphs.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。