使用ELK处理Docker日志(二) - 知乎专栏
{"debug":false,"apiRoot":"","paySDK":"/api/js","wechatConfigAPI":"/api/wechat/jssdkconfig","name":"production","instance":"column","tokens":{"X-XSRF-TOKEN":null,"X-UDID":null,"Authorization":"oauth c3cef7c66aa9e6a1e3160e20"}}
{"database":{"Post":{"":{"title":"使用ELK处理Docker日志(二)","author":"xiao-shu-42-5","content":"上篇文章介绍了如何将容器日志收集到ELK （Elasticsearch，Logstash和Kibana）的基本步骤。不管最终使用哪种方法来收集Docker日志--使用日志驱动程序或专用日志驱动均可行，接下来要解决的问题是如何在Elasticsearch中编入索引并在Kibana展现时处理日志。本文将进一步分析使用ELK记录Docker的过程 - 分析和可视化日志。Dockerized环境要求:由ELK，Prometheus和Grafana容器组成使用Docker日志收集器将Docker日志发送到 ELK。若使用自己的ELK部署，分析和可视化日志的概念保持不变。分析之前的准备工作...解析分析容器生成日志的难度级别取决于如何解析--将消息分解成有效字段的效率越高，可视化起来也就越容易，这正是 Kibana 知名的原因。由于Dockerized环境存在差异，提供详细的解析说明是很困难的，以下是同一主机上两个不同容器的日志。首先是Grafana容器：t=T13:04:47+0000 lvl=info msg=\"Request Completed\" logger=context userId=1 orgId=1 uname=admin method=GET path=/logout status=302 remote_addr=109.67.183.188 time_ms=1ns size=29
\n然后是Elasticsearch容器：[T13:05:01,974][INFO ][o.e.c.r.a.DiskThresholdMonitor] [0EUzBd2] rerouting shards: [high disk watermark exceeded on one or more nodes]\n日志解析小技巧：时间戳 尝试规范不同类型容器日志的时间戳字段，有助于以后日志的分析，不用修改每个新镜像的时间格式。服务ID /标签 为了区分不同的容器日志，给每个日志类型添加标签至关重要，这样可以在Kibana中以不同的流来区分日志，若想在日志中获取容器名称和ID，也可以添加更多的数据注释，以便将来分析。丢掉不必要的数据 如果有不必要的数据字符串，可以使用Logstash过滤器删除，经常清理后续分析会变得容易一些，另外，请不要将日志写入STDOUT / STDERR。当然，自己完成所有这些操作并不简单，可以借助logspout和日志收集器等工具。日志查询上篇文章已经介绍如何将Docker日志存入Elasticsearch,基于这个条件我们开始新的操作。分析数据之前，最好将一些字段添加到主日志显示区域（“Discover”选项），有助于了解数据。如上所述，这个字段列表以及是否可以用于分析，完全取决于如何配置解析。示例中保留了一些有用的字段，可以看到诸如“image”（容器镜像名称），“id”（容器ID）和“name” （容器名称）。.接下来就是查询日志，这里需要熟悉Kibana基本查询语法，简单介绍下使用Kibana搜索Docker日志上下文，更多Kibana语法查询方法可关注Kibana教程。用 \"free-text\"在日志中进行搜索是比较常用的方式，更精确的搜索例如\"Field-level\"可锁定特定容器或主机的日志：id: 84379bdbe8e0
\n还可以在逻辑语句中组合两个\"field-level\"搜索，以查找特定容器和重要日志：id: 6c05ea5efd6d AND loglevel:INFO
\n记住，这些字段需要在解析中进行映射，以便执行基于字段的搜索。查看特定容器的日志的另一种方法是使用\"exists\"查询，可根据日志消息中存在的特定字段过滤。例如:_exists_:loglevel
\n完成数据查询后，不要忘记保存查询语句，这将会在接下来的可视化环节提供帮助，虽然可以在创建可视化的同时进行搜索，但是过滤后的数据范围缩小了查找更容易。Docker日志可视化Kibana以索引数据为基础创建丰富的可视化和仪表板的能力而闻名，事实上，得到这些数据并不容易。需要再次强调的是-如何映射和解析消息至关重要。下面来看一些简单的例子。单个容器日志根据每个容器或主机生成的日志量创建可视化饼图，使用容器“name”字段的聚合，得到以下结果：当然也可以使用 \"image\" 或 \"host\" 进行聚合。单个容器事件另一个例子是监控特定容器的事件数量，为此，将基于保存的事件日志搜索创建可视化折线图，示例中有生成日志事件(错误和警告日志)的特殊容器，需要做的是将X轴配置为使用日期直方图：条形图可以更全面地查看每个容器日志:镜像/容器/主机的数量用独特的可视化聚合方式，在环境中显示Docker容器，镜像和主机的数量：这些只是在Kibana中可视化Docker容器日志的简单示例，Kibana包含更多可用的可视化类型 --平铺地图可视化可以创建IP字段（映射为地理位置字段），条形图，数据表等的地理图表。如果使用 ELK来记录Docker日志，则可以在ELK APPS 中使用预制的仪表板--一个免费的Kibana可视化和仪表板库：.结束语尽管在Docker1.12中引入了Docker驱动程序，容器日志记录仍然是一个很大的挑战，日志收集没有捷径，解决方案各有优缺点，然而文中未提及的Docker生成其他类型的数据(例如 container stats 和 daemon events)也应当被记录下来。尽管从Docker主机到ELK的设置并创建良好的日志解析通道并不简单，但最终的结果是值得的，可视化全方位日志将能更有效地关联事件并监控Dockerized环境。原文链接：
","updated":"T08:40:40.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"collapsedCount":0,"likeCount":0,"state":"published","isLiked":false,"slug":"","lastestTipjarors":[],"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-46145a4cdf6d2beb5a26_r.png","links":{"comments":"/api/posts//comments"},"reviewers":[],"topics":[{"url":"/topic/","id":"","name":"Docker"},{"url":"/topic/","id":"","name":"容器"},{"url":"/topic/","id":"","name":"ELK"}],"adminClosedComment":false,"titleImageSize":{"width":740,"height":266},"href":"/api/posts/","excerptTitle":"","column":{"slug":"shurenyun","name":"数人云"},"tipjarState":"activated","tipjarTagLine":"真诚赞赏，手留余香","sourceUrl":"","pageCommentsCount":0,"tipjarorCount":0,"annotationAction":[],"snapshotUrl":"","publishedTime":"T16:40:40+08:00","url":"/p/","lastestLikers":[],"summary":"上篇文章介绍了如何将容器日志收集到ELK （Elasticsearch，Logstash和Kibana）的基本步骤。不管最终使用哪种方法来收集Docker日志--使用日志驱动程序或专用日志驱动均可行，接下来要解决的问题是如何在Elasticsearch中编入索引并在Kibana展现时处理日志。本…","reviewingCommentsCount":0,"meta":{"previous":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-46145a4cdf6d2beb5a26_r.png","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"Docker"},{"url":"/topic/","id":"","name":"容器"},{"url":"/topic/","id":"","name":"ELK"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"公众号：dmesos
","isFollowing":false,"hash":"b6e55e508edfdc4a88d6a28","uid":271400,"isOrg":false,"slug":"xiao-shu-42-5","isFollowed":false,"description":"公众号：dmesos，数人云——构建灵动新IT，最轻量级PaaS平台，热点聚焦云计算前言技术，开源动态，实践落地等，让分布式技术走出象牙塔。","name":"数人云","profileUrl":"/people/xiao-shu-42-5","avatar":{"id":"v2-0c26abf4fa749ad2a10e33","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},"column":{"slug":"shurenyun","name":"数人云"},"content":"Daniel Berman（ 产品经理）为了纪念Docker四岁生日，撰写一系列文章，介绍如何使用ELK收集和处理Dockerized环境日志。今天给大家带来的第一部分将介绍如何安装各个组件以及不同日志收集方案的特点，下一部分将侧重于分析和可视化，近期发出，记得关注我们噢~容器运行程序时产生的日志具有“无常，分布，隔离”等特点，因此在架构中收集Docker日志面临很大的挑战，有待尝试一种强有力的日志收集和处理方案来解决此类复杂问题。ELK （Elasticsearch，Logstash和Kibana）是处理容器日志的一种方式，尽管设置ELK工作流并不容易（难度取决于环境规格），但最终可以使用Kibana的监控面板来展示Docker日志:日志收集的流程Dockerized环境中的典型ELK日志收集流程如下所示： Logstash负责从各种Docker容器和主机中提取日志，这个流程的主要优点是可以更好地用过滤器来解析日志，Logstash将日志转发到Elasticsearch进行索引，Kibana分析和可视化数据。当然这个流程可以有多种不同的实现方式， 例如可以使用不同的日志收集和转发组件, 如Fluentd或Filebeat 将日志发送到Elasticsearch，或者，添加一个由Kafka或Redis容器组成的中间层，作为Logstash和Elasticsearch之间的缓冲区。上图显示了日志从Docker到ELK的基本流程。那么，如何设置这个流程呢？组件安装可以将ELK套件安装在一个容器里，也可以使用不同的容器来分别安装各个组件。关于在Docker上部署ELK是否是生产环境的可行性解决方案（资源消耗和网络是主要问题）仍然存在很多争议，但在开发中这是一种非常方便高效的方案。ELK的docker镜像推荐使用 ， 它支持丰富的运行参数(可使用这些参数组合不同的版本)和文档, 而且完全支持最新版本的 Elasticsearch, Logstash, 和 Kibana.在安装组件之前需要确保以下端口没有被占用:5601 (Kibana), 9200 (Elasticsearch), and 5044 (Logstash).同时需要确保内核参数 vmmaxmap_count 至少设置为262144:sudo sysctl -w vm.max_map_count=262144
\n运行如下命令:git clone /deviantony/docker-elk.git
\ncd docker-elk
\ndocker-compose up
\n正常情况下, ELK套件的三个服务(Elasticsearch, Logstash, Kibana)会启动成功，默认持久化数据目录 /var/lib/elasticsearch (Elasticsearch 的数据存储目录)sudo docker ps\n\nCONTAINER ID
NAMES\n\n73aedc3939ad
dockerelk_kibana
\"/bin/sh -c /usr/l...\"
7 minutes ago
Up 6 minutes
0.0.0.0:/tcp
dockerelk_kibana_1\n\nbd6
dockerelk_logstash
\"logstash -f /usr/...\"
7 minutes ago
Up 6 minutes
0.0.0.0:/tcp
dockerelk_logstash_1\n\nae6a
dockerelk_elasticsearch
\"/bin/bash bin/es-...\"
7 minutes ago
Up 7 minutes
0.0.0.0:/tcp, 0.0.0.0:/tcp
dockerelk_elasticsearch_1
\n测试安装组件可通过如下的方式来确保所有组件都能正常运行。首先尝试访问Elasticsearch运行如下命令:curl localhost:9200
\n输出结果:{\n \"name\" : \"W3NuLnv\",\n \"cluster_name\" : \"docker-cluster\",\n \"cluster_uuid\" : \"fauVIbHoSE2SlN_nDzxxdA\",\n \"version\" : {\n
\"number\" : \"5.2.1\",\n
\"build_hash\" : \"db0d481\",\n
\"build_date\" : \"T22:05:32.386Z\",\n
\"build_snapshot\" : false,\n
\"lucene_version\" : \"6.4.1\"\n },\n \"tagline\" : \"You Know, for Search\"\n}\n打开 Kibaba 页面通过:值得注意的是需要输入索引模式才能正常进行后续处理,这个稍后将会介绍。发送Docker日志到ELK安装组件比较简单，相比而言将Docker日志发送到ELK有点复杂，这取决于输出日志的方式。如果没有额外指定，容器的stdout和stderr输出（也称为“docker logs”）输出到JSON文件。所以，如果是一个小型Docker环境，使用Filebeat来收集日志将是不错的选择。但如果使用其他日志记录驱动程序，则可能需要考虑其他方法。以下是将日志导入ELK的三种不同的方法，切记，这并不能包含所有的方案。使用FilebeatFilebeat属于Elastic的Beats系列日志收集组件， Filebeat是用Go语言开发的,支持追踪特定文件和日志加密的中间组件,它可以配置将日志导出到Logstash或者直接导出到Elasticsearch.如上所述，若使用默认的json文件记录驱动程序，Filebeat是一种相对简便的方式，可以输出日志到ELK.Filebeat部署在主机上，或将其作为容器与ELK容器一起运行（在这种情况下，需要添加到ELK容器的链接），这里有各种可用，有些包括运行Filebeat并将其连接到Logstash的配置。Filebeat配置将需要指定JSON日志文件的路径（位于：/ var / lib / docker / containers / ...）和目标的详细信息（通常是Logstash容器）。下面是一个配置的例子prospectors:
\n - paths:
- /var/log/containers/&xxx&
document_type: syslog
\n logstash:
enabled: true
- elk:5044\n使用日志驱动Docker从1.12开始支持，允许将Docker日志路由到指定的第三方日志转发层，可将日志转发到AWS CloudWatch，Fluentd，GELF或NAT服务器。使用logging drivers比较简单，它们需要为每个容器指定，并且将需要在日志的接收端进行其他配置。在将日志发送到ELK的上下文中，使用syslog日志驱动可能是最简单的方法。下面是一个指定Logging Driver的例子:docker run \\
\n --log-driver=syslog \\\n --log-opt syslog-address=tcp://&SyslogServerIP&:5000\n \\ --log-opt syslog-facility=daemon\n \\ alpine ash\n如此这样运行每一个容器，结果是将Docker容器日志流输出到syslog实例，这些日志将转发到Logstash容器进行解析和数据增强，进入Elasticsearch。使用LogspoutLogspout是Docker流行和轻量级的（15.2MB）日志路由器，它将附加到主机中的所有容器，并将Docker日志流输出到syslog服务器（除非定义了不同的输出目标）。sudo docker run -d --name=\"logspout\" --volume=/var/run/docker.sock:/var/run/docker.sock gliderlabs/logspout syslog+tls://&syslogServerIP&:5000
\n使用直接将日志路由到Logstash容器，但这需要其他配置和编译工作。的日志采集器本人在 这篇文章中介绍了Logz.io的日志采集器，像Logspout一样，它附加在Docker主机中的所有容器上，但它不仅运送Docker日志，还包含Docker统计信息和Docker守护程序事件。docker run -d --restart=always -v /var/run/docker.sock:/var/run/docker.sock logzio/logzio-docker -t &YourLogz.ioToken&
\n目前它是为 ELK 套件的用户设计的，我们正在努力将它开源项目。数据持久化配置Logstash来解析数据至关重要，因为这部分过程将添加上下文到容器的日志中，并能够更轻松地分析数据。在Logstash配置文件中需要配置三个主要部分：输入，过滤和输出。 （若运行的是Logstash 5.x，则该文件位于：/ usr / share / logstash / pipeline）输入取决于日志传送方式，使用Filebeat，则需要指定Beats输入插件。如果使用logspout或syslog日志记录驱动程序，则需要将syslog定义为输入。过滤器部分包含用于分解日志消息的所有过滤器插件，依赖于正在记录的容器类型以及该特定容器生成的日志消息。这部分的配置没有捷径，因为每个容器都输出不同类型的日志。有很多尝试和错误涉及，但是有一些在线工具可参考, 比如:。导出部分将指定Logstash输出，例子中是Elasticsearch容器。以下是通过syslog发送的Docker日志的基本Logstash配置示例。注意一系列过滤器的使用（grok，date，mutate和if条件）：input {
\n syslog {\n
port =& 5000\n
type =& \"docker\"\n
}\n}\n\nfilter {
match =& { \"message\" =& \"%{SYSLOG5424PRI}%{NONNEGINT:ver} +(?:%{TIMESTAMP_ISO8601:ts}|-) +(?:%{HOSTNAME:service}|-) +(?:%{NOTSPACE:containerName}|-) +(?:%{NOTSPACE:proc}|-) +(?:%{WORD:msgid}|-) +(?:%{SYSLOG5424SD:sd}|-|) +%{GREEDYDATA:msg}\" }\n
syslog_pri { }\n
match =& [ \"syslog_timestamp\", \"MMM
d HH:mm:ss\", \"MMM dd HH:mm:ss\" ]\n
mutate {\n
remove_field =& [ \"message\", \"priority\", \"ts\", \"severity\", \"facility\", \"facility_label\", \"severity_label\", \"syslog5424_pri\", \"proc\", \"syslog_severity_code\", \"syslog_facility_code\", \"syslog_facility\", \"syslog_severity\", \"syslog_hostname\", \"syslog_message\", \"syslog_timestamp\", \"ver\" ]\n
mutate {\n
remove_tag =& [ \"_grokparsefailure_sysloginput\" ]\n
mutate {\n
gsub =& [\n
\"service\", \"[-]\", \"\"\n
if [msg] =~ \"^ *{\" {\n
source =& \"msg\"\n
if \"_jsonparsefailure\" in [tags] {\n
mutate {\n
remove_field =& [ \"msg\" ]\n
}\n}\n\noutput {
\n elasticsearch {\n
hosts =& \"elasticsearch:9200\"\n
}\n}\n重新启动Logstash容器以应用新的配置。检查Elasticsearch索引,确保日志流能正常工作：curl 'localhost:9200/_cat/indices?v'
\n具有Logstash模式的索引：health status index
pri rep docs.count docs.deleted store.size pri.store.size\n\nyellow open
logstash- kgJ0P6jmQjOLNTSmnxsZWQ
10.1kb\n\nyellow open
09NHQ-TnQQmRBnVE2Y93Kw
\n打开Kibana的页面Kibana已经创建了'logstash- *' 索引是标识，按下“创建”按钮，可在Kibana中看到日志。结语Docker日志记录没有完美的方案，无论选择什么解决方案，使用日志记录驱动程序，Filebeat还是SaaS监控平台，每个方案都有优缺点。值得一提的是，Docker日志很有用，但它们只代表由Docker主机生成的数据的一个维度，检索容器统计信息和守护程序事件等还需要额外的日志记录层。综上所述，日志收集器提供了一个全面的日志解决方案，将三个数据流一起拉到ELK中。如需统计数据，建议尝试一下Dockerbeat.本系列的下一部分将重点介绍如何在Kibana中分析和可视化Docker日志。Docker 生日快乐!Daniel Berman是产品经理。擅长日志分析、大数据、云计算,热爱家庭,喜欢跑步,Liverpool FC和写颠覆性的技术内容。原文链接：","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T15:21:05+08:00","url":"/p/","title":"使用ELK处理Docker日志(一)","summary":"Daniel Berman（ 产品经理）为了纪念Docker四岁生日，撰写一系列文章，介绍如何使用ELK收集和处理Dockerized环境日志。今天给大家带来的第一部分将介绍如何安装各个组件以及不同日志收集方案的特点，下一部分将侧重于分析和可视…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":0,"likesCount":0},"next":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-da152c05a176b70d2c4df_r.png","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"容器"},{"url":"/topic/","id":"","name":"Docker"},{"url":"/topic/","id":"","name":"IT 工程师"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"公众号：dmesos
","isFollowing":false,"hash":"b6e55e508edfdc4a88d6a28","uid":271400,"isOrg":false,"slug":"xiao-shu-42-5","isFollowed":false,"description":"公众号：dmesos，数人云——构建灵动新IT，最轻量级PaaS平台，热点聚焦云计算前言技术，开源动态，实践落地等，让分布式技术走出象牙塔。","name":"数人云","profileUrl":"/people/xiao-shu-42-5","avatar":{"id":"v2-0c26abf4fa749ad2a10e33","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},"column":{"slug":"shurenyun","name":"数人云"},"content":"导读：容器是这两年最热的一个话题，去年都在谈Mesos、Kubernetes、Swarm究竟哪家的挖掘技术强，今年容器技术的进一步普及，大家更关心容器技术如何落地，下面我们就基于一个实际的案例来聊一下容器落地遇到的问题。背景：某银行数据中心计划搭建一个基于容器的PaaS平台持续集成持续集成是容器一个绕不过去的话题，无论哪家容器厂商都一定会谈到，数人云关于持续集成，最开始用的是drone，一个小众的持续集成工具，将drone内置在平台上，通过平台的持续集成功能可以方便的实现持续集成的配置和管理。drone 的坑一开始我们觉得这是一个很好的工具，但是后来发现其实没有想象中的那么美好，它的问题：对SVN的支持不好容易出问题，因为数人云平台所有的组件都是容器化的，所以若使用drone，则需要使用docker-in-docker技术，但是该技术已经是一个不再被维护的技术了，所以继续使用的风险很大。Jenkins是个好工具Jenkins是一个好工具，功能强大且稳定，基于Jenkins实现的持续集成基本没有花费什么开发的时间，通过脚本将代码构建和平台连接在一起即可轻松实现CI/CD。总结往往用户需要的并不是那些看起来很酷的功能，真正需要的是能够实际解决问题的方案，即使这个方案很普通。配置管理在我看来，容器是一个革命性的产物，改变了软件交付的方式，它开箱即用的特性消灭了程序员常说的一句话 “在我这里运行时正常的啊！”； 它快速部署，环境无关的特性帮助运维人员提高了工作效率，但是任何事情都有其两面性，它的开箱即用，环境无关带来好处的同时，也带来了问题——配置文件。传统应用在容器时代面临的第一个问题一般而言，每个程序都会有一个或多个配置文件，里边记录着DB地址、账号、密码、缓存地址等信息，在容器时代之前，应用程序一般的流转方式是“从开发-&测试-&生产”：开发同学交付一个编译之后的二进制文件，源文件（解释执行）或者代码仓库中某一个tag，同时附带一个release notes；测试同学拿到开发同学交付的内容后，就将其部署在自己的测试环境中，如果release notes中说明了有配置信息需要更新或依赖文件版本需要升级，会依照文件进行调整；如果测试通过，确定可以投产，那么就将其交付给运维同学进行生产部署。此时有一个问题，开发、测试、运维每个环节都会自己维护配置文件，如果使用了容器，那么配置文件管理就是很麻烦的问题了，因为配置文件被放到了容器里，若想修改配置文件就不是那么简单的事情了，所以这就是传统应用在容器化时面临的第一个问题，当然这个问题也不是不能解决，一般而言，有以下几种解决方案：挂盘，将配置文件放到外部存储中，然后将该目录挂到容器中；生成新的镜像，基于Docker文件系统的特性，使用测试环境的配置文件覆盖开发环境的镜像，从而得到测试环境的镜像，同理，使用生产环境的配置文件覆盖开发环境的配置文件得到生产环境的镜像，使用该方案会导致每个环境都有一个镜像。容器时代配置管理的正确打开方式以上分析了传统应用容器化基本都会遇到的一个问题，而且也没有给出很好的解决方案，下面我们来谈下容器化时代配置管理的正确打开方式。其实通过上面问题的描述，我们可以很容易的找到问题的根本原因：配置文件本身是一个本地存储状态，要对其做无状态改造，对于配置管理的无状态改造一般是通过配置中心来完成的，即应用通过配置中心获取配置信息，无需读取本地配置文件，但是这个问题更麻烦，要解决这个问题需要首先解决两个问题：要先有个配置中心要改代码，使其可以适配配置中心随着容器的普及，未来配置中心肯定会逐渐成为程序的标配。最终选择的解决方案关于容器时代配置文件的问题，上边大概提到了3种方案，在最终落地的时候选择的是哪一种呢？答案是第二种——生成新的镜像。这是一个很保守的方案，为什么没有选择另外两种呢？ 我们来解释下原因：方案一[挂盘]， 这个方案会给容器产生另外一个状态，外部文件，不符合cloud 的思想，pass；方案三[配置中心]，成本太高，周期太长，而且需要改代码，往往之前的应用已经被维护了很多年，修改其配置接口，风险太大。总结虽然这个选择从技术上来看很保守，但是个人认为，使用一个不太优雅的方案帮助一个新技术快速落地，然后推动其快速前进，比一直纠结于方案是否高大上，是否优雅等，而导致新的技术一直被悬在空中更好，就像大家一直在争论Mesos、Kubernetes、Swarm究竟哪个更好，现在也没有一个结论，与其争论这么多虚的，不如仔细想一下自己的问题是什么，究竟哪个技术更适合自己。日志目前使用ELK作为日志方案。传统应用的坑一般而言，传统的应用都是把日志写到一个指定的路径下，然后通过Logstash采集日志并送入Elasticsearch进行存储，但是这种应用如果直接容器化之后就会带来一个问题——应用的日志文件应该如何存储。方案一：放到容器里方案二：挂盘，写到外部存储上两种方案都有一些问题：放到容器里，逻辑上最简单，不需要做任何改动，但是它的问题是，怎么从容器中把日志取出来。通过挂盘，把容器日志写到外部存储，然后沿用传统的Logstash + ES 的方式处理日志，听起来很美好，但是如何建立容器和日志的对应关系？容器时代日志的正确打开方式按照之前的惯例，我们先提出在容器时代，日志的正确处理方式，如果应用使用Docker进行交付，不建议写日志文件，直接将日志写入标准输出即可，然后Logstash通过Docker的log-driver捕获日志，这样日志文件既不需要落盘，也使日志文件摆脱了状态，可以更容易的横向扩缩。最终选择的解决方案最终我们实现的是方案三，因为用户在我们的建议下，选择了将日志输出到标准输出。新的问题写日志的目的是为了看的，这是一个无比正确的废话，但是如何实时的看到需要的日志却成了我们面临的一个新问题。在容器时代之前，我们一般是通过tail来实时的看日志或者通过Kibana来分析日志。在容器的时代，通过Kibana看日志的方式没什么变化，但是看实时日志就有了一些问题，在用户采取了我们的建议将日志写入标准输出后可以比较优雅的处理日志了，但是另外一个问题出现了，实时日志没有了，因为日志已经被log-driver收走了，怎么办？虽然依然可以从ES中找到日志，但是由于ELK本身的机制，不能通过ELK看到实时日志。新的解决办法新的问题，需要新的办法来解决，如何解决，其实说穿了也简单，实现了一个log-agent的功能，可以将日志送到两个地方，Logstash和实时日志。总结事情就是这样，我们以为解决了一个问题的时候，往往一个新的问题又摆在前面，像容器落地这种事情，对传统应用的整体工作方式和流程都有很大的冲击，所以一定也会遇到同等规模的问题需要解决。监控银行对监控是非常重视的，尤其是运维部门，所以为了满足客户的需求，我们实现了：平台自身监控宿主机监控中间件监控监控本身是我们平台很重要的一个部分，但是在实际实施过程中发现，客户其实不是很在意做的监控页面，仪表盘等监控数据，他们自身有健全的监控平台，其实我们需要做的事情就是将我们的数据吐到他的平台上即可。总结世事难料，你永远不知道下一块巧克力什么味道，这个我们自身投入了很大精力和时间来实现的功能在用户那里就变成了一个对接的任务。弹性扩缩弹性扩缩一直是容器厂家喜欢谈的一个口号，曾经有一度我们认为基于Docker的特性来实行弹性扩缩是一件很容易的事情，但是后来发现，这里其实有一个大坑。扩很容易，缩很难弹性扩容是一件比较容易的事情，我们只要对接监控数据，然后配置一些规则，即可触发应用容器个数增加，实现扩容，但是缩容就会面临几个问题：什么时候缩容？如何安全的缩容？什么时候缩容，这个问题相对来说还不是特别麻烦，可以设定一个指标，比如CPU，内存，IO等指标来触发缩容，这里只要做一些带有缓冲的规则，避免由于规则简单而导致的扩缩抖动即可。如何安全的缩容相当麻烦，缩容在本质上是要停掉一些容器的，如何判断这个容器是可以停止的，如果一个容器没有流量了，那么应该是可以被停止的，如何让一个容器的流量停止？可以通过前端负载进行控制，不往这个容器分发流量，那么前端的负载是如何判断应该如何往后端分发流量呢？这个有多重因素：自身算法应用程序本身是有状态的，需要保持会话从以上简单的分析中我们可以发现，缩容不是简单的条件符合了就可以做的事情，要想在不影响业务的情况下实现缩容，是一件非常麻烦的事情，它与平台架构，运行的程序的业务逻辑有很深的耦合。总结要实现自动的扩缩容，不是一件简单的事情，而是一个系统的工程。以上内容是基于数人云在某银行实施过程中总结出来的一些感悟，如果能给大家一些帮助，我们非常高兴，如果有问题，请指出来，我们共同提高，Docker到现在大概有3年多的历史，个人看来它距离真正落地还有很大一段路程要走，我们必须不停的摸索。欢迎关注同名专栏扫码关注公众号，获得更多姿势aHR0cDovL3dlaXhpbi5xcS5jb20vci9nMHpidzlERWRvMEpyWlNnOXhtUg== (二维码自动识别)","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T19:23:30+08:00","url":"/p/","title":"实践 | 一个案例思考容器落地的山高路远坑深","summary":"导读：容器是这两年最热的一个话题，去年都在谈Mesos、Kubernetes、Swarm究竟哪家的挖掘技术强，今年容器技术的进一步普及，大家更关心容器技术如何落地，下面我们就基于一个实际的案例来聊一下容器落地遇到的问题。背景：某银行数据中心计划搭建一个基于容…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":0,"likesCount":0}},"annotationDetail":null,"commentsCount":0,"likesCount":0,"FULLINFO":true}},"User":{"xiao-shu-42-5":{"isFollowed":false,"name":"数人云","headline":"公众号：dmesos，数人云——构建灵动新IT，最轻量级PaaS平台，热点聚焦云计算前言技术，开源动态，实践落地等，让分布式技术走出象牙塔。","avatarUrl":"/v2-0c26abf4fa749ad2a10e33_s.jpg","isFollowing":false,"type":"people","slug":"xiao-shu-42-5","bio":"公众号：dmesos
","hash":"b6e55e508edfdc4a88d6a28","uid":271400,"isOrg":false,"description":"公众号：dmesos，数人云——构建灵动新IT，最轻量级PaaS平台，热点聚焦云计算前言技术，开源动态，实践落地等，让分布式技术走出象牙塔。","profileUrl":"/people/xiao-shu-42-5","avatar":{"id":"v2-0c26abf4fa749ad2a10e33","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false,"badge":{"identity":null,"bestAnswerer":null}}},"Comment":{},"favlists":{}},"me":{},"global":{},"columns":{"shurenyun":{"following":false,"canManage":false,"href":"/api/columns/shurenyun","name":"数人云","creator":{"slug":"xiao-shu-42-5"},"url":"/shurenyun","slug":"shurenyun","avatar":{"id":"v2-7dc2d9f6b5643c06ceaf77","template":"/{id}_{size}.jpg"}}},"columnPosts":{},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldAddVideo":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"drafts":{"draftsList":[]},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"isAppView":false,"appViewConfig":{"content_padding_top":128,"content_padding_bottom":56,"content_padding_left":16,"content_padding_right":16,"title_font_size":22,"body_font_size":16,"is_dark_theme":false,"can_auto_load_image":true,"app_info":"OS=iOS"},"isApp":false},"sys":{}}