著者|エチレンアリクラウドロギングサービスクライアントは、現在のグループlogtail規模展開で百万クライアントを収集しているデータの収集を担当して、アプリケーションのPBの数は多くの時間が、二重の12のテストをダブル11を経験し、日々データの数千人を集めます。
REVIEW： K8S常に更新の繰り返しで、K8Sロギングシステムの構築の現像液を用いて、徐々に複雑な問題や課題の様々な遭遇。この記事では、著者は分析K8Sは、システム構築の難しさを記録し、読者のために有益な基準を提供する楽しみ、経験の彼の多くの年を兼ね備えています。
昨年、数年間のログシステムKubernetesを構築する方法についてのより多くの学生のアドバイスをこれを行うにはログイン、またはどのプロセスで解決するために一連の問題を満たすために、与えるよりも、魚に人々を教えます学生は回り道を避けることができるように、私たちが記事に発行された形で蓄積された経験のこれらの年を望んでいた魚に男は、こちらの記事を参照してください。記事のこのシリーズは、実際の運用と経験の共有を落ちる傾向にある彼のシリアル、コンテンツとして位置付けされ、コンテンツは反復技術と、頻繁に更新しています。
序文
私は名前Kubernetesを聞いた最初の時間が原因での利益の範囲（スケーラビリティ、宣言型のインターフェイス、クラウドフレンドリー）に、まだKubernetesとドッカースウォームで、その時点で、2016年に「三国時代」Mesosプログラム、Kubernetesました新興、最終的に優位で競争。
プロジェクトCNCF（誰）のコアとしてKubernetes、クラウドネイティブ（クラウドネイティブ）着陸ベース、現在はベースKubernetesアリは完全に1〜2年で、クラウドネイティブの駅の改修工事で実施されているされて、アリババは100％事業は、パブリッククラウドで実行されます。
中CloudNative 定義CNCFコアがある：パブリッククラウド、プライベートクラウド、ハイブリッドクラウド環境などコンテナサービスメッシュ、MicroServices、不変のインフラストラクチャによって、として 、宣言のAPI 、管理が容易な弾性的に伸長をビルドして実行すると、高い耐障害性を持っています疎結合のアプリケーションでは、観察することができます。可観測は、アプリケーションシステムの不可欠な一部であり、クラウドの設計思想は、ネイティブがあります：診断、設計用（診断性）、クラスタレベルのログ、メトリックおよびトレースを含みます。
なぜ我々は、システムログが必要なのか
ログの特定の位置に応じて、位置決め問題トレースモジュールによれば、理由モジュールメトリックで問題を識別：通常の問題は、位置決めプロセスラインです。トラブルシューティングの中核である情報の誤り、などのログ・パスで実行するコードなどの重要な変数を、含み、ログは常にトラブルシューティングパスを通過するラインです。
10年にはアリ、連続進化の形でコンピューティング・システムの開発とログは、大きく3つの主要な段階に分け：
- サービスの圧力が上昇するが、唯一のIBMのミニコンピュータの高い標準を切り替えると、スタンドアローンの時代では、ほとんどすべてのアプリケーションは、スタンドアロン展開されています。通常、他のLinux一般的なテキストgrepコマンド解析と連動して、アプリケーションシステム、主に使用され、デバッグプログラムの一環としてログオンします。
- 随着单机系统成为制约阿里业务发展的瓶颈，为了真正的 Scale out，飞天项目启动：2013 年飞天 5K 项目正式上线。在这个阶段各个业务开始了分布式改造，服务之间的调用也从本地变为分布式，为了更好的管理、调试、分析分布式应用，我们开发了 Trace（分布式链路追踪）系统、各式各样的监控系统，这些系统的统一特点是将所有的日志（包括 Metric 等）进行集中化的存储；
- 为了支持更快的开发、迭代效率，近年来我们开始了容器化改造，并开始了拥抱 Kubernetes 生态、业务全量上云、Serverless 等工作。在这阶段，日志无论从规模、种类都呈现爆炸式的增长，对日志进行数字化、智能化分析的需求也越来越高，因此统一的日志平台应运而生。
可观察性的终极解读
在 CNCF 中，可观察性的主要作用是问题的诊断，上升到公司整体层面，可观察性（Observability）不仅仅包括 DevOps 领域，还包括业务、运营、BI、审计、安全等领域，可观察性的最终的目标是实现公司各个方面的数字化、智能化。
在阿里，几乎所有的业务角色都会涉及到各式各样的日志数据，为了支撑各类应用场景，我们开发了非常多的工具和功能：日志实时分析、链路追踪、监控、数据加工、流计算、离线计算、BI 系统、审计系统等等。日志系统主要专注于数据的实时采集、清洗、智能分析与监控以及对接各类各样的流计算、离线系统。
Kubernetes 日志系统建设难点
单纯日志系统的解决方案非常多，相对也比较成熟，这里就不再去赘述，我们此次只针对 Kubernetes 上的日志系统建设而论。Kubernetes 上的日志方案相比我们之前基于物理机、虚拟机场景的日志方案有很大不同，例如：
- 日志的形式变得更加复杂，不仅有物理机/虚拟机上的日志，还有容器的标准输出、容器内的文件、容器事件、Kubernetes 事件等等信息需要采集；
- 环境的动态性变强，在 Kubernetes 中，机器的宕机、下线、上线、Pod销毁、扩容/缩容等都是常态，这种情况下日志的存在是瞬时的（例如如果 Pod 销毁后该 Pod 日志就不可见了），所以日志数据必须实时采集到服务端。同时还需要保证日志的采集能够适应这种动态性极强的场景；
- 日志的种类变多，上图是一个典型的 Kubernetes 架构，一个请求从客户端需要经过 CDN、Ingress、Service Mesh、Pod 等多个组件，涉及多种基础设施，其中的日志种类增加了很多，例如 K8s 各种系统组件日志、审计日志、ServiceMesh 日志、Ingress 等；
- 业务架构变化，现在越来越多的公司开始在 Kubernetes 上落地微服务架构，在微服务体系中，服务的开发更加复杂，服务之间的依赖以及服务底层产品的依赖越来越多，这时的问题排查将更加复杂，如果关联各个维度的日志将是一个困难的问题；
- 日志方案集成困难，通常我们都会在 Kubernetes 上搭建一套 CICD 系统，这套 CICD 系统需要尽可能的自动化的完成业务的集成和部署，其中日志的采集、存储、清洗等也需要集成到这套系统中，并和 K8s 的声明式部署方式尽可能一致。而现有的日志系统通常都是较独立的系统，集成到 CICD 中代价极大；
- 日志规模问题，通常在系统初期的时候我们会选择自建开源的日志系统，这种方式在测试验证阶段或公司发展初期是没有什么问题的，但当业务逐渐增长，日志量增长到一定规模时，自建的开源系统很多时候都会遇到各种各样的问题，例如租户隔离、查询延迟、数据可靠性、系统可用性等。日志系统虽不是 IT 中最核心的路径，但一旦关键时刻出现这些问题都将是非常可怕的影响，例如大促的时候出现紧急问题，排查时多个工程师并发查询把日志系统打爆，导致故障恢复时间变长，大促收到影响。
相信在搞 K8s 日志系统建设的同学看到上面的难点分析都会深有感触，后面我们会从落地角度出发，详细介绍在阿里我们如何去搭建 K8s 的日志系统，敬请关注。
「アリババクラウドネイティブマイクロチャネルパブリック番号（ID：Alicloudnative）フォーカスマイクロサービスで、サーバレス、コンテナ、サービスメッシュ及び他の技術分野、クラウドネイティブで人気の技術動向を中心に、クラウドネイティブの大規模な着陸の練習は、ほとんどがクラウドネイティブ開発を理解してください技術公衆番号。」