mtail是谷歌开源的一款从应用日志提取metrics的工具，它会实时读取应用程序的日志，然后通过自己编写的脚本分析日志，最终生成时间序列的指标，项目地址是：https://github.com/google/mtail。夜莺的Categraf对日志指标的收集也是采用的mtail，不过做了一些优化，具体优化了什么我们慢慢道来。现在，我们先从谷歌的mtail开始聊起，再慢慢聊到夜莺的mtail插件。mtail的安装前面已经对mtail做了简短的介绍，其实那就是全部。所以，我们直接从安装开始。从https://github.com/google/mtail/releases下载需要的版本，操作如下
有没有人和我一样，遇到同样的困惑：当我使用Prometheus来搭建监控体系的时候，每当有一个组件需要监控，我就要为其增加一个exporter，如果有10个组件，我就要增加10个exporter，先不说这10个exporter的质量如何(因为大部分exporter都是广大网友自己开发的)，光学习成本、部署成本以及维护成本都让人头疼。有没有一个组件，就能搞定大部分指标采集的?Categraf就是这样的一个采集器。惊不惊喜，意不意外?什么是CategrfCategraf是一个监控采集Agent，类似Telegraf、Grafana-Agent、Datadog-Agent，希望对所有常见监控对象提供
categraf支持多种方式进行部署、托管，社区里部署和管理categraf也是五花八门，大家自己使用方便即可。之前我们觉得大家通过ansible之类的工具批量下发/更新就能很简单地完成任务，最近很多用户咨询我们关于categraf有没有更方便的升级方式，这也促使我们思考如何让用户更快捷方便地完成服务管理与升级。这两天我们发布了一个新版本，这里讲一下linux下的推荐方式，欢迎大家提ISSUE和PR。systemdsystemd是一个Linux系统下的系统和服务管理工具，它是Linux启动过程的第一个进程（PID=1），它用于管理整个系统的服务状态，包括进程控制、日志记录、系统状态跟踪等等。它
夜莺初探三·Categraf采集器前言github仓库文档中对Categraf有很详细的介绍，简单重复一下就是:支持多种数据格式的remote_write；All-in-one的设计理念，指标采集只需要一个agent完成，也计划支持日志和调用链路的数据采集；Go编写，依赖少，容易分发和安装；内置一些监控大盘和告警规则，用户可以直接导入使用；开源项目并由快猫研发团队持续迭代。特殊目录结构说明input采集插件基本都位于input目录下，并且有些采集器提供了通用的大盘（alters-xxx.json）和告警(dashbord.json)配置可以导入n9e直接使用（例如监控仪表盘中更多操作的批量导入
痛点市面上常见的采集器，比如telegraf、grafana-agent、datadog-agent等，通常内置了多种采集插件，比如可以采集操作系统的常规指标，也可以采集mysql、redis、mongodb、kafka、elasticsearch、jmx等指标，但是具体要采集什么数据，通常需要在客户端采集器上进行配置，修改采集器的配置文件，比较麻烦，尤其是对于一些不太容易登录的机器，这个操作就更难实现了。解决方案快猫技术团队开源了categraf采集器，在夜莺社区里得到广泛使用。categraf支持两种采集配置管理方式，一个是修改本地配置文件，一个是通过HTTP的方式从远端拉取。这就为中心端
一、Nightingale介绍： 1.1、Nightingale简介和架构图夜莺监控（Nightingale）是一款国产、开源云原生监控分析系统，采用All-In-One的设计，集数据采集、可视化、监控告警、数据分析于一体。于2020年3月20日，在github上发布v1版本，已累计迭代60多个版本。从v5版本开始与Prometheus、VictoriaMetrics、Grafana、Telegraf、Datadog等生态紧密协同集成，提供开箱即用的企业级监控分析和告警能力，已有众多企业选择将Prometheus+AlertManager+Grafana的组合方案升级为使用夜莺监控。夜莺监控
一、Nightingale介绍： 1.1、Nightingale简介和架构图夜莺监控（Nightingale）是一款国产、开源云原生监控分析系统，采用All-In-One的设计，集数据采集、可视化、监控告警、数据分析于一体。于2020年3月20日，在github上发布v1版本，已累计迭代60多个版本。从v5版本开始与Prometheus、VictoriaMetrics、Grafana、Telegraf、Datadog等生态紧密协同集成，提供开箱即用的企业级监控分析和告警能力，已有众多企业选择将Prometheus+AlertManager+Grafana的组合方案升级为使用夜莺监控。夜莺监控
上一篇我们介绍了如何监控Kube-Proxy，Kube-Proxy的/metrics接口没有认证，相对比较容易，这一篇我们介绍一下Kubelet，Kubelet的监控相比Kube-Proxy增加了认证机制，相对更复杂一些。Kubelet端口说明如果你有多台Node节点，可以批量执行 ss-tlnp|grepkubelet 看一下，Kubelet监听两个固定端口(我的环境，你的环境可能不同)，一个是10248，一个是10250，通过下面的命令可以知道，10248是健康检查的端口：[root@tt-fc-dev01.nj~]#psaux|grepkubeletroot1634900.00.0121
简介首先，请阅读文章《Kubernetes监控手册01-体系介绍》，回顾一下Kubernetes架构，Kube-Proxy是在所有工作负载节点上的。Kube-Proxy默认暴露两个端口，10249用于暴露监控指标，在 /metrics 接口吐出Prometheus协议的监控数据：[root@tt-fc-dev01.njlib]#curl-shttp://localhost:10249/metrics|head-n10#HELPapiserver_audit_event_total[ALPHA]Counterofauditeventsgeneratedandsenttotheauditbacke
上一篇我们介绍了如何监控Kube-Proxy，Kube-Proxy的/metrics接口没有认证，相对比较容易，这一篇我们介绍一下Kubelet，Kubelet的监控相比Kube-Proxy增加了认证机制，相对更复杂一些。Kubelet端口说明如果你有多台Node节点，可以批量执行 ss-tlnp|grepkubelet 看一下，Kubelet监听两个固定端口(我的环境，你的环境可能不同)，一个是10248，一个是10250，通过下面的命令可以知道，10248是健康检查的端口：[root@tt-fc-dev01.nj~]#psaux|grepkubeletroot1634900.00.0121
