Logtail从入门到精通(三):机器分组配置

本文涉及的产品
对象存储 OSS,20GB 3个月
阿里云盘企业版 CDE,企业版用户数5人 500GB空间
对象存储 OSS,内容安全 1000次 1年
简介: 基于集团内数年来的Agent运维经验总结,我们设计了一种灵活性更高、使用更加便捷、耦合度更低的配置&机器管理方式:自定义标识机器分组。此种方式对于动态环境非常适用,尤其适用于弹性伸缩服务和swarm、pouch(阿里docker)、Kubernetes等容器环境。

什么是机器分组


上一篇中我们对机器分组进行了简单的介绍,从更通俗的角度讲:机器分组就是一批产生相同日志的机器,一般情况下是一组应用,比如Nginx、MongoDB、HDFS等集群。通常一个机器分组下会产生多种日志,会分别采集到多个logstore。而同时一个机器也可以扮演多种角色(比如同时担当前端和后端的角色,既部署了Nginx也部署了应用worker),因此一个机器也会属于多个机器分组中。所以我们有了以下的机器分组模型:


c4550e27-6622-4349-ba39-dda308b91539.png


机器分组类型


目前我们支持了两种不同的机器分组,分别是IP标识和自定义标识分组。


IP标识机器组


IP标识的机器组通俗易懂,非常易于上手,只需简单的将IP输入到分组里即可完成配置,同时也支持一个分组里面输入多个IP。


c3aa2deb-ef35-4d5e-94f2-0f42834d3d84.png


IP标识的机器组虽然配置简单,但存在非常大的缺陷:不支持动态缩扩容。在实际使用中机器组中机器经常会发生变化(例如机器替换、服务扩容/缩容),尤其在使用弹性伸缩服务、Kubernetes容器服务更为明显,如果没有及时同步更新或忘记配置,新增加的机器便无法采集到日志。


自定义标识机器组


基于集团内数年来的Agent运维经验总结,我们设计了一种灵活性更高、使用更加便捷、耦合度更低的配置&机器管理方式:自定义标识机器分组。


自定义标识机器分组操作非常简单:机器上设置一个或多个标识,并把机器组配置为自定义标识类型(userdefined-id),输入相应的标识,机器组即会自动匹配。


此种方式对于动态环境非常适用,尤其适用于弹性伸缩服务和swarm、pouch(阿里docker)、Kubernetes等容器环境。只需在虚拟机镜像、DockerFile或Kubernetes的yaml模板等提前配置好标识,后续扩容的机器一上线就会立即加入到对应的机器分组中,并根据对应机器分组上的采集配置开始工作。


使用方式


详细使用方式参见自定义标识机器组


步骤一 本地配置


  • Linux Logtail


通过文件 /etc/ilogtail/user_defined_id 来设置userdefined-id。


例如,设置自定义机器标识如下:


cat /etc/ilogtail/user_defined_id
k8s-demo


  • Windows Logtail


通过文件 C:\LogtailData\user_defined_id 来设置userdefined-id。


例如,设置自定义机器标识如下:


C:\LogtailData>more user_defined_id
k8s-demo


注意: 若目录 /etc/ilogtail/C:\LogtailData或文件 /etc/ilogtail/user_defined_idC:\LogtailData\user_defined_id不存在,请手动创建。


  • Docker 应用


如果您在容器中安装Logtail,可以在DockerFile中使用以下方式在发布时配置标识:


RUN mkdir /etc/ilogtail/
RUN echo ${您的机器组自定义标识} > /etc/ilogtail/user_defined_id


  • Kubernetes 集群


K8S使用可以参见Kubernetes日志采集


步骤二 创建自定义标识机器组


  1. 在机器组列表页面单击右上角的创建机器组。
  2. 填写机器组配置。
  • 机器组名称。填写自定义的机器组名称。
  • 机器组标识。选择用户自定义标识。
  • 用户自定义标识。填写步骤一中配置的userdefined-id,例如k8s-demo
  1. 单击确认结束配置。后续扩容无需修改机器组。


60915910-9376-4fdf-900f-6d884a20d434.png


步骤三 查看机器组心跳


在机器组列表页面,单击目标机器组右侧的查看状态,可以查看使用相同自定义标识的机器列表及其心跳状态。


7fbbbbad-6978-4654-ab5c-18042aa0104f.png

若有收获,就点个赞吧

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
Prometheus Cloud Native 网络协议
prometheus专题—(十三) proemetheus多实例采集
文档:https://prometheus.io/docs/guides/multi-target-exporter/
848 0
prometheus专题—(十三) proemetheus多实例采集
|
8月前
|
存储 数据采集 Kubernetes
一文详解K8s环境下Job类日志采集方案
本文介绍了K8s中Job和Cronjob控制器用于非常驻容器编排的场景,以及Job容器的特点:增删频率高、生命周期短和突发并发大。文章重点讨论了Job日志采集的关键考虑点,包括容器发现速度、开始采集延时和弹性支持,并对比了5种采集方案:DaemonSet采集、Sidecar采集、ECI采集、同容器采集和独立存储采集。对于短生命周期Job,建议使用Sidecar或ECI采集,通过调整参数确保数据完整性。对于突发大量Job,需要关注服务端资源限制和采集容器的资源调整。文章总结了不同场景下的推荐采集方案,并指出iLogtail和SLS未来可能的优化方向。
|
7月前
|
运维 监控 Serverless
函数计算产品使用问题之如何配置YAML以自动打开日志功能
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
8月前
|
网络协议 Shell
Ansible 学习笔记 - 定位主机和组的模式
Ansible 学习笔记 - 定位主机和组的模式
|
监控 Linux 应用服务中间件
【Zabbix_6.x 第三章】 监控任意主机(下)
【Zabbix_6.x 第三章】 监控任意主机(下)
114 0
|
监控 Windows
【Zabbix_6.x 第三章】 监控任意主机(上)
【Zabbix_6.x 第三章】 监控任意主机(上)
147 0
|
消息中间件 存储 Java
RabbitMQ——发布确认高级 & 备份交换机的概念理解及应用举例
RabbitMQ——发布确认高级 & 备份交换机的概念理解及应用举例
RabbitMQ——发布确认高级 & 备份交换机的概念理解及应用举例
|
JSON 监控 Java
zabbix精华篇-低级自动发现详解---批量自动获取主机所有tomcat端口并进行监控(二十四)
zabbix利用低级自动发现自动监控tomcat端口 1.为什么要使用自动发现 由于我们tomcat服务器特别多,且每一个上面跑的实例长达几十个,但是这些tomcat的端口也都需要监控起来,如果手动添加的话将会非常麻烦,我们可以利用自动发现,将自动发现配置一些规则并做成模板,给有tomcat的服务器链接模板就可以了,这个过程就会大大减少人工的工作量
542 0
zabbix精华篇-低级自动发现详解---批量自动获取主机所有tomcat端口并进行监控(二十四)
|
Cloud Native Prometheus 容器
带你读《Prometheus监控实战》之三:安装和启动Prometheus
本书首先从监控体系讲起,介绍了关于监控的各种经典理论和方法。然后循序渐进地介绍了Prometheus的各个功能组件和配置方法,包括监控主机和容器、服务发现、警报管理,以及Kubernetes和运行其上的应用程序的监控。
|
监控 Kubernetes Docker
从零开始搭建K8S--如何监控K8S集群日志
架构选择(ELK VS EFK) ELK 我们首先介绍一下传统的日志监控方案。其中,ELK Stack 是我们最熟悉不过的架构。所谓ELK,分别指Elastic公司的Elasticsearch、Logstash、Kibana。
3259 0